[gst-devel] sample caching

[Ronald S. Bultje]

On Fri, 2004-11-26 at 12:11, Benjamin Otte wrote:
> 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.

Those are bugs. I can fix them.

> 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.

Well, that's not true. One of the tracks is flagged with _MASTER, and
that one controls output. Gnome Volume Applet uses that, too.

> > 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.

Right, point taken. Anyway, like you said, "coders decide", and Iain is
the coder here, right?...

Ronald

-- 
Ronald S. Bultje <rbultje at ronald.bitfreak.net>