Can QAudioOutput pull data from a QIOdevice, in a thread?

[aart]

I am writing a low level audio application where i want to use a QAudioOutput in "pull" mode, requesting its samples from a QIODevice. I create a QAudioOutput and QIODevice and have moved both of them to my audioThread. I make sure to call QAudioOutput::start(QIODevice *) on the audio thread. But for some reason when i check from which thread QIODevice::readData is called it is still the main gui thread.

Is it impossible to use QAudioOutput with pulling from a QIODevice in a thread, or have i forgotten something?
Thanks in advance for any help!

[aart]

@aart There seems to be a bug report about this same issue: https://bugreports.qt.io/browse/QTBUG-43690. The solution given here is "It only pulls data in the GUI thread if the QAudioOutput object resides in the GUI thread. It's your responsibility to move the object to another thread if you want it to process data there." However I have checked that the QAudioOutput has been moved to the audio thread, just like the QIOdevice.

Answer is still unclear.

[SGaist]

Hi,

Are you using the worker object approach ?

[aart]

so ive been working on this problem a bit more, and i have some suspicion what the problem is. I have also tried using the QAudioOutput in "Push" mode, and i found that the sample writing only happens in the worker thread when i use my own QTimer. If i use the QAudioOutput build-in notify mechanism, everything runs in the gui thread.

The starnge thing is that i explicitly move the QAudioOutput to the audio thread, i guess for some reason the timer inside responsible for the notify signals is not moved with it? Maybe this also explains why "Pull" mode ran on the wrong thread. i can imagine that Pull uses the internal notify timer.

last note: I am using Qt 5.12.4, on Windows

[SGaist]

Can you share the code you are using ?
Do you get any warning about a timer being in the wrong thread ?