© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
0e1f616
(Get the code!)
Yes, I have module-alsa-sink.
{lestat}~> ls -l /usr/lib/
-rw-r--r-- 1 root root 9564 Mar 27 00:40 /usr/lib/
Contents of ~/.pulse/
#!/usr/
.include /etc/pulse/
load-module module-alsa-sink device=plughw:0 rate=44100
sink_name=mysink
set-default-sink mysink
I have some comments, though. High CPU usage by polkitd can be attributed to constant prodding by pulseaudio and there's not much polkitd can do about it. In case there should be a limit to the number of unsuccessfull start attempts, I suppose that should be the responsibility of the process which is starting pulseaudio. It could implement "restarting too fast" check, similar to the traditional init behavior.
However, polkitd is severely leaking memory if something like this happens. It should be the responsibility of polkitd to clean up the memory after its client disconnects (I'm assuming pulseaudio is it's client, correct me if I'm wrong) and the large number of clients which are accessing it sequentialy in time shouldn't render the machine unusable. I suppose it's leaking some memory per client in any case, it's just not very visible if there are only a few clients in its lifetime.
As for pulseaudio, I suppose it should change its initialization sequence to get the local resources first (meaning load the modules, but don't run them, check the readability and hopefully syntax of local configuration files, if any, etc.) and if that goes well, then get the remote resources (network services, start external processes or whatever) by running the modules. Since pulseaudio seems to be an unattended autospawn service, it's important to prevent domino effect in case some kind of error happens, be it a bug, misconfiguration, upgrade to not quite compatible version or whatever.
And if the error is permanent (a syntax error in configuration file, for example), autospawn should be turned off.