[linuxworks]

spdif is great. but what if you wanted to GET to spdif VIA usb? laptops and things that don't allow for pci/e/etc cards.

so, usb comes into it a lot since its a common and fast interconnect. its fast enough so that it could send and keep buffers full at the remote end and have that end clock data out 'properly' from its local deep buffers. that would make the interconnects entirely and completely irrelevant (as they should have been, all along, sigh).

the best data model, I think, is to follow a networking model where timing only matters at the very last stage and the hop *to* that stage is also irrelevant, as long as all the data gets there and has enough buffering to do local playback from local clocks. that way, all the paths up to that point become go/noGo and not quality limiting points. to have to worry about jitter and signal timing at many hops, that just seems wrong (and inefficient) to me.

 

[qusp]

Quote:

Originally Posted by AndrewFischer /img/forum/go_quote.gif This might be a stupid question, but why not use S/PDIF if you want more than 44.1kHz and 16-bit? Many computers have some sort of S/PDIF connector. The iMac I'm using at the moment has a mini TOSLINK connectors twinned with the analog headphone and microphone jacks. As I recall (correct me if I'm wrong) current macs support 96KHz 24-bit 2-channel in and out with the on-board connectors as well as 5.1 out.

errmm yeah not sure why you thought you needed to mention that. I already have my dacs running via AES (balanced transport protocol for spdif) and BNC spdif fed from my Mac-> RME 9632 (upgraded power supply caps and line drivers)->custom breakout cable with solderless connectors->MUX->i2s->DAC. but as Linuxworks mentions, the cable and receiving chain of command results in jitter always in this way, lowish if done right, but still something to worry about because there is not the buffering and bandwidth of USB or ethernet.

linuxworks explained all that rather well, so I dont really have anything to add there, but lets say being a cable guy I know some of the issues and I would rather not have them. funny a cable guy wanting for the industry to make part of his revenue irrelevant, but hey i'm an end user too.

oh and optical is the worst of them due to having the extra conversions along the way, nicely isolated, but causes more problems than it solves IMO and certainly not capable of 8 x 24/192. optical USB is another one thats kinda interesting

 

[CodeToad]

"I would not quite trust this since it includes some BD stuff. BD is evil (ie, non-open and very anti consumer)."

Sorry to interject but this needs as many eyeballs as possible.

Anti-Counterfeiting Trade Agreement | Electronic Frontier Foundation

Copy protection and DRM inside your OS. DRM chips in your motherboard. HDMI, HDCP, BluRay etc. You gotta wonder if at some point everything will be cloud based and everything single action you do will be Pay-Per-View. (The Temples of Syrinx may be here sooner than 2112)

Now is a good time to start an open source transport project

 

[digger945]

Quote:

Originally Posted by linuxworks /img/forum/go_quote.gif spdif is great. but what if you wanted to GET to spdif VIA usb? laptops and things that don't allow for pci/e/etc cards. so, usb comes into it a lot since its a common and fast interconnect. its fast enough so that it could send and keep buffers full at the remote end and have that end clock data out 'properly' from its local deep buffers. that would make the interconnects entirely and completely irrelevant (as they should have been, all along, sigh). the best data model, I think, is to follow a networking model where timing only matters at the very last stage and the hop *to* that stage is also irrelevant, as long as all the data gets there and has enough buffering to do local playback from local clocks. that way, all the paths up to that point become go/noGo and not quality limiting points. to have to worry about jitter and signal timing at many hops, that just seems wrong (and inefficient) to me.

Your logic has already been implemented in things like the Genesis Digital Lens and others, where the continuous spdif stream from the transport to the dac is stored and resent, not much different than a USB to spdif converter that takes the individual USB packets and then resends them in continuous spdif format. This is something that I think sets products from Weiss* and Berkeley Audio Design apart from the others in that they make use of this logic of reclocking at the last possible stage before the dac chip itself. You would think that going async would then be unnecessary and not needed, but much reading, and recent experiments of my own, has shown that async makes a pretty sizable impact on the quality of the end analog sound.

Quote:

Originally Posted by qusp /img/forum/go_quote.gif oh and optical is the worst of them due to having the extra conversions along the way, nicely isolated, but causes more problems than it solves IMO and certainly not capable of 8 x 24/192. optical USB is another one thats kinda interesting

While optical may be limited by the current hardware configurations that we must use now, the fiber itself is capable of 1000x the transmission rate and immune to EMI and RF interference. I've found nothing in my research to indicate that it would be susceptible to reflections or harmonics like wire coax.


For my next experiment I would like to try something wireless from the computer to the dac. Not enough time and money to do it all right now. Right now I'm on the prowl for other async converters/dacs to listen to.

*The Weiss stuff I refer to like the Minerva and DAC2 use firewire.