31-Aug-2014, 23:42
Hello Thierry,
I understand about the two different clock domains. My hypothesis is that the buffer in the Devialet means that when streaming via AIR, the two clock domains are almost entirely de-coupled and therefore don't suffer from the issues that you refer to.
In other words, the "building the data" part doesn't depend on having a good clock, provided the computer can read and decode the audio file to generate the output samples quickly enough. That's a matter of throughput rather than clock accuracy. I'm assuming we're talking about streaming from an audio file, with a codec that's just a deterministic, algorithmic process - so given the same input data it would produce the same output data whether or not it's run in real time. Another way of thinking of it is that instead of running the codec you could simply have a file full of already-decoded audio samples. The bits would be the same irrespective of how and when they were generated.
I know some might argue that's not the case, but I hold the point of view that if the computer runs correctly it will always decode a given audio file to the same bits (assuming the codec is deterministic). Maybe that's where we should agree to differ?
Also, I believe transferring the data between the computer and the Devialet via AIR is not critically time-sensitive. Because of the buffer in the Devialet, the computer can deliver the data at roughly the right overall rate and there should be no difference in end result provided all the data arrive and the buffer doesn't over- or under-flow. In practice this must be the case because AIR is implemented using a mechanism (UDP) that may drop packets even when running over wired Ethernet. This means that packets may need to be re-sent if they're "lost" in transit, which could give quite large timing variations in delivery of audio samples to the Devialet. Nevertheless the buffer means that such timing variations aren't important provided the packets reach it before they're needed.
It seems to me the only part that is critically-dependent on a good clock is the transfer of data from the buffer to the Devialet's audio system. And of course that's all controlled by clocks internal to the Devialet.
Cheers,
Ian
I understand about the two different clock domains. My hypothesis is that the buffer in the Devialet means that when streaming via AIR, the two clock domains are almost entirely de-coupled and therefore don't suffer from the issues that you refer to.
In other words, the "building the data" part doesn't depend on having a good clock, provided the computer can read and decode the audio file to generate the output samples quickly enough. That's a matter of throughput rather than clock accuracy. I'm assuming we're talking about streaming from an audio file, with a codec that's just a deterministic, algorithmic process - so given the same input data it would produce the same output data whether or not it's run in real time. Another way of thinking of it is that instead of running the codec you could simply have a file full of already-decoded audio samples. The bits would be the same irrespective of how and when they were generated.
I know some might argue that's not the case, but I hold the point of view that if the computer runs correctly it will always decode a given audio file to the same bits (assuming the codec is deterministic). Maybe that's where we should agree to differ?
Also, I believe transferring the data between the computer and the Devialet via AIR is not critically time-sensitive. Because of the buffer in the Devialet, the computer can deliver the data at roughly the right overall rate and there should be no difference in end result provided all the data arrive and the buffer doesn't over- or under-flow. In practice this must be the case because AIR is implemented using a mechanism (UDP) that may drop packets even when running over wired Ethernet. This means that packets may need to be re-sent if they're "lost" in transit, which could give quite large timing variations in delivery of audio samples to the Devialet. Nevertheless the buffer means that such timing variations aren't important provided the packets reach it before they're needed.
It seems to me the only part that is critically-dependent on a good clock is the transfer of data from the buffer to the Devialet's audio system. And of course that's all controlled by clocks internal to the Devialet.
Cheers,
Ian
Roon (Mac Mini), Wilson Benesch Full Circle, Expert 1000 Pro CI, Kaiser Chiara
Warwickshire, UK
