[PROBLEM] Using roc-recv with Moode on the same device

[Matthias]

Hi!

I use Moode on a Raspberry Pi 3B+ and an Allo Boss without problems. I would like to run roc-recv from https://roc-streaming.org/ for streaming audio from my Android phone on the same device.

My problem is that roc-recv claims the Alsa interface continuously even when it does not receive any data, so that Moode complains with “MPD error Failed to open “ALSA Default” (alsa); Failed to open ALSA device “_audioout”; device or resource busy”.

Would it be possible for both MPD and roc-recv to play audio over the same ALSA interface (not simultaneously)? Does anybody have a similar setup and can help me with setting this up?

Thank you - Matthias

[steve4star]

Looking at their documentation it looks as if you could try and treat like the other renderers in moode and start it only when you need it.

Have you tried running roc-rcv with

Code:

--oneshot
Exit when last connected client disconnects (default=off)

[Tim Curtis]

That's an interesting sync audio project. Do you know if it supports multicast addressing?

AFAIK you would need to kill the roc-recv player in order to release the ALSA interface for other players to use. It could be a feature request for the roc project to have the receiver release the interface after a timeout, similar to the -C option for Squeezelite.

[Matthias]

That's an interesting sync audio project. Do you know if it supports multicast addressing?

AFAIK you would need to kill the roc-recv player in order to release the ALSA interface for other players to use. It could be a feature request for the roc project to have the receiver release the interface after a timeout, similar to the -C option for Squeezelite.

I think it does support multicasting (see Advanced features).

Killing roc-recv releases the interface for mpd. I would like to avoid having start and stop it manually every time, though. Using “--oneshot” might work (thank you @steve4star), but that would probably still require me to restart roc-recv manually. 

I will ask the author of roc-recv if a behavior similar to Squeezelite would be possible.

[steve4star]

Not sure what would happen, but would the following help

--no-play-timeout=200s

[Nutul]

Not sure what would happen, but would the following help

   --no-play-timeout=200s

To be able to see results in a reasonable timeframe I'd suggest using 5s, rather that 200... ;-)

[steve4star]

:-) Good idea, I just cut n pasted the example.

Cheers, Steve

[Matthias]

Not sure what would happen, but would the following help

   --no-play-timeout=200s

That unfortunately removes a “session” roc-internally, but it does not disconnect roc from ALSA.

I do not understand the idea behind

Code:

--oneshot

at all: this causes roc-recv to terminate immediately since there is no client connected, and you cannot connect a client, as roc-recv terminates immediately…

I am going to request a feature in roc-recv to have it detach from ALSA when no client is connected. I noticed that Moode displays a message “AirPlay Active“ when I stream audio from an iPhone and I do not understand how Moode is able to monitor the status of shairplay-sync. I am asking, as I would request the new feature in roc-recv to be implemented so that Moode might monitor the status of roc-recv as well.

In the meantime: is there an easy way to start a shell script from the Moode-GUI? I could use this to start and stop roc-recv without having to use ssh every time.

[Tim Curtis]

The only way to run a script in moOde other than vis SSH is via the GPIO Buttons feature. Allowing scripts to be run via a field on a form would be a bad idea.

There are two ways moOde monitors renderers:

1. Renderer event scripts (/var/local/www/commandw/)
This is the approach used for shairport-sync, librespot and squeezelite but the scripts are different and unique to each renderer. The event script updates moOde state to indicate whether a renderer is active or not.

2. Renderer binary running.
This is the approach used for Bluetooth (bluealsa-aplay), RoonBridge and Multiroom-receiver (trx-recv) which don't support event scripts. moOde's worker daemon simply polls and checks whether the binary is running or not to determine whether it's active.

Multiroom receivers like trx and roc are based on rdp/udp network protocols which are "connectionless". Clients don't really connect to these receivers they just start sending packets to a multicast or multi-unicast address(s). A receiver is "active/playing" when it's receiving packets. When no packets are received (within some timeout period) then it could be considered "stopped/listening".

[Matthias]

I have asked the author of ROC for a solution. Currently the only option is to kill roc-recv.

He might come up with a better solution in a future release; Issue 680