Re: [proaudio] Real-Time for audio playback?

[Grant <emailgrant@xxxxxxxxx>]

>>>>> <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