16-Jan-2018, 08:52
@ogs: in both the cases you mentioned, describing it as "re-clocking" is not very clear because the input and output formats are so different and in particular don't operate at the same clock rate. Yes, it will be generating output based on an accurate clock, which I think is what you mean to say, but it's doing far more besides.
For example if it's taking USB input and producing AES output, it has to understand the USB audio protocol to extract the audio data from the incoming USB packets in the same way as a USB DAC. In principle and in practice the USB input might include data and control messages for completely unrelated, non-audio devices as well as the audio data. Rather than converting those audio samples to analog as a DAC would do, the MC-3 is synthesising a completely new data stream on the AES output (and other outputs), based on its internal high-precision clock.
Another way to look at this is that if you're sending (for example) a 44.1 kHz audio stream via USB, there is nothing on the USB wire that obviously looks like a 44.1 kHz signal or any direct multiple thereof. The only way the DAC (or Mutec) knows that there's a 44.1 kHz audio stream embedded in the USB packets is by virtue of it implementing a USB audio endpoint that understands what the USB host (source) tells it. IIRC this the host does this by sending control requests, defined by the USB audio class protocol, to set the audio sample format, sample rate, etc.
This is why the MC-3+USB "looks like" a USB audio device to the host (source) and might require installation of USB audio drivers on Windows at least. On the other hand (I believe) something like an iFi USB Purifier does just literally re-clock the USB bitstream, without knowing anything about the USB audio protocol, and therefore doesn't require driver software.
Sorry if I'm repeating stuff you already know, but it seems that to describe what the Mutec is doing in this set-up as "re-clocking" is doing it somewhat of a disservice as well as being potentially confusing. I do know that this is how Mutec describe it as well, of course
For example if it's taking USB input and producing AES output, it has to understand the USB audio protocol to extract the audio data from the incoming USB packets in the same way as a USB DAC. In principle and in practice the USB input might include data and control messages for completely unrelated, non-audio devices as well as the audio data. Rather than converting those audio samples to analog as a DAC would do, the MC-3 is synthesising a completely new data stream on the AES output (and other outputs), based on its internal high-precision clock.
Another way to look at this is that if you're sending (for example) a 44.1 kHz audio stream via USB, there is nothing on the USB wire that obviously looks like a 44.1 kHz signal or any direct multiple thereof. The only way the DAC (or Mutec) knows that there's a 44.1 kHz audio stream embedded in the USB packets is by virtue of it implementing a USB audio endpoint that understands what the USB host (source) tells it. IIRC this the host does this by sending control requests, defined by the USB audio class protocol, to set the audio sample format, sample rate, etc.
This is why the MC-3+USB "looks like" a USB audio device to the host (source) and might require installation of USB audio drivers on Windows at least. On the other hand (I believe) something like an iFi USB Purifier does just literally re-clock the USB bitstream, without knowing anything about the USB audio protocol, and therefore doesn't require driver software.
Sorry if I'm repeating stuff you already know, but it seems that to describe what the Mutec is doing in this set-up as "re-clocking" is doing it somewhat of a disservice as well as being potentially confusing. I do know that this is how Mutec describe it as well, of course
Roon (Mac Mini), Wilson Benesch Full Circle, Expert 1000 Pro CI, Kaiser Chiara
Warwickshire, UK
