On 02/20/2016 12:57 PM, Fons Adriaensen wrote:
[...]
>
> My point is that if an app configures an ALSA device for a
> period size and count, and this configuration succeeds, the
> actual buffer size is irrelevant. There should be no reason
> for the app to check or set it, and not even for ALSA to
> allow this.
>
> Zita-alsa-pcmi _does_ call snd_pcm_hw_params_set_buffer_size()
> after having set the period size and count. This is just because
> its code was originally based on jack's backend, and I always
> wondered why it should be necessary (the available docs don't
> explain any of this). Given the period values the driver should
> be able to work this out by itself.
>
> The mmap interface means that the user will obtain a new pointer
> and stride (distance between samples of the same channel) for each
> period (and channel). It's this that allows the buffer layout to be
> flexible (e.g. interleaved or not).
>
> The user shouldn't make any assumptions about the pointer and stride
> values returned by snd_pcm_mmap_begin(). Ergo even if the buffer as
> seen by the user is actually the HW one, it shouldn't matter if the
> HW uses the full buffer or only part of it. And all the rest (the
> read/write interface) can be implemented on top of mmap.
>
> Ciao,
>
That was basically my guess too but I have not found any documentation
on ALSA on that yet.
_______________________________________________
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:02 2016
This archive was generated by hypermail 2.1.8 : Sat Feb 20 2016 - 20:15:02 EET