gstreamer mixer limitations, proposal

[Garrett D'Amore-5]

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


------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel