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.