[alsa-devel] Available frames > buffer size

[Rob Duncan]

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.