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 350667 - gnome-volume-control does not support being able to set capture/record flags
gnome-volume-control does not support being able to set capture/record flags
Status: RESOLVED FIXED
Product: gnome-media
Classification: Deprecated
Component: gst-mixer
unspecified
Other opensolaris
: Normal major
: ---
Assigned To: gnome media maintainers
gnome media maintainers
Depends on:
Blocks:
 
 
Reported: 2006-08-10 00:19 UTC by Brian Cameron
Modified: 2009-05-22 21:32 UTC
See Also:
GNOME target: ---
GNOME version: 2.15/2.16


Attachments
patch to hack g-v-r to be useful on Solaris (24.61 KB, patch)
2006-08-10 00:20 UTC, Brian Cameron
needs-work Details | Review
image of capture tab (22.82 KB, image/png)
2006-08-25 21:32 UTC, Brian Cameron
  Details
playback tab (22.39 KB, image/png)
2006-08-25 21:33 UTC, Brian Cameron
  Details
updated patch (24.37 KB, patch)
2006-11-09 23:01 UTC, Brian Cameron
needs-work Details | Review
updated patch (28.81 KB, patch)
2007-09-25 21:43 UTC, Brian Cameron
none Details | Review

Description Brian Cameron 2006-08-10 00:19:45 UTC
Because the GStremaer mixer interfaces do not support getting/setting flags
(refer to bug #347557 filed against GStreamer), the gnome-volume-control tool is unable to specify what input/output devices should be affected by the sliders.

I don't think the right fix is to add additional sliders for each input/output
choice because the way SunAudio interfaces work the same input/output gain
is used for each input/output choice.  In other words, you have a single gain 
value for output and you can specify that "built-in speaker, microphone, and
headphone" are active, but they all use the same gain value. 

If I tried to fix this by adding separate sliders for each choice, then
moving any output slider up and down would affect all output choices that are 
turned on, and mute/unmute would be an awkward way to try to pick the device,
I'd think.

I do realize that the GST_MIXER_TRACK_RECORD flag can be used to switch the input between stdin and the microphone, but this is far more limited than what is supported on Solaris. 

On Solaris, the flags can include the following.

For Output:

- Built-in Speaker
- Headphone
- Line Out
- SPDIF Out
- AUX1 Out
- AUX2 Out

For Input:

- Microphone
- Line In
- Internal CD
- SPDIF In
- AUX1 Input
- AUX2 Input
- Codec Loopback

The attached pack hacks gnome-volume-control to add checkboxes so that the
user can pick which input/output devices are affected by the sliders.  It's
a bit ugly, but it makes gnome-volume-control usable on Solaris.

Not sure if this is appropriate to go into CVS head or not.  Probably the
right fix is to update the GStreamer mixer interface so that you can get/set
flag values via a standard interface rather than embedding the SunAudio code
directly into gnome-volume-control.

But at the very least, this bug report highlights a limitation in the GStreamer framework that affects Solaris.
Comment 1 Brian Cameron 2006-08-10 00:20:23 UTC
Created attachment 70599 [details] [review]
patch to hack g-v-r to be useful on Solaris
Comment 2 Brian Cameron 2006-08-10 00:20:55 UTC
oops, patch comment says "g-v-r", I means "g-v-c" for gnome-volume-control.
Comment 3 Ronald Bultje 2006-08-25 12:20:34 UTC
Can you attach a screenshot of the behaviour that you're talking about? I'm not sure I fully understand.
Comment 4 Brian Cameron 2006-08-25 21:32:58 UTC
Created attachment 71623 [details]
image of capture tab
Comment 5 Brian Cameron 2006-08-25 21:33:27 UTC
Created attachment 71624 [details]
playback tab
Comment 6 Brian Cameron 2006-08-25 21:34:19 UTC
Attached images showing the capture and playback tab.  These show how you can now set the flags in the tabs.  Hopefully this helps you understand.  If not, let me know and I can explain further.
Comment 7 Brian Cameron 2006-08-25 21:36:12 UTC
Hmm, looking at the playback tab, looks like the image is a bit corrupted...but you can see what I mean, I think.
Comment 8 Ronald Bultje 2006-08-25 21:44:34 UTC
Yes, I understand now. So basically, hardware-matically, you can only set the
volume on three control,s but each of those control one or (playback-case)
multiple physical outputs (speakers, headphone, line-out, etc. (out) vs.
microphone, line-in, built-in mic, phone, cd, etc. (in)).

Here's one way we could integrate that without totally messing up g-v-c. Please
let me know if you like it. So in Linux (alsa), some soundcards have not only
inputs/outputs, but also switches and options. For eaxmple, my soundcard has an
option (implemented as a combobox) to set the recording input from built-in mic
or line-in. You could use that (rather than the current radiobuttons) for the
capture case. Code for this is available in gstalsamixer, see search for
AlsaMixerOptions or so in it.

Now, this will work for capture where only a single one can be selected at a
time, however, it will not work for playback, where multiple can be selected at
the same time. To come up with a nice solution here, I would need some more
information. If I select/unselect (toggle) a checkbox, what happens? Obviously,
the volume control now starts influencing this channel, however, does this also
cause a mute/unmute? One possibility would be to implement this as the boolean
toggles (GstAlsaMixerControl or so? I can't remember exactly how this is
called). It would still be a list of checkboxes, but in a separate tab. Not
sure if you like that usability-wise. We can, optionally, merge tabs with a
preference intended for solaris@sparc users (or autodetect on startup).

Please let me know if those sound useful to you. For me, such changes would be
acceptable upstream (i.e. in gnome-media), and I'm sure the gst people would
accept it also.
Comment 9 Brian Cameron 2006-08-25 21:58:44 UTC
Yes, we could use a combobox for the input, but wouldn't it be a bit weird to have this show up on a separate options tab rather than in the capture tab?

In terms of playback, selecting one of the devices causes the audio to start playing to that device.  Unselecting on causes the audio to mute to that device.
The same gain value applies to all devices, so it doesn't really make sense to use separate sliders.  If you did use separate sliders, I guess they would all move together when you moved any of them?
Comment 10 Brian Cameron 2006-08-25 22:00:34 UTC
Also note that there are about 7 input/output devices.  Just on my machine only 3 playback choices are supported.  But on other machines the list of available checkboxes for capture/playback are different.  You have to check the sunaudio interface to see which ones are available.  If you look at my patch you can see I'm checking the "avail_ports" stuff to set up the list of checkboxes right.
Comment 11 Ronald Bultje 2006-08-25 23:48:26 UTC
No, no, I don't mean separate sliders, I mean checkboxes for each of them, like in the alsa options, very similar to what you have now, but better integrated (and thus easier to merge upstream).

As for the combobox-in-separate-tab issue, as said, I wouldn't mind having a gconf option to merge tabs that can be used for this purpose. It could be turned on by default on Sparc/solaris builds.
Comment 12 Brian Cameron 2006-08-28 23:19:48 UTC
I agree that doing the above work (use Options for the src plugins) and make it possible to configure g-v-c so that the options can appear on the source tab) would probably be good to do.

