[pulseaudio-discuss] how's fighting rewind going?

[David Henningsson]

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.com at lists.freedesktop.org
>> [mailto:pulseaudio-discuss-bounces+mengdong.lin=intel.com at lists.freedesk
>> 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
>> pulseaudio-discuss at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
> _______________________________________________
> pulseaudio-discuss mailing list
> pulseaudio-discuss at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
>


-- 
David Henningsson, Canonical Ltd.
http://launchpad.net/~diwic