On 2011-06-20 03:15, Lin, Mengdong wrote: > Hi David, > > Where can I find your patch for GStreamer and pulseaudio? > > Thanks > Amanda The PulseAudio patches have been committed: http://cgit.freedesktop.org/pulseaudio/pulseaudio/commit/?id=fe7b972487bfc85940d2d427096fd9189af3bd7a and http://cgit.freedesktop.org/pulseaudio/pulseaudio/commit/?id=74eb4d892137f6ba4d87b011e46118668187307b The GStreamer patch is here: http://bugzilla-attachments.gnome.org/attachment.cgi?id=179744 > >> -----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 > _______________________________________________ > pulseaudio-discuss mailing list > pulseaudio-discuss at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss > -- David Henningsson, Canonical Ltd. http://launchpad.net/~diwic
