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

[Lu Guanqun]

On Sat, Jun 18, 2011 at 12:49:33AM +0800, David Henningsson wrote:
<snip>
> 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.

Thanks for the info.

The phenomenon here is it will rewind for ever, while the CPU load is
not very high. Maybe my test time should last longer.

> 
> 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.

So is it supposed to be the bigger buffer in pulsesink, the less number
of rewind it will encounter?

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

-- 
guanqun