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 :-) 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. -- David Henningsson, Canonical Ltd. http://launchpad.net/~diwic
