GNOME Bugzilla – Bug 313495
Audigy 2 mixer duplication and inactive mixers shown
Last modified: 2007-01-06 21:39:47 UTC
Distribution/Version: Gentoo In gnome-volume-control, the preferences shows loads of pointless mixers (such as EMU10K1 PCM Send Routing 1-32). In amixer, these mixers are only shown if you specify the --inactive option. Another problem is the duplication of mixers, such as "PCM", "Synth", "Microphone", "Line2", "IEC958 Optical". If you tick one of the duplicated mixers, it will appear, but if you then tick the other control with the same name, it will not appear, but unticking either of the duplicated mixers will remove it. These mixers do not affect the sound output, so I have to resort to using alsamixer or enabling OSS in my kernel. The only reason I can see for this in the amixer output, is the duplicated controls have both "cvolume" and "pvolume" in their capabilities, e.g.: Simple mixer control 'PCM',0 Capabilities: pvolume cvolume Playback channels: Front Left - Front Right Capture channels: Front Left - Front Right Limits: Playback 0 - 100 Capture 0 - 100 Front Left: Playback 56 [56%] Capture 57 [57%] Front Right: Playback 56 [56%] Capture 57 [57%] "alsamixer" works correctly, as does the OSS mixer, and this bug has affected me since Gnome 2.10, currently running a CVS copy. alsa-driver: 1.0.9b alsa sound driver: snd_emu10k1 according to lspci: Creative Labs SB Audigy (rev 04)
Aren't those hidden by default in 2.10? I'll have a look at what this 'inactive' means...
It seems there are two bugs here: first of all, some mixers are reported twice in the mixer, and they behave oddly; second, some mixers are shown even though ALSA says they are 'inactive'. I am seeing the first bug on my machine containing a Sound Blaster Live, however I haven't seen the inactive controls (PCM Send Routing 1-32 etc.) for quite a while, even in alsamixer and I can not now get amixer to list them even when I specify --inactive. So perhaps the second bug has been fixed by a newer release of ALSA? In looking closer at the first bug, I compared the output of 'amixer' with the result of calling gst_mixer_list_tracks(). I inserted this code at line 285 of gst-mixer/src/element.c: g_print ("%s, %d\n", track->label, i); The GstMixerTrack is track, and i is the result of get_page_num(); it is 0 if track->flags is GST_MIXER_TRACK_OUTPUT and 1 if it is GST_MIXER_TRACK_INPUT. I found that the bug can be divided into two sub-bugs. ALSA mixer controls where capabilities == 'pvolume cvolume cswitch' are handled by gstreamer by returning two GstMixerTracks with the same name, one with flags == GST_MIXER_TRACK_OUTPUT and the other with GST_MIXER_TRACK_INPUT). The first sub-bug is that gnome-volume-control simply can not handle the case where two GstMixerTracks have the same label. On my system, the following GstMixerTracks confuse gnome-volume-control in this way: Surround, 1 Surround, 0 Synth, 1 Synth, 0 Wave, 1 Wave, 0 Line LiveDrive, 1 Line LiveDrive, 0 Line2 LiveDrive, 1 Line2 LiveDrive, 0 IEC958 Coaxial, 1 IEC958 Coaxial, 0 IEC958 LiveDrive, 1 IEC958 LiveDrive, 0 IEC958 TTL, 1 IEC958 TTL, 0 The second sub-bug is a problem with gstreamer, and how it interprets ALSA mixer controls that have a set of capabilities different from those remarked above. gstreamer returns two GstMixerTracks, but both have flags == GST_MIXER_TRACK_OUTPUT. For the ALSA mixer controls with capabilities == "volume", I get: Bass, 0 Bass, 0 Treble, 0 Treble, 0 where capabilities == "volume volume-joined": 3D Control Sigmatel - Depth, 0 3D Control Sigmatel - Depth, 0 3D Control Sigmatel - Rear Depth, 0 3D Control Sigmatel - Rear Depth, 0 and where capabilities = "pvolume cvolume": AC97, 0 AC97, 0 This could be a manifestation of #336075.
Created attachment 63904 [details] [review] First patch Here's a first attempt at fixing the problem in gnome-volume-control.
The inactive bug does indeed seem to have disappeared, but maybe this should still be investigated further. If another card's driver was to have an inactive mixer for whatever reason (maybe if it had detection for whether a cable was plugged in), maybe it would still appear in gstreamer mixers. Is a "Show inactive mixers" option in order, maybe? If I didn't suck at kernel stuff I'd try writing a test-suite like alsa driver ;) Still that's a lower priority, and possibly not even a bug any more, so back to this bug. I'm still getting the duplicated mixers problem as you've said, and it does sound like it's doing what you're saying. I'll try that patch and see if it fixes the gnome-volume-control problem on my system. This second "sub-bug" does look like it may be #336075. Once both of these are fixed, if anything problems left then another bug could be reported.
If you have gnome-applets 2.14 installed, could you see what happens with the volume control panel applet when you select one of the duplicated mixer controls in its preferences? I've only got 2.12 here and it acts strangely, once 2.14 hits Debian I will try to fix it as well.
Created attachment 64973 [details] [review] Second attempt Updated the patch. * Works with the patch at bug #336075 * Handles ALSA controls capture groups and exclusive capture switches
(In reply to comment #6) > Created an attachment (id=64973) [edit] > Second attempt > > Updated the patch. > > * Works with the patch at bug #336075 You cannot rely on capture channels/switches having "Capture" in the label. The patch at bug #336075 appends "Capture" (or the native language translation!!) to the base label only if the track is a mixed one (playback and capture, like PCM sometimes). Using 'GST_MIXER_TRACK_HAS_FLAG (track, GST_MIXER_TRACK_INPUT)' should be enough to distinguish capture from playback switches.
Created attachment 65447 [details] [review] Third attempt Correctly determines which flag (MUTE or RECORD) should be toggled when changing the value of a switch. Also force the GstMixer to update its state (when refreshing mixer values) so that we notice when a GstMixerTrack's flags are updated.
I like this. Is there a reason why you din't simply add _() around the strings in get_page_description() and why you use g_strdup() instead of a const string? Otherwise, it appears we can use this patch right now, which'd be cool.
No good reason--only because I know nothing about i18n. It'd be great if you could merge this patch, as it (and the patch for bug #336075) make GNOME's mixer actually useful on my machines. :)
Created attachment 66602 [details] [review] Fourth attempt Use gettext for the mixer page descriptions.
Created attachment 66603 [details] [review] Fifth try Oops, fix the crash caused by freeing the result of a gettext call.
This is cool, I'll take this.
Did you mean that the latest patch was ok to commit?
Yes, if the gstreamer patch is committed along with it (else the whole thing is useless).
I still find the patch useful without the gstreamer patch... but it's even more useful with it.
Patch doesn't seem to apply to CVS any longer, any chance you could update it?
I will apply this after 2.16 (string freeze), along with the modifications to make it apply to CVS.
Created attachment 78625 [details] [review] updated patch Looks like the rejected parts were already applied with some slight changes. Does this patch contain the rest of what's needed to close this bug?
Committed, along with misc.[ch] from the other patches: 2007-01-06 Ronald S. Bultje,,, <rbultje@gnome.org> * gst-mixer/src/Makefile.am: * gst-mixer/src/element.c: (gnome_volume_control_element_dispose): * gst-mixer/src/misc.c: (get_page_num), (get_page_description): * gst-mixer/src/misc.h: * gst-mixer/src/preferences.c: (gnome_volume_control_preferences_init), (gnome_volume_control_preferences_change): * gst-mixer/src/track.c: (should_toggle_record_switch), (cb_toggle_changed), (cb_check), (gnome_volume_control_track_add_title), (gnome_volume_control_track_add_switch): Don't duplicate devices for the Audigy (#313495). Patch by Sam Morris <sam@robots.org.uk>.