GNOME Bugzilla – Bug 597601
[pulsesink] needs to take control of minreq value
Last modified: 2009-10-14 10:07:48 UTC
Created attachment 144911 [details] [review] Trivial patch Pulsesink was changed recently to pass -1 as the minreq buffer attribute of pulseaudio, which means that the server should select a sensible value. The problem is that there is apparently no way to actually determine what value is sensible and useful. As it turns out, pulseaudio always chooses 20ms currently. This affects mobile/embedded use cases for e.g. long-term music playback. I think it's not so much about sending data in larger chunks to the daemon (the granularity of pa_stream_write is determined by the buffer size of the audio decoder), but it means that bursts of data will be written out in larger intervals if the latency-time is set to larger values. This allows battery-powered devices to perform better power management; I measured an energy consumption penalty of ~10% on the N900 for local file mp3 playback (latency-time=500000 and buffer-time=1000000). Attached is a trivial patch that restores pulsesink to the old setting of passing the segsize as the desired minreq, which means applications can tune the buffer control overhead a bit by playing with the latency-time property again.
Are you certain this doesn't create large latencies or break latency reporting especially related to voip calls ?
No, because for VoIP you can go back to smaller fragsize/minreq by reducing the latency-time.
You are right, we need to be able to control this property ourselves. commit f9274226e807d9fccf2131001c1fb6dbc8e470fc Author: René Stadler <mail@renestadler.de> Date: Tue Oct 6 22:28:50 2009 +0300 pulsesink: set desired minreq value to segsize/latency-time If we let the daemon decide freely by passing -1, we end up always getting 20ms. We want to set this value because in some cases we want to select a higher latency-time in order to save power. Fixes #597601