Yes! OSC packets are received on the network thread and pushed to a lockfree queue. In the audio callback, before calculating a new block of audio (= control period), it would take packets from the queue. If the packet is an OSC message, it is executed immediately. If it is an OSC bundle with a future time stamp, it is put on a priority queue, so it gets executed later at the desired time. As @jamshark70 has pointed out, the callback might compute several blocks in a row:
number of blocks = hardware buffer size / block size
I also wonder if sync messages are handled more infrequently than other OSC messages (like bus set for example).
/sync is an asynchronous command. Asynchronous commands travel between the RT and NRT thread and look like this:
(stage 0: receive packet on network thread)
stage 1: RT thread → interpret OSC message and dispatch command
stage 2: NRT thread → do work (e.g. read a soundfile into a buffer)
stage 3: RT thread → exchange results (e.g. swap buffer data)
stage 4: NRT thread → send
/done message + NRT cleanup (e.g. free old buffer data)
(stage 5: RT thread → RT cleanup)
Unlike “real” async commands,
/sync doesn’t do any real work. Its sole purpose is to travel through all stages to make sure that all previous async commands have finished.
Generally, the duration of a
Server.sync call is indeterminate, as it depends on pending asynchronous commands. If
sync becomes a bottleneck, you’re likely using it in a non-optimal way
I can second @jamshark70’s recommendation:
I suspect the solution to your problem may be to reduce the number of sync calls – clump the messages into bundles of 10-20 messages each, and issue one sync per bundle.