Hi all,
I am somewhat at loss at how is OSC supposed to be used in Bela.io.

First, I tried using a Bela with older image ("Bela release image, v0.2.0b, 15 December 2016"):

root@bela ~$ uname -a
Linux bela 3.8.13xenomai-bone41 #2 Wed Mar 26 11:41:31 GMT 2014 armv7l GNU/Linux

Then, I tried to build both the oscx ([dumpOSC], [OSCroute] and [sendOSC]) and (... since oscx complains that its deprecated, and itself recommends instead ... ) the mrpeach ([udpreceive], [unpackOSC], [routeOSC], [packOSC]) PD external objects on the Bela itself; this passed, and I copied the relevant *.pd_linux and possible *.so files in a /root/Bela/projects/pd-externals folder on the Bela.

Then, I made a new test project on the Bela, copied to my PC, edited the _main.pd there to make a patch that uses them to be a server and receive OSC, and copied this back to the Bela. Ran the PD patch on the Bela, started the OSC client on my PC that sends OSC messages to 192.168.7.2 - everything worked without a problem, messages received, no errors. (I did this in two rounds - first a PD patch that exclusively uses the oscx objects, then changed the PD patch so it exclusively uses the mrpeach ones - everything worked fine in both cases).

Now I'm trying to do the same on another Bela, that has "Bela image, v0.3.1, 8 November 2017":

root@bela:~# uname -a
Linux bela 4.4.87-ti-xenomai-r121 #1 PREEMPT Wed Oct 25 17:50:16 BST 2017 armv7l GNU/Linux

Did the exact same procedure. So, when having a server listener and OSC receiver in the PD patch using mrpeach objects, as soon as the PD patch is ran on the Bela, I get:

2445 mode switches detected on the audio thread!
Underrun detected: 1 blocks dropped
5227 mode switches detected on the audio thread!
Underrun detected: 1 blocks dropped
8006 mode switches detected on the audio thread!
Underrun detected: 1 blocks dropped
...

... and once I start sending OSC messages from the PC client, I get something like:

...
error: udpreceive_read: Bad file descriptor (9)
errerror: udpreceive_read: Bad file descriptor (9)
272154 mode switches detected on the audio thread!
...

When I change the PD patch to use oscx objects instead of mrpeach, again I get the "mode switches detected on the audio thread" and "Underrun detected" - except this time, I never get any indication that any sort of message has been received, when I send OSC messages from the client on the PC!

So, does anyone have any idea why this happens - and how can I get OSC to work in the Bela with the newer kernel image?

I tried to find some info on OSC with PD on Bela, and now I'm even more puzzled:

Since my process of building PD externals on the Bela worked fine on a Bela with an earlier kernel image, I guess it should be possible to do on a Bela with a newer kernel image - except, I cannot tell how?! Could anyone help me get this running on a newer image?

Many thanks in advance for any clarifications regarding this!

All right, I think I got this...

First, in the thread https://forum.bela.io/d/492-pd-crashes-with-osc which mentions mode switch errors (although it was probably for PD running on the desktop, here it is on the Bela), it is mentioned:

giuliomoro You are not meant to use sleep() inside the render() callback: that function is called at regular intervals depending on the block size and it needs to be done completely before the next time it is called. sleep() would make it overrun.

... and also:

giuliomoro The reason why you are getting mode switches on Bela is probably this bug here: https://github.com/BelaPlatform/Bela/issues/366

I looked briefly at this patch, and indeed it attempts to remove sleep(); so at first I thought there must be sleeps in udpreceive or dumpOSC, but it turns out, there aren't any. I think, the problem is actually described here https://forum.bela.io/d/594-udp-audio-over-ethernet :

giuliomoro Is the source for udp~ available anywhere? It turns out that netsend/netreceive/udpsend/udpreceive, do the networking I/O in the audio thread, which is completely crazy. If [udp~] believes similiarly, then that would require to be rewritten, otherwise you could just compile it for Bela.

Alternatively: on Bela I already rewrote [netsend] and [netreceive] so that they do the networking bits in a separate thread, so they are safe to use, so what about using this vanilla replacement for udp~?

Ah nice - so as my original setup for the mrpeach objects was [udpreceive PORT] -> [unpackOSC] -> [routeOSC /msg] -> [print]; I simply replaced [udpreceive PORT] with the PD vanilla object [netreceive -u -b PORT] ; note that -u is required for UDP, and -b is required for binary mode, which is what mrpeach's [unpackOSC] expects. All this works well on desktop - however, trying it on the Bela again gave me mode switch and underruns.

So, now the question was when where these objects ([netreceive], [netsend]) updated for the Bela. That posting is from 28 Jun 2018, and my Bela image is "Bela image, v0.3.1, 8 November 2017" - so apparently, I needed to update; this also was confirmed by the https://forum.bela.io/d/498-basic-netsend-netreceive thread.

So, as I did have a Bela git folder on my PC, I just did git pull to bring the master branch to the latest, and then on the PC did:

Bela_git$ ./scripts/update_board -y

... and after a while the update completed. Restarted the Bela, and lo and behold - finally I get OSC messages in, without any mode switches and underruns - nice!

So eventually, I've used the vanilla-PD-but-modded-for-Bela [netreceive] object, the rest being the mrpeach objects [unpackOSC] and [routeOSC], in order to get this to work... Unfortunately, the splash screen on my updated Bela still shows "Bela image, v0.3.1, 8 November 2017", which might end up being confusing in the future. But at least, I have reception of UDP in a PD patch on the Bela without errors now, which is great.

          Great that you got it working.
          The entirely vanilla solution would use [netreceive -u -b] - [oscparse].

          sdaau which mentions mode switch errors (although it was probably for PD running on the desktop, here it is on the Bela), it is mentioned:

          "Mode switches" are a Bela-only thing: a mode switch occurs when the audio thread passes from "Xenomai" mode (that is: high-priority, deterministic low-latency) to "Linux" mode (that is: non-deterministic behaviour). This happens when a Linux system call is issued directly from the audio thread, for instance to do some networking I/O. Unfortunately, most of Pd networking is done in the audio thread (which is awful bad practice on any system doing real-time audio, not just on Bela, but Bela gives you a particularly strong message that you are "doing it wrong").
          This is why I re-wrote [netreceive] and [netsend] so that they work properly. The rest of the objects you use ([unpackOSC], [routeOSC]) don't actually do any networking, so they are safe to use.

              Hi @giuliomoro,

              Many thanks for your reply!

              giuliomoro The entirely vanilla solution would use [netreceive -u -b] - [oscparse].

              Thanks for that! I did some research on PD objects for OSC, and for some reason, I never stumbled upon [oscparse] until now! 🙂 Maybe I was in a bit too much of a hurry, and didn't read carefully enough 🙂

              giuliomoro "Mode switches" are a Bela-only thing: a mode switch occurs when the audio thread passes from "Xenomai" mode (that is: high-priority, deterministic low-latency) to "Linux" mode (that is: non-deterministic behaviour).

              Thanks for this too - I eventually gathered those messages have something to do with real-time performance, but it's great to have that confirmed with proper terminology.

              This is why I re-wrote [netreceive] and [netsend] so that they work properly. The rest of the objects you use ([unpackOSC], [routeOSC]) don't actually do any networking, so they are safe to use.

              Thanks for both the rewrite and the confirmation - feels much better proceeding with the rest of my project now 🙂

              Cheers!