QAudioOutput vs QTimer strange behaviour

[mzimmers]

@abarmotov I don't know a lot about this area, but evidently Creator is generating your connect statement for you. It looks to me like you want a queued connection, but you're not getting one. I want to point out that I very well could be mistaken about this; hopefully someone more knowledgable can jump in here.

As a total hack/band-aid, you could block your function by checking that variable and not proceeding until it's false:

void MainWindow::on_pushButton_clicked()
{
    while (slotIsRunning_) {
        qDebug() << "HMMM";
        // wait a few ms
    }
    ...

You'd probably want to put in a timer so that you don't wait forever if something goes wrong, but you could use this to test what's going on.

[abarmotov]

@mzimmers i thought, that in singles thread qt app is not possible that slot interrupts another slot - they are serialized in execution

so maybe here bug with QAudioOutput somehow, because if i comments out "new QAudioOutput" - there is no "HMMM" in output

full source here: https://github.com/a132791/TestQt3

[mzimmers]

@abarmotov evidently, you're right - calls to slots are queued and don't interrupt one another.

I'm running Qt 6.4 and made a couple changes to your slot. Program works as expected.

void MainWindow::on_pushButton_clicked()
{
    if (slotIsRunning_)
        qDebug() << "HMMM";

    slotIsRunning_ = true;
//    QAudioFormat format;
    QAudioOutput* audioPlayer_ = new QAudioOutput();
    qDebug() << "QAudioOutput created";

    QThread::sleep(1); // some work

    delete audioPlayer_;
    qDebug() << "QAudioOutput deleted";
    slotIsRunning_ = false;
    QTimer::singleShot(std::rand()%50, this, &MainWindow::on_pushButton_clicked);
}

The code wouldn't compile with the QAudioOutput c'tor as coded.

[jsulm]

@abarmotov said in QAudioOutput vs QTimer strange behaviour:

but how it set "true" ?

You set it to true in the slot, so I don't understand the problem.
On first slot call "HMMM" will not be printed but slotIsRunning_ will be set to true, so on second slot call you will print "HMMM"...

[abarmotov]

@mzimmers said in QAudioOutput vs QTimer strange behaviour:

I'm running Qt 6.4 and made a couple changes to your slot.

does it means what in 5.12 the QAudioOutput is broken ?

[abarmotov]

@jsulm said in QAudioOutput vs QTimer strange behaviour:

You set it to true in the slot, so I don't understand the problem.

the problem is that slot interrupted in SINGLE thread app - that not expected by me
is it documented somewhere ?

[mzimmers]

@abarmotov said in QAudioOutput vs QTimer strange behaviour:

does it means what in 5.12 the QAudioOutput is broken ?

Doubtful. According to the docs for 5.15, your constructor looks good (I notice you don't initialize your QAudioOutput object, but that shouldn't matter for this exercise).

I'm more suspecting there's something wrong with re-using your slot as the argument to the QTimer::singleShot call. When that's commented out, it seems to work fine, right?

[abarmotov]

@mzimmers said in QAudioOutput vs QTimer strange behaviour:

When that's commented out, it seems to work fine, right?

no, HMMM is still there on second click
but i tested only on 5.12.8

[jsulm]

@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...

[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.