Bug 318986 - Kmix starting before pulseaudio is delaying login
Summary: Kmix starting before pulseaudio is delaying login
Status: CONFIRMED
Alias: None
Product: kmix
Classification: Applications
Component: Backend: Pulseaudio (show other bugs)
Version: unspecified
Platform: Ubuntu Linux
: NOR minor
Target Milestone: ---
Assignee: Colin Guthrie
URL:
Keywords:
: 317041 319581 320067 327901 339963 (view as bug list)
Depends on:
Blocks:
 
Reported: 2013-04-27 17:35 UTC by Rael Gugelmin Cunha
Modified: 2021-02-12 13:42 UTC (History)
8 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Rael Gugelmin Cunha 2013-04-27 17:35:43 UTC
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.

Reproducible: Always

Steps to Reproduce:
1. Login
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
4. Logout.
5. Login.
6. Check time until mouse is ready to respond. Locally: about 15s.
Actual Results:  
Kmix waits for pulseaudio. Time to system become ready to use: 1m20s.

Expected Results:  
Pulseaudio starts before Kmix. Time to system become ready to use: 15s.

Move pulseaudio-kde.desktop to /etc/xdg/autostart as default.
Comment 1 Christian Esken 2013-05-21 23:00:29 UTC
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?
Comment 2 Colin Guthrie 2013-05-22 08:20:19 UTC
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
Comment 3 Christian Esken 2013-07-17 20:32:54 UTC
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)

[1] issues with the MPRIS2 backend, feedback from kdemultimedia and other KDE developers, and also from Internet searches.
Comment 4 Christian Esken 2015-01-06 22:29:36 UTC
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

http://commits.kde.org/kmix/91284ff2561ba9627dfe47d21593f472df9ffa8e
Comment 5 Colin Guthrie 2015-01-07 09:10:22 UTC
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.
Comment 6 Jonathan Marten 2021-02-12 13:34:57 UTC
*** Bug 319581 has been marked as a duplicate of this bug. ***
Comment 7 Jonathan Marten 2021-02-12 13:35:35 UTC
*** Bug 339963 has been marked as a duplicate of this bug. ***
Comment 8 Jonathan Marten 2021-02-12 13:36:06 UTC
*** Bug 317041 has been marked as a duplicate of this bug. ***
Comment 9 Jonathan Marten 2021-02-12 13:36:29 UTC
*** Bug 320067 has been marked as a duplicate of this bug. ***
Comment 10 Jonathan Marten 2021-02-12 13:39:21 UTC
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.
Comment 11 Jonathan Marten 2021-02-12 13:42:56 UTC
*** Bug 327901 has been marked as a duplicate of this bug. ***