[gst-devel] sample caching

[Lennart Poettering]

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.

Lennart

-- 
name { Lennart Poettering } loc { Hamburg - Germany }
mail { mzft (at) 0pointer (dot) de } gpg { 1A015CC4 }  
www { http://0pointer.de/lennart/ } icq# { 11060553 }