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
