00940
Headphoneus Supremus
- Joined
- Nov 6, 2002
- Posts
- 4,493
- Likes
- 47
This is a nice little marketing write up, with just enough truth in it. Their overall argument is a bit flawed though, as they compare adaptive transfer+jitter cleaning to asynchronous transfer, throwing words around to hide the fact that jitter cleaning has to be added to the adaptive transfer while it's pretty much intrinsic to the asynchronous mode.
In an asynchronous transfer, your data is fed from the First In, First Out (FIFO) buffer into the DAC by a local clock. The level of jitter of that clock is all the jitter you'll ever get at the DAC. The irregularities in USB transfer do not matter since the packets are stored in the buffer and only get out when asked to by a derivative of the local clock. Obviously, you want to keep the buffer small for budgetary reasons so there is a feedback mechanism provided for by the USB specifications, which allows the sink to adjust the source's sending frequency.
In an adaptive USB transfer, you have no possibility to control the source's sending frequency. So you must find another system to keep your small FIFO buffer neither empty nor full while feeding the DAC with a constant clock. In practice, you must generate the clock that will empty the buffer in relation with (and thus on the basis of) the timing of the incoming packets. The problem is to generate a perfectly clean clock out of a jittery flow of packets.
Actually, there are indeed very good ways to clean up jitter and to generate such clean clock, it's been done for a while for spdif. I don't feel bad using adaptive receivers and a good adaptive implementation could beat a bad asynchronous one. But, conceptually, the asynchronous method is still arguably superior as it doesn't require an extra layer of jitter cleaning.
Quote:
In an asynchronous transfer, your data is fed from the First In, First Out (FIFO) buffer into the DAC by a local clock. The level of jitter of that clock is all the jitter you'll ever get at the DAC. The irregularities in USB transfer do not matter since the packets are stored in the buffer and only get out when asked to by a derivative of the local clock. Obviously, you want to keep the buffer small for budgetary reasons so there is a feedback mechanism provided for by the USB specifications, which allows the sink to adjust the source's sending frequency.
In an adaptive USB transfer, you have no possibility to control the source's sending frequency. So you must find another system to keep your small FIFO buffer neither empty nor full while feeding the DAC with a constant clock. In practice, you must generate the clock that will empty the buffer in relation with (and thus on the basis of) the timing of the incoming packets. The problem is to generate a perfectly clean clock out of a jittery flow of packets.
Actually, there are indeed very good ways to clean up jitter and to generate such clean clock, it's been done for a while for spdif. I don't feel bad using adaptive receivers and a good adaptive implementation could beat a bad asynchronous one. But, conceptually, the asynchronous method is still arguably superior as it doesn't require an extra layer of jitter cleaning.
Quote:
Just came across this little write-up while i was doing some research on this awesome product i bought a while ago as my portable solution for now and thought it might be interesting especially to those who are somewhat disappointed that asynchronous USB transfer isn't implemented in the Audio-GD range.
The product in question is the DACport and information is extracted directly from www.centrance.com. The makers of the DACPort are credible members of the hifi community and have licensed their USB implementations know-how to many prominent high-end audio manufacturers.
So in the same fashion as people are only/more concerned with the actual DAC chip used and not actual onboard implementation of the DAC as a whole, people who feel they might be missing out just because their DACs are implemented with asynchronous USB transfer should rethink their stand.
.
