GStreamer-devel

Re: [pulseaudio-discuss] [PATCH 0/3] Fighting rewinds

Classic

List

Threaded

6 messages Options

David Henningsson

Re: [pulseaudio-discuss] [PATCH 0/3] Fighting rewinds

[adding gstreamer-devel to the discussion]

On 2010-12-09 17:18, pl bossart wrote:
>> However, the problem is quite complex and there does not seem to be one
>> perfect fix, it's more of an optimisation problem. GStreamer in particular
>> sends out many small data packages, and PulseAudio does not handle that very
>> well.
>
> That's the default behavior, but you can cut the traffic by using the
> latency-time property in pulsesink. This makes sure you send bigger
> buffers, up to the 64k limit that PulseAudio has internally.

Thanks, that's good to know. Now, I'm just playing a simple audio file
with totem, so obviously we want high latency and large packet sizes,
but I'm not a gstreamer developer - do you have an idea of what can be
at fault here? Should totem specify a big packet size (regardless of
sink?), or can we just change the default packet size to something big
for people not requesting anything in particular?

--
David Henningsson, Canonical Ltd.
http://launchpad.net/~diwic

------------------------------------------------------------------------------
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

pl bossart

Re: [pulseaudio-discuss] [PATCH 0/3] Fighting rewinds

>>> However, the problem is quite complex and there does not seem to be one
>>> perfect fix, it's more of an optimisation problem. GStreamer in
>>> particular
>>> sends out many small data packages, and PulseAudio does not handle that
>>> very
>>> well.
>>
>> That's the default behavior, but you can cut the traffic by using the
>> latency-time property in pulsesink. This makes sure you send bigger
>> buffers, up to the 64k limit that PulseAudio has internally.
>
> Thanks, that's good to know. Now, I'm just playing a simple audio file with
> totem, so obviously we want high latency and large packet sizes, but I'm not
> a gstreamer developer - do you have an idea of what can be at fault here?
> Should totem specify a big packet size (regardless of sink?), or can we just
> change the default packet size to something big for people not requesting
> anything in particular?

The default pulsesink settings for latency/buffering are inherited
from a base class. I would agree with you that they should be large by
default and decreased explicitly when the application wants
low-latency (gaming, speech), but the opposite is done...
It's my understanding that higher-level components in the Meego/Qt
stack will specify bigger buffers/higher latencies, but for people who
use plain vanilla gstreamer optimizing for power requires a bit of
knowledge and manual configurations. This is unfortunate since every
single player will need to repeat this configuration.
-Pierre

------------------------------------------------------------------------------
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

Stefan Sauer

Re: [pulseaudio-discuss] [PATCH 0/3] Fighting rewinds

Am 10.12.2010 17:37, schrieb pl bossart:

>>>> However, the problem is quite complex and there does not seem to be one
>>>> perfect fix, it's more of an optimisation problem. GStreamer in
>>>> particular
>>>> sends out many small data packages, and PulseAudio does not handle that
>>>> very
>>>> well.
>>>
>>> That's the default behavior, but you can cut the traffic by using the
>>> latency-time property in pulsesink. This makes sure you send bigger
>>> buffers, up to the 64k limit that PulseAudio has internally.
>>
>> Thanks, that's good to know. Now, I'm just playing a simple audio file with
>> totem, so obviously we want high latency and large packet sizes, but I'm not
>> a gstreamer developer - do you have an idea of what can be at fault here?
>> Should totem specify a big packet size (regardless of sink?), or can we just
>> change the default packet size to something big for people not requesting
>> anything in particular?
>
> The default pulsesink settings for latency/buffering are inherited
> from a base class. I would agree with you that they should be large by
> default and decreased explicitly when the application wants
> low-latency (gaming, speech), but the opposite is done...
> It's my understanding that higher-level components in the Meego/Qt
> stack will specify bigger buffers/higher latencies, but for people who
> use plain vanilla gstreamer optimizing for power requires a bit of
> knowledge and manual configurations. This is unfortunate since every
> single player will need to repeat this configuration.
> -Pierre

We could consider tweaking the settings on the high-level bins. I mean after all
playbin2 is used for playback of media, so it could select a high latency (at
least a higher default). Imho farsight would alreday set a low latency on the
pulsesrc/sink.

Stefan

------------------------------------------------------------------------------
Oracle to DB2 Conversion Guide: Learn learn about native support for PL/SQL,
new data types, scalar functions, improved concurrency, built-in packages,
OCI, SQL*Plus, data movement tools, best practices and more.
http://p.sf.net/sfu/oracle-sfdev2dev
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

