[gst-devel] sample caching

[Benjamin Otte]

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
http://web.verbum.org/blog/2004/Nov/12#transitive-threadunsafeness

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.

Benjamin