[pulseaudio-discuss] how's fighting rewind going?

[David Henningsson]

On 2011-06-17 09:13, Lu Guanqun wrote:
> Hi David,
>
> On Fri, Jun 17, 2011 at 02:31:41PM +0800, David Henningsson wrote:
>> On 2011-06-17 02:21, Lu Guanqun wrote:
>>> Hi David,
>>>
>>> How's your fighting rewind going?
>>>
>>> Now, I find there's a rewind flood in my environment, and it's doing a
>>> rewrite rewind all the times. At the time of rewinding, the write index
>>> is less than the read index.
>>>
>>> Do you have any idea what's going on? I'm only seeing this when I'm
>>> viewing an 1080p MP4 file.
>>>
>>> Thanks!
>>
>> Hi Lu,
>>
>> My patches has been optimisations so far, which means that it's reducing
>> the amount of rewinds rather than eliminating them. With a slow enough
>> computer (for Intel, the Atom comes to mind), or lots of other things to
>> do for that computer (such as viewing an 1080p file?), the rewind flood
>> thing can still happen.
>
> Oh, man, you totally got me. :) I'm playing 1080p on an Atom based machine.
> I find the rewind flood on this platform. For 480p video, it works quite
> fine.
>
>>
>> What client are you using to connect to PulseAudio? For gstreamer based
>> clients, my gstreamer patch was first applied upstream, then reverted
>> for reasons I don't fully understand. Applying it is likely to help
>> against rewinds. See bug https://bugzilla.gnome.org/show_bug.cgi?id=641072
>
> Yes, I used gstreamer clients. FYI. The two patches on pulesaudio are
> already applied.  However, no matter when I applied the gstreamer patch,
> the rewind flood still can be seen.
>
> As you said, you're doing optimizations. Is there a way to fully solve
> this issue, or this is just a mission impossible per your understanding?

Nothing is impossible, the impossible just takes slightly longer to fix :-)

Lately I've been thinking that we should implement some kind of 
ratelimit to rewinding as well. Something like; if we've done 10 rewinds 
during the latest second, block rewinds for the upcoming second. That 
would give a "hickup" (likely temporary silence), but not complete 
brokenness.
In combination with the existing patches, I believe that would give 
sufficient protection. I haven't figured out, however, what would be the 
right numbers for a particular machine.

The best thing you can do for now, however, is to make sure the client 
sends large packets. I e, rather one packet per second with one second 
of sample data in it, than a hundred packets with 10 ms of sample data 
in it.


-- 
David Henningsson, Canonical Ltd.
http://launchpad.net/~diwic