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