noman pouigt wrote:
I am using tinycap to capture the audio and setting below settings: bitwidth = 16 rate = 16000 channel = 1 period_size = 320 period_count = 2
I am wondering how is below period_size and buffer_size calculated?
Shouldn't period_size of 320 bytes and period_count of 2 fail?
From the tinyalsa source code:
param_set_min(¶ms, SNDRV_PCM_HW_PARAM_PERIOD_SIZE, config->period_size);
So it uses either the supplied value, or if that is too small, the
smallest allowed value.
Probably I was not clear; Why ALSA picked period_size of 2042 bytes when the minimum period bytes specified is 4084?
Reason for this question is probably my wrong understanding. AFAIK: period_bytes_min specified in hw_params means the minimum bytes after which audio driver can expect an interrupt. So, total buffer size should be multiple of period_bytes_min or multiple of user provided period size if it is greater than period_bytes_min.
So, if the above understanding is right then buffer size should have been 4084*2 (number of periods asked by user).
Ultimately the question is how period size is calculated given min_period_bytes, max_period_bytes, buffer_bytes_max from pcm_hardware and user supplied period size and period count?
I tried looking into the code but looks like there is lot of macro magic going on in pcm native layer.
cat sub0/hw_params
access: RW_INTERLEAVED format: S16_LE subformat: STD channels: 1 rate: 16000 (16000/1) period_size: 2042 buffer_size: 4084
The actual values of period_size and period_count are returned by pcm_open().