Re: Ardour session with plain ALSA, without JACK

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxxxxxxxxxxx
http://lists.linuxaudio.org/listinfo/linux-audio-user



[Index of Archives]     [Linux Sound]     [ALSA Users]     [Pulse Audio]     [ALSA Devel]     [Sox Users]     [Linux Media]     [Kernel]     [Photo Sharing]     [Gimp]     [Yosemite News]     [Linux Media]

  Powered by Linux