joerg-krause writes

I am using my audio device as standalone player, but I am about to add multi room support using the mpd2sc package. MPD is running on the device, as well as librespot, a Spotify Connect player.

By default, the audio device is working in "Standalone" mode, meaning mpd2sc is not running and MPD as well as librespot are using ALSA for audio output.

When enabling PL-to-Songcast in upplay or by invoking "SetSourceIndex" with the value 2 with an UPnP tool, the audio device is switching to "Multi-room" mode, meaning it starts the OhSender (mpd2sc) and OhReceiver (sc2mpd) tools. For this to work, I wrote a custom scmakesender script, as my audio device does not have Python support. The scmakesender script is mainly a port of the original python script. Additionally it adds some code to configures MPD and librespot to use a pipe for audio output. This works quite well and the following processes are running:

 1589 upmpdcli -c /etc/upmpdcli.conf -l 4
 1611 {scsender.lua} /usr/bin/luvi -- /usr/bin/luvit /usr/lib/luvi_modules/scsender.lua -p 6600 -f Multiroom
 1646 /usr/bin/mpd2sc -f /tmp/snapfifo -A 44100:16:2:1 -a 0 -u 0023B1E3C315 -n Multiroom -p
 1664 /usr/bin/sc2mpd -d -u ohz://239.255.255.250:51972/0023B1E3C315 -c /etc/upmpdcli.conf

However, if I switch back to "Standalone" mode, by invoking "SetSourceIndex" with the value 0 or by disabling PL-to-Songcast in upplay, the OhReceiver process is killed, but the OhSender process is still active, as well as the scmakesender script used to start the mpd2sc process:

 1589 upmpdcli -c /etc/upmpdcli.conf -l 4
 1611 {scsender.lua} /usr/bin/luvi -- /usr/bin/luvit /usr/lib/luvi_modules/scsender.lua -p 6600 -f Multiroom
 1646 /usr/bin/mpd2sc -f /tmp/snapfifo -A 44100:16:2:1 -a 0 -u 0023B1E3C315 -n Multiroom -p

I would like to do some cleanup when the scmakesender script is killed, like reconfiguring MPD and librespot to use the ALSA output again. Maybe I missed something when writing my custom scmakesender script.

How does upmpdcli returns back from the Aux. MPD to the main MPD anyway?

medoc92 writes

I understand that you just replaced the main scmakempdsender script (either in place or by changing the scsenderpath in /etc/upmpdcli.conf) ?

upmpdcli reuses the main script when switching to/from sender/receiver mode, it never gets killed.

However, this is not the case for external sources. See: https://www.lesbonscomptes.com/upmpdcli/upmpdcli-manual.html#UPMPDCLI-SENDER and look for the managing external sources section, and especially the comments at the top of the sample script, which gives the details (I need to transfer this to the manual).

Also a link to a HOWTO for using the external source script mechanism to link a bluetooth player source to songcast: https://www.lesbonscomptes.com/upmpdcli/github-issues/upmpdcli-html/issue-71.html#issuecomment-292785458

Unlike the main script, the external source ones get killed when switching (I think that they get a SIGTERM, and then SIGKILL if they don’t comply), and it’s quite probable that your existing script can be used mostly without modification.

joerg-krause writes

> I understand that you just replaced the main scmakempdsender script (either in place or by changing the scsenderpath in /etc/upmpdcli.conf) ?

Yes, by changing the scsenderpath.

> upmpdcli reuses the main script when switching to/from sender/receiver mode, it never gets killed.

I see! So the auxiliary MPD process is killed, when upmpdcli is killed, right?

> However, this is not the case for 'external' sources.

Thanks! I already had a look at this. I wondered which source type I should use. The link to the bluetooth player is very helpful! I’ll try this.

joerg-krause writes

On second thought, does it mean that once mpd2sc has been started it is never stopped, meaning the Sender service is always enabled (unless I stop upmpdcli)?

medoc92 writes

> I see! So the auxiliary MPD process is killed, when upmpdcli is killed, right?

Yes, it’s created on first use, and never killed. I’m not too sure why actually. It’s also the case for mpd2sc, they just sit here and do nothing, so, yes, this means that the Sender service is always there too. I think it’s the same for the Linn Songcast apps.

This means that you can connect a Receiver to an inactive Sender. I’m not too sure if this is a bug or a feature, the whole thing is a bit complicated (but mostly working), and I’d have to think and experiment hard before changing this.

I just noticed that the upmpdcli Receiver is still reported by the upplay songcast tool as connected to its Sender even after being switched back to source Playlist. This seems to be an Upplay status report issue only though, and to not prevent stuff from working.

And by the way, this also probably means that there are two Sender services when using an external source script.

medoc92 writes

Joerg, when you are satisfied with the result, it would be nice if you could write a small recipe in the style of the HOWTO linked above. I’d then link to it from the manual, I’m sure that this can be of interest to other people.

joerg-krause writes

I will!

joerg-krause writes

I’ve quit satisfied now with my luvit-based songcast sender script setup: https://gist.github.com/joerg-krause/6661cfa54957ecb6c9332251d215440c.

The trick is that MPD is configured with two audio_outputs: ALSA and FIFO. The script is using mpc to toggle MPD between these both audio outputs. This way, there is no need for starting an auxiliary MPD instance.

This works quite well for my setup. Therefore, I am closing this issue.