Re: Notes from Sound BoF at GUADEC 2008

[Lennart Poettering <lennart poettering net>]

On Thu, 24.07.08 00:06, Ronald S. Bultje (rsbultje gmail com) wrote:

> 
> Hey Lennart,
> 
> On Mon, Jul 14, 2008 at 7:13 PM, Lennart Poettering
> <lennart poettering net> wrote:
> >           1. write a new gnome-volume-control, directly linking against
> >              libpulse, that does all what pavucontrol does, however
> >              doesn't suck, isn't written in C++ and looks as pretty as
> >              the current g-v-c. (a compact version should be
> >              embeddable into the panel, a full version should run
> >              standalone. Also see Topaz mockups)
> [..]
> >           1. Check with people (i.e. Solaris, ...) if it is OK to
> >              link against libpulse directly from some very specific
> >              desktop applications (such as g-v-c) instead of always
> >              going through some kind of abstraction layer (i.e.
> >              GStreamer, libcanberra, ...).
> >           2. Ask KDE folks about how to proceed with PA and lib
> >              canberra
> 
> How hard (compared to rewriting g-v-c/g-v-a to link to libpulse) is it
> to abstract libpulse away in gst's mixer API, or to extend it to fit
> libpulse's needs?

The question is not so much whether it can be done or not. It's about
whether that makes sense or not. The reason why I think that linking
directly against libpulse is a good idea is that 90% of the features
"abstracted" in that gstreamer API would be specific for
PA. i.e. per-stream volumes, arbitrary stream/device meta data
(icons...), moving of stream between devices, policy routing,
hot-plug, flat volumes, ... The mixer controls a lot of PA internals,
and needs to know a lot of how audio is routed internally of PA, in
contrast to normal playback the whole mixer stuff is just too specific
to PA to justify abstraction. And then, abstractions with just a
single backend are particularly lame.

Also, my personal belief is that the gst mixer is in a really really
bad state anyway, and would need quite a bit of work to not be racy
and incomplete.

And then, what would this be good for anyway? It would be only g-v-c
which would link directly to PA. It's not that we'd have millions of
consumer apps for this API.

To answer your question: It would certainly be possible to do
this abstraction. Would be more than just trivial work. You'd have to
sit down hack quite a while, agree to the abstraction and do that
again each time PA learns a new feature.

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net         ICQ# 11060553
http://0pointer.net/lennart/           GnuPG 0x1A015CC4