Multiroom / power on-off amp

[ptoschi]

Hello,
I'm new to MoodeAudio but as far as I can see, it works really well. I've been using Volumio before and I use a python script to power on the attached amplifier when mpd is playing and powering it off when mpd has stopped.

This works perfectly with MoodeAudio too.

Now I'm trying to get Multiroom to work. The configuration is no problem but it doesn't trigger my python script, probably because the renderer doesn't use mpd. How can I see if a renderer is playing to power on my amp with my script?

Thank You very much,
ptoschi

[Tim Curtis]

Use the commands below to check ALSA output for "closed"

Sender

Code:

# Not playing
pi@trx:~ $ cat /proc/asound/card2/pcm0p/sub0/hw_params
closed

# Playing
pi@trx:~ $ cat /proc/asound/card2/pcm0p/sub0/hw_params
access: MMAP_INTERLEAVED
format: S16_LE
subformat: STD
channels: 2
rate: 48000 (48000/1)
period_size: 4096
buffer_size: 16384

Receiver

Code:

# Playing
pi@sig:~ $ moodeutl --hwparams
closed

# Not playing
pi@sig:~ $ moodeutl --hwparams
access: RW_INTERLEAVED
format: S16_LE
subformat: STD
channels: 2
rate: 48000 (48000/1)
period_size: 241
buffer_size: 6144

Note that currently the moodeutl --hwparams command does not work for Multiroom sender. I'll fix that for upcoming 8.3.8 release.

[ptoschi]

Thank You very much! That's exactly what I was looking for!

[ptoschi]

I've tested it in the meantime but it doesn't really work moodeutil -hwparams changes its output from closed as soon as the receiver is connected to the sender. So the amp would be on as long as multiroom is configured. It should only be on when actual music is playing.

Is there another option for this?

Thank You very much!

[Tim Curtis]

Right, the receiver opens the audio device and leaves it open while its waiting for data packets from the sender.

The receiver daemon does not post a "play state" event indicating whether it's playing or not, and I'm not sure that state can be determined by an external program. I checked various ALSA blocks and no luck seeing an indication of play state.

# ALSA device block (card1 = Heaphone)

Code:

pi@pb1:~ $ ls /proc/asound/card1/pcm0p/sub0/

hw_params  info  prealloc  prealloc_max  status  sw_params

# ALSA commands

Code:

alsabat
alsabat-test
alsacap
alsactl
alsa-info
alsaloop
alsamixer
alsatplg
alsaucm

TRX Receiver source
https://github.com/bitkeeper/trx/blob/fe...urtis/rx.c

I did a quick test of the receiver in debug mode while sender is stopped and then playing and there were no NULL packets reported. In other words no obvious way to determine the play state from debug output.

Code:

sudo killall trx-rx
sudo trx-rx -d plughw:1,0 -h 239.0.0.1 -p 1350 -m 128 -j 64 -f 1920 -R 45 -v 2

I can add "Code a trx-rx event to indicate play state" to the TODO list but practically speaking its going to take another dev to do the investigation and work because of time constraints on my end.

[Nutul]

How does all the chain work (really, I would expect the http broadcast is used, but actually don't know)...? I mean, isn't it possible to examine the sender also for *where* it is sending data? (well, if it is the http thing being used, of course not...)

[Tim Curtis]

On the sender sources that play to _audioout.conf for example MPD, AirPlay, Spotify Connect and Bluetooth use the chain below.

Source -> ALSA Loopback <- Sender (OPUS/RTP/UDP) -> Multicast 239.0.0.1

[ptoschi]

Thank You very much for all the info! I can still use it if I take care to add and remove the receivers as needed.

Again thank You!