Are all Asynchronous USB chips/implementations created equal??

[MLGrado]

Are all Asynchronous USB chips/implementations created equal??


Or not? In theory, Asynchronous USB should eliminate ALL interface jitter. On paper, it should be the end all cure of interface jitter. The Master clock is in control of flow from the computer. Data is downloaded into a buffer to eliminate any variations in flow that may have occurred either in the computer or the USB cable. The Master clock then takes the data directly from the buffer in perfect time. The only issue it seems would be flow control and potential overrun or underrun when the computer clock doesn't want to play nicely. A larger buffer would seemingly be all that is needed to account for all but the very worst of deviations.

But, the problem is, in practice this doesn't seem to be the case. WHY? I don't know why, and hence the reason I am positing the question. And furthermore, why do DAC manufactures INSIST on placing further jitter reduction technology such as a second buffer or an ASRC?? It should not be necessary with an asynch. setup as I just described.

I am brought to this question by this little iFi iDSD Nano I just purchased. It has technology and programming code trickled down from Abbingdon Music Research. It has an XMOS Asych USB controller presumably with custom code written by AMR. But then, they add what would be seemingly redundant, a second jitter elimination system. It is a buffer that essentially acts as a digital PLL, clocking the data at an average rate of the input and making adjustments as necessary. WHY? There should be no interface jitter after the asynch. USB receiver! To me it seems that this could only make the jitter worse, as you just made the master clock right before the DAC a variable clock. Even if it varies very little (or not at all) the intrinsic jitter of such a clock would be higher than a truly fixed oscillator master clock.

Interestingly enough, the iFi iDSD's big brother, the AMR DP-777, actually does measure higher jitter numbers over asynchronous USB than SPDIF with the "Zero Jitter" mode I just described. Actually, the overall jitter numbers of any input on that device is relatively poor compared to the current state of the art. (Stereophile measurements)

Furthermore, other manufactures seem content to add further jitter reduction after their Asynch. USB interface. One that immediately comes to mind is Emotiva. On the other hand, Benchmark has bypassed its trademark ASRC jitter reduction in its latest DAC when using Asynchronous USB. They acknowledge that there is no need for further jitter reduction.


So, experts, can you tell me... why do asynchronous USB interfaces that should have little to no interface jitter because of the buffer need to have further jitter reduction? Am I missing something? Or are all Asych. USB interfaces not created equal???

With great curiosity...

Andrew

 

[merrillaudio]

The same question would result from different uses of USB cables. I don't know the answer, however if one USB cable is missing bits compared to the other, would computers be losing bits and all the information on the computer be wrong? However dependable sources have said the USB cable makes a difference in sound. I understand that in playback timing, i.e. jitter, is critical. If all the information is stored in memory and reclocked, the timinig should be good an anything prior to that will not/should not matter. I have not had the time yet to investigate this and if anyone has info on this, that will be great.

 

[ar-t]

No. Period.


OK...............why? Code is a big part of it, says the guy who knows nothing about code, but knows folks who do.

 

[jkeny]

Yes, in theory an input buffer into which the data is read followed by an independent local clock, clocking that data out should be immune to upstream influences, one would imagine. But this scheme is only separating the timing of the input data from the timing of the data further downstream - it is not isolating input noise from the system downstream. It is also not isolating the system from a possible issue - where the quality of the input signal can result in the receiver chip working harder to retrieve this data. This harder work may give rise to more fluctuating PS current draws & more fluctuating ground noise - all of which can have an affect on the audio handling chips downstream.

So, not just data isolation but power plane isolation is also needed.

This applies to USB, SPDIF or any system that is retrieving data in real-time for audio use

 

[Alrainbow]

Data transport is perfect , it has to be as no CPU would function if not.
The real situation in jitter is more electrical noise and not clock jitter. Better USB cables matter as they shield and lower the noise level. The USB input on mNy dacs is the part that causes the jitter not the dac inside and not the cpu . Although the noise coming from the CPU is causing it. What we need to understand is audio is a continuos data string and any all delays cause the sound to change badly. This is what jitter is. We as humans are very sensitive to time changes in sound from one detail to the next. It is our hearing that makes the determination in sound quality . A product like offramp 5 lowers the noise and does have a internal clock as well that might be lower than your dacs. But irs the electrical noise that his device lowers as well. This proves to me when I use it with almost any dac it is much better and closer to perfection. The same thing is done with the AP1/PP. Reading specifications from a company is misleading at best.

Al

 

[ar-t]

OK, whatever...............

 

[jkeny]

Jocko,
(My reply from the land of rotten potatoes as you say)
Just saying "Code is a big part of it" doesn't help to explain anything to the OP
If you mean that the digital data is changed in value because of the code then I suspect that you are wrong.
If you are suggesting that the code alters something else in the datastream, then what is that something else?