multiroom as server

[lifeform]

hello
i using moodeplayer for daily basis music player in my room. 
and want to implement something like sonos do (just excited to create something like that in my mind)

there is downside about using moodeplayer default multiplayer. the moode must be standalone as server that can stream the audio to another multiroom speaker.
is there any plan to change this ? or might be implementing with something else?

there is bark project but it might not active project, aand recently i found sonobus https://github.com/sonosaurus/sonobus
but i'm not good in programming, so might some suggestion why not used it?

thanks before.

[Tim Curtis]

Snapcast is going to be tested for multiroom audio but the requirement for the sender being standalone may still continue.

[lifeform]

Snapcast is going to be tested for multiroom audio but the requirement for the sender being standalone may still continue.

hello
i guess why you decided to used standalone server sender. in my mind i think it is about latency. but i am not sure
but using sender as receiver might be so efficient  i want to used it as speaker active server. and sync in multiple room, if i have separate standalone sender server it might difficult to set if i want to send some sender source...

if latency is the main problem looks like bark audio sync might nice solution right now?

if i need 2 song with 4 room speaker, first song only in first and second room, second song in third and forth room. i must create 2 sender moode right?

[Tim Curtis]

No not latency, trx receiver when running on the sender could not receive multicast packets. It could be that some sort of special network config is require, I don't know.

I ask in the bark repo a long time ago but no response from the maintainer so this project is a non-starter for me.

I've never tried your usage scenario but for sure you can't run two senders using the same multicast address on the network. I suppose you could try using a different multicast address for the second sender and receivers and see what happens.

I'm not sure what type of networking Snapcast uses, or any of its other capabilities. My interest in it has to do with its capability to maintain clock sync between sender and receivers which improves the to-the-ear sync.

[lifeform]

No not latency, trx receiver when running on the sender could not receive multicast packets. It could be that some sort of special network config is require, I don't know.

I ask in the bark repo a long time ago but no response from the maintainer so this project is a non-starter for me.

I've never tried your usage scenario but for sure you can't run two senders using the same multicast address on the network. I suppose you could try using a different multicast address for the second sender and receivers and see what happens.

I'm not sure what type of networking Snapcast uses, or any of its other capabilities. My interest in it has to do with its capability to maintain clock sync between sender and receivers which improves the to-the-ear sync.

hello,
i just read the readme of the snapcast, and i think it is great that snapcast support more than one server

Code:

Snapcast can be used with a number of different audio players and servers, and so it can be integrated into your favorite audio-player solution and make it synced-multiroom capable. The only requirement is that the player's audio can be redirected into the Snapserver's fifo /tmp/snapfifo. In the following configuration hints for MPD and Mopidy are given, which are base of other audio player solutions, like Volumio or RuneAudio (both MPD) or Pi MusicBox (Mopidy).

so it might really nice changing with snapcast. any beta for moodle that i can test?

[Tim Curtis]

Looking at Snapcast is next on the TODO list for "major work efforts" but there are other smaller items and bug fixes that are ahead of it and as new bugs are discovered this list grows.

I'm not sure how much work Snapcast might be until I get a better understanding of its network and command & control interfaces. The current TRX Multiroom solution is relatively simple using IP Multicast for networking and a REST API for command & control. 

Maybe another dev with Snapcast experience will take on the work effort :-)

[Tim Curtis]

No not latency, trx receiver when running on the sender could not receive multicast packets. It could be that some sort of special network config is require, I don't know.

I ask in the bark repo a long time ago but no response from the maintainer so this project is a non-starter for me.

I've never tried your usage scenario but for sure you can't run two senders using the same multicast address on the network. I suppose you could try using a different multicast address for the second sender and receivers and see what happens.

I'm not sure what type of networking Snapcast uses, or any of its other capabilities. My interest in it has to do with its capability to maintain clock sync between sender and receivers which improves the to-the-ear sync.

@lifeform, I did a quick test this morning running two senders and distributing different streams to their respective receivers and no problems.

Sender-1 and Receiver-1 at 238.0.0.1 
Sender-2 and Receiver-2 at 238.0.0.2

The multicast address is not exposed in the config UI but here are the commands to update the address. Restart the sender and receiver after updating.

Code:

# Sender Pi
moodeutl -q "update cfg_multiroom set value='239.0.0.2' where param='tx_host'"

# Receiver Pi
moodeutl -q "update cfg_multiroom set value='239.0.0.2' where param='rx_host'"

Currently in the UI there is no address filter on the Receiver and Discovery lists so both senders will see the same list of receivers even though they will only be able to send to receivers configured with their multicast address. I could add that filter and also add the address field to Receiver Config > Advanced.

What do you think?

[Tim Curtis]

The full feature enhancement will be in upcoming 9.0.4
Simply set a different multicast address for example 239.0.0.2 for the second Sender and its Receivers.

       

[lifeform]

No not latency, trx receiver when running on the sender could not receive multicast packets. It could be that some sort of special network config is require, I don't know.

I ask in the bark repo a long time ago but no response from the maintainer so this project is a non-starter for me.

I've never tried your usage scenario but for sure you can't run two senders using the same multicast address on the network. I suppose you could try using a different multicast address for the second sender and receivers and see what happens.

I'm not sure what type of networking Snapcast uses, or any of its other capabilities. My interest in it has to do with its capability to maintain clock sync between sender and receivers which improves the to-the-ear sync.

@lifeform, I did a quick test this morning running two senders and distributing different streams to their respective receivers and no problems.

Sender-1 and Receiver-1 at 238.0.0.1 
Sender-2 and Receiver-2 at 238.0.0.2

The multicast address is not exposed in the config UI but here are the commands to update the address. Restart the sender and receiver after updating.

Code:

# Sender Pi
moodeutl -q "update cfg_multiroom set value='239.0.0.2' where param='tx_host'"

# Receiver Pi
moodeutl -q "update cfg_multiroom set value='239.0.0.2' where param='rx_host'"

Currently in the UI there is no address filter on the Receiver and Discovery lists so both senders will see the same list of receivers even though they will only be able to send to receivers configured with their multicast address. I could add that filter and also add the address field to Receiver Config > Advanced.

What do you think?

so the proof of concept is works, right? 


i see that in their ROADMAP they will support this "JSON-RPC Possibility to add, remove, rename streams"
but i do not know the "Streams" they said is the multicast ip or not. or another protocol will be used. 

if you add the filter and multicast setting it will be the best way to used it. 
i thinking how to make it really simple to changing the multicast ip, if it used command it would be hard to change from one to another speaker

the case i want to implement is like this:
for example : i have 5 room, 3 bed room, 1 living room, 1 bath room. every single have 1 speaker with moode integrated. 
every room can play different song. but i also can make living room as server, living room also as speaker, bathroom as speaker and one of the bed room  as speaker
while living room as server playing song, i also make another bed room play another song sync
another case is, at midnight i playing lullaby song for bed room speaker the server is one of moode in the bed room

i just thinking, how if moode have something like API command to add, remove, set mode? it will be more easier to handle for user

[lifeform]

The full feature enhancement will be in upcoming 9.0.4
Simply set a different multicast address for example 239.0.0.2 for the second Sender and its Receivers.

hello
it is still cannot used sender as receiver also right?

i trying but cannot used as receiver (sender mode-)