However, it does seem like some infrastructure needs to be added to the GStreamer mixer plugins to better support switches also.  Wouldn't it make more sense to do this after the GStreamer bug in comment #1 is fixed.  For now, we can just apply the nasty patch to Solaris and leave it out of CVS head.

I just wanted to make you aware of the problems we noticed getting this to work on Solaris, and how we worked around them.  I'm not sure that we have the resources to address the GStreamer bug.  But perhaps other distros would benefit from having the ability to use flags in the mixer plugin.  If so, there is a +1 vote from Solaris to add such a feature.

I'm changing the synopsis so it more clearly describes the issue, since the
ability to use flags on the capture/record tabs might benefit platforms other
than Solaris.
Comment 13 Ronald Bultje 2006-08-29 01:33:05 UTC
Of course, you should use this patch for Solaris as long as the generic solution is not in-place. I'm just hoping to have a generally acceptable solution upstream, to make this software better and your life easier. :-).
Comment 14 Brian Cameron 2006-11-09 23:01:38 UTC
Created attachment 76306 [details] [review]
updated patch


For reference I am attaching an updated patch that we now use that has some usability improvements recommended by Calum.  For those who want to build gnome-volume-control on Solaris so it works reasonably, I'd recommend applying this patch.
Comment 15 Kjartan Maraas 2006-12-19 15:46:42 UTC
Should the patch be marked as needs-work, or is the patch itself fine and just in need of some general infrastructure work?
Comment 16 Ronald Bultje 2006-12-19 17:53:54 UTC
The patch is a needs-work case. My proposed solution in comment 8 (and 11) is how this probably should be done for this to be acceptable for merging in main CVS.

