[gst-devel] sample caching

[Benjamin Otte]

On Thu, 25 Nov 2004, Ronald S. Bultje wrote:

> On Thu, 2004-11-25 at 06:02, Colin Walters wrote:
> [..]
> > > 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.
> >
> > 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.
>
> That's what we currently do. There's a toplevel GstAlsaElement (or
> GstOssElement, ...) class that derives from GstElement. It contains the
> file descriptor (or alsa handle). For OssElement, the mixing
> functionality is built-into this class (could be separated, that'd be
> somehwat more perfectly clean). For ALSA, there's a child class
> GstAlsaMixer that has this. Then there's GstAlsaSink/Source that derive
> from the mixer and OssSource/Sink that derive from the OssElement. I
> considered this cleaner than Benjamin's proposal, because it allows me
> to use the mixer interface on sources (i.e. I open a osssrc and can then
> adjust volumes on line-in using that very same object). Benjamin seems
> to disagree. I kind-of see his point with the sinks. The thing is that
> other players do the same thing. Helixplayer, for example, uses the
> mixer of the audio output for volume control (yes, it uses hardware
> volume). Totem could do that too, by only a minor change.
>
I've already got issues with the mixer stuff when I shuffled some
initialization code in alsasink around. I've also got strange errors
because there were no mixing interfaces even though I didn't want to use a
mixer at all. Stuff like that only happens because the mixer is part of
the sink.
It's correct though that it's a nice idea to associate the volume controls
of a sink with the sink, kinda like we currently do. Though our
implementation isn't much better either, because the sink still doesn't
tell me which volume slider will really change the output volume. It just
gives me a long list of sliders to try.

> As for the caching interface, only backends explicitely supporting this
> would implement the interface, which is currently only esd (if anyone
> feels like implementing that) and polypaudiosink. Alsasink/osssink won't
> get any new code because they don't implement sample caching. I don't
> really see the problem here...
>
Oh it's just 2 elements, so we can take the clunky approach first and fix
it later?
A wise being once said about that: "If once you start down the dark path,
forever will it dominate your destiny." Nowadays they call it API
compatibility.

Benjamin