Version: (using KDE KDE 3.5.1) Installed from: Debian testing/unstable Packages OS: Linux When I add the mixer applet, the mixer has duplicate entries for some controls. The bass, treble, and "3D Control Sigmatel" sliders have two sliders side by side. These are not split channels, and changing the left slider makes the right slider change to match it. Changing the right slider has no effect on the left slider (or the actual mixer channel's effect on audio). If I hide one of the two controls, the removed one returns if i logout and log back in. This occurs even with a completely new user (ie, no existing config file) I'll attach an image showing the controls in question, but if i find I can't, http://yallara.cs.rmit.edu.au/~alpilley/images/mixer.png shows them (2nd through 7th sliders from the left) I'm using alsa, and I have an SB Audigy. Discussions in #kde on freenode indicate that it appears to be sound-card-brand specific (another SB owner confirms the bug on a different distro) The application 'kmix' and alsa's mixers do not show the same problem.
Created attachment 14568 [details] Image of the sliders that are duplicated (2nd through 7th from left of applet)
I'm seeing exactly the same issue here using alsa and an sblive! value. http://straw.sh.nu/kde/KDE-panel-mixer-bug-snap1.png taken after attempting to reproduce the problem when mentioned in #kde on freenode.
Created attachment 14569 [details] region screen cap of the problem
Oops. I should mention I'm using Fedora Core 4, KDE 3.5.1.
Soundcards like "SB Live" and "SB Audigy" have separate playback and recording volumes on some controls. So those extra controls are simply the recording controls. So this is a feature, not a bug. There is nothing to fix here. In the KMix main window those controls show up on different tabs. In the Panel Applet they are not distinguishable. A possible solution would be to add this information to the recording controls, e.g. "Record: PCM" or "PCM (Record)". Comments are appreciated.
One extra comment from me: The feature to show both "playback" and "recording" controls is new in KDE3.5.1.
If that's the case, why do these sliders act the way they do? I fail to see why changing the left-hand of the pair changes the right-hand version, but not vice-versa. It stands to reason that they should be completely independent, shouldn't it? They need independent names, if only internally, so that when I hide one, the other doesn't vanish if I logout and log back in. Pity we can't have a different colour for input sliders atm, would have made it far less confusing :) Thanks for clearing this up a bit tho.
Hiding should already work properly. That would be a bug. Obviously I haven't read your original bug report correctly. Sorry about that. I currently don't see what is wrong, so I need somebody with an Audigy and programming knowledge for resolving this issue. This might need some time ...
I've got a copy of kdemultimedia's source here. My c++'s a little rusty compared to my C/java skills, but I'm willing to spend some time with it, particularly if you'll mention the areas that deal with storing and loading the preferences and why the two aren't completely independent. I'll dig around and see if I can find references on debugging panel applets in a useful way in the mean time.
"and why the two aren't completely independent. " i meant the two channels, not the storing/loading of preferences :)
*** Bug 121827 has been marked as a duplicate of this bug. ***
SVN commit 512943 by esken: Fix bug 121451 : Playback and Capture Sliders now save their GUI properties indepencently (thus you can for example show the playback and hide the capture controls). The bugfix contains a "compatibilty loader", that loads the old properties if new ".Capture" properties are not found. This fix needs confirmation from testers. CCBUGS: 121451 M +36 -0 kmixtoolbox.cpp --- branches/KDE/3.5/kdemultimedia/kmix/kmixtoolbox.cpp #512942:512943 @@ -98,6 +98,36 @@ */ // !!! check devgrp.sprintf( "%s.%s.Dev%s", viewPrefix.ascii(), grp.ascii(), mdw->mixDevice()->getPK().ascii() ); + + /** + Find an appropriate group name for capture GUI elements. + We try devgrp.append(".Capture") + If it doesn't exist, we fall back to devgrp. + This is the second compatibility measure, and was introduced for KDE3.5.2. + */ + if ( mdw->mixDevice()->getVolume().isCapture() ) { + /* A "capture" GUI element must save its own state. Otherwise playback and capture + properties would be written twice under the same name. This would mean, when + restoring, both would get the same value. This is bad, because hidden sliders will re-appear + after restart of KMix, and a lot of other nasty GUI-related problems. + So we add ".Capture" to the group name. + See bug 121451 "KMix panel applet shows broken duplicates of bass, treble sliders" + + The name should have been set in the backend class, but we REALLY cannot do this for KDE3.5.x. !! + This issue will be fixed in KDE4 by the great config cleanup. + */ + QString devgrpTmp(devgrp); + devgrpTmp.append(".Capture"); + if ( config->hasGroup(devgrpTmp) ) { + // Group for capture device exists => take over the name + devgrp = devgrpTmp; + } + else { + // do nothing => keep old name (devgrp). + // Saving wil autmatically create the group 'devgrp.append(".Capture")' + kdDebug(67100) << "KMixToolBox::loadConfig() capture fallback activcated. Fallback group is " << devgrp << endl; + } + } // isCapture() if ( ! config->hasGroup(devgrp) ) { // fall back to old-Style configuration (KMix2.1 and earlier) devgrp.sprintf( "%s.%s.Dev%i", viewPrefix.ascii(), grp.ascii(), n ); @@ -148,6 +178,12 @@ } devgrp.sprintf( "%s.%s.Dev%s", viewPrefix.ascii(), grp.ascii(), mdw->mixDevice()->getPK().ascii() ); //devgrp.sprintf( "%s.%s.Dev%i", viewPrefix.ascii(), grp.ascii(), n ); + + if ( mdw->mixDevice()->getVolume().isCapture() ) { + /* see loadConfig() for the rationale of having an own name for capture devices. */ + devgrp.append(".Capture"); + } // isCapture() + config->setGroup( devgrp ); if ( qmdw->inherits("MixDeviceWidget") ) { // -<- in reality it is only in MDWSlider
Hope this attaches to the bug properly. I just applied that patch to a copy of KDE3.5.1's kdemultimedia source that i have here, compiled it, and tested it. Looks good. The recording and playback channels save their state in an independent way. My only concern is that the tooltips for both in the applet when hovering over the slider (or in the "Channels" dialog from the right click menu on the panel applet) still has just "Bass" and "Treble" Shouldn't it display "Capture:Bass" or something for the capture channel? Andrew On Thu, 2006-02-23 at 23:57 +0000, Christian Esken wrote: [bugs.kde.org quoted mail]
Thanks a lot for the very quick testing, Andrew. :-) The tooltips are problematic, I know that. But it is not trivial, because there are a lot of issues to be considered: 1) I must also think about the majority of people who don't have both record and playback controls. Those will suddenly see "Capture:PCM", and wonder where their playback slider has gone. 2) "Capture:Capture" will show up, which might me very confusing. 3) I am not sure what imact this has for other backends like OSS, Solaris or IRIX. There are no possibilities to test this until KDE3.5.2. 4) Tooltips would then probably be dependent on whether they are shown on the PanelApplet or on the MainWindow (showing an extra "Capture" on the input tab would be superfluous). 5) User visible changes should not be done for KDE3.5.2, unless this is a *severe* usability impact (yes, this could actually be argued). There is no decision yet, but I am very reluctant to do this in a bugfix release. There are pros an´d cons, so I'll keep this bug report open during pondering.
Yeah, fair enough, as a quick fix it definently does the job. If it turns out that modifying the tooltip doesn't have much impact, it'd be nice for 3.5.2, but if it messes up kmix proper, etc, it'll survive as it is, it's only a fairly minor usability bug, all things considered. Now to just get debian to roll it into a patch to kdemultimedia if they release a new build before 3.5.2 :) Thanks Andrew On Fri, 2006-02-24 at 23:04 +0000, Christian Esken wrote:
I'll rather close this bug report as the original problem is actually solved. Just for the usability issues reported in comment 13 and discussed by my own self in comment 14, it is not worth to keep this bug report open. I'll happily discuss this in personal mail if somebody is interested. "KDE Usability" might then want to take a look into this, too.