GNOME Bugzilla – Bug 350667
gnome-volume-control does not support being able to set capture/record flags
Last modified: 2009-05-22 21:32:46 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.
Created attachment 70599 [details] [review] patch to hack g-v-r to be useful on Solaris
oops, patch comment says "g-v-r", I means "g-v-c" for gnome-volume-control.
Can you attach a screenshot of the behaviour that you're talking about? I'm not sure I fully understand.
Created attachment 71623 [details] image of capture tab
Created attachment 71624 [details] playback tab
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.
Hmm, looking at the playback tab, looks like the image is a bit corrupted...but you can see what I mean, I think.
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.
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?
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.
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.
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.
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. :-).
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.
Should the patch be marked as needs-work, or is the patch itself fine and just in need of some general infrastructure work?
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...
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.
(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) :)
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.
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.
Oh sorry, I meant bug #347557 is probably a duplicate bug.
(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. :)
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.
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.