对于 Alsa pcm 设备，period_size 设置为 128，但有时轮询会延迟

Question

I am facing an issue where the period size has been set to 128, still sometimes the polling starts late.
For this configuration, where the period size is set to 128 and rate is 16 Khz, therefore polling should occur after each 128/16 = 8 ms, but in some cases the polling occurs a bit late which causes certain issues in the application.
Since, polling is triggered internally by Alsa system modules which is dependent on the configuration, kindly suggest if we are going wrong somewhere with the configuration or any similar issue anyone might have experienced. Pasting the PCM dump of my Setup below:-

APCM_DUMP_DEVICE_DETALS :-
Hardware PCM card 0 'mt2712-d1v1' device 5 subdevice 0
Its setup is:
stream       : CAPTURE
access       : RW_INTERLEAVED
format       : S16_LE
subformat    : STD
channels     : 1
rate         : 16000
exact rate   : 16000 (16000/1)
msbits       : 16
buffer_size  : 512
period_size  : 128
period_time  : 8000
tstamp_mode  : NONE
tstamp_type  : MONOTONIC
period_step  : 1
avail_min    : 128
period_event : 0
start_threshold  : 128
stop_threshold   : 512
silence_threshold: 0
silence_size : 0
boundary     : 4611686018427387904
appl_ptr     : 0
hw_ptr       : 0

APCM_DUMP_DEVICE_DETALS :-
Hardware PCM card 0 'mt2712-d1v1' device 1 subdevice 0
Its setup is:
stream       : PLAYBACK
access       : RW_INTERLEAVED
format       : S16_LE
subformat    : STD
channels     : 1
rate         : 16000
exact rate   : 16000 (16000/1)
msbits       : 16
buffer_size  : 512
period_size  : 128
period_time  : 8000
tstamp_mode  : NONE
tstamp_type  : MONOTONIC
period_step  : 1
avail_min    : 128
period_event : 0
start_threshold  : 128
stop_threshold   : 512
silence_threshold: 0
silence_size : 0
boundary     : 4611686018427387904
appl_ptr     : 0
hw_ptr       : 0

APCM_DUMP_DEVICE_DETALS :-
Hardware PCM card 0 'mt2712-d1v1' device 12 subdevice 0
Its setup is:
stream       : CAPTURE
access       : RW_INTERLEAVED
format       : S16_LE
subformat    : STD
channels     : 1
rate         : 16000
exact rate   : 16000 (16000/1)
msbits       : 16
buffer_size  : 512
period_size  : 128
period_time  : 8000
tstamp_mode  : NONE
tstamp_type  : MONOTONIC
period_step  : 1
avail_min    : 128
period_event : 0
start_threshold  : 128
stop_threshold   : 512
silence_threshold: 0
silence_size : 0
boundary     : 4611686018427387904
appl_ptr     : 0
hw_ptr       : 0

APCM_DUMP_DEVICE_DETALS :-
Hardware PCM card 0 'mt2712-d1v1' device 11 subdevice 0
Its setup is:
stream       : PLAYBACK
access       : RW_INTERLEAVED
format       : S16_LE
subformat    : STD
channels     : 1
rate         : 16000
exact rate   : 16000 (16000/1)
msbits       : 16
buffer_size  : 512
period_size  : 128
period_time  : 8000
tstamp_mode  : NONE
tstamp_type  : MONOTONIC
period_step  : 1
avail_min    : 128
period_event : 0
start_threshold  : 128
stop_threshold   : 512
silence_threshold: 0
silence_size : 0
boundary     : 4611686018427387904
appl_ptr     : 0
hw_ptr       : 0

Answer 1

For the issue, we tried to analyze the kernel traces, after going through the kernel traces, we found out that we were reading the entire available data (snd_pcm_avail_update) for the capture device(rather than the period_size), due to which a flag in kernel was set to 0 since it had 0 bytes available due to which it was missing the interrupt to wake up the read thread(application) in time. Once we set the pcm_read to read only the required data, the behaviour was rectified