I did and got this reply. In short the answer is yes. Thankyou!
"With the old isochronous USB mode, the computer was in charge of sending the data - controlled by its internal clock. That's why it was necessary for the DAC to "lock onto" the computer's clock using some method - like a PLL. The DACs clock could "follow" the computer's clock, and apply all sorts of smoothing to even it out, but it was basically forced to follow rather than lead - and even the fanciest PLL is basically a filter - and so can reduce but not totally eliminate variations in the incoming signal. (If you'd used an entirely independent clock in the DAC, you'd risk having the computer send data faster than you were receiving, and so having "extra bytes"; or, even worse, if the DAC got ahead of the computer, you could run out of audio data and end up waiting for the next sample.) This made it impossible to use an entirely separate, and better, local fixed clock in the DAC.
With an isochronous ASYNCHRONOUS connection, the DAC has its own internal clock, and the DAC "requests" that the computer send enough data to keep its buffer full. In detail, it's a little more complicated, and you can still run out of data if the computer simply fails to keep up, but the important part is that the DAC gets to control the data clock - using its own local high-quality clock, and so the DAC is relatively immune to both inconsistencies in timing from the computer's USB output clocking, and from jitter and timing errors that might occur in the cable or elsewhere along the way. (Unlike using an ASRC, or some other similar mechanism, to regenerate the data and lock it to a new clock, the USB data itself doesn't have to be recalculated, and so remains bit-perfect.)
(And, yes, the USB inputs on the XDA-2, the DC-1, the Ego DACs, and the USB Stream input on the XMC-1, are all asynchronous.)
WASAPI is a Windows internal communication mode - and is required to avoid having Windows re-sample everything you pass through it to a fixed sample rate. With Windows, audio output is "normally" resampled to whatever sample rate you have selected in the Sound Settings in Control Panel; there is no setting for "send it along at whatever sample rate you receive it at". For whatever mysterious reason, when WASAPI mode was added to bypass that, it was NOT made the default mode. (Actually it's not mysterious; if you have two different programs sending audio data at different sample rates, then at least one of them will have to be resampled because you can only mix two audio streams at the same sample rate - and Windows assumed this would be happening. So, for example, if you play a 96k audio file, but the system beeps and boops are at 44k, then either something will have to be resampled, or you won't be able to hear both at the same time.) WASAPI Push and WASAPI Event are mostly concerned with how Windows, the drivers, and your audio player interact - so the DAC doesn't care which one you use - but some player programs, and some drivers, may work better with one or the other. (Technically, since the clocking is controlled by the DAC, and both WASAPI modes should be bit-perfect unless something goes wrong, they should sound the same.... but some player/driver combinations have trouble with one or the other.)"
Author
Topic: Emotiva XMC-1 USb is it Asynchronous? (Read 5193 times)