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
