Is it ever correct for snd_pcm_avail() to return a value that’s greater than that returned by snd_pcm_hw_params_get_buffer_size()?
I’m trying to track down some unexpected underruns in my application and I notice that when they occur I also see that the available frames count is wrong.
For example here are a couple of lines from my logging:
2015-12-08T23:17:23.118817-08:00 X ? 2080 + 2080 2015-12-08T23:17:23.119524-08:00 X = 2080 ? 4126
The first log line: here I asked the device how many frames are available and it responds with 2080; I accordingly write 2080 frames.
The second log line: the writei() call returns 2080. I immediately ask how many frames are available now (I usually get a small number in response ~ 20-30) but this time I get an XRUN. I call snd_pcm_recover() and then snd_pcm_avail() again and now I get 4126 frames.
As you can see the time between these two logs is less than 1 millisecond, so I don’t understand how the PCM can go from 2080 frames available to >4096 frames available so quickly. Is this evidence of a bug in the device driver?
My application is using a single channel dshare PCM (rt) that has an 8-channel device underneath. Here’s the configuration fragment:
pcm_slave.cid_dsp { pcm "hw:0,0" channels 8 rate 44100 }
pcm.rt_channel { type dshare ipc_key 1025 ipc_gid audio ipc_perm 0660 slave cid_dsp bindings { 0 5 } }
pcm.rt { type plug slave.pcm rt_channel }
The underlying hardware looks like this:
access: MMAP_INTERLEAVED format: S16_LE subformat: STD channels: 8 rate: 44100 (44100/1) period_size: 1024 buffer_size: 4096
tstamp_mode: ENABLE period_step: 1 avail_min: 1 start_threshold: 1 stop_threshold: 1073741824 silence_threshold: 0 silence_size: 0 boundary: 1073741824
Thanks for any insight and help,
Rob.