Mopidy/Iris + Snapcast: no audio

Q&A
1

I’m trying to get a multiroom-able solution with Spotify working under Raspberry Pi OS (Lite/CLI), with Pipewire, so that I can have the media server while still having the RPi run other services too. I followed this MagPi tutorial.

  1. I’m currently stuck with no sound when playing songs from Spotify in Iris. I’m running Mopidy as a service, here’s my config:
~ $ sudo cat /etc/mopidy/mopidy.conf
[http]
hostname = 0.0.0.0

[audio]
output = audioresample ! audioconvert ! audio/x-raw,rate=48000,channels=2,format=S16LE ! wavenc ! filesink location=/tmp/snapfifo

[spotify]
client_id = //my id here
client_secret = //my secret here

[local]
media_dir = /home/ben/Music
enabled =  true

Using aplay like so: aplay /usr/share/sounds/alsa/Front_Center.wav gives me the correct audio output (“front center” is played), using aplay with the local .mp3 files (~/Music) plays just noise.

Unfortunatley, I don’t know what to make of the error messages - can someone maybe point me in the right direction?

~ $ service mopidy status
● mopidy.service - Mopidy music server
Loaded: loaded (/lib/systemd/system/mopidy.service; enabled; preset: enabled)
Active: active (running) since Mon 2024-11-18 02:22:31 CET; 1 day 17h ago
Process: 803 ExecStartPre=/bin/mkdir -p /var/cache/mopidy (code=exited, status=0/SUCCESS)
Process: 811 ExecStartPre=/bin/chown mopidy:audio /var/cache/mopidy (code=exited, status=0/SUCCESS)
Main PID: 812 (mopidy)
Tasks: 13 (limit: 3916)
CPU: 9.445s
CGroup: /system.slice/mopidy.service
└─812 /usr/bin/python3 /usr/bin/mopidy --config /usr/share/mopidy/conf.d:/etc/mopidy/mopidy.conf

Nov 18 02:23:36 raspi4 mopidy[812]: WARNING  [Core-8 (_actor_loop)] mopidy.core.tracklist Track is not playable: spotify:track:6RBrvlIDz6AhFs0qkTPriB
Nov 18 02:23:36 raspi4 mopidy[812]: ERROR    [MainThread] mopidy.audio.gst GStreamer error: Could not open file "/tmp/snapfifo" for writing.
Nov 18 02:23:36 raspi4 mopidy[812]: WARNING  [Audio-2 (_actor_loop)] mopidy.audio.actor Setting GStreamer state to GST_STATE_PLAYING failed
Nov 18 02:23:36 raspi4 mopidy[812]: WARNING  [Core-8 (_actor_loop)] mopidy.core.tracklist Track is not playable: spotify:track:0ccnwSwBtYMgiszKl9GaIT
Nov 18 02:23:36 raspi4 mopidy[812]: ERROR    [MainThread] mopidy.audio.gst GStreamer error: Could not open file "/tmp/snapfifo" for writing.
Nov 18 02:23:36 raspi4 mopidy[812]: WARNING  [Audio-2 (_actor_loop)] mopidy.audio.actor Setting GStreamer state to GST_STATE_PLAYING failed
Nov 18 02:23:36 raspi4 mopidy[812]: WARNING  [Core-8 (_actor_loop)] mopidy.core.tracklist Track is not playable: spotify:track:6GzfuT24wqfHZquZZwLYIV
Nov 18 02:23:36 raspi4 mopidy[812]: ERROR    [MainThread] mopidy.audio.gst GStreamer error: Could not open file "/tmp/snapfifo" for writing.
Nov 18 02:23:36 raspi4 mopidy[812]: WARNING  [Audio-2 (_actor_loop)] mopidy.audio.actor Setting GStreamer state to GST_STATE_PLAYING failed
Nov 18 02:23:36 raspi4 mopidy[812]: WARNING  [Core-8 (_actor_loop)] mopidy.core.tracklist Track is not playable: spotify:track:2PosJTq6obVASb20uOSmgC

In the tutorial, I omitted the DAC and Airplay parts, because, my RPi currently doesn’t have a DAC, and I don’t use any Apple devices.
I have the speaker connected to the 3,5mm audio jack.
I wonder if the issues are related to Pipewire - it’s never mentioned in the documentation e.g. of Snapcast. Most docs and RPi-related tools still seem to assume only Alsa/Pulseaudio.
I installed Pipewire on this Raspberry Pi OS because it’s needed for a different thing I wanted to try - and anyways, it’s now the default for Raspberry Pi OS.

