Shairport / Mopidy "Hand off" audio? how to switch from one to the other?

Hi
I have setup a raspberry pi 4 with raspian bullseye lite. Headless. IQ-Audio DAC+.
Everything works, I have audio from Mopidy to the DAC and also from Shairport.

Except, that if I start mopidy playback and then want to stream something via airplay mopidy keeps playing and even after stopping mopidy there is no sound from airplay.

I have to reboot the pi to make shairport working again.

The other way round, if I start with shairport playback and then play mopidy I have no sound. Until I disconnect the device streaming to airplay completely, then I have sound from mopidy. It’s not pretty, but reasonable.

Is there anyway to make this more seamless?

Thank you for your time!

Hi again,
I did try out more stuff. While I didn’t succeed I found out some things that might be interesting for others.

This is for RaspberryPi4 bullseye lite, probably also bullyseye. And the IQAudio DAC+ but probably also other DACs.

First I edited the shairport configuration as such:

sudo nano /etc/shairport-sync.conf

And uncommented / changed the line:

output_device = “hw:IQaudIODAC”;

The name of the card I found by using:

aplay -l

I changed/edited the mopidy configuration

sudo nano /etc/mopidy/mopidy.conf

by adding
[audio]
output = alsasink device=hw:IQaudIODAC

This works to the extend that per reboot I can use either shairport OR mopidy. When I used one or the other, the next will not play audio.

So I figured I could turn off, disable the raspberry pi 4 HDMI audio completely, and on board sound of course too, so that the raspberry pi has nothing BUT the DAC. I did this by editing the config text:

sudo nano /boot/config.txt

and changed one line to

dtoverlay=vc4-kms-v3d,noaudio

and of course commented-out:
#dtparam=audio=on

(don’t forget, DAC only works if this is in the file:)

dtoverlay=iqaudio-dacplus

After doing that, the only alsa sound output available is the DAC. Neat. And because of that, mopidy does not output any sound anymore.

After removing
output = alsasink device=hw:IQaudIODAC

from the mopidy config it works again.

Now I also removed

output_device = “hw:IQaudIODAC”;

from the shairport configuration. It also is not needed anymore.

So, long story short:
If you are using a DAC+ you can simply change the config.txt to:
dtoverlay=vc4-kms-v3d,noaudio
#dtparam=audio=on
dtoverlay=iqaudio-dacplus

And you will not need to configure shairport or mopidy because your DAC will be the only soundcard in the system and both will understand that.

However you will still not be able to use both shairport AND mopidy… which I think sucks donkey balls… :wink:

While I’m not really further I hope this will help others with other problems maybe somehow… :slight_smile:

Only one process can be using a hardware alsa device at any time. Mopidy will be using the device until playback stops. It stops when all tracks have played or when you explicitly issue a stop command. Pausing is not stopping. When paused, Mopidy is still using the alsa device.

Shairport has a config option to run a command before its playback starts, use that to run mpc stop and force Mopidy to release the alsa device. There’s a load of posts on this forum about this already. Just check the shairport config option has not changed since the stuff on here was written.

Alternatively you configure an ALSA dmix plugin and then configure both programs to output to that instead of directly to the hardware device. Multiple processes can use a dmix device at the same time. There’s also posts on here about that.

Hi and thank you for your answer,

My quick search in the forum before I posted was not good enough. I apologize.

However, also now that I have had a deeper search I can not solve my problem. The information about dmix is mostly outdated or incomplete. Also from the alsa site I learned that there seems to be samplerate conversion going on with dmix and that is not so nice for sound-quality. One needs to set dmix to 44khz at some point or 48khz whatever is listened to more in some setting somewhere… man, that is a rabbit hole… I’m not going into at this moment. Maybe after a coffee or five…

It seems like it shall be “mpc stop”…
the trick with “mpc stop” has a problem here: I don’t even have mpd/mpc installed on my system. So there is nothing to stop. But since I have sound from both mopidy and shairport I don’t see why installing it and then stopping it would help me.

I keep on trying and post updated results here.

Ok, so I went along and installed mpc and mpd

sudo apt-get install mpc
sudo apt-get install mpd

and after that nothing worked anymore. Shairport didn’t even show up on ios/mac devices and mopidy would not play any sound anymore.
So I uninstalled mpc and mpd again

sudo apt-get --purge remove mpd
sudo apt-get --purge remove mpc

and will try the dmix route now.

You don’t need to install mpd. Mpd and mpc are different programs and not reliant on each other. Mpc works with Mopidy-MPD (which you need to install if not done already, I should have been clearer about that) .

