All of lore.kernel.org
 help / color / mirror / Atom feed
* snd_pcm_rewind() weirdness
@ 2008-04-19 23:37 Lennart Poettering
  2008-04-21  6:58 ` Jaroslav Kysela
  0 siblings, 1 reply; 4+ messages in thread
From: Lennart Poettering @ 2008-04-19 23:37 UTC (permalink / raw)
  To: ALSA Development Mailing List

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

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net         ICQ# 11060553
http://0pointer.net/lennart/           GnuPG 0x1A015CC4

^ permalink raw reply	[flat|nested] 4+ messages in thread
end of thread, other threads:[~2008-04-24  0:38 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-04-19 23:37 snd_pcm_rewind() weirdness Lennart Poettering
2008-04-21  6:58 ` Jaroslav Kysela
2008-04-24  0:34   ` Lennart Poettering
2008-04-24  0:38     ` Lennart Poettering

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.