The Digital Fallacy

[markof]

There's a lot to be said for not ignoring the time domain: the time it takes for a mechanically-carried signal to rise from zero to one and fall again; bit-interval timing; interaction between clocks; SRC operation . . . at every level, assessing the dynamic behaviour of a realtime digital system is very much more complex than the literally asynchronous business of storage.

We're magnetically drawn to think about music files as if they're no different to image files - and of course they are! But it's not about the files. It's not about whether the data is pulled through an interface from static point A to static point B and lands in the same shape: it's about how the interface behaves during transit.

And very much about how the 'analog' basis of all those mechanisms (they don't waft through some platonic ether) impacts on the rest of the system: a USB cable ducts a significant chunk of the computer's ground-plane noise originating from massively noisy 1kW switch-mode supplies, directly into the DAC's motherboard. Most DACs are literally part-powered by the computer. The same noise is injected into (frequently) shared mains, so it's potentially all over the amplifier, too.

The distinction between 'digital' and 'digital-processing' is important to make: digital is not an antonym of analog.

We've grown so accustomed to the shorthand 'digital components' that we don't often stop to think that they're all still - highly miniaturised - analog components interpreting voltage signals and processing them digitally. And it's that 'analogness' that a realtime-operational DAC + amplifier is sensitive to, whereas printers aren't. Similarly, though for different reasons, a toaster works fine next to a microwave, but a radio doesn't!

Hurray - a fine explanation.

[Adrian]

Meep,

The wiki quote about the receiver does not control data supply does not seem correct to me.

Most communication systems are designed to communicate at the max rate of the slowest component.

If a transmitter at 9600 baud is communicating with a receiver of 3600 baud, then after a handshake occurs the transmitter transmits at 3600 baud.

Otherwise the system breaks down, there is no point in transmitting at a data rate which exceeds the design rating of the receiver.

SCSI (legacy interface) is a good example, SCSI devices sharing the same bus will transmit data at the speed of the slowest component on the bus, even though there may be several components which have a data transfer rate several orders of magnitude greater than the slowest component on the same bus.

My understanding is that data communication is not about transmitting data at the fastest rate possible, it's about communicating data successfully, I.e. checksums, parity checking etc.

That is only possible provided the max data rate of the slowest component is not exceeded.

[jkeny]

Yes, the difficulty arises when we try to deal with digital audio as a purely digital device like other digital devices i.e as long as the correct bits arrive in the correct sequence at the device then all is fine.
The fact that audio introduces a timing factor (i.e all bits also have to arrive at EXACTLY the correct time) then it introduces the analogue world of thinking.

Now anything that might effect this arrival of the correct bits at EXACTLY the right time (we are talking about picoseconds of timing here) seems to have an impact. This doesn't just apply to the final connection between computer & DAC but also anything upstream which might cause a timing glitch at this final connection point.

Now, many will say that PCs are so powerful that they can handle audio with only about 1-2% of CPU usage but is it just about processing or is it more about the smooth flow of the data to the point of connection with the DAC so that the data gets delivered EXACTLY on time? So can we analyse & qualify this delivery of data & how timely it is? Well, I came across such a series of measurements a while back which prove to be very interesting. They come from Jim LeSurf, http://www.st-andrews.ac.uk/~www_pa/Sco ... e/Jim.html a retired lecturer "recently retired as reader in Physics and Electronics at the School of Physics and Astronomy at the University of St. Andrews." who also has been interested in audio for most of his life.

From his audio pages you will see his test which reveals at a deeper level what is going on in the final digital connection between computer & DAC (or USB to SPDIF converter). This sort of measurement has not been done before & it reveals some interesting real-world issues. The test he calls IQ-test. http://www.audiomisc.co.uk/Linux/Sound3 ... hange.html

Here you will find a test of the DACMagic Vs USB Halide bridge - both using the USB connection with the computer for transmission of the audio data. Now the interesting thing is that there is a distinct & measurable difference between the two devices. Not surprisingly, maybe as the DacMagic is running adaptive USB & Halide is running asynchronous USB. Adaptive USB uses the PC's clock for timing, asynchronous USB uses the local clock in the DAC for timing.

These measurements were taken at the analogue output of the DacMagic when fed using it's internal USB or using the Halide bridge for USB duties. The graph here shows that the DacMagic suffers a jump in timing errors every 15 seconds compared to the Halide Bridge steady

[jkeny]

Now the beady-eyed among you will spot that the Y axis is in PPM (parts per million) & may think that this is of no consequence. Remember what he is measuring is a jump in timing errors. This is a difficult one to answer & needs a bit of analysis of the measurement technique & what is actually being measured first. I'm not sure I fully understand the implications of the measurement system to be able to fully answer this. However, all the information is on the linked page & on the details of how the IQ-test is run along with software download to do these tests (I'm hoping to get to do some on a Linux system when I get the time)

He concludes his analysis of the results as follows (I have bolded parts that I believe are particularly relevant to this discussion):

The most obvious conclusion we can draw from the above results is that using the Halide Design USB-SPDIF Bridge clearly improves the performance of the system I used. The output becomes much more uniformly timed. i.e. wow and flutter (jitter) is reduced by using the Halide Bridge rather than relying on a direct USB connection from computer to DACMagic. Another advantage of the Halide Bridge is that it allows higher rate and bit depth material to be played via USB. (In fact I found that 192k/24 and 176·4k/24 LPCM files also played via the Halide Bridge, but were downsampled to a ‘mere’ 96k/24 or 88·2k/24.) Overall, therefore, using the Halide Bridge instead of a direct USB connection gave a clear improvement in both capability and performance.

The above said, we should take care not to put the blame on the DACMagic for the higher replay rate flutter when using a direct USB connection. The root of the problem here is that a normal domestic computer tends to keep being ‘distracted’ by having a number of under-the-hood activities to perform. It also probably has a computer clock whose clock rate isn’t ideal as a basis for 44·1k or 48k operations. Audio is very demanding in terms of the final output needing to be clocked in a very uniform and regular manner. So the unwanted ‘jumps’ here are likely to be due to things going on inside the computer system that get in the way of maintaining a carefully regulated flow of audio data to the DAC. For this reason the details of the flutter can be expected to vary from one domestic computer setup to another. And may also change if you alter what software is running or do something as innocuous as connect or disconnect some other device from the USB ports. What is clear is that the Halide Bridge can take control of the data flow and overcome these problems.

Unfortunately, he never did any more tests (other than an Arcam rDac) or tested his thesis about OS load causing fluctuations in the measurements. I'm hoping to do this (sometime) but would also offer all this for others to maybe take up the challenge :)

[Diapason]

Excellent posts, John.

[Fran]

Yes indeed - excellent posts John.

Its so simplistic to say its all 1s and 0s - of course it is. But its the timing of those 1s and 0s that is critical!


Fran

[jaybee]

is the data stream fixed?

by that I mean is the order of the bits fixed ( like cars on a motorway ) or is it flexible ( quantised and reassembled on arrival)

[jkeny]

is the data stream fixed?

by that I mean is the order of the bits fixed ( like cars on a motorway ) or is it flexible ( quantised and reassembled on arrival)

That depends on what sort of transmission you are using between PC & your audio device.
Which is a bit more complicated to answer. If using USB the data gets sent in frames which are the correct order for playback - i.e it's a serial stream of data (with no re-transmission of any incorrect data, AFAIK). However in the receiving USB audio device there is usually a buffer (memory) into which the data is stored before being processed/sent to the DAC chip.

If talking about network transmission as is used in the Squeezebox, then packets are sent from the PC, not necessarily in the strict order required for direct playback & the packets are reassembled at the receiving device (SB classic or Touch or?). So again it requires a buffer.

I know the argument goes that if the data is reassembled into a buffer & played back from this buffer then any upstream activity shouldn't matter. This sounds & is logical but we are obviously missing some factor because in the real world it seems not to work this way. USB cables make a difference for instance (I don't know about LAN cable differences in SB).

A portion of the answer seems to be got to do with the noise that is transmitted down the USB ground wire. So any activity in the PC can cause modulated noise in the ground noise i.e not steady state noise which is easy for us to accommodate to in our hearing (LPs or tapes) but noise modulation which is much more intrusive.

So far, so good! Why not use an isolated connection? There is only one isolator that works at USB2.0 Full Speed (480Mbps) & that is Adnaco ($400?). I deal with it differently by using battery shunts that handle the ground noise & prevent it from effecting the sensitive digital circuitry. However, there is still something up because different USB cables can sound different.

Now there is some other noise called common mode (CM) noise coming from the PC that doesn't ride on the ground but rather rides on the 2 signal lines in a USB cable. I also deal with this, AFAIK.

But still what's happening on the PC translates into the audio side. Just this morning, I downloaded the latest version of Jplay playback software & it is a noticeable improvement on the previous version.

I guess all that can be reliably said is to keep an open mind & go figure!

[jaybee]

ah the mind is open....

the more I hear the more I'm convinced to bifurcate into vinyl and computer for my hifi sources....

my only long term concern is that the "album" as a concept ( not concept albums..!!!) will morph into a collection of tracks...

[jkeny]

the more I hear the more I'm convinced to bifurcate into vinyl and computer for my hifi sources....

What were the other options you had in mind?