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
