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
