20 Feb
2016
20 Feb
'16
12:57 p.m.
On Sat, Feb 20, 2016 at 11:57:52AM +0100, Robin Gareus wrote:
I should maybe rephrase that: 'as long as the required size, or
more, is available'.
On 02/20/2016 11:32 AM, Fons Adriaensen wrote:
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.
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,
--
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)