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

[Lin, Mengdong]

Hi David,

Where can I find your patch for GStreamer and pulseaudio?

Thanks
Amanda

> -----Original Message-----
> From:
> pulseaudio-discuss-bounces+mengdong.lin=intel.com at lists.freedesktop.org
> [mailto:pulseaudio-discuss-bounces+mengdong.lin=intel.com at lists.freedesk
> top.org] On Behalf Of David Henningsson
> Sent: Saturday, June 18, 2011 12:50 AM
> To: Lu, Guanqun
> Cc: General PulseAudio Discussion
> Subject: Re: [pulseaudio-discuss] how's fighting rewind going?
> 
> On 2011-06-17 16:22, Lu Guanqun wrote:
> > 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.
> 
> PulseAudio has some packet overhead, and rewinding has some extra
> overhead. Here's how it gets stuck:
> 
> When PulseAudio's buffer is empty, and a new packet comes in that is to
> be played immediately, that causes a rewind. Now assume this packet is
> so small, that by the time PulseAudio gets to process the next packet,
> the buffer is empty again, because the few samples added have already
> been played. Then a new rewind will be triggered, and this goes on and
> on until the kernel kills PA for having used too much CPU with realtime
> priority.
> 
> So, the time taken to process the packet, including the rewind, and
> possibly also time stolen by other processes etc, must be less than the
> time taken to play back the samples that the packet carries. (And
> probably with a decent margin.)
> 
> What my PA patch does is to try to merge several packets that PA has in
> its processing queue so it will only do rewind once.
> What my GStreamer patch should do, is to remove some strange packet
> splitter in the pulsesink end, but I might have misunderstood something
> since it got reverted. It did however help me, and quite a few other
> people as well, so it's still in Ubuntu.
> 
> --
> David Henningsson, Canonical Ltd.
> http://launchpad.net/~diwic
> _______________________________________________
> pulseaudio-discuss mailing list
> pulseaudio-discuss at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss