Thank you for your answer @anon48770766
I do agree about the maxim and that it would be better with only one realtime thread. However, I have some constraints on the Dante/Audinate side that made me write the code like this…
It may possible to do it very differently but implies a big refactoring that will take more time than I have right now.
I also see clearly the race conditions you are mentioning and thought the same thing.
The shared resource however (ringbuffer) is supposed to be non-blocking. Only the write & read heads are atomic and only one of the thread modify each of them. Close to a lock-free-fifo (or so I hope!).
Last question remains: I cannot make JUCE set the priority just a little lesser with the priority field of the RealtimeOptions struct. From my first rough test (I have to investigate further) this parameter does not seem to have any visible effect… Why is that?
I will continue to investigate the code of JUCE for this last question and try to evaluate the refactoring need for a 1 realtime thread version.
Anyone has already fiddle with this parameter?
I saw this post as well : startRealtimeThread examples - #3 by lcapozzi
But it is centered around Apple problems…
Thank’s
Benjamin