<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN"> <HTML> <HEAD> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8"> <META NAME="GENERATOR" CONTENT="GtkHTML/3.18.1"> </HEAD> <BODY> Hi, comments inline :) On Sun, 2008-04-13 at 18:34 +1000, Ben Finney wrote: <BLOCKQUOTE TYPE=CITE> <PRE> Tanu Kaskinen <<A HREF="mailto:tanuk@iki.fi">tanuk@iki.fi</A>> writes: > I believe /var/log/syslog has more error messages. You're right, thank you. </PRE> </BLOCKQUOTE> 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 try 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. <BLOCKQUOTE TYPE=CITE> <PRE> 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 </PRE> </BLOCKQUOTE> 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. <BLOCKQUOTE TYPE=CITE> <PRE> 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. </PRE> </BLOCKQUOTE> 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 <A HREF="http://pulseaudio.org/wiki/Modules#module-alsa-sink">http://pulseaudio.org/wiki/Modules#module-alsa-sink</A> ) 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. <BLOCKQUOTE TYPE=CITE> <PRE> 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. </PRE> </BLOCKQUOTE> 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. <BLOCKQUOTE TYPE=CITE> <PRE> I'm not sure why the 'setrlimit()' calls fail. </PRE> </BLOCKQUOTE> See above. <BLOCKQUOTE TYPE=CITE> <PRE> The ALSA server hasn't been configured to use 'hw:0'. </PRE> </BLOCKQUOTE> Ack! ALSA isn't a server! :( <BLOCKQUOTE TYPE=CITE> <PRE> I've configured '/etc/asound.conf' as per the PulseAudio wiki page, <URL:<A HREF="http://www.pulseaudio.org/wiki/PerfectSetup">http://www.pulseaudio.org/wiki/PerfectSetup</A>>: $ 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'. </PRE> </BLOCKQUOTE> 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. <BLOCKQUOTE TYPE=CITE> <PRE> What can I do next to diagnose this further? </PRE> </BLOCKQUOTE> 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 <A HREF="http://pulseaudio.org/wiki/Modules">http://pulseaudio.org/wiki/Modules</A> 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 workarounds. Also, for lower latency, you can find many of us on chat.freenode.net in the #pulseaudio channel. :) <PRE> </PRE> Best regards, Sean </BODY> </HTML>