[alsa-devel] [pulseaudio-discuss] Documentation for how rewinding works

[Tanu Kaskinen]

On Wed, 2012-08-22 at 09:14 +0800, Raymond Yau wrote:
> 2012-8-19 下午7:17 於 "Tanu Kaskinen" <tanuk at iki.fi> 寫道：
> >
> > Hi,
> >
> > While reviewing a rewind related patch, I noticed that I don't
> > understand the rewinding code thoroughly, even though I have studied it
> > a few times in the past. I decided that I should write a wiki page for
> > the code so that working with it would be easier in the future for me
> > and everybody else.
> >
> > So, here's the result:
> >
> http://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/Developer/Rewinding
> >
> > While doing that, I found quite a few bugs, which are noted on that
> > page. I don't plan fixing them any time soon (help with that would be
> > very welcome), so I will just file bugs about the issues so that they
> > are not forgotten.
> >
> it seem that the alsa sink is more complicated than your figure.

The fact that there's a region in the beginning of the sink buffer that
shouldn't be rewound is an implementation detail of alsa sink, and does
not need to be taken into account in the general rewind handling. The
alsa sink is able to take care of it internally.

> Refer to figure 14 HD Audio DMA and buffering , section 4.6 Energy
> Efficient HA audio mechanism
> 
> most sound cards have fixed size FIFO buffer instead of dynamic FIFO and
> minimum transfer size(brust) similar to hda controller which snd_pcm_rewind
> cannot rewind any audio data in those first in first out buffer.
> 
> http://cgit.freedesktop.org/pulseaudio/pulseaudio/commit/src/modules/alsa?id=4df443bbe682055a41e7c2248877dcc7682a69b8

Thanks for bringing that commit into attention, because it seems to
introduce a new bug (although judging from the commit message, Pierre
was aware of it and considered it a feature): the code doesn't take
tsched_watermark into account anymore when doing rewinds. The point of
tsched_watermark is to ensure that pulseaudio has enough time to fill
the sink buffer. If it's ignored when rewinding, it's likely that there
will be an underrun when refilling the sink buffer, if tsched_watermark
is greater than rewind_safeguard.

> 1) do the server really need to rewind when there is only one pulse client ?

Yes. The sink buffer may have up to 2 seconds of audio from the one
pulse client, and if you then change the software volume of the sink (or
sink input, doesn't matter), you will have to rewrite the sink buffer
contents unless you want to wait 2 seconds until the volume change
becomes audible.

> 2) does pulseaudio add this rewind safeguard delay to the latency ?

Unless I'm misunderstanding what you mean by "the latency", the rewind
safeguard doesn't add any latency, so there's nothing to worry about.

-- 
Tanu