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

[Lu Guanqun]

On Fri, Jun 17, 2011 at 03:43:53PM +0800, David Henningsson wrote:
> 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 :-)

Definitely. :)

> 
> 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.

Thanks for the idea, let me try on this direction.
BTW: is smaller packet the root cause of infinite rewrite rewind? Could
you elaborate the overall process in a little more detail? It makes me
think it's due to the wrong corporation between pulseaudio and gstreamer
client.

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

-- 
guanqun