[pulseaudio-discuss] main.c: daemon startup failed.

Sean McNamara smcnam at gmail.com
Sun Apr 13 10:07:39 PDT 2008

Hi, comments inline :)

On Sun, 2008-04-13 at 18:34 +1000, Ben Finney wrote:

> Tanu Kaskinen <tanuk at iki.fi> writes:
> > I believe /var/log/syslog has more error messages.
> You're right, thank you.

When you start PA with --daemonize=true (the default
in /etc/pulse/daemon.conf), it outputs to /var/log/syslog. If you want
to see what's going on for a single console invocation of PA, you can
pulseaudio -vvvv --daemonize=false
It will then output all the debugging info to the console. The first v
is for errors; the second, warnings; the third, notices; the fourth,
debugging. Sometimes two v's isn't enough to get the full picture.

> Here are the messages that get logged when I try starting the server:
>     Apr 13 18:27:52 lily pulseaudio[26288]: main.c: setrlimit(RLIMIT_NICE, (31, 31)) failed: Operation not permitted
>     Apr 13 18:27:52 lily pulseaudio[26288]: main.c: setrlimit(RLIMIT_RTPRIO, (9, 9)) failed: Operation not permitted

These two calls are PA's attempt to get real-time scheduling permission.
There are several reasons why this may not work (no PolicyKit, incorrect
PolicyKit configuration, users not belonging to the right groups, etc.),
but these errors are not fatal. The only surefire way to get realtime
permissions regardless of system configuration is to start PA as root
with --system=false.

>     Apr 13 18:27:53 lily pulseaudio[26288]: alsa-util.c: Error opening PCM device hw:0: No such device
>     Apr 13 18:27:53 lily pulseaudio[26288]: module.c: Failed to load  module "module-alsa-source" (argument: "device_id=0 source_name=alsa_input.pci_106b_3e_alsa_capture_0"): initialization failed.

This is module-hal-detect attempting to automatically configure your
ALSA devices. "no such device" on hw:0 is a pretty bad sign that your
ALSA configuration is hosed. Without PA started, do you hear something
when you execute something like `aplay /usr/share/sounds/shutdown.wav`
in the console? The default device assumed by aplay is hw:0, but in very
rare cases you can actually have a hw:1 configured without a hw:0. In
that case, you might want to enumerate the first few reasonably high
card numbers until you hear sound:
for i in "1 2 3 4 5"; do aplay -v --device=hw:
$i /usr/share/sounds/shutdown.wav; done;
If you get any sound in that test, manually use the card number that
worked in a `load-module module-alsa-sink` statement (an example is
commented out in /etc/pulse/default.pa and you can view the full module
parameters at http://pulseaudio.org/wiki/Modules#module-alsa-sink )
If you don't get any sound, your problem is with ALSA and rather outside
the scope of this mailing list. You can catch me on #alsa on
chat.freenode.net as `allquixotic` if you want some help going through
your ALSA configuration.

>     Apr 13 18:27:53 lily pulseaudio[26287]: main.c: read() failed: No such file or directory
>     Apr 13 18:27:53 lily pulseaudio[26287]: main.c: daemon startup failed.

I'm not sure what read is failing here. It probably isn't telling you
because of starting pa with -vv rather than -vvvv. This may just be a
side-effect of not having any valid sinks; or, it may be revealing a
problem with module-x11-publish (a very common problem when starting PA
as root). I'd disable this module in default.pa if I were you.

> I'm not sure why the 'setrlimit()' calls fail.

See above.

> The ALSA server hasn't been configured to use 'hw:0'.

Ack! ALSA isn't a server! :(

>  I've configured
> '/etc/asound.conf' as per the PulseAudio wiki page,
> <URL:http://www.pulseaudio.org/wiki/PerfectSetup>:
>     $ cat /etc/asound.conf
>     pcm.pulse {
>         type pulse
>     }
>     pcm.!default {
>         type pulse
>     }
>     ctl.pulse {
>         type pulse
>     }
>     ctl.!default {
>         type pulse
>     }
> I can only assume the 'Failed to load  module "module-alsa-source"' is
> because of the corresponding error from 'alsa-util.c'.

What you configure in /etc/asound.conf is totally disjoint from, and
ignored by, the default PulseAudio configuration. module-hal-detect,
when enabled, will attempt to autoplug any working ALSA card at the raw
hw layer, which bypasses the ALSA plug layer. The way you have
asound.conf configured, it guarantees that any applicatons which are
ALSA clients (except PA) will be routed through PulseAudio, so long as
they use the device string "default" rather than "hw:x". If you manually
configured PA to use the "default" device rather than letting
module-hal-detect plug in hw, you would end up going in an infinite loop
with any sound playback request: PulseAudio daemon -> ALSA<->Pulse ->
PulseAudio daemon -> ALSA<->Pulse -> .... (until something errors out or
whatever ;)) So, definitely don't go do that.

> What can I do next to diagnose this further?

1. Start the daemon with -vvvv --daemonize=false, and try running it
alternately as root and non-root. Paste the full console output to us.

2. Study up on the parameters and semantics of the modules you're
loading in default.pa, at http://pulseaudio.org/wiki/Modules

3. If the aplay test failed, go to alsa-project.org, look up your sound
hardware on the wiki, and see whether it's supported or if there are any

Also, for lower latency, you can find many of us on chat.freenode.net in
the #pulseaudio channel. :)

Best regards,

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/pulseaudio-discuss/attachments/20080413/5c70132e/attachment.htm>

More information about the pulseaudio-discuss mailing list