OSC Jitter on Windows

Support, Help & Resources
1

Hi Folks,

Looks like this has been covered before and is something in the bowels of Erlang (Is it possible to control via Sonic Pi an instrument in Ableton? - #34 by ian) but I have pretty pictures so I thought I would post them. I backed into this problem so my test harness is probably needlessly complicated as I wasn’t sure where the jitter was originating. Should have searched here first :).

Test Harness:

  • Sonic Pi sending an OSC packet every 100ms.
  • esp32 that is flipping a pin via the hardware clock (very precise) every 100ms. Also flips a pin when it gets an OSC packet.
  • logic analyzer with PulseView and the jitter command to see the relationship between the two pins
  • R code to analyze it

win-wifi* runs send the packet over wifi to the wsp32.
*rs485 use a python bridge on the host and send data via serial.

You’ll see here the macos based one is spot on. But the windows has bimodal jitter due to inaccuracies in the erlang scheduler.

mac_vs_window_jitter
mac_vs_window_jitter862×550 49.4 KB

This is running v3.3.1 and makes it clear I should be using my old mac laptop for this project.

–chris

2

Interesting results, thanks for sharing. You’ll definitely get some jitter from using WiFi - if it’s possible to repeat this experiment using Ethernet, that should eradicate that aspect.

There is definitely lower timing resolution for the Erlang osc scheduler in v3.3.1 and below on Windows.

However the latest Erlang release which will feature in the upcoming beta does purport to fix this, so in addition to repeating with Ethernet, I’d love to see these repeated with the new beta to see if things really have improved.

3

That’s great to hear that it looks like they’ve addressed this in the Erlang scheduler. I’ll keep my testing harness around so I can rerun these tests when the beta is available.

I can’t reproduce these tests using ethernet as none of my development boards have ethernet. What I did instead was use RS-485 serial. You can see in this picture I compared Mac OS (with the more accurate scheduler) using RS-485 in the top row, and then the bottom two rows are the same test running over Wi-Fi. As you pointed out, you can see that the distribution of events is smeary and left shifted for the Wi-Fi cases. Packets will never arrive early, but can always arrive late :-).

macos-wifi-vs-serial

1 Like