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
