[gst-devel] Problems with ringbuffer management on systems with large audio buffers

Thomas Vander Stichele thomas at apestaart.org
Fri Apr 14 14:54:01 CEST 2006


> >> I'm forwarding the following comment from the 
> >> desktop-discuss at opensolaris.org alias regarding the fact that GStreamer
> >> audio has a lag.  Because the sunaudiosink needs to set the ringbuffer
> >> size to 512K,
> > 
> > 512K is more than 3 seconds at 44.1 kHz 16 bit stereo.  What possible
> > reason is there for sunaudiosink to need that much ?
> That must simply be the size of the audio output buffer.  If I set it
> to anything smaller, I hear stutters in the audio playback.

I think you've mentioned this before, but it still doesn't make any
sense.  You really should start here first and get to the root of this
problem.  Seriously - there is not a single OS/system where 3 seconds of
buffering is needed to have stutterless playback.  I simply can't
believe that your process regularly does not get scheduled for that
amount of time by the kernel.  Something else is wrong.

> It doesn't seem that SunAudio interfaces allow you to set the audio
> output buffer to anything smaller.

How does this relate to the previous statement ? Does the code for
SunAudio not allow you to choose smaller values somehow?

> So, if I hack sunaudiosink to expose the mixer interface, then I can
> make the sunaudiosink always modify the system volume even when a
> user changes it in an appliction?

Your sink uses a sun-specific backend. This sun-specific backend I
assume has functions that allow you to change hardware volume settings.
Compare to our alsa and oss plug-ins.

>   Is that how it would work?  Do
> you know if there is an example of this in GStreamer I could base
> the code from?  Also do you know if rhythmbox and totem support
> this?

AFAIK most gnome applications request something out of the decoding
pipeline that implements the mixer interface.  It may be that most of
them prefer a software mixer (which is implemented by volume) over a
hardware mixer, precisely because this allows for per-application volume
settings, which is probably what end users want.

So, while to be a good audio sink, your sink should export the mixer
capabilities of your audio backend, I still think you really should
invest in figuring out the original problem.


More information about the gstreamer-devel mailing list