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

[Mark Knecht <markknecht@xxxxxxxxx>]

On Sun, Jan 3, 2010 at 6:43 AM, Grant <emailgrant@xxxxxxxxx> wrote:
>>>>>> <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?

Using JAck - yes. It's called an xrun and Jack reports them clearly.
To the best of my knowledge when not using Jack the answer is no.

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

Yep, that's my opinion.

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

I'm not qualified to answer that question. Basically, as I understand
it, rt-sources sets up a higher level queue for rt-threads. The
rt-developers (Ingo, Thomas, Steven and others) have gone through the
kernel sources line by line looking for things that can block the
rt-queue from getting immediate service. They fix these, but also have
ported a lot of that back into the mainline code so that over time
there is less of the mainline kernel getting changed.

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

My point/opinion/wish was that the *driver* should accept ALL formats
ALSA supports, and then the driver should convert to whatever the best
format is for the sound card. However I will qualify this with the
statement that the driver shouldn't be doing things that cause loss in
quality unless there's no other way to get the data to the card. This
way things like manual intervention with hacks like plughw and all
it's undocumented issues (I've NEVER learned to use any of that
stuff!)

My understanding:

hw:1,0 is a path to the hardware
plughw:1,0 is a path to some undocumented software

Good luck with your tasks,
Mark