[gst-devel] sample caching

Benjamin Otte in7y118 at public.uni-hamburg.de
Fri Nov 26 03:01:49 CET 2004

On Thu, 25 Nov 2004, Lennart Poettering wrote:

> On Thu, 25.11.04 00:02, Colin Walters (walters at redhat.com) wrote:
> >
> > > We could then add _one_ interface to each element that requests the audio
> > > framework. After that we could nicely query the framework about supported
> > > capabilities and also add capabilities later on without the need to
> > > fiddle with the elements and risking to break playback with every change.
> >
> > Why not do it the other way around: Make GstAudioFramework a first-class
> > object (plugin) and have methods for retrieving the source, sink, volume
> > control, and sample caching elements.  This is conceptually cleaner I
> > think because that way they can easily share data such as a connection
> > to the sound server, or an open fd on a sound device.
> I support this. Polypaudio has the ability to attach multiple streams
> to a single connection socket. Currently there's no way of making use
> of that via the gstreamer API. Each instance of polypsink has its own
> network socket and its own playback stream.
Which I think is a good idea, because different elements might run in
different threads and we don't want to end up with something like

Ressource sharing between different elements nearly always requires locks,
so most of the time it's pretty useless performance-wise to do so.
And it's far easier to debug, too.


More information about the gstreamer-devel mailing list