[Interest] OSX 10.11.4 network socket issue

["Alexander Carôt"]

> > 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?

Yes, correct.

> 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"?

No, the buffer thread gets notified right after the slot has triggered (a matter of microseconds). The problem is that the time between the sender thread has sent the UDP packet and the arrival at the receiver slot is extremely high or changes in higher dimensions as before. 

For the actual test case with localhost it typically takes less than a millisecond, however, since 10.11.5 (right: .5 is the one I am running) it takes several hundreds of milliseconds.

For a moment I thought having misused the setReadBufferSize() call (leading to high network buffering delays) but according to the docs:

"Only QTcpSocket uses QAbstractSocket's internal buffer; QUdpSocket does not use any buffering at all, but rather relies on the implicit buffering provided by the operating system. Because of this, calling this function on QUdpSocket has no effect."  

this has no effect with UDP sockets. However, in the meantime I noticed that this does not happen using the boost lib so it might be Qt related (no matter if Qt4 or Qt5) and only applies with the latest OSX.

Thanks for your recommendation regarding a different implementation but there a numerous reasons for doing it in precisely this way and it has been working fine for a number of years already. If you are interested in the details please check this work of mine, which was released in 2009:

http://www.carot.de/Docs/dissertation_AC.pdf

Summed up: I am under the impression that with OS 10.11.5 it takes a significant amount of additional time for network slot to trigger.

Any thoughts about this ?

Thanks again,
best

Alex

--
http://www.carot.de
Email : Alexander at Carot.de
Tel.: +49 (0)177 5719797


> Gesendet: Mittwoch, 25. Mai 2016 um 09:01 Uhr
> Von: "Till Oliver Knoll" <till.oliver.knoll at gmail.com>
> An: "Qt Project" <interest at qt-project.org>
> Betreff: Re: [Interest] OSX 10.11.4 network socket issue
>
> 
> 
> > 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
> 
> 
> _______________________________________________
> Interest mailing list
> Interest at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
>