Originally Posted by JackRyan
For asynchronous USB interfaces such as the E-MU 0404, it should not be succeptible to differences in USB cables as it operates an independent internal clock for the audio stream, rather than referencing the USB data frames directly or indirectly. Therefore, I would argue that any jitter at the SPDIF output of the 0404 is caused by the SPDIF output parts or circuit design. Even with the jitter, however, I would imagine a properly designed DAC that contains the proper reclocking circuitry should not have any issues at all.
I have decided to not adress trolls anymore, but this post will give me the opportunity to explain something that I haven't addressed before.
In the wonderland/digital dream world that some people seem to be living in a device such as the EMU 0404 usb is perfect.
It has been said that emu 0404 usb is an async device. However, putting the clock on the usb device doesn't mean that they have used an error check protocol.
As I said earlier, I have generated the following test under the same conditions and using a low latency setting:
cable A: drop-outs
cable B: no drop-outs
In fact, I didn't think of the test by myself, it just happened that I realized (after upgrading the usb cable) that I could use lower latency settings without crackles and pops.
So if it were un-affected by the USB cable why would I hear differences and why would I generate a test where even a causual listener can here the drop outs/crackles and the absence of those.
My listening tests concerning the EMU 0404 usb (vs. other converters) has been confirmed by Stereophile measurements.
Stereophile measured 8ns of jitter on the emu. On the same test, the M-Audio Transit has only 2ns.
The EMU 0404 usb is far from the perfect converter that would not be affected by the usb cable.
Here are some conditions/suggestions for an async converter, to be completely
independant from the usb cable.
1. It has to be galvanically isolated from the computer (not draw power from the computer)
2. It has to use good drivers that allow for error check and resending for lost data in the transmission
3. It has to use a large buffer inside in order to smooth the operation and not starve for data in case of momentary CPU spikes/overloads.AGAIN, if you have any usefull information on how to improve the listening experience, you are welcome to post in this thread.
On the other hand, if you are just going to say that such or such is not audible, we really don't care about it.