[gst-devel] [pulseaudio-discuss] [PATCH 0/3] Fighting rewinds

[Arun Raghavan]

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