GNOME Bugzilla – Bug 597463
[pulsesrc] has no lower bound for fragment size
Last modified: 2009-10-06 17:59:15 UTC
Since -good commit 1a8938 ("pulsesrc; cleanups, report real latency"), pulsesrc surrenders control of the segsize to pulseaudio. The latency-time value is given to pulse as a suggestion, but the actual value returned by PA is blindly accepted. This can have bad results for applications with higher latency requirements (intended to reduce buffer handling overhead). I'm mostly thinking about Maemo 5/N900 here, which has the corner case of a pulseaudio that is configured to have a 10ms fixed latency source (this will be fixed in the future). Since this a battery powered device, no application really wants to actually deal with 10ms audio buffers (not even for VoIP calls), so we trade in a little latency for some CPU load and battery life. Attaching proposed patch. The idea is to set the ring buffer segsize to a larger value if pulseaudio picks a fragsize that is too low. This results in the ring buffer transparently joining the smaller buffers coming from pulseaudio into GStreamer buffers of duration equal or close to the requested latency-time.
Created attachment 144831 [details] [review] Proposed patch
This makes sense. If the user requested 20ms, it's better to give him 20ms even if we can give him 10ms.
commit 15c6175044d1a308eb463347cd8d4c88b53ecb35 Author: René Stadler <mail@renestadler.de> Date: Fri Oct 2 23:51:29 2009 +0300 pulsesrc: guard fragment size with a lower limit based on latency-time In case that the pulse daemon runs the source device at a relatively low fixed fragment size compared to the requested latency-time, configure the ring buffer segsize to the largest integer multiple of the fragment size that is still smaller than or equal to the requested latency-time. Fixes bug #597463.