Re: Ardour session with plain ALSA, without JACK

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

 



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.

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

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,

-- 
FA

A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)

_______________________________________________
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