[pulseaudio-discuss] Exponential recovering from rewinds

[Tanu Kaskinen]

On Fri, 2010-11-05 at 09:15 -0400, David Henningsson wrote:
> Just following up on an idea brought to my attention at the 
> Ubuntu/Linaro Developer Summit, and I'm not sure whether this is the 
> original idea or if I refined it a little myself. Anyway.
> 
> Since rewinds often come in chunks, and sometimes there are no rewinds 
> for a very long time, it makes sense to not fill up the entire buffer 
> immediately after a rewind. I propose the following algorithm:
> 
> 1. After a rewind, write only 250 ms (or a configurable value) of data 
> to the buffer. Then go to sleep and set to wakeup 250 ms later (minus 
> the tsched watermark).
> 2. Now write 500 ms to the buffer and go to sleep.
> 3. Write 1 s to the buffer and go to sleep, and so on.
> 
> Continue until the entire buffer is filled, and we'll then fall back to 
> normal handling, or if we get a new rewind at any point, start over from 
> point 1.
> 
> This would enable ARM (and others) to go to low-power modes for long 
> periods of time, while not risking to throw away a lot of processing due 
> to several rewinds in a short period of time.
> 
> I briefed Lennart yesterday about this and he seemed positive to the 
> idea, and I guess Linaro are interested in contributing to the 
> implementation.
> 
> Any thoughts, comments etc?

I had the impression that this was already planned by Lennart, and I
haven't heard any objections before, so I think it's quite safe to go
forward and implement this. One thing that wasn't mentioned in your
algorithm was that the tsched watermark should probably increase at
every iteration so that there's a larger safety buffer when working on
rendering 10s of audio than when only 250 ms needs to be rendered.

-- 
Tanu