OSC blobs are lost above certain size

General JUCE discussion
1

I saw that some applications like the Wekinator use OSC blobs for streaming audio.
So I tried something similar with JUCE and found that blob data are not sent with a block size above 4076 bytes (on my machine - this value could of course differ on other machines/OSes).

Tested with JUCE 4.3.0 and /develop branch.
Debugging into OSC send showed nothing that is obviously failing inside JUCE, so it might be something happening asynchronous (side not: found that it might be a bit risky that OSCSender::Pimpl.send does not check for the return value of outStream.writeMessage (message); - but in my case it is true).

I filed an issue with reproducible test case for this.

Did anyone experience this before?

2

That’s a limitation of UDP messages. Depending on the OS (and its settings) , there will be a limit on the maximum size of udp packets that you will be able to use. I thought it was reasonably safe up to 8192 bytes but your experience shows that the safe max size is lower than that.

3

Wow, I thought it is close to 64K. See e.g. Wikipedia:

The practical limit for the data length which is imposed by the underlying IPv4 protocol is 65,507 bytes (65,535 − 8 byte UDP header − 20 byte IP header).

But I was mislead: in fact the protocol allows 64K, but the practical guaranteed limit is 576 bytes.
The IPv4 Spec (search for 576) itself says:

It is recommended that hosts only send datagrams
larger than 576 octets if they have assurance that the destination
is prepared to accept the larger datagrams.

So without protocol overhead, it should always be limited to 512 bytes to be safe.
Thanks @jpo for your hint - sorry that I was not researching it correctly…

Anyway it is not nice that the packages get completely lost without further notice.
But even there I guess that nothing can be done at JUCE level as it is probably due to UDP having no handshake, right…?

4

In case someone stumbles upon this problem OSC blob size again:
Here’s a little test tool to test the max. working OSC blob size.
This way maybe my stupid beginner’s researches are not useless :wink:

It sends blobs with increasing size until one fails and shows you the last successful size.
Works immediately without parameters on one machine.
Or on 2 machines remotely with ip, port, send/receive mode parameters, see description in the code.

5

I have also hit this limit. Is there a way in Juce to send osc over tcp instead of udp?

6

Yea, this might be interesting… We would trade reliability for latency then…
There seem to be some discussions and even implementations for OSC via TCP.
E.g. here is one: http://liblo.sourceforge.net/docs/group__liblo.html#gaceb4b068bc48c2b075e790910cab3075

So I think it would just need to be implemented in JUCE, but there’s no reason not to do it.
Maybe I’ll try it if I find some time…

7

Tool to get max. OSC blob size in your network setup
Hey ho, in case someone stumbles upon this issue again:
I rewrote my little test tool to get max. OSC blob size in your network setup.
It is now hopefully mature and due to bisection finding any size fast and without start value.
It is also tested with 2 separate clients now.


Have fun!