[alsa-devel] snd_pcm_rewind() weirdness
Hey!
On ALSA 1.0.16 with the HDA driver I am experiencing some weird things with snd_pcm_rewind() which I think are the result of a kernel bug, but I am not sure.
Here's what I do to trigger this:
I play some PCM. Eventually I want to rewrite what I already have written. I call snd_pcm_hwsync() and then snd_pcm_avail_update() to determine how "empty" the playback buffer is. I subtract that value from the total buffer size. The resulting value should be something resembling the number of frames that I might be able to rewind. I then subtract enough frames to keep away from the playback pointer far enough (50ms, the playback buffer is 370ms, period is 185ms).
Now I pass that value to snd_pcm_rewind() and it returns something that is higher than what I passed in. Which I find quite surprising. I had expected that the returned value could be equal or smaller than what I passed in, but never higher!
So, my interpretation of the API was apparently wrong. It looks like on HDA the snd_pcm_rewind() parameter is apparently rounded *up* to the next period boundary (which in this case was equivalent to the *entire* buffer)?
Of course, rewinding that far immediately caused an XRUN. Which is why I think rounding up in this cases is a bad idea and the API shouldn't work this way. Rounding down is OK, rounding up is call for trouble.
To tape over this I added some code to immediately call snd_pcm_forward() with the difference if I noticed that the device forwarded more than I requested. This value also got rounded up -- to twice the period size. So with this backward+forward operation I ended up at a frame index that is farther ahead than where I originally came from!
So, what's the expected behaviour of snd_pcm_rewind()? Always round up? What's the rationale behind this?
If this is not a bug but expected behaviour, could we at least add something for passing the direction to round to?
What I am working on is the "glitch-free" playback model in PulseAudio (http://0pointer.de/blog/projects/pulse-glitch-free.html). To do this I am writing blocks smaller than the period size to the device via the mmap interface all the time. Given that on HDA _rewind() is apparently not granular to the frame size, is writing via mmap in small blocks like that OK? If it's not, how can I learn about this in advance?
Lennart
On Sun, 20 Apr 2008, Lennart Poettering wrote:
Hey!
On ALSA 1.0.16 with the HDA driver I am experiencing some weird things with snd_pcm_rewind() which I think are the result of a kernel bug, but I am not sure.
What alsa-lib plugins are on path? It looks like a rate plugin issue. Post also snd_pcm_dump() output. Driver does not do any alignment.
Jaroslav
----- Jaroslav Kysela perex@perex.cz Linux Kernel Sound Maintainer ALSA Project, Red Hat, Inc.
On Mon, 21.04.08 08:58, Jaroslav Kysela (perex@perex.cz) wrote:
On Sun, 20 Apr 2008, Lennart Poettering wrote:
Hey!
On ALSA 1.0.16 with the HDA driver I am experiencing some weird things with snd_pcm_rewind() which I think are the result of a kernel bug, but I am not sure.
What alsa-lib plugins are on path? It looks like a rate plugin issue. Post also snd_pcm_dump() output. Driver does not do any alignment.
It's front:0. I don't think the rate plugin is used.
Device is being opened with SND_PCM_NO_AUTO_RESAMPLE|SND_PCM_NO_AUTO_CHANNELS|SND_PCM_NO_AUTO_FORMAT and snd_pcm_hw_params_set_rate_resample(..., 0).
That should get me only softvol, right?
The output of snd_pcm_dump() is here (please ignore the "D: alsa-util.c" prefix)
<snip> D: alsa-util.c: Soft volume PCM D: alsa-util.c: Control: PCM Playback Volume D: alsa-util.c: min_dB: -51 D: alsa-util.c: max_dB: 0 D: alsa-util.c: resolution: 256 D: alsa-util.c: Its setup is: D: alsa-util.c: stream : PLAYBACK D: alsa-util.c: access : MMAP_INTERLEAVED D: alsa-util.c: format : S16_LE D: alsa-util.c: subformat : STD D: alsa-util.c: channels : 2 D: alsa-util.c: rate : 44100 D: alsa-util.c: exact rate : 44100 (44100/1) D: alsa-util.c: msbits : 16 D: alsa-util.c: buffer_size : 16384 D: alsa-util.c: period_size : 8192 D: alsa-util.c: period_time : 185759 D: alsa-util.c: tstamp_mode : NONE D: alsa-util.c: period_step : 1 D: alsa-util.c: avail_min : 31001 D: alsa-util.c: start_threshold : -1 D: alsa-util.c: stop_threshold : -1 D: alsa-util.c: silence_threshold: 0 D: alsa-util.c: silence_size : 0 D: alsa-util.c: boundary : 4611686018427387904 D: alsa-util.c: Slave: Hardware PCM card 4 'HDA Intel' device 0 subdevice 0 D: alsa-util.c: Its setup is: D: alsa-util.c: stream : PLAYBACK D: alsa-util.c: access : MMAP_INTERLEAVED D: alsa-util.c: format : S16_LE D: alsa-util.c: subformat : STD D: alsa-util.c: channels : 2 D: alsa-util.c: rate : 44100 D: alsa-util.c: exact rate : 44100 (44100/1) D: alsa-util.c: msbits : 16 D: alsa-util.c: buffer_size : 16384 D: alsa-util.c: period_size : 8192 D: alsa-util.c: period_time : 185759 D: alsa-util.c: tstamp_mode : NONE D: alsa-util.c: period_step : 1 D: alsa-util.c: avail_min : 31001 D: alsa-util.c: start_threshold : -1 D: alsa-util.c: stop_threshold : -1 D: alsa-util.c: silence_threshold: 0 D: alsa-util.c: silence_size : 0 D: alsa-util.c: boundary : 4611686018427387904 </snip>
Lennart
On Thu, 24.04.08 02:34, Lennart Poettering (mznyfn@0pointer.de) wrote:
Hey!
On ALSA 1.0.16 with the HDA driver I am experiencing some weird things with snd_pcm_rewind() which I think are the result of a kernel bug, but I am not sure.
What alsa-lib plugins are on path? It looks like a rate plugin issue. Post also snd_pcm_dump() output. Driver does not do any alignment.
It's front:0. I don't think the rate plugin is used.
OK, I just checked this with using hw:0, i.e. without softvol in the path. That seems to fix the problem, so I guess softvol is to blame.
BTW: any comment regarding http://mailman.alsa-project.org/pipermail/alsa-devel/2008-April/007354.html?
Lennart
participants (2)
-
Jaroslav Kysela -
Lennart Poettering