Bug 320067 - kmix shows alsa related control when pulseaudio is being used.
Summary: kmix shows alsa related control when pulseaudio is being used.
Status: RESOLVED DUPLICATE of bug 318986
Alias: None
Product: kmix
Classification: Unclassified
Component: Backend: Pulseaudio (show other bugs)
Version: unspecified
Platform: Chakra Linux
: NOR normal (vote)
Target Milestone: ---
Assignee: Colin Guthrie
URL:
Keywords:
: 324798 (view as bug list)
Depends on:
Blocks:
 
Reported: 2013-05-20 20:48 UTC by Weng Xuetian
Modified: 2021-02-12 13:36 UTC (History)
4 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 Weng Xuetian 2013-05-20 20:48:43 UTC
During some suspend/resume and fresh startup, kmix shows the alsa control, but actually pulseaudio is being used.

Restart kmix will make it works with pulseaudio.

KDE 4.10.3, Chakra Linux
Pulseaudio 3.99.1

Reproducible: Sometimes
Comment 1 Christoph Feck 2013-07-20 12:59:20 UTC
This could be related to/duplicate of bug 319581.
Comment 2 Ragnar Thomsen 2013-10-31 17:36:00 UTC
I can confirm this with KDE 4.11.2 and pulseaudio 4.0. Upon fresh start, kmix shows alsa controls. After restarting kmix, the proper pulseaudio controls are shown.

It seems kmix does not detect pulseaudio upon boot. Maybe pulseaudio gets started after kmix?
Comment 3 Antonio Rojas 2013-10-31 17:45:15 UTC
*** Bug 324798 has been marked as a duplicate of this bug. ***
Comment 4 Colin Guthrie 2013-10-31 18:09:30 UTC
The above comments regarding pulseaudio not being started automatically feel very much like a distro integration thing rather than an upstream problem.

Perhaps PulseAudio is not configured to autospawn or similar or some other, unrelated issue with PA prevents it from starting properly in early login.

Either way, the kmix code does not disable any of the PA autospawning code and therefore it cannot be a bug in kmix itself.

FWIW, systemd-based user sessions would fix up any autospawning-related problems but that's hardly a solution today ;)
Comment 5 Antonio Rojas 2013-10-31 18:11:54 UTC
autospawn is indeed turned off by default in Arch Linux. Can this be the cause of this problem?
Comment 6 Ragnar Thomsen 2013-10-31 18:25:22 UTC
I tried uncommenting autospawn = yes in /etc/pulse/client.conf. This did not fix the issue.

Also I tried moving pulseaudio.desktop and pulseaudio-kde.desktop from /etc/xdg/autostart/ to /usr/share/autostart, as suggested in this thread: https://bbs.archlinux.org/viewtopic.php?pid=1253866
This did not fix the issue.

I tried moving kmix_autostart.desktop and restore_kmix_volumes.desktop from /usr/share/autostart to /etc/xdg/autostart, which was also suggested on the above-mentioned thread. This did not fix the issue.

I noticed by going to System setting -> Multimedia, that phonon always detects pulseaudio, while kmix always fails to.
Comment 7 Colin Guthrie 2013-10-31 18:26:30 UTC
(In reply to comment #5)
> autospawn is indeed turned off by default in Arch Linux. Can this be the
> cause of this problem?

Yup! Autospawn is basically required on any PA system. Without it you're relying very much on good will and that static scripts that start PA when logging into a graphical environment are run early enough.

To explain PA does have some modules that hook into X11. These modules are loaded when logging into an X11 system and this has the side effect of starting PA explicitly, but PA should still be started on an as-needed basis, including when anything else tries to connect to it - and this could include logging in via a text tty console and running e.g. mpg123 or similar to produce sound from the CLI.

You certainly shouldn't be relying on the $DESKTOP_ENVIRONMENT's startup scripts for this!
Comment 8 Colin Guthrie 2013-10-31 18:31:18 UTC
(In reply to comment #6)
> I tried uncommenting autospawn = yes in /etc/pulse/client.conf. This did not
> fix the issue.

Interesting. Make sure you don't also have a ~/.pulse/client.conf (or ~/.config/pulse/client.conf) which overrides it.

> Also I tried moving pulseaudio.desktop and pulseaudio-kde.desktop from
> /etc/xdg/autostart/ to /usr/share/autostart, as suggested in this thread:
> https://bbs.archlinux.org/viewtopic.php?pid=1253866
> This did not fix the issue.

Hmm, that should make absolutely zero difference. Both folders should be enumerated for startup items. But as mentioned in my previous comment, these scripts start helper modules, and should not be relied up on actually start PA before kmix as there is no odering semantics in XDG Autostart files (again systemd-based user sessions would fix this separate issue too)

> I tried moving kmix_autostart.desktop and restore_kmix_volumes.desktop from
> /usr/share/autostart to /etc/xdg/autostart, which was also suggested on the
> above-mentioned thread. This did not fix the issue.

Again, it shouldn't matter. These folders should both be enumerated and shouldn't affect the ordering. If it does it's an implementation quirk and certainly not in the XDG spec. Please ignore this advice.
 
> I noticed by going to System setting -> Multimedia, that phonon always
> detects pulseaudio, while kmix always fails to.

Phonon starts as needed, not at login. It detects PA only when it needs to. kmix has to detect it when it starts and go into either PA or ALSA mode. As kmix starts a login, it needs PA available so it can connect to it. Autospawning should be the solution here.

If you want to test autospawning, reboot, log into a text console and try and run paplay with a simple wav file. If PA is not started automatically (check before that it's NOT yet running and check again after that it IS), then you still have a problem with autospawning.
Comment 9 Ragnar Thomsen 2013-10-31 20:42:34 UTC
(In reply to comment #8)
> Interesting. Make sure you don't also have a ~/.pulse/client.conf (or
> ~/.config/pulse/client.conf) which overrides it.

Aah, I found "autospawn=no" in my ~/.pulse/client.conf. Setting it to yes fixed the issue for me. Don't know why it was set to no in the first place, though. Thanks for the help.
Comment 10 Andrew Crouthamel 2018-11-10 03:23:45 UTC
Dear Bug Submitter,

This bug has been stagnant for a long time. Could you help us out and re-test if the bug is valid in the latest version? I am setting the status to NEEDSINFO pending your response, please change the Status back to REPORTED when you respond.

Thank you for helping us make KDE software even better for everyone!
Comment 11 Andrew Crouthamel 2018-11-21 04:24:53 UTC
Dear Bug Submitter,

This is a reminder that this bug has been stagnant for a long time. Could you help us out and re-test if the bug is valid in the latest version? This bug will be moved back to REPORTED Status for manual review later, which may take a while. If you are able to, please lend us a hand.

Thank you for helping us make KDE software even better for everyone!
Comment 12 Jonathan Marten 2021-02-12 13:36:29 UTC

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