In default configuration, kmixer and pulseaudio-kde are both under /usr/share/autostart.
This way, after login, kmix starts and keep waiting for pulseaudio, delaying the login and the "mouse readiness" about 40 seconds.
If I move pulseaudio-kde.desktop to /etc/xdg/autostart, the problem is gone.
But after new system update, pulseaudio-kde.desktop is back to /usr/share/autostart, and the problem is back.
Steps to Reproduce:
2. Check time until mouse is ready to respond. Locally: about 1m20s.
3. Open a terminal, run: sudo mv /usr/share/autostart/pulseaudio-kde.desktop /etc/xdg/autostart
6. Check time until mouse is ready to respond. Locally: about 15s.
Kmix waits for pulseaudio. Time to system become ready to use: 1m20s.
Pulseaudio starts before Kmix. Time to system become ready to use: 15s.
Move pulseaudio-kde.desktop to /etc/xdg/autostart as default.
Informational note: It might be a similar issue like we have with MPRIS. If it is the same, then the Pulseaudio backend needs to be converted to do asynchronous communication. Not sure whether the Pulse lib supports such a mode. Colin, what would you say?
The PulseAudio libraries are, and always have been, fully asynchronous. The main issue is that we need to test for PulseAudio before deciding which mode to use and thus that part of the operation has to be synchronous. That said, there should never be delays of this long while starting, so something somewhere is contributing to that. Quite what, I don't know
Colin, I agree that during startup it is a problem (we need to know which backends to activate).
Unfortunately these lockups with arbitrary other applications are hard to diagnose and fixing it is even harder. It tends to happen again and again, and not only with KMix. We had that with kded, global shortcuts and notification area (probably more not yet identified). I can only give the following tips for people affected:
Try to find out whether it is really Pulseaudio specific (likely (but not 100% confirmed) given the exact description of the bug reporter) by changing the backend:
# killall kmix; sleep 2;
# kwriteconfig -file kmixrc -group Global -key Backends -type string ALSA ;
# sleep 1 ; kmix
Also see http://kmix5.wordpress.com/2011/12/30/winter-of-69-welcome-kmix-v4/ that shows how to additionally add MPRIS2 (but which also has lockup problems in 4.10)
 issues with the MPRIS2 backend, feedback from kdemultimedia and other KDE developers, and also from Internet searches.
Git commit 91284ff2561ba9627dfe47d21593f472df9ffa8e by Christian Esken.
Committed on 06/01/2015 at 22:29.
Pushed by esken into branch 'master'.
Add a Lock to avoid duplicate initializiation, which may help with some
startup issues (delays, lockups). Not likely a solutin for all, but
please test. Also some ceanups, less logging and fixing a small memleak.
Related: bug 339272, bug 339525, bug 317926
M +1 -0 CMakeLists.txt
M +122 -59 apps/KMixApp.cpp
M +7 -10 apps/KMixApp.h
M +2 -7 apps/kmix.cpp
M +1 -0 apps/main.cpp
M +1 -1 backends/mixer_mpris2.cpp
M +4 -4 backends/mixer_pulse.cpp
M +4 -2 core/GlobalConfig.cpp
M +13 -0 core/GlobalConfig.h
M +2 -1 core/mixdevice.cpp
M +2 -2 core/mixer.cpp
M +14 -7 gui/kmixprefdlg.cpp
M +2 -2 gui/viewbase.cpp
FWIW, some work has progressed on making PulseAudio socket activatable which avoids a lot of the complex autospawn stuff. I expect this to be mainstrain in the next six months to a year (it takes some work for distributions to switch over to this scheme). It might not have any impact on this issue, but I figure it's relevent so worth mentioning. Some work is needed on various dbus related things (specifically dbus-launch and friends) to make this actually possible.
*** Bug 319581 has been marked as a duplicate of this bug. ***
*** Bug 339963 has been marked as a duplicate of this bug. ***
*** Bug 317041 has been marked as a duplicate of this bug. ***
*** Bug 320067 has been marked as a duplicate of this bug. ***
Collecting all of the "KMix startup being delayed by PulseAudio" bugs together here.
If anyone is able to test with current KMix and Plasma 5, please indicate whether this is still an issue.
*** Bug 327901 has been marked as a duplicate of this bug. ***