[gstreamer-bugs] [Bug 597601] New: [pulsesink] needs to take control of minreq value

[GStreamer (bugzilla.gnome.org)]

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.