Hi,

I'm trying to get pulseaudio running on a Raspberry Pi 3 (ARM). I'm having trouble getting the service to start properly. The status always says "activating", but never seems to finish. Any ideas?


$ systemctl --user start pulseaudio.service
Job for pulseaudio.service failed. See 'systemctl status pulseaudio.service' and 'journalctl -xn' for details.

$ systemctl status pulseaudio.service
● pulseaudio.service
Loaded: not-found (Reason: No such file or directory)
Active: inactive (dead)

$ systemctl --user status pulseaudio.service
● pulseaudio.service - Sound Service
Loaded: loaded (/home/pi/.config/systemd/user/pulseaudio.service; enabled)
Active: activating (start) since Mon 2017-05-22 08:57:37 PDT; 5s ago
Main PID: 3351 (pulseaudio)
CGroup: /user.slice/user-1000.slice/***@1000.service/pulseaudio.service
└─3351 /usr/bin/pulseaudio --daemonize=no

# ---------------------
~/.config/systemd/user/pulseaudio.service
# ---------------------

[Unit]
Description=Sound Service
Requires=pulseaudio.socket

[Service]
Type=notify
ExecStart=/usr/bin/pulseaudio --daemonize=no
Restart=on-failure

[Install]
Also=pulseaudio.socket
WantedBy=default.target
What's the pulseaudio version? Raspbian ships 5.0, and if you have
that, then pulseaudio doesn't notify systemd when it has started.
Systemd expects that notification, since you set type=notify in the
service file. You can try type=simple instead.
Thanks for the reply! I'm running Raspbian and have pulseaudio version 5.0.
I tried changing it to type=simple, and that fixed the notify issue, but it's still not working. This is what I get:

$ paplay test.wav
connect localhost port 6020: Connection refused
xcb_connection_has_error() returned true
Connection failure: Connection refused
pa_context_connect() failed: Connection refused
These are unfamiliar errors to me... Is your X11 setup unusual? The
first error could be about libpulse trying to connect to X11 using port
6020, which would be strange, because normally X11 uses unix sockets.
Is pulseaudio running? If it is, paplay doesn't find the socket. That
might be because systemd sets the XDG_RUNTIME_DIR environment variable
for the services it starts, and that affects the socket location, but
your login environment might not have that variable set. Try setting
XDG_RUNTIME_DIR=/run/user/1000 in your login session setup.

If that doesn't help, run "PULSE_LOG=99 pactl info". That will show
what socket pactl tries to use. You can compare that to the output of
"netstat -lx | grep pulse", that will show what socket the server uses.
Apparently the "xcb_connection_has_error()" message is caused by my having SSHed to the device. If I run the same command on the device directly, I don't get that message. My environment already had that variable set as you suggested:

$ echo $XDG_RUNTIME_DIR
/run/user/1000

In any case, I still get the "pa_context_connect() failed" message.

Is pulseaudio running? Yes:
$ ps -ef | grep pulse
pi 1050 809 0 11:14 ? 00:00:54 /usr/bin/pulseaudio --daemonize=no

$ PULSE_LOG=99 pactl info
xcb_connection_has_error() returned true
Using shared memory pool with 1024 slots of size 64.0 KiB each, total size is 64.0 MiB, maximum usable slot size is 65496
Trying to connect to /run/user/1000/pulse/native...
connect(): Resource temporarily unavailable (11)
Trying to connect to /var/run/pulse/native...
connect(): No such file or directory (2)
Connection failure: Connection refused
pa_context_connect() failed: Connection refused

$ netstat -lx | grep pulse
unix 3 [ ACC ] STREAM LISTENING 12344 /run/user/1000/pulse/native

Any other thoughts? Does it matter that I have "--daemonize=no" in my service file? By the way, if I do not use a systemd service at all, I've been able to get Pulseaudio to run successfully by manually typing "pulseaudio --start" at the command line. That doesn't really help me though, because I need Pulseaudio to be available on bootup, without manual intervention.
This is the problem. The socket exists, but connecting to it fails. Are
you perhaps trying to use socket activation? In that case systemd
creates the socket, but pulseaudio doesn't use it, because 5.0 doesn't
support socket activation. Removing the .socket file should do the
trick.

Why are you trying to use systemd to manage the user instance, by the
way? The old autospawning mechanism should work fine for automatically
starting pulseaudio on demand. Raspbian disables autospawning at every
boot by overwriting ~/.config/pulse/client.conf, though, so maybe
that's why you're trying this alternative method... In that case, I
would try to find what overwrites client.conf and disable that thing.
Ah! Sure enough, I had this line in my pulseaudio.service file:

Requires=pulseaudio.socket

I copied this file directly from the Debian source:
https://sources.debian.net/src/pulseaudio/8.0-2/src/daemon/systemd/user/pulseaudio.service.in/

Debian trunk must be using a newer version of Pulseaudio than Raspbian. It looks like the latest version of Pulseaudio is 10.0.
Do you know why Raspbian is still using 5.0?

This is very interesting! I didn't know that:
"Raspbian disables autospawning at every boot by overwriting ~/.config/pulse/client.conf"
I actually had tried setting "autospawn=yes" in /etc/pulse/client.conf (isn't this the master version of client.conf?), but that seems to have no effect. I also don't know how to disable the overwriting of ~/.config/pulse/client.conf.

So, now pulseaudio starts at boot, which is fantastic, thank you!

Alas, I am still having a problem.
Here's my .service file to start my script.

# ----------------
# foo.service

[Unit]
Description=Foo
Requires=pulseaudio.service
After=network.target pulseaudio.service

[Service]
Type=simple
ExecStart=/home/pi/foo
Restart=on-failure

[Install]
WantedBy=default.target
# ----------------

If I start it from the command line, it works just fine, but if I enable it to run at boot, it doesn't work, and in the logs I see this:

ALSA lib pulse.c:243:(pulse_connect) PulseAudio: Unable to connect: Connection refused

Any ideas? Maybe a timing issue with the ALSA plugin to interface with Pulseaudio?
The Raspbian images provided by the Raspberry Pi Foundation are based
on the latest Debian stable release, and those stable releases don't
happen often. The current Debian stable release still uses pulseaudio
5.0.
If ~/.config/pulse/client.conf exists, /etc/pulse/client.conf won't be
used at all.
I don't know that either. I'd like to disable it on my rpi too.
No, the alsa plugin is a library that the application loads, not a
thing that needs to be started.

It could be that pulseaudio is not yet fully ready when your script is
started. This is why Type=notify is useful.

Try sleeping in the beginning of your script.
Just to close this issue out: adding a few seconds of delay to my script worked perfectly. Thank you, Tanu!