Broadcast OSC messages to multiple laptops

Questions
1

Hello,

I am trying to send OSC messages to multiple laptops for a Laptop Orchestra performance via the broadcast IP. There will be around 30 performers for this.

I noticed that some messages are dropped and even worst there might be inconsistencies between the computers involved. I was trying various options, routers etc but seems that I cannot completely resolve the issue. Are there any recommendations on this?

This is the test code I use for transmitting the messages to the crowd. It goes of course with a simple OSCdef for picking up the messages and printing them on each orchestra member

NetAddr.broadcastFlag_(true);
// ~transmission = NetAddr.new("192.168.0.255", 57120) // Broadcast Address option 1
~transmission = NetAddr.new("255.255.255.255", 57120) // Broadcast Address option 2

(
var test;
test = [" ******** ", " -------- "].choose;
~transmission.sendMsg(\teleport, test);
)
1 Like
2

AFAIK the only way to solve this is through redundancy: send the message repeatedly until receiving a message back from the other machine.

I’ve never seen broadcast UDP work reliably.

hjh

2 Likes
3

Although @jamshark70 has already replied, I would like to share my experience.

If I remember correctly, OSC messages over UDP were received almost correctly when using a wired connection.
However, I always had problems when using a wireless connection.
My situation did not allow me to use a wired connection. So I did the following:

  • Send the same OSC message repeatedly to other computers for one or two seconds.
    The number of times a message is sent per second depends on the CPU speed of the computer sending the OSC messages.

  • Other computers should not receive OSC messages for a while after receiving an OSC message.

It worked for me because I did it to change the screen to the next screenshot of the score.

It may not work for the exact synchronised command. However, in human performance there is always a lot of slight unsynchronisation, even when playing rhythmically in unison.

1 Like
4

Thank you so much both for your help and for sharing your experience. Wondering if this is a generic problem related to OSC protocol, to the UDP or to the SC implementation. Seem its the UDP.

I am thinking about the following scenarios. Any insight would be really helpful

I have read that TCP is more stable. I could dedicate one laptop just for sending the messages via TCP. I know I can change the way the server is communicating by s.options.protocol(\tcp) but in this case I need only to define the way NetAddr is handling the messaging to other computers. Is there a way for each computer in the orchestra to keep the default UDP protocol for the internal server communication but handle OSCdefs in TCP? Mind that each laptop uses their own internal servers to generate sound. No central audio engine here.

I could develop the messaging/communication section in Max/MSP or Processing or TouchOSC if SC (NetAddr) is the issue. I need to send also verbal text to the performers so TouchOSC is not ideal but I would find a workaround I think…

Kind regards

5

I think TCP can be problematic for real-time performance:

6

Thanks for this. Yes, I thought that an infinite checking loop could be a nightmare! I think I will try implementing also a Max/MSP sender just to check any performance differences. I am pretty much sure thought I will face the same problems.

FYI by testing yesterday with 10 computers, there were a few messages dropped here and there so resending the message 1-2 times should really work. There were more severe problems with one Ubuntu Laptop which puzzled me. Will have to check now with more clients and it gets a bit scary but as Italians say " vivere pericolosamente!"

1 Like
7

Is the sadam package still the one that has the functional TCP to offer? I tried it almost 10 years ago and once after that. I cannot remember exactly…
Screenshot 2024-05-22 at 15.16.21

8

I will try this, but also the default [udpsend] just to see any possible differences.

By the way I have tried writing down each participant’s IP and send to them individually (instead of broadcasting) but still I think I got inconsistency problems

9

You might want to look at Utopia. It uses broadcast pings to populate an address book which you can then use to send to all. This has been very robust.

The problems I’ve had with broadcast though have usually been related to correct subnet configuration, security settings, etc. This can be very tricky to get right.

You are right that UDP has no delivery guarantees, but on a well setup LAN this shouldn’t be an issue.

10

Very interesting thanks, I will check it.

I did not have problems to broadcast so far. As far as I understand once you calculate the broadcasting IP things are straight forward. I found out that there are two ways to broadcast.

In my case it is 192.168.0.255 which I guess broadcasts in all range from 192.168.0.1 - till 254 but also 255.255.255.255 which broadcasts I think in every possible IP the router can assign. I am not really sure if I am correct.

I am tempted to ask what would be a well setup LAN? I am testing on a TP-Link and also an older AirPort Extreme. There are tons of options there. I have hard reset the routers and basically left them unmodified

Even with a minimal setup though (one MacMini broadcasting to two other MacBooks on a dedicated router) there can be times when one message is dropped from one computer.

With a small group of 10 computers my experience right now is that sending a message for a second time solves the problem. Don’t know how will it work with 30 computers though!

11

255.255.255.255 means this network, ie the LAN, AFAIK.

A question for the ages! I’m not an expert, but yeah, vanilla router settings, no firewalls or other gunk. I’ve had good success with just simple dumb switches, though this means no DHCP. Check the subnet mask and security settings etc. on all the attached computers. A network is not defined merely by the router.

Yeah, I generally find broadcast messages are best for things like ‘hello!’ ie discovery. An exception might be when you need super fine sync, as a broadcast message only happens when there’s no contention (at least that’s my non-expert understanding!) so they should be received (if not handled) as close to simultaneously by all peers as possible. Utopia uses a pseudo-reference beacon approach in BeaconClock which exploits this to do sync.

12

So whether you use a wired or wireless connection should be no problem?

If I remember correctly, in my room (smaller than 4m * 5m) at home, I have no problem with the wireless connection. However, in a hall (recital hall and chamber hall) the wireless connection was not so reliable. Also, 2.4GHz was more reliable than 5GHz for screen sharing and OSC communication…
I used 1:n send and receive with specific addresses rather than broadcast.

Next time I will check the local connection configuration.

13

I would always use a dedicated wired connection where performance is critical. Concert halls often have a lot of RF stuff so can be particularly bad for wireless. IAC testing on wireless removes one variable.

1 Like
14

Thank you all for your feedback. I have tested again today with 12 Laptops and seems that indeed the only way to make sure everything arrives everywhere is by sending the messages multiple times. I am using a routine (fork) for this and I am filtering the messages in the receiving OSCdef to reject repetitions. I hope I will be able to test with more computers next week. Anyway, the good news is that there are not time critical demands that would require absolute sync

Wiring them all should be definitely a better and probably more reliable option but for this project the orchestra is scattered into the audience. They simulate a swarm of bees. Info here Bee Swarms Wiring would look more like a Max/MSP patch! :rofl: Still, maybe its a good idea to have my main (sending) computer connected via eth0

Very good to know that 2.4GHz works better, thanks!

1 Like