[gst-devel] pulsesink optimizations

[Lennart Poettering]

On Thu, 15.10.09 00:48, René Stadler (mail at renestadler.de) wrote:

> >I finally took the time to look at the code and check what was going
> >on. It seems that the overhead is mainly due to the granularity of
> >transfers between pulsesink and PulseAudio. What happens is that the
> >sink waits for space available in the PulseAudio buffer. When PA
> >requests data in a callback, the mainloop unblocks and the sink writes
> >its PCM to PulseAudio. The problem is that the sink will not try to
> >fill the whole buffer before handing-off the data to PulseAudio. For
> >example, say PulseAudio requests 100k (as defined by minreq) and you
> >are doing MP3 decode, you are going to send one frame (4608 bytes) at
> >a time to PulseAudio until the 100k have been filled. That's a lot of
> >overhead. It would be a lot more efficient power-wise to decode and
> >store as many frames as possible into the PA buffer before calling
> >pa_stream_write().
> 
> Wim just committed my patch that changes pulsesink back to set the
> minreq to the value of the latency-time property, which lets
> applications tune the gst<->pa overhead again.

In this context: a few days ago I wrote up this wiki page which tries
to explain how to
configure latency properly for pa streams:

http://pulseaudio.org/wiki/LatencyControl

> During the investigation of that regression, I found that there is
> some further things to optimize in pulsesink. I will be filing more
> bugs and sending more patches as I come up with better solutions.

BTW, any chance I could be subscribed automatically to all bugs
regarding pulsesink? Anyone knows if gnome bz can do that?

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/           GnuPG 0x1A015CC4