[gst-devel] gstreamer mixer limitations, proposal

[Garrett D'Amore]

Hi all,

First a quick intro: I'm the guy at Sun Microsystems who's been tasked 
with developing the new kernel framework for audio on Solaris.  (This is 
includes adding support for OSS APIs, but it has involved a lot of new 
development.)  This project is named Boomer -- see 
http://www.opensolaris.org/os/project/opensound/ for more details.

I should also note that Brian Cameron is a "virtual" member of the 
Boomer team, and is involved as well.

We've been making lots of progress, and the framework already is fairly 
fully functional with most audio applications, including gstreamer.  
(Getting 7.1 audio in totem on Solaris is pretty neat. :-)

Anyway, as part of this project, we want full integration with 
Gstreamer, and we're planning on doing a lot to improve the quality of 
the OSSv4 plugin for Gstreamer.

One of the areas I've been looking at recently has been the mixer (and 
specifically gnome-volume-control) in gstreamer.

The problem is that gstreamer (and g-v-c) make what I believe are some 
very poor assumptions about controls, with the result that the 
application isn't very flexible or usable for end-users.  I'd like to 
fix that, and to that end I'm willing to contribute fixes.

The main issue is that gstreamer/g-v-c assumes that certain controls of 
certain types  have certain properties.  A good example si the "record" 
button associated with input volume sliders.  On one hand, real audio 
hardware can select a recording sources which don't have any associated 
gain control (such as loopback or post-mix results), on another hand the 
separate gain control for most real hardware is associated only with the 
monitor, and not the actual record gain, and finally most hardware 
*also* has a separate gain control, which has a volume level independent 
of the monitor gain.

In the OSSv4 API we express the above situation (e.g. for AC'97 devices) 
as a group of sliders and an enumeration:  a slider for record gain, one 
for each monitor source, and an enumeration to select the record source.

With gstreamer/g-v-c (after some other non-controversial fixes) the 
above isn't quite right... g-v-c displays one a record microphone button 
for each volume slider (which does nothing), and the record source 
enumeration winds upon an a seemingly "unassociated"  "Options" tab.

My proposal to fix most of these is to add some intelligence to the 
gstreamer and g-v-c applications.  The main part of this would be to add 
to new bits the mixer flags, so that gstreamer could use these bits to 
indicate more to applications about the control.  (For example, whether 
the slider is a monitor source or a record gain, and whether it should 
have a separate record enable with it.  And, I'd add some additional 
bits which would allow controls *other* than slider types to be grouped 
as either playback or record controls and put on the appropriate frame.

There might be other changes I'd make as well, but my goal would be to 
minimize the amount of change in the protocol (adding new mixer flags 
seems relatively low-impact, at least to me) if at all possible.

By the way, one of the impacts of this change that I'd like to be able 
to do is remove the special #if sun hacks we have for the Sun /dev/audio 
specific hacks that are maintained separately in the Sun gnome (aka JDS) 
tree.  I'd like to have things be as generic as possible, so that it 
should be possible for code based on either Sun or OSS to express their 
devices reasonably completely, without weird artifices required to make 
things fit within a limited gstreamer model.

What I'd like to know from the larger group (especially the core gnome 
developers) is whether such changes would be appreciated.  I'd of course 
prefer to contribute my improvements upstream, and I'd prefer to write 
them in such a way that they are useful for not just Sun but for other 
platforms & API consumers, but I also am not interested in spending a 
lot of time in any kind of protracted political or philosophical 
debates.   I expect that the folks who work on the gstreamer core have 
no more time for that than I do.

Anyway, if folks could let me know what they think about such an 
approach, as well as what might be any other areas of concerns or 
landmines that I'm not seeing, I'd appreciate it very much.

At the end of the day, I hope that we can get the OSSv4 plugin up to 
snuff so that it can be part of the "good" plugins, instead of "bad".  I 
recognize from the time I've spent in it already, that a fair amount of 
work will be required to make this happen, but I think I'm prepared to 
commit the resources of myself (and others on my time) to help this happen.

Thanks!

    -- Garrett