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
_______________________________________________
pulseaudio-discuss mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