~ $ inxi --audio
Audio:
Device-1: bcm2711-hdmi0 driver: vc4_hdmi
Device-2: bcm2711-hdmi1 driver: vc4_hdmi
API: ALSA v: k6.6.51+rpt-rpi-v8 status: kernel-api
Server-1: PipeWire v: 1.2.4 status: active
2

Last time I checked pipewire was definitely not the default for Pi OS Lite since it makes no sense in that environment but maybe they’ve changed things around. I don’t think it’s your problem here, you’re not going anywhere near pipewire in your Mopidy setup since you’re outputting to a fifo.

The first hit on Google for your error message takes you to Gstreamer error - #13 by bachschmidmedia did you try it?

1 Like
3

Oops… I actual found this thread, but didn’t see the solution somehow - thanks, and sorry about the oversight!
This worked in that Mopidy isn’t throwing any more errors, and I get sound from Spotify, but playing on my desktop pc that I’m controlling the Raspberry Pi from and where I have the Iris UI opened.
However, there’s still no sound coming out of the RPi.

I think this is still the case for Lite, apparently Pipewire was only introduced for the regular GUI release with bookworm. But when I installed Lite on this device, it had only Alsa. It’s just that now when instructions say Alsa or Pulseaudio, I don’t know how to handle it for my case.

4

Ok, well given your audio output config is sending all audio to snapserver, what you are getting is what I would expect. If you want to also play audio on the pi, you have two options.

One is to define two Mopidy outputs using an output config setting similar to the dual output example at Icecast — Mopidy 3.4.2 documentation

The other method is to leave the output config as it is, and also run snapclient on your pi so that it plays locally, in addition to remotely through your web browser. If you do it this way the audio will be in sync, maybe that’s useful.

However, both methods require you have a working sound system on your pi. I don’t know how you do that with pipewire. I’d stick with normal ALSA if I was you, rather than trying to fight software on an unsupported platform.

1 Like
5

Thank you! The aforementioned tutorial I followed included installing Snapclient on the same RPi to achieve exactly this.
I re-checked my Snapcast config (which is apparently spread across two separate files for the server), and found that I had an unrecognized hostname for the server. I should have left that file untouched, then the server seems automatically finds its local client.
So, I have Spotify sound on both ends now, the RPi4 locally, and the box I am accessing Iris from - exactly as I wanted, in perfect sync!

Just need to figure out 2 more things now:

  • Iris keeps randomly freezing my whole browser, until I find which process belongs to its tab and kill it.
  • The RPis Alsa volume goes down to 40% after each reboot (or maybe even after restarting some service, because I actually don’t remember rebooting it).

EDIT: I guess I got too happy too soon: I did try a reboot now (also finding out that Alsa does not keep the default volume after running sudo alsactl store), and the server wouldn’t play agani. Turns out, /tmp/snapfifo is owned by the snapserver user again. I ran sudo chown -R mopidy /tmp/snapfifo again (server works), rebooted, and got

~ $ ls -l /tmp/snapfifo
prw-rw-rw- 1 snapserver snapserver 0 Nov 20 23:42 /tmp/snapfifo

again (server no play), so snapserver keeps re-claiming ownership of the fifo after each reboot, disabling Mopidy.
Any ideas?
I mean Mopidy does have read permission in this state, shouldn’t it work like this?

6

For the iris issue take a look at Support · jaedb/Iris Wiki · GitHub

1 Like
7

Thanks, will do. But I think I’ll first have to find a way to reconcile Mopidy with Snapcast. When it’s allowed to play consistently, I can diagnose the Iris crashes (or maybe they’ll just disappear once this is resolved, fingers crossed).
Any idea why Mopidy won’t play nice if Snapcast owns /tmp/snapfifo - or else, why Snapcast has to own it (which intuitively makes sense though)?

8

It needs permission to write to it. I would think putting them in the same group and giving that group ownership would be enough.

Also make sure you disable fs.protected_fifo.

9

but it does have write permission already: “world” is rw-
I have feeling that if I change the ownership to anything else, Snapcast will just change it back again at the next reboot…

Sorry I don’t know how to do that. Could you elaborate?
(side note: figured out the Alsa volume problem)

10

It’s at snapcast/doc/player_setup.md at master · badaix/snapcast · GitHub which presumably you’ve read …?

1 Like
11

Not yet, but already on it! Thanks for the pointer!

EDIT:

Just for posterity: This did the trick, no need to change the ownership of /tmp/snapfifo
I added fs.protected_fifos=0 to the bottom of /etc/sysctl.conf to make the change last across reboots.
It was probably not mentioned in the tutorial because it’s 4 years old at the time of writing this. Appreciate the help, and thanks a bunch for an amazing piece of software!

12

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.