[Interest] OSX 10.11.4 network socket issue

[Till Oliver Knoll]

> Am 24.05.2016 um 22:48 schrieb Alexander Carôt <alexander_carot at gmx.net>:
> 
> Hi all,
> 
> ...
> 
> SENDER AUDIO CALLBACK
> SENDER THREAD
> RECEIVER SLOT
> BUFFER THREAD

What is this? So you have two threads, the "Audio Grabber" and the "Buffer" thread, and the Grabber tells the Buffer via an asynchronous Qt signal that there's data to buffer? Do I interpret your sequence above correctly?

And now you noticed that on OS X 10.11.4 (the latest ist .5 btw) the Buffer thread gets notified "a little bit later than expected"?

I cannot tell whether the apparent change in thread scheduling on OS X is for the better or worse (least of all whether it's "intentional" - you never know with Apple these days ;)) - but in general "assumptions about the When" in multi-threaded programming always call for trouble. Only if in the most obscure border case.

I'm not sure what you meant by "it messes up my system", but I guess you mean the buffer is overwritten with audio samples repeatedly, without the Consumer of the buffer having a chance to read the previous data. Or you have delays until the proper data is written or... let's just say the audio data you grab is "corrupted" and sounds "choppy" when you play it afterwards.

So in general, when you want to make sure about the "When" (e.g. "No thread proceeds until all involved threads have reached THIS point") you would apply "Barriers".

Off course with audio you have some "real time requirements", so the "Barrier pattern" might not be too useful: "Audio grabbing cannot wait".

So you might try to (dynamically) resize the buffer, that is, "grab more and write more into the (now larger) buffer" when you realise that the Consumer thread "reacts too slowly" (of course the assumption is that there's some kind of "feedback loop" back to the Grabber thread: "I have now buffered N data").

Or use several buffers and fill them up until the first N buffers have been consumed. Then "recycle" them, or deallocate them dynamically again if the system load permits again.

But in no circumstance should you make an assumption about "when" the receiver of your asynchronous signal will eventually get notified. For your mental design assume that "it takes hours" - design your synchronisation accordingly.

Cheers,
  Oliver