After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 570832 - Add flags to enhance mixer interfaces
Add flags to enhance mixer interfaces
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-base
git master
Other All
: Normal enhancement
: 0.10.23
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks: 571106
 
 
Reported: 2009-02-06 23:53 UTC by Brian Cameron
Modified: 2009-02-24 17:45 UTC
See Also:
GNOME target: ---
GNOME version: 2.25/2.26


Attachments
patch adding flags (2.26 KB, patch)
2009-02-06 23:54 UTC, Brian Cameron
none Details | Review

Description Brian Cameron 2009-02-06 23:53:41 UTC
This patch adds a few flags to the mixer and mixerctrl interfaces.  If there
are any issues with how the flags should be named, how they work, or the
documentation; then we would be happy to rework the patch as needed.  Just
let us know.

Note this patch was written by Garret D'Amore (garrett.damore@sun.com) with
some help from me.  He is the lead engineer working to integrate OSSv4 into 
Solaris.

Obviously these new flags won't have any effect until plugins make use of them and gnome-volume-control is enhanced to make use of them.  I have patches for
the SunAudio (in gst-plugins-good) and OSSv4 (in gst-plugins-bad) plugins to 
make use of these flags, and I also have a patch for gnome-volume-control to
recognize the flags and do the right thing when the flags are set.  I can
attach those patches to this enhancement request if you think they would
be helpful to review this change.

A few words on binary compatibility:

a) If you don't use the flags, they are benign. (i.e. no change if the mixer 
   plugin doesn't implement any of them.)
b) A mixer plugin need not implement any of these flags.  In that case, gvc 
   will behave much as it does today.
c) If you have not updated gvc with support for these flags, but you *have* got
   mixer plugins that use them, you might not be too happy -- the application 
   will work, but the layout will probably not be what you'd like to see.  The 
   results are not terribly user-friendly.
d) In other words, all of these flags primarily impact usability/ui, by giving 
   the mixer implementation more influence on the resulting UI.  The end result 
   is much more flexible support and a nicer user interface as well.

The inline doc comments explain them briefly, but here's more detail:

New mixer flags
---------------

GST_MIXER_FLAG_HAS_WHITELIST:

This allows the mixer implementation to indicate that it doesn't want to use 
the builtin whitelist in applications (gnome-volume-control), but will flag 
tracks & options that should be displayed by default.  (This hands control over 
the "default" display to the mixer implementation, instead of relying on a 
horrible hack in gnome-volume-control.)

GST_MIXER_FLAG_GROUPING:

This flag, if present, means that some tracks will not be flagged as either INPUT or OUTPUT.  Those tracks will be displayed on the "OPTIONS" page in gvc.  
Furthermore, if this flag is present, switches and options that are marked as 
either INPUT or OUTPUT will be put in the appropriate flagbuttonbox, and 
displayed on the Playback or Recording notebook pages.  (I added this flag so 
that I could retain the old behavior in case ALSA or something relied on it.)

New track flags
---------------

GST_MIXER_TRACK_NO_RECORD:

If present, this suppresses the display of the "record" button on input 
tracks.  This is necessary for both the Sun audio and OSS v4 plugins,
where there is not a 1-1 mapping of input tracks and hardware record sources.  
(I.e. where the record source selection is handled via a separate option.)

GST_MIXER_TRACK_NO_MUTE:

If present, this suppresses the display and handling of the "mute" button on a 
track.  The idea is that some sliders may represent values where "mute" makes 
no sense... for example, a slider representing tone levels, 3D centering, or 
balance adjustments, should not have a "mute" button.

GST_MIXER_TRACK_WHITELIST:

If present (and the mixer has GST_MIXER_FLAG_HAS_WHITELIST), then this track 
will be in the default whitelist of tracks to display by default.  If it is not 
present, but the mixer has GST_MIXER_FLAG_HAS_WHITELIST set, then the track 
will *not* be in the default whitelist of tracks to display by default.   Note 
that this is handled by gvc; its a hint to the application only.
Comment 1 Brian Cameron 2009-02-06 23:54:30 UTC
Created attachment 128126 [details] [review]
patch adding flags
Comment 2 Brian Cameron 2009-02-09 22:13:32 UTC
Note gvc enhancement request bug #571106 which shows the changes needed to gvc to 
make this work.  It also includes a picture to show how things work with this change.
Comment 3 Jan Schmidt 2009-02-20 12:53:09 UTC
These extra flags look fine to me. I'll add them to -base later, unless there are objections?
Comment 4 Jan Schmidt 2009-02-24 17:31:09 UTC
Committed:

commit b8af1223db33a929df6c792516f4f3c3a7087a28
Author: Garret D'Amore <garrett.damore@sun.com>
Date:   Tue Feb 24 17:23:58 2009 +0000

    mixer interface: Add flags to enhance mixer interfaces
    
    This patch adds a few flags to the mixer and mixerctrl interface to
    better support OSSv4 (and potentially other backends).
    
    Patch By: Garret D'Amore <garrett.damore@sun.com>
    Signed-Off-By: Jan Schmidt <jan.schmidt@sun.com>
    
    API: GST_MIXER_FLAG_HAS_WHITELIST, GST_MIXER_FLAG_GROUPING,
    API: GST_MIXER_TRACK_NO_RECORD, GST_MIXER_TRACK_NO_MUTE,
    API: GST_MIXER_TRACK_WHITELIST