[gst-devel] sample caching

[Benjamin Otte]

On Tue, 23 Nov 2004, Colin Walters wrote:

> Hi,
>
> I'd like to muse a bit on how GStreamer could expose a sample caching
> API.  One thought is to make this an interface on sink elements.  So
> e.g. polypaudiosink would implement GstSampleCacheInterface, and call
> into the relevant polypaudio functions.  alsasink could just not
> implement it.
>
There is one thing that really annoys me about making these sorts of
interfaces: an audio sink is not a sample cache. We're currently
overloading the functionality of audio sinks heavily. I know that we don't
have a good solution atm, but using interfaces on an audio sink to
indicate capabilities of the audio framework behind it looks like a bad
idea in an architectural POV.
(The same goes for the volume interface btw, an audio sink is not a volume
regulating framework)
This is increasingly annoyiong for me because changes I do to an audio
sink potentially break parts I'd never associate with an audio sink and
weren't aware of.

What I would prefer would be an abstraction that makes audio frameworks a
first class struct in GStreamer.
Kinda like this:
struct GstAudioFramework {
  GType inputelement; /* GST_TYPE_ALSA_SRC */
  GType outputelement; /* GST_TYPE_ALSA_SINK */
  GType volumechanger; /* GST_TYPE_ALSA_MIXER */
  ...
};
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.

As for caching dings in sound servers: I haven't played with the
different sound servers enough to know if it'd be better to have an
element as a "cachesink" or if it would be better to make every audio
framework provide some functions that implement simple things like guint
id = gst_audio_framework_cache_file (framework, filename); and
gst_audio_framework_play_cached_file (framework, id);


> One difficulty here is that apps will just get the sink from GConf,
> which could be a bin containing e.g. audioconvert and audioscale too.
> So we'd need to make GstBin implement GstSampleCacheInterface too, which
> would suck.  Is there a better way?
>
gst_bin_get_by_interface (bin, GST_TYPE_AUDIO_FRAMEWORK_INTERFACE)
or whatever should do the trick.

The thing I'm not so sure about though is the fact that you want to get
the ding caching method from looking at the audio sink. Those two are
likely related, but could be completely different. Like using alsa to
output to $soundserver could still mean I want stuff cached in
$soundserver directly.

Another thing that noone has bothered thinking about so far is
live-updating when GConf keys change. If I change my audio sink from
"esdsink" to "polypsink", all my ding caching apps are going to relocate
there sound samples to the new server, right?

Benjamin