[gstreamer-bugs] [Bug 597601] New: [pulsesink] needs to take control of minreq value
GStreamer (bugzilla.gnome.org)
bugzilla at gnome.org
Tue Oct 6 12:56:50 PDT 2009
https://bugzilla.gnome.org/show_bug.cgi?id=597601
GStreamer | gst-plugins-good | git
Summary: [pulsesink] needs to take control of minreq value
Classification: Desktop
Product: GStreamer
Version: git
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: Normal
Component: gst-plugins-good
AssignedTo: gstreamer-bugs at lists.sourceforge.net
ReportedBy: mail at renestadler.de
QAContact: gstreamer-bugs at lists.sourceforge.net
GNOME target: ---
GNOME version: ---
Created an attachment (id=144911)
--> (https://bugzilla.gnome.org/attachment.cgi?id=144911)
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.
--
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.
More information about the Gstreamer-bugs
mailing list