>>>>> <SNIP> >> Can there exist small time inconsistencies (latencies?) throughout the >> streaming of the buffer to the USB DAC? >> >> I'm just trying to root out any possibilities for improvement in Linux >> as a digital audio player. Even the choice of USB cable is said to >> make an audible difference. This type of thing can descend into >> paranoia pretty easily, but I want to press on. >> >> - Grant > > Not if it's designed correctly. All audio timing is controlled by the card. > > In the external sound card you have some sort of a buffer. It's large > enough to handle whatever the latencies are in the system to keep it > from running dry. Let's say the buffer is 1K deep and the sound card > requests data (in let's say) 128 bytes chunks (1 block) across the USB > bus. When you want to start playing audio the ALSA driver sends enough > data to fill the device's buffer and then the sound card starts > playing the audio. As it plays the buffer is drained. When the buffer > has 128 empty locations the sound card flags that it can handle > another 128 bytes so the ALSA driver sends it, but the card still has > 1024-128 bytes waiting to be played. As long as the new data can be > delivered faster than it's being played then the buffer stays (mostly) > filled. As long as the buffer doesn't run empty the sound is produced > 'perfectly'. > > The only place the kernel latency effects this process is if something > happens that allows the buffer to run dry. The buffer can get as low > as 1 byte and the sound is still perfect. If new data arrives in time > then it continues to be perfect. It doesn't matter whether we use a > rt-kernel or a vanilla kernel. If the buffer doesn't run dry the audio > is 'perfect'. > > Where the rt-kernel helps is that when the sound card asks for data > there should be a much lower 'latency' from the sound card raising a > hardware flag to the ALSA driver requesting data to the kernel > supplying this data to the ALSA driver sending it out to the card. > Lower latency in the rt-kernel helps the buffer not run dry, but the > truth is that the audio is identical and all that matters is that the > buffer not run dry.
Excellent description, thank you. So the question becomes, does the card's buffer ever run dry? Is there a way to find out? Considering that the card is actually DACing out of its own buffer, the audiophile USB cable concept sounds pretty ridiculous. I know many USB cables produce audible errors, and I bet is what led to the audiophile USB cable thing. It is probably only necessary to get a cable that doesn't produce errors. > Assuming you build an rt-kernel then the other thing you have to look > at is how you set real-time priorities. ALSA drivers don't just run > real-time because it's an rt-kernel. You have to configure WHAT you > want to run RT and at what priority. Is it fair to say that the rt part of rt-sources is basically a super-strict scheduler? > Note that the 24-bit/16-bit problem you are trying to solve really > doesn't have anything to do with this specific problem. That seems to > be more about either what the card supports or what the ALSA driver > thinks it supports. That problem *may* be solvable in the driver. Even > if the card doesn't actually support 16-bit audio the driver could > fool the application by accepting 16-bit data and reformatting it with > 8 extra bits, and then send that to the card as 24-bit audio. It > doesn't change the actual audio, just uses more bandwidth on the USB > bus. I think you were exactly right here. I needed ALSA to send audio to the card in S24_3LE format because that's the only format the card can accept as input. plughw makes the format conversion, but hw does not. - Grant
