Re: [Interest] OSX 10.11.4 network socket issue

[Alexander Carôt]

Hello again,

 

1.) I doublechecked and can confirm that the receiver slots takes between 500 ms and 1 s to respond.

 

2.) However, I figured how to bypass this issue:

 

In my audio callback thread (which is executed every 2.7 ms) I also trigger a levelmeter via QCoreApplication::postEvent(my->sj,ce); - this way the levelmeter values are set within the Qt event loop, which is turn does not block my audio callback thread. This has been working fine for the last 5 years on every OSX, Linux and Windows (any release) but since OSX El-Capitan this causes the trouble. When I disable the levelmeter event the audio receiver slot is working fine again (it responds immediately as expected).

 

Just in case here the simple structure of the event loop:

 

bool soundjack::event(QEvent *e){

    // calls in order to get the event number num and then

    // many events for several thing and finally -->

   

    /// LEVELMETER
    if (num == 654330){
        level->setLevel(dFC->maxSampleValue);
    }

 

    return QWidget::event(e);

}

So - now I wonder if anything changed regarding the event loop since OSX10.11.5 or if anyone has other ideas what could be wrong.

 

Thanks in advance,

best

 

Alex

 

--
http://www.carot.de
Email : alexan...@carot.de
Tel.: +49 (0)177 5719797

 

 

Gesendet: Mittwoch, 25. Mai 2016 um 17:17 Uhr
Von: "Alexander Carôt" <alexander_ca...@gmx.net>
An: "Till Oliver Knoll" <till.oliver.kn...@gmail.com>, "qt qt" <interest@qt-project.org>
Betreff: Re: [Interest] OSX 10.11.4 network socket issue

Just figured: The slot is triggered fine but other aspects related to my current problem have come up. Will get back again later.

Best

Alex
--
Diese Nachricht wurde von meinem Android Mobiltelefon mit GMX Mail gesendet.

Am 25.05.2016, 09:01, Till Oliver Knoll <till.oliver.knoll@gmail.com> schrieb:

> Am 24.05.2016 um 22:48 schrieb Alexander Carôt <alexander_ca...@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@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

_______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest

_______________________________________________
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest