Computer Audio Asylum

Posted by Tony Lauck (A) on September 19, 2014 at 10:36:08

In Reply to: RE: Here's my understanding (based on Wikipedia) of why buffering on DAC side is irrelevant posted by carcass93 on September 19, 2014 at 09:27:47

I'm not sure it's completely irrelevant. There is a control loop in either case that keeps the source and the sink in approximate synchronization, such that there are no buffer underruns at either end of the connection. The difference between SPDIF and async USB is which end is in control and how the feedback process works.

With SPDIF the computer is in control and the DAC must adjust. If it does a slow job of adjusting, its buffer will become exhausted. If it does a fast job of adjusting, it will adjust to jitter in the incoming signal, thereby degrading the audio quality. There are two ways to improve the situation: do a better job of predicting the average speed or use a large buffer. (If the buffer is large enough and is preloaded then there will be no need to adjust for an entire playlist, ...)
The best systems use a high order predictor and use rate information and buffer threshold to set strategy. Here the control loop is entirely in the DAC and under control of the DAC designer, the only unknown variable is the rate of the clock at the transport.

With Async USB the DAC is in charge. It controls the rate at which the computer sends data, but not the rate at which the computer sends frames. This means varying the number of samples per frame. There is some leeway for how to do this, but there is going to be a delay between when the requested number of frames is changed and when this takes effect in the returned frames. This requires sufficient buffering in the DAC to accommodate these delays. I suspect the logic to do this is probably implemented in firmware in the DAC and in software in the driver, but I don't know enough about O/S details to know how this is accomplished (e.g. at what interrupt level). This means that O/S latency can come into effect as well. In my experience, only the very best engineers can get these details correct, otherwise things "sort of" work.

There is a limit on the practical amount of buffering that can be used in the pipeline between the player application, driver, USB, USB cable, USB, and DAC proper (the part that gets an I2S stream). Not a matter of cost these days, but a matter of latency for end to end interaction, which depends on the application. A loose application allowing large delay is audiophile playback, where a lot of slop in the buffering just means that start, stop, skip forward, skip backward user interface operations are sluggish. With video playback there has to be audio video sync. For audio production work involving overdubbing or interactive audio (telephony or video conferencing) there is round trip delay and related human factors in perception of echos, etc... and the delay between application and analog audio must be small.

My main point is that this is very complicated and hard to get right. It need not affect overall sound quality. Sound quality will be affected by the size of the buffers, which determines the rate at which buffers have to be processed and the frequency of CPU loading. However, if multiple buffers are used to allow for rare delay circumstances then this won't affect the frequency of buffer loading. So there are actually two dimensions that can be adjusted, buffer size and number of buffers. Both of these may or may not be exposed via configuration windows.

At least in audio applications there are only two computers involved: transport and DAC. It gets far uglier when multiple computers get strung together and multiple clocks and multiple buffers have to be kept working in harmony.





Tony Lauck

"Diversity is the law of nature; no two entities in this universe are uniform." - P.R. Sarkar