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

[Mark Knecht <markknecht@xxxxxxxxx>]

On Fri, Jan 8, 2010 at 7:41 AM, Grant <emailgrant@xxxxxxxxx> wrote:
>>>>>>>>>> <SNIP>
>>>>>> 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.
>>>
>>> I thought jack set up a buffer of its own.  Does jack report on the
>>> sound card's buffer?
>>>
>> <SNIP>
>>
>> Correct - Jack reports it's own buffer - not the sound card's. The
>> filling of the sound card's buffer is managed by the card talking to
>> the Alsa driver.
>>
>> The one place where the card is in control is the *frequency* this all
>> occurs at. The card's internal crystal is used as the overall
>> controlling clock for Jack and is delivered through the Alsa driver.
>> This way Jack keeps the audio data flowing at the rate the sound card
>> requires. All of the audio apps then respond to Jack with the correct
>> number of samples per second.
>
> Do the sound card's buffer and jack's buffer mirror each other then?
> If not, I'm not sure monitoring jack's buffer will be helpful since it
> sounds like it's the status of the card's buffer that determines
> whether playback is perfect or not.
>
> - Grant
>

To some extent yes - the data is the same and in the same order -
although the depth of the two buffers doesn't have to be the same. The
sound card might be 600 bytes deep (purposely chosen as a weird size
only to make the point) and your Jack buffer might be 256 bytes deep
because you want certain latencies. Jack accepts data in 256 byte
chunks from the Jack enabled audio app (your CD player or Ardour in my
case) and then holds it for delivery to the sound card as soon as the
card can accept 256 bytes. Again, as long as the card doesn't run
empty sound is perfect. As long as Jack & Alsa delivers 256 bytes
faster then the card uses 256 bytes the buffer doesn't run empty, but
the actual sizes of the buffers doesn't make too much difference. Just
keep the buffers full and sound will be fine.

Keep in mind that Jack offers additional features which aren't of
primary interest to you, such as mixing audio from multiple apps,
adding dithering and other things, but what I think is of interest is
that Jack TELLS you ACTIVELY if your application or system aren't
keeping up. Music playing apps in general don't do that so you have no
way to determine if the sound card ever had problems. This is reason
enough for me to use Jack *most* of the time. Unfortunately things
like audio from a web page doesn't integrate well in this model so my
machines all have two sound cards. I use a good quality RME card in
most machines as the primary Jack-enabled device, but I still use the
internal sound chip to hand system sounds, audio from browsers and
other stuff I'm not too worried about. I then send that audio into my
good card and deliver it to the RME which goes through external DACs
to my studio monitors.

Hope this helps,
Mark