QAudioOutput vs QTimer strange behaviour

[abarmotov]

@jsulm said in QAudioOutput vs QTimer strange behaviour:

Still don't get what the issue is...

the mouse click on button "should not" interrupt any running slot, but must be queued in qt event loop in single thread app
am i wrong ?

[abarmotov]

@jsulm said in QAudioOutput vs QTimer strange behaviour:

so on second button press slotIsRunning_ is true

slotIsRunning_ is set to false at end of slot - that the point

[mzimmers]

@jsulm said in QAudioOutput vs QTimer strange behaviour:

@abarmotov Why do you think so? You wrote: "then press on button two times". So, as I explained: on the first button press you set slotIsRunning_ to true, so on second button press slotIsRunning_ is true and you print "HMMM". So, nothing is interrupted. Still don't get what the issue is...

He sets slotIsRunning_ at the start of the slot, but then sets it to false towards the end.

[jsulm]

@mzimmers Yeah, did not notice that.

[abarmotov]

Any thoughts on why this is happening?

[abarmotov]

i found it:

QPulseAudioOutput::~QPulseAudioOutput()
{
    close();
    disconnect(m_tickTimer, SIGNAL(timeout()));
    QCoreApplication::processEvents(); // THAT STRING BREAKS EVENT LOOP
}

[jsulm]

@abarmotov said in QAudioOutput vs QTimer strange behaviour:

THAT STRING BREAKS EVENT LOOP

It does not "break" event loop, it just tells event loop to check and handle events if there are any.

[abarmotov]

@jsulm
but this is the way my slot is called a second time, while that slot in middle on execution
this behavior is not obvious when deleting QAudioOutput

[jsulm]

@abarmotov Why did you add processEvents at all there?

[abarmotov]

@jsulm it ain't me )
QPulseAudioOutput - this is qt source code

[jsulm]

@abarmotov Ah, right. Would be interesting to know why it was added - doesn't look correct to me and causes the issue you have.