Bug 272844 - Muted sound on system start up when "Restore volumes at login" option is turned on
Summary: Muted sound on system start up when "Restore volumes at login" option is turn...
Status: RESOLVED DUPLICATE of bug 249180
Alias: None
Product: kmix
Classification: Applications
Component: Backend: Pulseaudio (show other bugs)
Version: unspecified
Platform: Ubuntu Linux
: NOR normal
Target Milestone: ---
Assignee: Colin Guthrie
Depends on:
Reported: 2011-05-09 12:26 UTC by lionlegion
Modified: 2012-04-25 22:41 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In:

Output of 'amixer -c 0' command (2.28 KB, text/plain)
2011-10-08 15:52 UTC, lionlegion

Note You need to log in before you can comment on or make changes to this bug.
Description lionlegion 2011-05-09 12:26:30 UTC
Version:           unspecified (using KDE 4.6.2) 
OS:                Linux

Kmix version 3.8

When "Restore volumes at login" checkbox is marked, each time after reboot the sound is muted. It can be easily unmuted with any of the sound controls ( keybord  keys or kmix applet ) but it is annoying.

When you turned off that checkmark - everything seems to be fine. In this case the sound at start up is exactly at the same level as it was before reboot ( at least at single user environment ) 

This bug appeared after upgrade from Kubuntu 10.10 to Kubuntu 11.04

Reproducible: Always

Steps to Reproduce:
Go to KMix settings
Check "Restore volumes at login" option
Save settings

Actual Results:  
The sound is muted at startup

Expected Results:  
The sound to be at the same level as before reboot

OS: Linux (x86_64) release 2.6.38-8-generic
Compiler: cc
Comment 1 George 2011-06-23 18:15:59 UTC
I can confirm this.
KDE 4.6.4, rpms for opensuse 11.4
Comment 2 Christian Esken 2011-08-17 21:07:32 UTC
Can you try to change the volume levels, and the quit KMix once (Ctrl-q). Quitting should definitely save the volume levels (but make sure you have volume restoring enabled in KMix). If those volume levels are restored on your next login, you will have at least an workaround. Please let me know once you tried that.

You can find out whether the volume levels were changed by playing around with the volume levels and then using the volume restorer manually in a Konsole window:

kmixctrl -s      # To save
kmixctrl -r      # To restore

Please note there might be other applications messing around with the sound volume, go example  the Flashplayer (often used in a Web browser). But also any Multimedia application might be changing the volume after KMix has done it.
Comment 3 lionlegion 2011-10-07 21:29:30 UTC
I tried to investigate problem using console commands that you supplied.
And I noticed that kmix saves and restore volume level only of master channel. In general it doesn't seem to be correct and evidently causes this problem. When computer have few audio channels all their volume levels should be saved and restored.

My laptop has 2 audio channels:
1) HDMI output ( not used so is always muted )
2) Internal speakers

I noticed that volume of internal laptop speakers is muted at start up only if HDMI volume is muted on computer shut down.

I think that when I shut down laptop internal speakers audio devices is being unplugged/umounted first. So Phonon fallback to another that is still active and it became master channel. So kmix saves volume level of one channel and restores it to completely another one.
Comment 4 Christian Esken 2011-10-08 10:21:14 UTC
KMix saves and restores all controls. Seems to be a soundcard related issue.

For further insight into this, please post the following information:

- Which sound backend is used. Please copy the output from
    KMix menu => Help => Hardware information

- The ouput of "amixer" (or "amixer -c 1" or any other number that corresponds to the affected soundcard).
Comment 5 lionlegion 2011-10-08 15:52:21 UTC
Created attachment 64340 [details]
Output of 'amixer -c 0' command
Comment 6 lionlegion 2011-10-08 16:03:18 UTC
KMix menu => Help => Hardware information:

Sound drivers supported: PulseAudio + ALSA + OSS
Sound drivers used: PulseAudio

For output of 'amixer -c 0' please see upper attachment

Since you mentioned that kmix should save all controls I tried to double check.
I had 3 output devices during my test
1) HDMI output ( not used so is always muted )
2) Internal speakers
3) Wireless speaker connected  via USB dongle

I did
1) kmixctrl -s
2) Change volume levels of all 3 channels
3) kmixctrl -r

And it always restores only level of 'Internal speakers' channel for me. Two other volume controls are not being affected by 'kmixctrl -r' command.
It works this way despite which one is set as master channel. So my previous guess about master channel issue is really incorrect.
Comment 7 Christian Esken 2011-12-30 18:37:24 UTC
I see you are using Pulseaudio as Backend. Probably KMix volume restoration (kmixctrl) interferes with the one built in Pulseaudio. In theory this should not happen, as kmixctrl will/should also use Pulsaudio.
This behavior has also been reported in a different bug report. I will look it up later and merge them if applicable. I might automatically disable volume restoration when Pulseaudio gets activated.
Comment 8 Christian Esken 2012-04-25 21:33:34 UTC
I think this might be the same issue as the one from bug 249180. I will not directly merge both bugs, but assign it over to the Pulseaudio backend maintainer, so he can either merge them, not merge them or give them back to me.
Comment 9 Colin Guthrie 2012-04-25 22:41:21 UTC
Yeah I think this is ultimately a dupe.

The issue was that kmixctl (a command line app) didn't recognise PulseAudio as running and thus "restored" volumes (normally if PulseAudio is detected, it should refuse to restore volumes - just like if the tick boxes were always turned off) Sadly, the volumes were *saved* from kmix (the GUI app) which DID detect PA properly and thus didn't ever save anything.

Thus kmixctl would always restore null or default volumes which have no relation to the previous volume.

This should now be fixed in kmix 4.8.3

*** This bug has been marked as a duplicate of bug 249180 ***