[gstreamer-bugs] [Bug 570832] New: Add flags to enhance mixer interfaces

[GStreamer (bugzilla.gnome.org)]

If you have any questions why you received this email, please see the text at
the end of this email. Replies to this email are NOT read, please see the text
at the end of this email. You can add comments to this bug at:
  http://bugzilla.gnome.org/show_bug.cgi?id=570832

  GStreamer | gst-plugins-base | Ver: git
           Summary: Add flags to enhance mixer interfaces
           Product: GStreamer
           Version: git
          Platform: Other
        OS/Version: All
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: Normal
         Component: gst-plugins-base
        AssignedTo: gstreamer-bugs at lists.sourceforge.net
        ReportedBy: brian.cameron at sun.com
         QAContact: gstreamer-bugs at lists.sourceforge.net
                CC: garrett.damore at sun.com
     GNOME version: 2.25/2.26
   GNOME milestone: Unspecified


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


-- 
See http://bugzilla.gnome.org/page.cgi?id=email.html for more info about why you received
this email, why you can't respond via email, how to stop receiving
emails (or reduce the number you receive), and how to contact someone
if you are having problems with the system.

You can add comments to this bug at http://bugzilla.gnome.org/show_bug.cgi?id=570832.