David Henningsson

Re: [pulseaudio-discuss] [PATCH 0/3] Fighting rewinds

In reply to this post by pl bossart

On 2010-12-10 16:37, pl bossart wrote:

Hmm, I enabled gstreamer debugging and spotted this (this is from an ogg
file playback in totem):

pulsesink.c:718:gst_pulseringbuffer_acquire:<autoaudiosink1-actual-sink-pulse>
tlength: 70560
pulsesink.c:719:gst_pulseringbuffer_acquire:<autoaudiosink1-actual-sink-pulse>
maxlength: -1
pulsesink.c:720:gst_pulseringbuffer_acquire:<autoaudiosink1-actual-sink-pulse>
prebuf: 0
pulsesink.c:721:gst_pulseringbuffer_acquire:<autoaudiosink1-actual-sink-pulse>
minreq: 3528

So tlength is actually reasonable. This means we have a segsize of 3528
and a segtotal of 20, then look at this code in gst_pulseringbuffer_commit:

/* Only ever write segsize bytes at once. This will
* also limit the PA shm buffer to segsize
*/
if (towrite > buf->spec.segsize)
towrite = buf->spec.segsize;

...I'm not sure whether it is the segtotal=20 that's unreasonable, or if
these lines are the offending ones, but the combination is actually
causing gstreamer to send 20 small packets instead of one big packet =>
unnecessary overhead (and PA rewinds if we're not enough ahead).

I tried changing "buf->spec.segsize" into "bufsize" (i e segsize *
segtotal) and it started writing 8192 bytes at a time instead of 3528,
which is slightly better, but still way far from tlength (or tlength/2,
tlength/4, or whatever is an optimal number of segments).

--
David Henningsson, Canonical Ltd.
http://launchpad.net/~diwic

------------------------------------------------------------------------------
Oracle to DB2 Conversion Guide: Learn learn about native support for PL/SQL,
new data types, scalar functions, improved concurrency, built-in packages,
OCI, SQL*Plus, data movement tools, best practices and more.
http://p.sf.net/sfu/oracle-sfdev2dev
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

David Henningsson

Re: [pulseaudio-discuss] [PATCH 0/3] Fighting rewinds

On 2010-12-12 22:01, David Henningsson wrote:

> On 2010-12-10 16:37, pl bossart wrote:
>>>>> However, the problem is quite complex and there does not seem to be one
>>>>> perfect fix, it's more of an optimisation problem. GStreamer in
>>>>> particular
>>>>> sends out many small data packages, and PulseAudio does not handle that
>>>>> very
>>>>> well.
>>>>
>>>> That's the default behavior, but you can cut the traffic by using the
>>>> latency-time property in pulsesink. This makes sure you send bigger
>>>> buffers, up to the 64k limit that PulseAudio has internally.
>>>
>>> Thanks, that's good to know. Now, I'm just playing a simple audio file with
>>> totem, so obviously we want high latency and large packet sizes, but I'm not
>>> a gstreamer developer - do you have an idea of what can be at fault here?
>>> Should totem specify a big packet size (regardless of sink?), or can we just
>>> change the default packet size to something big for people not requesting
>>> anything in particular?
>>
>> The default pulsesink settings for latency/buffering are inherited
>> from a base class. I would agree with you that they should be large by
>> default and decreased explicitly when the application wants
>> low-latency (gaming, speech), but the opposite is done...
>> It's my understanding that higher-level components in the Meego/Qt
>> stack will specify bigger buffers/higher latencies, but for people who
>> use plain vanilla gstreamer optimizing for power requires a bit of
>> knowledge and manual configurations. This is unfortunate since every
>> single player will need to repeat this configuration.
>> -Pierre
>>
>
> Hmm, I enabled gstreamer debugging and spotted this (this is from an ogg
> file playback in totem):
>
> pulsesink.c:718:gst_pulseringbuffer_acquire:<autoaudiosink1-actual-sink-pulse>
> tlength: 70560
> pulsesink.c:719:gst_pulseringbuffer_acquire:<autoaudiosink1-actual-sink-pulse>
> maxlength: -1
> pulsesink.c:720:gst_pulseringbuffer_acquire:<autoaudiosink1-actual-sink-pulse>
> prebuf: 0
> pulsesink.c:721:gst_pulseringbuffer_acquire:<autoaudiosink1-actual-sink-pulse>
> minreq: 3528
>
> So tlength is actually reasonable. This means we have a segsize of 3528
> and a segtotal of 20, then look at this code in gst_pulseringbuffer_commit:
>
> /* Only ever write segsize bytes at once. This will
> * also limit the PA shm buffer to segsize
> */
> if (towrite> buf->spec.segsize)
> towrite = buf->spec.segsize;
>
> ...I'm not sure whether it is the segtotal=20 that's unreasonable, or if
> these lines are the offending ones, but the combination is actually
> causing gstreamer to send 20 small packets instead of one big packet =>
> unnecessary overhead (and PA rewinds if we're not enough ahead).
>
> I tried changing "buf->spec.segsize" into "bufsize" (i e segsize *
> segtotal) and it started writing 8192 bytes at a time instead of 3528,
> which is slightly better, but still way far from tlength (or tlength/2,
> tlength/4, or whatever is an optimal number of segments).
>

Hi Pierre and rest of gstreamer-devel,

Given the discussion above, did you have any time to do more thinking
about it? I'm attaching a simple patch. Some testing of that patch
hasn't reported any regressions, and it does start to send larger
packages (which in turn saves PA from additional packet overhead).
I'm attaching a patch for Ubuntu, but given that I give you a proper git
header etc to that patch, would the folks here apply it?

// David

------------------------------------------------------------------------------
Gaining the trust of online customers is vital for the success of any company
that requires sensitive data to be transmitted over the Web. Learn how to
best implement a security strategy that keeps consumers' information secure
and instills the confidence they need to proceed with transactions.
http://p.sf.net/sfu/oracle-sfdevnl
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

default-buffer-size.patch (2K) Download Attachment

Arun Raghavan

Re: [pulseaudio-discuss] [PATCH 0/3] Fighting rewinds

On Mon, 2011-01-10 at 10:24 -0600, David Henningsson wrote:
> On 2010-12-12 22:01, David Henningsson wrote:
[...]

> > Hmm, I enabled gstreamer debugging and spotted this (this is from an ogg
> > file playback in totem):
> >
> > pulsesink.c:718:gst_pulseringbuffer_acquire:<autoaudiosink1-actual-sink-pulse>
> > tlength: 70560
> > pulsesink.c:719:gst_pulseringbuffer_acquire:<autoaudiosink1-actual-sink-pulse>
> > maxlength: -1
> > pulsesink.c:720:gst_pulseringbuffer_acquire:<autoaudiosink1-actual-sink-pulse>
> > prebuf: 0
> > pulsesink.c:721:gst_pulseringbuffer_acquire:<autoaudiosink1-actual-sink-pulse>
> > minreq: 3528
> >
> > So tlength is actually reasonable. This means we have a segsize of 3528
> > and a segtotal of 20, then look at this code in gst_pulseringbuffer_commit:
> >
> > /* Only ever write segsize bytes at once. This will
> > * also limit the PA shm buffer to segsize
> > */
> > if (towrite> buf->spec.segsize)
> > towrite = buf->spec.segsize;
> >
> > ...I'm not sure whether it is the segtotal=20 that's unreasonable, or if
> > these lines are the offending ones, but the combination is actually
> > causing gstreamer to send 20 small packets instead of one big packet =>
> > unnecessary overhead (and PA rewinds if we're not enough ahead).
> >
> > I tried changing "buf->spec.segsize" into "bufsize" (i e segsize *
> > segtotal) and it started writing 8192 bytes at a time instead of 3528,
> > which is slightly better, but still way far from tlength (or tlength/2,
> > tlength/4, or whatever is an optimal number of segments).
> >
>
> Hi Pierre and rest of gstreamer-devel,
>
> Given the discussion above, did you have any time to do more thinking
> about it? I'm attaching a simple patch. Some testing of that patch
> hasn't reported any regressions, and it does start to send larger
> packages (which in turn saves PA from additional packet overhead).
> I'm attaching a patch for Ubuntu, but given that I give you a proper git
> header etc to that patch, would the folks here apply it?

Ultimately, the size of the write also depends on the number of samples
passed to the sink from the decoder, and there is currently no way to
negotiate this (it's something being looked at for GStreamer 1.0,
though).

That said, IMO this patch makes sense - I see no reason to not push as
much data as possible on each iteration.

-- Arun

------------------------------------------------------------------------------
Protect Your Site and Customers from Malware Attacks
Learn about various malware tactics and how to avoid them. Understand
malware threats, the impact they can have on your business, and how you
can protect your company and customers by using code signing.
http://p.sf.net/sfu/oracle-sfdevnl
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel