No audio on headless machine (CentOS)

[kwodzicki]

Hello all,

I'm trying to get this package running on a CentOS 8 system. The machine is headless, i.e., no local logins. I have the package installed, and it runs fine as a user service, but I get no audio.

Digging through the interwebs, it seems to be that users gain access to audio cards when they login at the machine; however, there is no access to audio cards through systemd. I read the user running spotifyd to the audio group is not a good idea, but I can't seem to figure out how to get the user (spotify) to grab control of audio.

Some updates

Over the past few days I've been trying a bunch of different thing to get this working, which are outlined below

What I'm trying to do is connect a sound system to my 'headless' server and have it appear in Spotify to cast to. I would like spotifyd to be loaded at boot so that it is always available for casting. However, I can't seem to get the service to take control of audio.

System

• Dell Optiplex 7010 running CentOS 8
• spotifyd v0.2.24 built using the --features pulseaudio_backend (note that pulseaudio does not appear in the --help message)
• Using the 'default' spotifyd.conf file found in main README.md

I am trying to run spotifyd under a user I created name spotify.
I am trying to do all of this over ssh.

spotifyd.service file

This file is installed at ~/home/spotify/.config/systmed/user and is started using systemctl --user start spotifyd

[Unit]
Description=A spotify playing daemon
Documentation=https://github.com/Spotifyd/spotifyd
Wants=sound.target
After=sound.target
Wants=network-online.target
After=network-online.target

[Service]
ExecStart=/home/spotify/.cargo/bin/spotifyd --no-daemon

[Install]
WantedBy=default.target

If I start this service, or try to run the daemon from command-line over ssh, I get the following:

Loading config from "/home/spotify/.config/spotifyd/spotifyd.conf"
No password specified. Checking password_cmd
Running "********" using "/bin/bash"
No proxy specified
Using alsa volume controller.
Couldn't read volume from alsa device with name "default".
Connecting to AP "guc3-accesspoint-b-s7sx.ap.spotify.com:443"
Authenticated as "******" !
Using alsa sink
Couldn't read volume from alsa device with name "default".
Couldn't set volume: "Couldn\'t find selem with name \'PCM\'."
Country: "US"

I have also tried setting device = sysdefault as mentioned in #87, but this doesn't work either.
Here is the output from aplay -Ll

null
    Discard all samples (playback) or generate zero samples (capture)
pulse
    PulseAudio Sound Server
aplay: device_list:272: no soundcards found...

What I have tried

Adding spotify user to audio group

So, if I add the spotify user to the audio group (I know, bad to do), sound cards appear when running aplay -l, and I can play audio files using aplay -D sysdefault (using the default device does not work) and the spotifyd works just fine. However, if I try to run the service again, I get the same issue as above where it cannot read the alsa device. After some testing, I noticed that when the service runs, the audio group does not appear under the id command, so the user's groups do not seem to be honored in services and access to soundcards is not possible.

System-wide pulseaudio

I have tried a few times to create a system-wide pulse audio instance by:

• Disabling global services with systemctl --global disable pulseaudio.service pulseaudio.socket,
• Setting up a new system sevice
• Setting autospawn = no in /etc/pulse/client.conf
• Adding the spotify user to pulse-audio access group
• Rebooting

However, this still does not work. I just cannot seem to get the service to grab hold of pulseaudio when it runs. If I log into the machine locally so that the GUI environment grabs audio, then run the service, then log out locally, it does seem to work. However, I have not had much luck any other way.

Shell script for more information

Running the following script as the ExecStart parameter in the spotifyd.service file:

#!/bin/bash
LOG=$HOME/spotifyd.log
echo $(id) >> "$LOG"
aplay -Ll >> "$LOG"
$HOME/.cargo/bin/spotifyd --no-daemon --device pulse >> "$LOG"

Gives the following

uid=1002(spotify) gid=1004(spotify) groups=1004(spotify) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

null
    Discard all samples (playback) or generate zero samples (capture)
pulse
    PulseAudio Sound Server

Loading config from "/home/spotify/.config/spotifyd/spotifyd.conf"
No password specified. Checking password_cmd
Running "~/.config/spotifyd/*******.sh" using "/bin/bash"
No proxy specified
Using alsa volume controller.
Couldn't read volume from alsa device with name "pulse".
Caught panic with message: called `Result::unwrap()` on an `Err` value: Os { code: 19, kind: Other, message: "No such device" }

Note that changing the --device flag to default or sysdefault produces similar errors.

Has anyone had this issue or have any ideas that I could try. I am out of ideas and at this point think the only way this will work is if I run the daemon under root to have full sound card access, but I don't really want to do that for security sake.

[paxswill]

I just set up a similar configuration on a Raspberry Pi with Raspbian. I have PulseAudio set as a system-level service and then have spotifyd, shairport-sync and PulseAudio's Bluetooth modules set up as playback sources. A slight difference with my setup is I'm running spotifyd and shairport-sync under their own system users (no home directories) and the SystemD services are system services, not user services.

For troubleshooting PulseAudio I recommend looking at the output of pactl info, especially the "Server String" line. It should be the path to the system-level PulseAudio daemon socket. If that output looks right, pactl list can be used dump the PulseAudio daemon's status. Specifically, that output should have your default audio output listed as a "sink", and then spotifyd (assuming spotifyd is running) as a "sink input". For changing the volume from the command line I've been using pulsemixer.

For PulseAudio, I have this in /etc/pulse/client.conf.d/00-system.conf:

autospawn = no
default-server = /var/run/pulse/native

This is my /etc/systemd/system/pulseaudio.service:

[Unit]
Description=PulseAudio system server
# Putting this dependency in here instead of modifying the packaged shairport-sync.service file
Before=shairport-sync.service

[Service]
Type=notify
ExecStart=pulseaudio --daemonize=no --system --realtime --disallow-exit=yes
Restart=on-failure

[Install]
WantedBy=multi-user.target

Then enabled with sudo systemctl --system enable pulseaudio

Then I have this for /etc/systemd/system/spotifyd.service:

[Unit]
Description=A spotify playing daemon
Documentation=https://github.com/Spotifyd/spotifyd
Wants=sound.target
After=sound.target
Wants=network-online.target
After=network-online.target
Wants=pulseaudio.service
After=pulseaudio.service

[Service]
ExecStart=/usr/local/bin/spotifyd --no-daemon
Restart=on-failure
RestartSec=12
User=spotifyd
Group=nogroup

[Install]
WantedBy=multi-user.target

Having the explicit dependency between the system-level PulseAudio daemon and the later playback applications is an important detail. I also moved the installation back a little bit (from default to multi-user) but I'm not sure that's important.

I have the playback users (shairport-sync and spotifyd) in both the audio and pulse-access groups, but they might be able to just get by with pulse-access.

In /etc/spotifyd.conf I have backend = pulseaudio. If you're not seeing pulseaudio as an option for the backend in the help output I think something else is wrong there.

If you want to use ALSA and run spotifyd as a service, you might need to add a Groups= or SupplementaryGroups= and give it an explicit audio group membership (but I don't need to do this for my PulseAudio set up, so I'm not sure this is the reason for things not working).

If you're running spotifyd as a system service and attempt to use D-Bus things will probably end badly unless you make the changes mentioned in #244.

[mainrs]

I don't know what's wrong with adding users to the audio group. Yes, they can get exclusive access, yes, it might break some stuff when switching between seats a lot but if you don't, I think it's totally fine to do it then. Instead of fiddling with configs and commands around.

[kwodzicki]

Thanks for all the info. I spent some time trying to get this working again last night, but no dice.

I recompiled spotifyd and now pulseaudio shows up as a backend; not sure why that didn't work before.

I also set up the pulseaudio system service; however, it doesn't seem to want to start when the system boots. Not sure what I am doing wrong there as I was able to get a system-wide pulseaudio instance running before. I am able to force it to start after the system boots though.

Last issue I have is that if I do get everything started manual, I can cast to spotifyd, but no audio plays. No errors are thrown by the command; it signals that it is playing a song and sits until then next track starts, signals that is running, then sits again.

I don't know if I broke something in all my testing from my OP, so I'll try again this weekend.

Thanks again.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.