| Summary: | KMix does not restore volume when logging in | ||
|---|---|---|---|
| Product: | [Applications] kmix | Reporter: | gjditchfield |
| Component: | general | Assignee: | Christian Esken <esken> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | alexeypluzhnik7, alunduil+kde, apogarte, cfeck, colin, crissi99, flying-sheep, gio_6b, heri+kde, leon.maurer, lionlegion, markg85, Mathias.Homann, mmbossoni, nemeskey.david, tekwyzrd, thomas, tonywhite100, web |
| Priority: | NOR | ||
| Version: | 4.1 | ||
| Target Milestone: | --- | ||
| Platform: | Ubuntu | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | 4.8.3 | |
| Sentry Crash Report: | |||
|
Description
gjditchfield
2010-08-27 05:55:42 UTC
Maybe related to 210262 Hi there, I managed to find a solution... Open Kmix configuration and UNCHECK restore volume option. Someone put inverse logic on that button... OR alsa/pulseaudio handles volume restore much better than kmix Check this bug on redhat bugzilla https://bugzilla.redhat.com/show_bug.cgi?id=657373 I confirm the fix; after unchecking the option and rebooting, my Maverick machine emitted the KDE start-up sound for the first time in months. I can also confirm the fix; this computer was always mute on startup, but now it restores correctly. I'll try it on my other computer which always has volume set to 100% on startup... Now I'll just have to remember to re-check that box if anyone ever bothers to fix this bug. This bug is still present in KMix 3.8 using KDE Development Platform 4.6.00 (4.6.0), installed from ppa:kubuntu-ppa/backports. Thanks for the feedback. This is a very interesting observation. As Pulseaudio is operating the hardware controls, it might be in conflict with KMix. But if Pulseaudio is detected, KMix will not restore the volume levels at all. My guess is that Pulseaudio is not yet running when the volume restore happens (done by kmixctrl). So "kmixctrl" would use the ALSA backend and restore volumes, while "kmix" runs much later and detects "Pulseaudio". So we have a race condition. We have to think very hard for a solution, but an idea would be to automatically disable the restore option when KMix runs with the Pulseaudio backend. This is a generic design issue (also affects MPRIS more or less), so I will NOT assign it over to the Pulsaudio component. I think KMix should just remove all volume restore options. It's really something that should be handled below the UI layer. This would likely solve the issues in this case. That said, PA should still restore it's volumes overwriting what kmixctrl has written if this race is as you describe. So I'm not sure what is going on. The volume is a user preference, so "someone" has to restore volumes on user/session level. And as kmixctrl is not UI related, it is currently a good candidate. PA doesn't restore volume level for my OpenSUSE and Ubuntu boxes (I didn't configure anything to enable or disable that). So I guess it's still an explanation, and disabling volume restoring if Pulseaudio is at least worth a try. *** Bug 256131 has been marked as a duplicate of this bug. *** I will now try to explicitly sync the volume configuration object. Probably it will help. SVN commit 1247885 by esken: CCBUGS: 249180 Explicitly Sync volume configuration (try to fix volume saving) M +1 -0 kmix.cpp M +1 -0 kmixd.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=1247885 To the bugreporter (and everybody els with this bug) - I'd like to do an experiment: 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. Awaiting feedback I tried the experiment requested in comment 12 above, with KMix 3.8 and KDE 4.6.5 on Ubuntu Natty When I changed the volume, logged out, and logged back in, the volume was set to 6%, so the bug was still there. When I changed the volume, made KMix quit, logged out, and logged back in, KMix started running and the volume was set to 6%. When I changed the volume to 40%, made KMix quit, ran "kmixctrl -s" in Konsole, logged out, and logged back in, KMix started running but the volume remained at 40%. Thanks for the feedback. It shows that KMix is not able to save the volume. Probably the fix in comment 11 will fix it. I will backport this to KDE4.7 so people will be able to try with KDE4.7.2. SVN commit 1254081 by esken: CCBUGS: 249180 Fix volume writing. Backport to branch 4.7 M +1 -0 kmix.cpp M +1 -0 kmixd.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=1254081 SVN commit 1254082 by esken: CCBUGS: 249180 Fix volume writing. Backport to branch 4.6 M +1 -0 kmix.cpp M +1 -0 kmixd.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=1254082 Can I just clarify here. Are the users experiencing problems using PulseAudio or not? When PulseAudio is used KMix should refuse to save/restore volumes. As I stated earlier, doing this kind of stuff in a UI layer is just wrong, especially when dealing with e.g. login sounds. It needs to be done at a lower level. If these fixes override the specific code I put in place to disable volume save/restore with PulseAudio, then they are very much a regression on the intended behaviour, regardless if they appear to solve the problem. Problems should be fixed in the correct layer, not worked around. Workarounds lead to confusion and strange corner cases (like the volume being loud for the first part of the login sound and then get turned down to be quieter or vice versa). In my case (currently Ubuntu Natty, pulseaudio 1:0.9.22+stable-queue-24-g67d18-0ubuntu3.1, KDE 4:4.6.5-0ubuntu1~ppa1), how would I tell if I'm having trouble with PulseAudio or not? I just want to push the volume up/down keys and have everything work. If I understand comment 18 correctly, KMix is deliberately not restoring the volume level when I log in, and PulseAudio was restoring the volume level to 6%; now, PulseAudio is restoring it to 40% because of the "kmixctrl -s" command. Could the real problem be that PulseAudio is unaware of the volume changes that KMix has made? (Use case 1: I log in to a KDE desktop session and observe that the audio volume is 33%. I push the "volume up" key to raise the volume to 50%. I log out of KDE and back in: the volume should be 50%. Use case 2: I log in to a KDE desktop session and observe that the audio volume is 33%. I push the "volume up" key to raise the volume to 50%. I log out of KDE, and log in to a GNOME session: the volume should be 50%. I think that's Colin Guthrie's intent, but I'll bet we get an argument!) kmixctrl -s certainly does not cause pulseaudio to start working and PA should very much be aware of the volume changes coming from kmix (kmix should be controlling PA directly - I presume the tabs shown in kmix are the fixed 4 that cover playback, recording, output and capture devices?) FWIW you'll get no argument about your use cases. This should all just work exactly as you describe without kmix doing anything regarding saving/restoring the volumes. The only thing kmix should be doing here, is listening for the key presses and then calling the appropriate PA APIs to adjust the volume. It would be very useful if you could do the following test for me. 1. Login. 2. Kill all kmix processes. 3. Use pavucontrol to set the volume to something memorable. 4. Reboot (not 100% needed but PA will not die immediately when you log out so either reboot is the easiest instruction! - If you prefer, logout, login on text console, type "pulseaudio -k", then logout there, and switch back to the GUI login screen.) 5. Check that the volume is as you left it. That said, I need to ensure that kmix doesn't run on login in step 5, so maybe just rename the kmix and kmixctl binaries temporarily before starting to be absolutely sure. If this all works, then there could still be a problem in kmix, but the problem is perhaps that it's restoring things when it shouldn't rather than not restoring when it should. If this doens't work then we need to work out why so I can fix it at the PA level. Thanks for any help tracking this issue down fully :) I killed kmix (pgrep only showed one process), used pavucontrol to change the volume from 42% to 66%, renamed /usr/bin/kmix and /usr/bin/kmixctrl, rebooted, and logged in. pavucontrol showed the volume to be 42%, and ps showed a kmix process running: "kdeinit4: kmix [default]" ! I renamed /usr/lib/kde4/libkdeinit/libkdeint4_kmix.so and .../libkdeinit4_kmixctrl.so, reset the volume, rebooted, and logged in. This time pavucontrol reported the volume to be 66%. Awesome, thanks for testing. So it seem that with kmix completely out the way, all is well. The issue is that kmix is actually probably restoring volumes to a previously saved value, but doesn't actually save it reliably. When kmix is kept completely out the equation the volume save/restore works fine.
OK, so my final question (hopefully) is this. Is your kmix definitely compiled with PA support? Do you see the four fixed tabs? "Playback Devices", "Capture Devices", "Playback Streams" and "Capture Streams"? Or is it showing you basically one tab with all the ALSA kcontrols on it ("Master", "PCM" etc.?)
I see all four tabs. The binaries are from the kubuntu PPA https://launchpad.net/~kubuntu-ppa/+archive/ppa. If you're curious about the hardware, you can find info at https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/845275 which is a bug I found during Oneiric beta testing. OK, thanks for confirming. That means I've definitely missed some places where the volume save/restore should be prevented. FYI, all the volume save/restore code should basically not run with a PA backend - certainly that was my original intention, but I've obviously not been as thorough as I need to be there. I'll have a hunt through the code shortly and see if I can find the problem cases. I do not think that you missed any place for volume save/restore, Colin. I still tend to my explanation in comment 6, namely kmixctrl using ALSA as pulseaudio is not launched (fast enough). (In reply to comment #25) > I do not think that you missed any place for volume save/restore, Colin. I > still tend to my explanation in comment 6, namely kmixctrl using ALSA as > pulseaudio is not launched (fast enough). Right, that would indicate a problem/race in PA code as it should always be autospawned when needed in 99.99% of setups (the times when you don't are when you're a developer like me and want to restart PA daemon a lot!) The problem is, I cannot reproduce any races like this. My system is pretty old, but an SSD disk means that things startup OK for me :s I guess I'll have to inject delays into the startup logic to try and reproduce the problem scenario. Gonna be tricky. *** Bug 287761 has been marked as a duplicate of this bug. *** *** Bug 253546 has been marked as a duplicate of this bug. *** FWIW, I found a bug recently in kmix's PA support such that kmixctl (the command line utility) would not properly detect PA as running. Normally, when PA is used, kmix should do nothing at login (i.e. regardless of the "Restore volumes at login" option, it should do nothing as PA will handle everything). Because of the bug, kmixctl actually did mess with the volumes and it might have set the volumes incorrectly (i.e. perhaps some very old data that will ultimately only be used to restore, never store hence the 6% case. Anyway, I'll commit the fix upstream whenever SVN or git opens, but in the meantime you can perhaps try this fix in this patch: http://svnweb.mageia.org/packages/cauldron/kdemultimedia4/current/SOURCES/0100-Prevent-kmixctrl-running-with-PulseAudio.patch?revision=229402&view=markup It's good to hear that there is a possible solution to the issue. It seemed a bit like an "impossible" situation. I believe there are more bug reports around like this. When I see them next time, I will check them and mark them as duplicate if it seems appropriate. *** Bug 210262 has been marked as a duplicate of this bug. *** *** Bug 298347 has been marked as a duplicate of this bug. *** *** Bug 272844 has been marked as a duplicate of this bug. *** So I've now committed the fix (forgot to reference the BUG sadly), so hopefully this is fixed, but let's wait for users upgrading to confirm seeing as the new version is expected any time now :) can this get some attention? it's KDE 4.8.3 by now and on two computers in my home kmix does *not* remember volume settings at all. on my own computer I have to *unmute* sound after every login, my wife has to turn her volume down after each login... not funny at all. @Mathias, considering I found and fixed a bug recently, I'm not sure what more you expect us to do in order to give it "more attention". Your tone does not motivate me to try and help you solve your problem - I do this for "fun" afterall! So please provide the following information: 1. Are you using PulseAudio 2. Is your kmix compiled with PulseAudio support 3. Is your Qt compiled with the GLib Main Loop Keep in mind that if you *are* using PulseAudio, kmix is not supposed to save/restore volumes. That job is left to PA. The recent problem fixed in 4.8.3 was actually a result of kmix restoring the wrong volumes (as it had never saved them) rather than just letting PA do it's thing. So please provide more information about your setup rather than just complaining. There are many factors involved. I am using pulseaudio, my kmix has PA support. How can I tell about QT and the glib main loop thing? I didn't actually know about the fact that since PA kmix is not *supposed* to save/restore volumes... so how does one save the volume settings with PA now? Well, PA should just save/restore volumes without any configuration (including per-application volumes) If you see PulseAudio style devices in kmix (i.e. four fixed tabs) then you can be quite sure about the Glib Mainloop thing (it's pretty much how most Qt's are built so it's generally speaking not an issue). Can you run kdebugdialog and tick all the kmix bug options and then do: kmixctrl -r This should give some nice debug output... Actually looking at this here I do see some interesting things.... (forgive the inline paste): kmixctrl(23716)/kmix MixerToolBox::initMixerInternal: "Sound drivers supported: PulseAudio + ALSA + OSS + MPRIS2 Sound drivers used: PulseAudio" Total number of detected Mixers: 4 kmixctrl(23716)/kmix MixSet::read: MixSet::read() of group "MixerPulseAudio::Playback_Devices:1" kmixctrl(23716)/kmix MixDevice::read: MixDevice::read(): This MixDevice does not permit volume restoration (i.e. because it is handled lower down in the audio stack). Ignoring. kmixctrl(23716)/kmix MixDevice::read: MixDevice::read(): This MixDevice does not permit volume restoration (i.e. because it is handled lower down in the audio stack). Ignoring. kmixctrl(23716)/kmix Mixer_PULSE::writeVolumeToHW: pa_context_set_sink_volume_by_index() failed kmixctrl(23716)/kmix Mixer_PULSE::writeVolumeToHW: pa_context_set_sink_volume_by_index() failed kmixctrl(23716)/kmix MixSet::read: MixSet::read() of group "MixerPulseAudio::Capture_Devices:1" kmixctrl(23716)/kmix MixDevice::read: MixDevice::read(): This MixDevice does not permit volume restoration (i.e. because it is handled lower down in the audio stack). Ignoring. kmixctrl(23716)/kmix Mixer_PULSE::writeVolumeToHW: pa_context_set_source_volume_by_index() failed kmixctrl(23716)/kmix MixSet::read: MixSet::read() of group "MixerPulseAudio::Playback_Streams:1" kmixctrl(23716)/kmix MixDevice::read: MixDevice::read(): This MixDevice does not permit volume restoration (i.e. because it is handled lower down in the audio stack). Ignoring. kmixctrl(23716)/kmix Mixer_PULSE::writeVolumeToHW: pa_context_set_sink_input_volume() failed kmixctrl(23716)/kmix MixSet::read: MixSet::read() of group "MixerPulseAudio::Capture_Streams:1" Running Mixer_Backend destructor Running Mixer_Backend destructor Running Mixer_Backend destructor Running Mixer_Backend destructor The messages are mostly correct, but the debug that says: "pa_context_set_sink_input_volume() failed" is odd as the call should never be called in the first place... Will look tonight. hm. I *do* see the usual 4 device tabs in kmix... have to do the debug thing later today, am not at the computer in question... here's what I get as debug output: http://paste.opensuse.org/5545756 on the other hand, http://susepaste.org/15011245 looks like kmix is built with the required options... I'm puzzled. That's basically what would happen in KDE versions prior to 4.8.3. I've looked at the tag in SVN and it definitely contains the commit I did... Are you 100% certain you've got kmix 4.8.3 (it was only a released a few days ago). ... i still have kmix 4.7.2 here, dont know how much you know about opensuse, packaging policies, and secondary repositories... packman still has kmix 4.7.2 so it gets downgraded all the time. (In reply to comment #35) > can this get some attention? it's KDE 4.8.3 by now and on two computers in > my home kmix does *not* remember volume settings at all. (In reply to comment #42) > i still have kmix 4.7.2 here Please in future don't provide contradictory information. You implied you were using 4.8.3 on both your machines when the bug report specifically menitoned the bug was fixed in that version then complained about it not being fixed yet... then it turns our you're on 4.7.2... this is not a downstream tracker, but an upstream one. I'm not really interested in downstream packaging policy etc. You should likely request that opensuse updates their packages like was done on fedora: https://bugzilla.redhat.com/show_bug.cgi?id=657373 (note I'm not a RH guy, just happened to notice that bug and let them know - you should do the same for opensuse). I'm going to mark this bug as fixed. Please reopen if you can reproduce with *latest* kmix. Hi, Sorry for dropping in this bug, but i can verify that the issue is still here. And yes, with KDE 4.8.3. Take a look at my kmixctrl: kmixctrl(1425)/kmix MixerToolBox::initMixerInternal: Looking for mixers with the : "PulseAudio" driver kmixctrl(1425)/kmix Mixer_PULSE::Mixer_PULSE: Probing for PulseAudio... kmixctrl(1425)/kmix sink_cb: Got some info about sink: "Barts HDMI Audio [Radeon HD 6800 Series] Digitaal stereo (HDMI)" kmixctrl(1425)/kmix sink_cb: Got some info about sink: "Intern geluid Analoog stereo" kmixctrl(1425)/kmix source_cb: Ignoring Monitor Source: Monitor of Barts HDMI Audio [Radeon HD 6800 Series] Digitaal stereo (HDMI) kmixctrl(1425)/kmix source_cb: Ignoring Monitor Source: Monitor of Intern geluid Analoog stereo kmixctrl(1425)/kmix source_cb: Got some info about source: "Intern geluid Analoog stereo" kmixctrl(1425)/kmix client_cb: Got some info about client: "ConsoleKit Session /org/freedesktop/ConsoleKit/Session1" kmixctrl(1425)/kmix client_cb: Got some info about client: "KMix KDE 4" kmixctrl(1425)/kmix client_cb: Got some info about client: "XSMP Session on KDE as 10ef125dbd9000133712051700000008640010" kmixctrl(1425)/kmix client_cb: Got some info about client: "libphonon" kmixctrl(1425)/kmix client_cb: Got some info about client: "KMix KDE 4" kmixctrl(1425)/kmix client_cb: Got some info about client: "kmix-probe" kmixctrl(1425)/kmix ext_stream_restore_read_cb: Initialising restore rule for new user: "Event Sounds" kmixctrl(1425)/kmix Mixer_PULSE::Mixer_PULSE: PulseAudio probe complete. kmixctrl(1425)/kmix Mixer_PULSE::connectToDaemon: Attempting connection to PulseAudio sound daemon kmixctrl(1425)/kmix Mixer_PULSE::Mixer_PULSE: PulseAudio status: Active kmixctrl(1425)/kmix MixDevice::init: MixDevice::init() _id= "alsa_output.pci-0000_01_00.1.hdmi-stereo" kmixctrl(1425)/kmix MixDevice::addToPool: MixDevice::init() id= "alsa_output.pci-0000_01_00.1.hdmi-stereo@" kmixctrl(1425)/kmix MixDevice::init: MixDevice::init() _id= "alsa_output.pci-0000_00_14.2.analog-stereo" kmixctrl(1425)/kmix MixDevice::addToPool: MixDevice::init() id= "alsa_output.pci-0000_00_14.2.analog-stereo@" kmixctrl(1425)/kmix Mixer_PULSE::open: Using PulseAudio for mixer: "Playback Devices" kmixctrl(1425)/kmix Mixer::openIfValid: Mixer::open() detected master: "alsa_output.pci-0000_01_00.1.hdmi-stereo" kmixctrl(1425)/kmix MixerToolBox::possiblyAddMixer: Added card "PulseAudio::Playback_Devices:1" kmixctrl(1425)/kmix MixerToolBox::initMixerInternal: Success! Found a mixer with the : "PulseAudio" driver kmixctrl(1425)/kmix MixDevice::init: MixDevice::init() _id= "alsa_input.pci-0000_00_14.2.analog-stereo" kmixctrl(1425)/kmix MixDevice::addToPool: MixDevice::init() id= "alsa_input.pci-0000_00_14.2.analog-stereo@" kmixctrl(1425)/kmix Mixer_PULSE::open: Using PulseAudio for mixer: "Capture Devices" kmixctrl(1425)/kmix Mixer::openIfValid: Mixer::open() detected master: "alsa_input.pci-0000_00_14.2.analog-stereo" kmixctrl(1425)/kmix MixerToolBox::possiblyAddMixer: Added card "PulseAudio::Capture_Devices:1" kmixctrl(1425)/kmix MixerToolBox::initMixerInternal: Success! Found a mixer with the : "PulseAudio" driver kmixctrl(1425)/kmix Mixer_PULSE::open: Using PulseAudio for mixer: "Playback Streams" kmixctrl(1425)/kmix MixerToolBox::possiblyAddMixer: Added card "PulseAudio::Playback_Streams:1" kmixctrl(1425)/kmix MixerToolBox::initMixerInternal: Success! Found a mixer with the : "PulseAudio" driver kmixctrl(1425)/kmix Mixer_PULSE::open: Using PulseAudio for mixer: "Capture Streams" kmixctrl(1425)/kmix MixerToolBox::possiblyAddMixer: Added card "PulseAudio::Capture_Streams:1" kmixctrl(1425)/kmix MixerToolBox::initMixerInternal: Success! Found a mixer with the : "PulseAudio" driver Running Mixer_Backend destructor Running Mixer_Backend destructor Running Mixer_Backend destructor Running Mixer_Backend destructor Running Mixer_Backend destructor Running Mixer_Backend destructor Running Mixer_Backend destructor Running Mixer_Backend destructor Running Mixer_Backend destructor Running Mixer_Backend destructor Running Mixer_Backend destructor Running Mixer_Backend destructor Running Mixer_Backend destructor Running Mixer_Backend destructor Running Mixer_Backend destructor Running Mixer_Backend destructor kmixctrl(1425)/kmix Mixer::setGlobalMaster: ref_card= "PulseAudio::Playback_Devices:1" , ref_control= "alsa_output.pci-0000_01_00.1.hdmi-stereo" , preferred= true kmixctrl(1425)/kmix Mixer::setGlobalMaster: Mixer::setGlobalMaster() card= "PulseAudio::Playback_Devices:1" control= "alsa_output.pci-0000_01_00.1.hdmi-stereo" kmixctrl(1425)/kmix MixerToolBox::initMixerInternal: "Sound drivers supported: PulseAudio + ALSA + OSS + MPRIS2 Sound drivers used: PulseAudio" Total number of detected Mixers: 4 kmixctrl(1425)/kmix MixSet::read: MixSet::read() of group "MixerPulseAudio::Playback_Devices:1" kmixctrl(1425)/kmix MixDevice::read: MixDevice::read(): This MixDevice does not permit volume restoration (i.e. because it is handled lower down in the audio stack). Ignoring. kmixctrl(1425)/kmix MixDevice::read: MixDevice::read(): This MixDevice does not permit volume restoration (i.e. because it is handled lower down in the audio stack). Ignoring. kmixctrl(1425)/kmix Mixer_PULSE::writeVolumeToHW: pa_context_set_sink_volume_by_index() failed kmixctrl(1425)/kmix Mixer_PULSE::writeVolumeToHW: pa_context_set_sink_volume_by_index() failed kmixctrl(1425)/kmix MixSet::read: MixSet::read() of group "MixerPulseAudio::Capture_Devices:1" kmixctrl(1425)/kmix MixDevice::read: MixDevice::read(): This MixDevice does not permit volume restoration (i.e. because it is handled lower down in the audio stack). Ignoring. kmixctrl(1425)/kmix Mixer_PULSE::writeVolumeToHW: pa_context_set_source_volume_by_index() failed kmixctrl(1425)/kmix MixSet::read: MixSet::read() of group "MixerPulseAudio::Playback_Streams:1" kmixctrl(1425)/kmix MixSet::read: MixSet::read() of group "MixerPulseAudio::Capture_Streams:1" Running Mixer_Backend destructor Running Mixer_Backend destructor Running Mixer_Backend destructor Running Mixer_Backend destructor The interesting one: "kmixctrl(1425)/kmix MixDevice::read: MixDevice::read(): This MixDevice does not permit volume restoration (i.e. because it is handled lower down in the audio stack)." KMix version: Qt: 4.8.1 KDE Development Platform: 4.8.3 (4.8.3) KMix: 4.1 The issue only seems to happen at boot and first login. Then KMix start up with a very low volume and an error (which i reported here https://bugs.kde.org/show_bug.cgi?id=300100). If you need any more information or want me to test out patches, please feel free to ask :) Cheers, Mark @Mark: Actually shows things working as intended. When used on top of PulseAudio, KMix should NOT restore any volumes. Although this was the title of this bug report, it's actually not really representative of what the ultimate problem was which was that kmixctrl wasn't detecting PulseAudio and was "restoring" volumes from invalid or outdated initial data (as it was never really saved). This basically made it look like the volume was not being restored on login, but in actual fact it was being *reset* on every login. PulseAudio should be restoring the volumes and if it does not, then the problem lies there and not in anything KDE related. You do have to make sure no other process is doing any kind of volume restoration (e.g. aumix). (of course the error "pa_context_set_sink_volume_by_index() failed" is interesting in itself and I do need to look at that but it's different from the root cause of this bug. I'll leave this bug open until I take a look at that specific issue. Git commit a4df93aee07fde55e3d9200d2cde0063e7b68a33 by Colin Guthrie. Committed on 16/05/2012 at 10:54. Pushed by cguthrie into branch 'master'. pulse: More fixes relating to volume restoration via kmixctrl. When we fail to read the values from a config file, do not attempt to then write them to the sinks and sources anyway. M +34 -30 core/mixdevice.cpp M +2 -2 core/mixdevice.h M +5 -1 core/mixer.cpp M +14 -4 core/mixset.cpp M +2 -2 core/mixset.h http://commits.kde.org/kmix/a4df93aee07fde55e3d9200d2cde0063e7b68a33 Git commit 1749da9d029dc0fe42604ec9bf17d45abac74428 by Colin Guthrie. Committed on 16/05/2012 at 10:58. Pushed by cguthrie into branch 'master'. pulse: Use the same Glib event loop detection as in phonon. This is a little bit neater IMO and does the same job. M +2 -3 backends/mixer_pulse.cpp http://commits.kde.org/kmix/1749da9d029dc0fe42604ec9bf17d45abac74428 @Mark The above commits should prevent any calls to the actual h/w writing code. I'm not sure it will solve your problems completely (it could ultimately be a problem outside of kmix) but it should certainly solve this particular bug. (In reply to comment #48) > @Mark The above commits should prevent any calls to the actual h/w writing > code. I'm not sure it will solve your problems completely (it could > ultimately be a problem outside of kmix) but it should certainly solve this > particular bug. Thank you for that. I'm guessing that fix will be in KDE 4.9.0 but not in KDE 4.8.4 right? (if there is even going to be a 4.8.4 release). I'm not sure if there will be a 4.8.4 or not (or how it'll be done considering the git migration), but if I hear of it happening, I'll be sure to cherry pick the fix. Other than that, yeah, 4.9 I guess (tho' you can ask your friendly arch packager to include the patch in their package in the short term) Git commit 899783ada273dea65a4fb615c16f44a382e826b0 by Colin Guthrie. Committed on 16/05/2012 at 10:58. Pushed by cguthrie into branch 'KDE/4.8'. pulse: Use the same Glib event loop detection as in phonon. This is a little bit neater IMO and does the same job. (cherry picked from commit 1749da9d029dc0fe42604ec9bf17d45abac74428) M +2 -3 backends/mixer_pulse.cpp http://commits.kde.org/kmix/899783ada273dea65a4fb615c16f44a382e826b0 I am using Arch Linux 64-bit with ALSA (no PulseAudio) with KDE 4.8.4 and the bug still exists. If I uncheck the check box "Restore volumes on login" everything works fine, but if checked it doesn't. KDE 4.11 here, pulseaudio and KDE installed from the official Archlinux repos, and i gave this problem. *have, not “gave”, sorry ArchLinux, KDE 4.12.97, pulseaudio: $ kmixctrl --save // Change volume in applet $ kmixctrl --restore // Sound not restored How can i help with this? Was working in KDE 4.12 C´edric: $ kmixctrl --save // Change volume in applet Does this means, the volume changes, when you call "kmixctrl --save"?!? This would be weird. $ kmixctrl --restore // Sound not restored So restore behavior is OK. KMix does NOT restore volume for Pulseaudio, as intended. Same problem. No way to set volume on login. At the end of login I have always the same volume I had at logout. Checking or not "Restore volumes on login" in KMix don't affect this behaviour. KDE 4.11.2 OpenMandriva Linux 2013.0, 64 bit (In reply to comment #57) > Same problem. No way to set volume on login. > At the end of login I have always the same volume I had at logout. Checking > or not "Restore volumes on login" in KMix don't affect this behaviour. This is expected behaviour. On a PulseAudio system, the volume is saved and restored. If you want a specific volume on login, you should set your volumes as desired, wait about 5s and then copy your ~/.pulse/*-device-volumes.tdb file to a known filename, then have a little init/login script that restores this file prior to pulseaudio starting (probably the best way is to rename /usr/bin/pulseaudio to /usr/bin/pulseaudio-bin and then write a replacement /usr/bin/pulseaudio bash script to do the copy and then exec the real PA. Something like: #!/bin/bash if [ -f $HOME/.pulse/preset-volumes.tdb ]; then cp -f $HOME/.pulse/preset-volumes.tdb $HOME/.pulse/$(< /etc/machine-id)-device-volumes.tdb fi exec /usr/bin/pulseaudio-real "$@" That should do the trick I think. This is certainly not something that is considered standard in PA, but it wouldn't be too hard to add support ot it. e.g. module-stream-restore for example has a fallback_table= argument to prime the data in the absense of saved data, but this still doesn't do what you want as user changes are still saved and restored. There is the restore_volume and restore_muted arguments to module-device-restore (the module which owns/manages the device-volumes.tdb file) which prevents it setting the volumes on restore, but then you rely on ALSA saving and restoring the volumes. Depending if the Mandriva folks have switched over to the alsactl state daemon or not, you could relatively easily use this approach. Namely prevent the alsa-store.service in systemd (systemctl mask alsa-store.service) and then only call "alsactl store" (as root) when you are happy with your volumes. That should also acheive the desired result. Hope that helps. For Archlinux users, it's not a pulseaudio issue but an alsa issue.... You need to install alsa-utils... Thanks for fast answer. I don't know if in OpenMandriva 2013 Pulse Audio is used and proposed solution is a bit too difficult for me. I've alsa-utils installed but it's not clear how tu use it. I opened a bug in OpenMadriva with link to this thread. (In reply to comment #60) > Thanks for fast answer. > I don't know if in OpenMandriva 2013 Pulse Audio is used and proposed > solution is a bit too difficult for me. > I've alsa-utils installed but it's not clear how tu use it. > I opened a bug in OpenMadriva with link to this thread. Note that Cédric's answer was about getting things to work as intended (i.e. volumes are saved throught use and then restored to the last used value on next login) where as your problem seems to be about restoring volumes to a user-defined known-good state at each login (i.e. not the last used state) - assuming I've understood correctly!! So these appear to be different issues. Hope that helps. (In reply to comment #61) > (In reply to comment #60) >... where as your problem seems to be about restoring volumes to a > user-defined known-good state at each login (i.e. not the last used state) - > assuming I've understood correctly!! So these appear to be different issues. > > Hope that helps. You've understood perfectly. Do you think it's better if I open a new thread? it works for me lel On Tue, Apr 8, 2014 at 4:18 AM, Giorgio <gio_6b@yahoo.it> wrote: > https://bugs.kde.org/show_bug.cgi?id=249180 > > --- Comment #62 from Giorgio <gio_6b@yahoo.it> --- > (In reply to comment #61) > > (In reply to comment #60) > >... where as your problem seems to be about restoring volumes to a > > user-defined known-good state at each login (i.e. not the last used > state) - > > assuming I've understood correctly!! So these appear to be different > issues. > > > > Hope that helps. > You've understood perfectly. Do you think it's better if I open a new > thread? > > -- > You are receiving this mail because: > You are on the CC list for the bug. > Marking as fixed again. Please create a new ticket, if you see this again, because the cause is most probably unrelated then. |