Re: [LAU] Ardour session with plain ALSA, without JACK

From: Robin Gareus <robin@email-addr-hidden>
Date: Sat Feb 20 2016 - 12:57:52 EET

On 02/20/2016 11:32 AM, Fons Adriaensen wrote:
> On Sat, Feb 20, 2016 at 10:47:14AM +0100, Robin Gareus wrote:
>
>> On 02/20/2016 03:46 AM, Markus Seeber wrote:
>>
>>> That is correct, the AIO, same as the RayDAT has a fixed buffer of 16K.
>>> This means that regardless of the requested number of periods and frame
>>> size, it will always report a buffer size of 16K and a number of periods
>>> equal to buffersize divided by framesize.
>>
>> Thanks for confirmation.
>>
>>> Never the less, if requested 2
>>> periods with framesize of 64 samples, the card will still work correctly
>>> and have a latency that corresponds to 2 frames of 64 samples.
>>
>> What is the case for exposing those this to userland?
>>
>> I ask for two, I get behavior of two, but when checking the parameters
>> the value is 16. That sounds like a bug to me.
>
> I agree.
>
>> Did anyone flag this up at ALSA-dev, or report a bug?
>>
>>> As said before, there are applications that make (most likely too many)
>>> assumptions about these numbers and therefor break with these cards.
>>
>> Ardour is not as forgiving as JACK. if a call to a snd_pcm_hw_params_*
>> fails or if the requested value does not match the one reported by the
>> card, it constitutes hard failure.
>
> Same for zita-alsa-pcmi.

Yes, since Ardour's ALSA backed uses zita-alsa-pcmi for audio, the
behavior is the same.

> Is the following interpretation correct ?
>
> If the available buffer is larger than what is necessary for
> the given period size and count, the soundcard hardware could
> work in two ways:
>
> 1. Use only the required part of the buffer, i.e. wrap back
> to the start of the buffer after the n-the period, or
>
> 2. Use the entire buffer anyway.
>
> I guess the AIO and RayDAT are behaving as (2). But this
> should affect only the driver, and be entirely irrelevant
> to the user side. In particular there is no reason to report
> incorrect values for the number of periods.
>
> In fact, when a soundcard is configured in terms of period
> size and count, the actual available buffer size is irrelevant
> (as long as the required size is available).

"As long as it is available" is key.

While buffersize is not critical, jack choosing the closest available
value has bitten a few users.
These days some internal soundcards only support 48K. Even when
requesting 44.1KSPS, jack silently falls back to use 48K (the closest
available).

> There is even no reason why an application should ever check it.
> So there should be no problem if the driver always reports the
> full buffer size, as long as the period size and count values
> are returned correctly.
>
> Ciao,
>

_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-user
Received on Sat Feb 20 20:15:01 2016

This archive was generated by hypermail 2.1.8 : Sat Feb 20 2016 - 20:15:02 EET