I understand if Brian has no time for that right now, I'll do it at some point...
Comment 17 Brian Cameron 2007-09-25 21:43:59 UTC
Created attachment 96197 [details] [review]
updated patch


Now that we can also support OSS on Solaris, I noticed that the previous patch didn't work well when switching the device (via File->Change Device in the menu) between OSS and SunAudio devices.  

This patch fixes gnome-volume-control so that it only shows the SunAudio checkboxes when you are actually using the SunAudio device, and doesn't show them when using OSS.
Comment 18 Marc-Andre Lureau 2008-03-24 00:49:37 UTC
(In reply to comment #17)
> Created an attachment (id=96197) [edit]
> updated patch

Hi Brian,

If I understand correctly, this patch is not for upstream yet and we need to find a more generic way to solve the problem. Is that correct (oh god, I am too tired to read the comment #8) :)
Comment 19 Brian Cameron 2008-03-24 17:42:23 UTC
Yes, this is correct.  The attached patch is just a hack to workaround this problem on Solaris.  It embeds Sun Audio (SADA) interfaces directly into gnome-volume-control, which is bad.  This patch isn't suitable for upstream, but just to show the problem and how we currently hack around it.  It would be better to fix the GStreamer mixer interface so you could better hide all low-level sound interfaces in the GStreamer plugin rather than hacking programs like gnome-volume-control.

I know that GstMixer does support GstOption.  This sort of does what is needed, but it is not sophisticated enough.  The problem with GstOption is that you are
only allowed one list of options per mixer.  So, if there are two or more sets 
of options that the user should be able to choose from (such as pick the input
device *and* pick the output device), you can not do this with the current
GstOption interfaces.

The other big problem is GstOption only allows you to pick one value.  As you notice in the bug description above, on Solaris you can pick multiple choices for output device.

In summary, it would be better if you could have an arbitrary number of options, not just one.  It would be nice if you could control how each is displayed in the dialog (e.g. checkboxes, combobox, radiobuttons, etc).  Some options should support multiple selection values (such as radiobuttons).

Then the values selected could be communicated back to the mixer plugin, and the mixer plugin could do the job of actually interacting with the low-level sound interfaces as needed.

I hope this summary of the issues is useful.
Comment 20 Brian Cameron 2008-03-25 22:47:58 UTC
I don't understand why this bug was marked as "RESOLVED INCOMPLETE".

While we work around this bug on Solaris with the attached patch, the problem that GStreamer doesn't have good support for getting/setting configuration 
values is something that should be fixed in GStreamer, I'd think.

Note that bug #343615 is sort of a duplicate bug, and talks about the same issue,
though this bug probably has more information.

Might make sense to mark this or that bug a duplicate of the other.
Comment 21 Brian Cameron 2008-03-25 22:49:22 UTC
Oh sorry, I meant bug #347557 is probably a duplicate bug.
Comment 22 Marc-Andre Lureau 2008-03-25 22:50:58 UTC
(In reply to comment #20)
> I don't understand why this bug was marked as "RESOLVED INCOMPLETE".

you did it.
 
> While we work around this bug on Solaris with the attached patch, the problem
> that GStreamer doesn't have good support for getting/setting configuration 
> values is something that should be fixed in GStreamer, I'd think.

agree.

(In reply to comment #21)
> Oh sorry, I meant bug #347557 is probably a duplicate bug.

may be, I'll check it.


feel free to reopen. :)

Comment 23 era+gnome 2009-02-05 10:18:13 UTC
I would like to add a suggestion to help troubleshoot audio issues: could the interface include something like a dB meter to show what sound there is "in theory" and which source it's coming from?  Especially for finding out which microphone corresponds to which widget on the screen, this could be extremely helpful.

Thinking out loud, perhaps something like a little scrolling chart of the last, say, 30 seconds of input level would be even more useful than just real-time blinkenlights.
Comment 24 Brian Cameron 2009-05-22 21:32:46 UTC
Note that this issue is no longer a problem for the SunAudio plugin.  Bug #583593 fixes the reported issues with this bug in a cleaner way.  Adding the new flags to GStreamer (see bug #571106) made this possible.  Marking this bug as fixed.