Version: (using KDE Devel) Installed from: Compiled sources Compiler: gcc 3.2.3 OS: Linux When I start from a fresh boot, the first thing I do is adjust the volume of my sound card (i810 on a Toshiba centrino laptop) with alsamixer and play a music file with ogg123. It plays fine. If I load xfce4 using startxfce4, then play music, it plays fine. However, if I load kde, using startkde, then once the desktop appears, my sound card is dead until I either reboot or unload and reload the modules. This behaviour is _independent_ of whether or not I start arts. An interesting observation is that when alsamixer starts, all channels are muted and the volume is set to zero. After loading kde, all volumes are zeroed (except for those that I raised in the first step), but no channels are muted. In addition, the alsa module does not have its use count set. I'm runing linux-2.6.0-test11, but this problem does not seem to be kernel specific; I've tried all the way back to -test6, when I _know_ things worked fine. I'm running gentoo with alsa-lib 0.98. I'm more than willing to help debug, if someone can point me in the right direction.
it's either arts or kmix. Arts beeing the more likely.
It cannot be arts, since the problem happens even without arts starting.
It's a kernel bug: http://bugzilla.kernel.org/show_bug.cgi?id=845. Somehow aRts triggers this bug, but it's nonetheless a bug. This is also a duplicate in our bug tracking system, but I can't find the original.
I have the same problem, but I am using a 2.4.20 kernel on a gentoo.! KDE 3.1.4 works fine, the cvs version has no sound... I see many other gentoo users have the same problem...
I am also having this problem on a Gentoo system (Dell Inspiron 1100 laptop, Linux 2.6.0-test9-mm1 kernel, Intel 82801DB sound card, ALSA 0.9.7). Sound works fine without KDE or in KDE 3.1.4 from the standard portage tree. I have attached the mixer settings corresponding to this working situation. After starting KDE-CVS (compiled using the Gentoo CVS ebuilds), sound is dead. I attached the mixer config corresponding to this situation as well. Restoring the original sound settings within the running KDE-CVS (using "alsactl -f /etc/asound.state restore) turns the sound back on. I looked at the diff between the "good" and "mute" states and found that the necessary and sufficient change to reenable sound from the "mute" state is changing "true" to "false" in the block control.33 { comment.access 'read write' comment.type BOOLEAN iface MIXER name 'External Amplifier Power Down' value true } After doing this in "asound.state.mute" and loading these settings ("alsactl -f asound.state.mute restore"), sound is active again. Does anyone know the meaning of the 'External Amplifier Power Down' setting and what might have changed between 3.1.4 and CVS?
Created attachment 4124 [details] Initial mixer settings with working sound These are the initial mixer settings before KDE-CVS is started; sound works OK with these settings.
Created attachment 4125 [details] KDE-induced mixer settings giving no sound These are the saved settings after KDE-CVS has started; sound is broken with these settings. Changing the "external amplifier down" setting from true to false reenables sound.
Additional note: the "start sound server" setting in the Sound System dialog has no influence on the situation.
According to http://nbpfaus.net/~pfau/inspiron.html (middle of the final section): "External Amplifier Power Down shuts off the speakers when unmuted." So it seems clear that this is indeed intended to shut down the speakers, and the question becomes which component turns this setting on. How do aRts/KMix know which settings to change?
I think the "Amplifier Power Down" switch is being turned on by KMix. After enabling the "Advanced" checknox in KMix, I saw this control was turned on, so I disabled it. Since then, sound is no longer being disabled upon KDE startup. I do not see any indication that this is a Gentoo-specific issue. It might be an on-board Intel sound card for laptops issue.
I also think is the "External Amplifier Power Down" switch fault.
I also have this problem -- suddenly. I used to use a cmipci8738 without too many problems. Sound levels were restored fine on KDE startup. Now I've managed to get a much better Terratec card to work with ALSA, it uses the ice1712 driver. Sound levels are no longer restored on KDE startup. My guess is that kmix, or something like that, tries to restore the levels, but fails. This idea comes from the fact the kmix crashes _a lot_ and does not show the huge amount of controls on the ice1712 very well, if at all. While this problem with KDE isn't a "crash", I think it's pretty bad.
I still don't fully get what's going on, but since i muted the "External amplifier down" channel, and KMix 3.2.1 (after an upgrade) now saves and restores my mixer settings properly (as reported in the 3.2.1 changelog), I don't really have a problem any more. Sound just works again under KDE 3.2.1 :-).
Is it fixed now?
Created attachment 6512 [details] kmixctrl-restore.patch It happens to me with current CVS, too. After some investigation: At startup 'kmixctrl --restore' is executed (from share/autostart/restore_kmix_volumes.desktop) It does the following things: 1. create a dummy configuration (with all volumes set to zero, all channels unmuted, ...) 2. fill this configuration with values read from 'kmixctrlrc' 3. overwrite the configuration representing the hardware status with this new configuration. 4. actually apply the hardware configuration. when kmixctrlrc does not exist, obviously the volumes are set to zero. I propose the attached patch, with substitutes points 1 and 2 and 3 as follows: 1. read hardware configuration from hardware status (hunk in mixer.cpp) 2. overwrite specific values with values read from 'kmixctrlrc' (hunk in mixdevice.cpp) Please give it a try.
I bet this behaviour has changed in CVS with all the recent kmix changes
I agree to Stephan Gehn. I have fixed the restore problem in KMix2.1pre2, which is in CVS HEAD. The fix looks similar to the one posted here. It is not identical, because the "Volume" class implementation has changed massively. Feedback about the current KMix CVS version or about the version shipping with KDE3.3 is appreciated, so i can close this bug report. Chris
Christian, I fail to see the relevant changes with respect to volume restoring in mixdevice.cpp and mixer.cpp, are they in midevice.cpp 1.6 and mixer.cpp 1.77?
Gregorio, you are right. I fixed the issue of "cannot restore volume levels > 100", but it mutes everything when there is no (or no suitable) kmixctrlrc. I'll review your patch again.
*** Bug 84482 has been marked as a duplicate of this bug. ***
Christian, could you take a look at this problem and see if it can be solved with the patch above or in some other way, before the freeze? Thanks
Gregorio, I had to look at a lot of other bugs first. Now I managed to take a look at your patch. If I am not mistaken it fails to set the channel mask. Also I would not like to change volumeLoad() - it seems too risky. The real solution would be to let "kmixctrl --restore" to do nothing if there is no kmixctrlrc. I haven't manged to make it do so yet.
Finally I found a trivial and straightforward way to fix this. You might want to try the next patch (it is already tested and commited to CVS HEAD): diff -u -r1.76 mixer.cpp --- mixer.cpp 19 Jun 2004 22:01:08 -0000 1.76 +++ mixer.cpp 23 Aug 2004 17:26:24 -0000 @@ -144,6 +144,13 @@ void Mixer::volumeLoad( KConfig *config ) { QString grp = QString("Mixer") + mixerName(); + if ( ! config->hasGroup(grp) ) { + // no such group. Volumes (of this mixer) were never saved beforehand. + // Thus don't restore anything (also see Bug #69320 for understanding the real reason) + return; // make sure to bail out immediately + } + + // else restore the volumes m_mixDevices.read( config, grp ); // set new settings
The patch is fine for me, the bug can be closed.
Thanks for the feedback Gregorio. I'll close the bug.
there will be a backport to the BRANCH or not?
I agree that this fix is important and a backport is a very good idea. I now did backport this to KDE_3_3_BRANCH and KDE_3_2_BRANCH .
*** Bug 90208 has been marked as a duplicate of this bug. ***
*** Bug 87899 has been marked as a duplicate of this bug. ***
I am filing this bug with kmix because I do not see to dit actually ; the problem : - with my KDE session all sound applications using mic input do no work ; this applies to skypr (32 bits version on 64 bit machines), Ekiga, Audacity, etc... - no problem with a Gnome session Where to search ? Regards.