Yes, there are some sample rate implications but you don’t actually need to do anything beyond what’s in the simplest examples to make it work. Certain audio enthusiasts will gawp at that but most will be unable to tell the difference (despite their oxygen-plated power cables).

Thank you!

I’ve been trying to get dmix working now.
Good news: alsa dmix does not need any configuration on bullseye to work with shairport. Simply do:
sudo nano /etc/shairport-sync.conf

and change output to:

output_device = “pcm.dmix”;

Shairport will use dmix.

As for sample rate conversion.
1: SampleRate conversion is a cumbersome process from 48khz to 44.1khz (not so from 88.2 to 44.1) because of simple mathematics. I do in fact hear this conversion, if the algorithm is bad. I have no idea if alsa has a good one or not. But I do agree, that the difference is small, even if the algorithm is bad. However in such a use case as here it is a matter of more than that. If you have a lower quality stream and on top of that the conversion, on top of that it’s just adding bad to bad and if I can avoid it I avoid it. And btw. I make fun of people buying expensive speaker cables.

2: Anyhow it easy to change. Assuming you listen to mostly music that was intended for CDs or is coming from CDs do and change:
sudo nano /usr/share/alsa/alsa.conf

defaults.pcm.dmix.rate 44100

However I tried to set mopidy to use dMix too.

I have done and tried:
sudo nano /etc/mopidy/mopidy.conf

output = alsasink device=pcm.dmix
output = alsasink device=dmix
output = pcm.dmix
output = dmix
output = alsasink device=plug:dmix
output = plug:dmix
#defined nothing at all

But none of those enable any sound from mopidy.

I also installed mopidy-mpd and mpc and did
sudo nano /etc/shairport-sync.conf

added
run_this_before_play_begins = mpc stop;

this again completely broke shairport.

So, I’m still stuck using either route. dmix or mpc stop.

I also followed this guide:
http://eequalspi.com/index.php/2019/08/25/mopidy-and-multiple-audio-streams-from-the-command-line-on-raspberry-pi/

To try to make it work with:
sudo python3 -m pip install Mopidy-ALSAMixer

No luck either.

Take that option, search on here for it, gives

You could try the verison in that thread a go. Giving the full path seems like a good idea. Not ending with a semicolon seem alike a good idea. Using quotes seems like a good idea.

Hi
Thank you. I had seen the post, I also tried this and many other variants of the same. It crashes shairport.

Also, I just found out that actually mopidy only plays an mp3 from a folder, but doesn’t stream anything from, say, the internet archive. So maybe I have another problem here.

When defining a Mopidy output setting you are providing the output end of a GStreamer pipeline. Typically that needs to specify a sink, just a bare device like “dmix” or “plug:dmix” here is useless. If you want/need to specify a device it needs to be output = alsasink device=something format. The something can be worked out by looking at the output of aplay -L. I’ve just gone and spent my time trying this so I know it works.

On my system with a USB soundcard (soundKey) and the on-board sound device (Headphones) as the default I see:

pi@testpi:~ $ aplay -L
null
    Discard all samples (playback) or generate zero samples (capture)
default:CARD=Headphones
    bcm2835 Headphones, bcm2835 Headphones
    Default Audio Device
sysdefault:CARD=Headphones
    bcm2835 Headphones, bcm2835 Headphones
    Default Audio Device
dmix:CARD=Headphones,DEV=0
    bcm2835 Headphones, bcm2835 Headphones
    Direct sample mixing device
dsnoop:CARD=Headphones,DEV=0
    bcm2835 Headphones, bcm2835 Headphones
    Direct sample snooping device
hw:CARD=Headphones,DEV=0
    bcm2835 Headphones, bcm2835 Headphones
    Direct hardware device without any conversions
plughw:CARD=Headphones,DEV=0
    bcm2835 Headphones, bcm2835 Headphones
    Hardware device with all software conversions
default:CARD=soundKey
    Cyrus soundKey, USB Audio
    Default Audio Device
sysdefault:CARD=soundKey
    Cyrus soundKey, USB Audio
    Default Audio Device
front:CARD=soundKey,DEV=0
    Cyrus soundKey, USB Audio
    Front speakers
surround21:CARD=soundKey,DEV=0
    Cyrus soundKey, USB Audio
    2.1 Surround output to Front and Subwoofer speakers
surround40:CARD=soundKey,DEV=0
    Cyrus soundKey, USB Audio
    4.0 Surround output to Front and Rear speakers
