On 2011-06-20 03:15, Lin, Mengdong wrote:
Hi David,
Where can I find your patch for GStreamer and pulseaudio?
Thanks
Amanda
The PulseAudio patches have been committed:
http://cgit.freedesktop.org/pulseaudio/pulseaudio/commit/?id=fe7b972487bfc85940d2d427096fd9189af3bd7a
and
http://cgit.freedesktop.org/pulseaudio/pulseaudio/commit/?id=74eb4d892137f6ba4d87b011e46118668187307b
The GStreamer patch is here:
http://bugzilla-attachments.gnome.org/attachment.cgi?id=179744
-----Original Message-----
From:
pulseaudio-discuss-bounces+mengdong.lin=intel....@lists.freedesktop.org
[mailto:[email protected]
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
[email protected]
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
_______________________________________________
pulseaudio-discuss mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
--
David Henningsson, Canonical Ltd.
http://launchpad.net/~diwic
_______________________________________________
pulseaudio-discuss mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
