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

[Grant <emailgrant@xxxxxxxxx>]

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

But in the end, there's really no way to know, right?  From what I
gather, jack can add another buffer and report on it, but it's the
sound card buffer that determines whether there are problems or not,
right?

I suppose using jack and real-time gives you extra assurance that the
sound card buffer is being served as necessary.  Using jack without
real-time wouldn't provide any more assurance than a setup without
jack, would it?

- Grant


> 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