Correctly sizing Alsa buffers, weird API

Question

I'm currently working on a project that requires me to do some sampling with Alsa. I'm trying to configure correctly everything but I'm stuck on how to correctly size my reading.

There are two primitives that seem to be interesting for my task:

snd_pcm_hw_params_get_period_time
snd_pcm_hw_params_get_buffer_size

The name of the first one suggests that the output will be the time length of a sampling period, however that's weird: if I'm setting the sampling rate on f = 44100Hz the sampling period (in nanoseconds) should be T0 = 1e9 / 44100 ~= 22676 ns while the function will answer T1 = 725 us = 725000 ns.

Meanwhile, even if I've been asked to use non-locking primitives, I'm trying to profile the time required for locking 'readi', and it turns out that the sample requires T2 = 8028603 ns in the best case time and T3 = 12436217 ns in the worst case.

Finally I can't figure out what's the meaning of the following two:

snd_pcm_hw_params_get_buffer_time
snd_pcm_hw_params_get_period_size

I don't get how could I measure the buffer in time and the period in size, However the former returns the same value as get_buffer_size, while the latter returns the same value as get_period_time.

Any hint?

Answer 1

ALSA has some weird^Wspecific terminology:

• Frames: samples x channels (i.e: stereo frames are composed of two samples, mono frames are composed of 1 sample,...)
• Period: Number of samples tranferred after which the device acknowledges the transfer to the apllication (usually via an interrupt).

The *_size functions appear to return sizes in frames.

HTH