surround41:CARD=soundKey,DEV=0
    Cyrus soundKey, USB Audio
    4.1 Surround output to Front, Rear and Subwoofer speakers
surround50:CARD=soundKey,DEV=0
    Cyrus soundKey, USB Audio
    5.0 Surround output to Front, Center and Rear speakers
surround51:CARD=soundKey,DEV=0
    Cyrus soundKey, USB Audio
    5.1 Surround output to Front, Center, Rear and Subwoofer speakers
surround71:CARD=soundKey,DEV=0
    Cyrus soundKey, USB Audio
    7.1 Surround output to Front, Center, Side, Rear and Woofer speakers
iec958:CARD=soundKey,DEV=0
    Cyrus soundKey, USB Audio
    IEC958 (S/PDIF) Digital Audio Output
dmix:CARD=soundKey,DEV=0
    Cyrus soundKey, USB Audio
    Direct sample mixing device
dsnoop:CARD=soundKey,DEV=0
    Cyrus soundKey, USB Audio
    Direct sample snooping device
hw:CARD=soundKey,DEV=0
    Cyrus soundKey, USB Audio
    Direct hardware device without any conversions
plughw:CARD=soundKey,DEV=0
    Cyrus soundKey, USB Audio
    Hardware device with all software conversions
pi@testpi:~ $ aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: Headphones [bcm2835 Headphones], device 0: bcm2835 Headphones [bcm2835 Headphones]
  Subdevices: 8/8
  Subdevice #0: subdevice #0
  Subdevice #1: subdevice #1
  Subdevice #2: subdevice #2
  Subdevice #3: subdevice #3
  Subdevice #4: subdevice #4
  Subdevice #5: subdevice #5
  Subdevice #6: subdevice #6
  Subdevice #7: subdevice #7
card 1: soundKey [Cyrus soundKey], device 0: USB Audio [USB Audio]
  Subdevices: 0/1
  Subdevice #0: subdevice #0

In Mopidy I then set output = alsasink device=dmix:soundKey. I can then also run gst-launch-1.0 audiotestsrc ! audioconvert ! alsasink device=dmix:soundKey and hear both Mopidy and the audio test tone playing at the same time. So I know this works.


In the past, when I used to use a dmix setup I would specify a dmix plug device in /etc/asound.conf how I wanted it and then also set it as the system default device:

pcm.!default {
    type plug
    slave.pcm {
        type dmix
        ipc_key 1024
        slave {
            pcm "hw:$CARD"
            rate 44100
        }
    }
}
ctl.!default {
    type hw
    card $CARD
}

Where $CARD is something like “0,0” depending on normal ALSA naming conventions which you have probably already read about. For my system the USB soundKey device would be “1,0”. Setting the system default like this means you can avoid having to explictly specify the device for each audio program e.g. your Mopidy config would become simply output = alsasink.

It seems specifying a dmix device like this is not required these days. And this is exactly why I’m adverse to providing copy and paste solutions for people that rot over time. I’d much rather point them in the right direction and let them discover the up-to-date way of doing things. Oh well, doesn’t always work.


I guess I should be able to set dmix:soundKey as my system default if I wanted:

pcm.!default {
    type plug
    slave {
        pcm "dmix:soundKey"
    }
}

Personally I’d use the mpc stop handshake solution but I am not able to support any more there than I already have. Good luck.

Thank you very much for your time and help.

I tried all your suggestions. In my case it was:
`output = alsasink device=dmix:IQaudIODAC

It did not work.
while
`output = alsasink device=hw:IQaudIODAC
allows for file playback but not streams.

I also tried to configure a second dmix plugin just in case the one that is always on by default in bullyseye is the problem. No luck either.

I am sorry I wasted your time. At this point I give up and go another route.

As a cautionary tale for every body else:
RaspberryPi4, bullseye Lite, IQAudio DAC+. Doesn’t work with mopidy properly (only plays files, not streams) and certainly not in conjunction with ShairportSync. I have not installed anything but those two things. All my tries are documented here. I hope it helps someone.

That’s not a dmix device. DeviceNames - AlsaProject

Look at what was in the full output I provided you with:

hw:CARD=soundKey,DEV=0
    Cyrus soundKey, USB Audio
    Direct hardware device without any conversions

vs

dmix:CARD=soundKey,DEV=0
    Cyrus soundKey, USB Audio
    Direct sample mixing device

I don’t mind helping but I really need people to provide their logs, full config files, full output of commands etc. Otherwise there’s too much guess work and that is a waste of time.

Good luck with your other route.

is what I used for dmix

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