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?

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

I think that's exactly how it works.

> 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

I think that's why we have a choice between default, plughw, or hw.
default seems to always resample to 48k, convert the format if
necessary, and convert the channels if necessary.  plughw does the
same, except it does not resample.  hw does none of it.

- Grant


> 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