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.
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
