QAudioOutput in pull mode
-
I am trying to create a QIODevice and pass it to a QAudioOutput->start(&device) (pull mode)
Then in the QIODevice::readData() method I simply produce 0s and check how much data is read by the Qt framework.
I initialise a timer on one side and count how many frames are read on the other side.
I would expect these 2 quantities to move in sync (clearly not exactly the same).And it happens exactly that until I resize the main Qt window. Then the amount of data read from the QIODevice slows down.
I am using Fedora 31 GNOME Wayland, pulse
Audio format 44100, 1, 16bit Signed Int. (tried different choices, no diff)
The difference is huge, after 20 seconds and resizing the window I get
Actual frames read 536576
Expected frames 848660 (elapsed * frames per ms)If I stop resizing, they stabilise.
To be crystal clear, my dummy readData function always returns in no time all the data required.
The state changes and some underrun happens, but again, the device is not to be blamed for this.
The category of the QAudioOutput seems to change a bit ("game" vs other), but in all cases resizing causes havoc.
Reading other posts in the forum it seems Qt AudioOutput is a dead end road. Not to be used.
https://forum.qt.io/topic/40026/real-time-audio-processing-with-qt5-general-conceptIs this true? What is the point of adding this feature if it works that badly?
-
I am trying to create a QIODevice and pass it to a QAudioOutput->start(&device) (pull mode)
Then in the QIODevice::readData() method I simply produce 0s and check how much data is read by the Qt framework.
I initialise a timer on one side and count how many frames are read on the other side.
I would expect these 2 quantities to move in sync (clearly not exactly the same).And it happens exactly that until I resize the main Qt window. Then the amount of data read from the QIODevice slows down.
I am using Fedora 31 GNOME Wayland, pulse
Audio format 44100, 1, 16bit Signed Int. (tried different choices, no diff)
The difference is huge, after 20 seconds and resizing the window I get
Actual frames read 536576
Expected frames 848660 (elapsed * frames per ms)If I stop resizing, they stabilise.
To be crystal clear, my dummy readData function always returns in no time all the data required.
The state changes and some underrun happens, but again, the device is not to be blamed for this.
The category of the QAudioOutput seems to change a bit ("game" vs other), but in all cases resizing causes havoc.
Reading other posts in the forum it seems Qt AudioOutput is a dead end road. Not to be used.
https://forum.qt.io/topic/40026/real-time-audio-processing-with-qt5-general-conceptIs this true? What is the point of adding this feature if it works that badly?
Hi @Audetto,
The category of the QAudioOutput seems to change a bit ("game" vs other), but in all cases resizing causes havoc.
It has been like that on Windows for years. Click on the title bar of a Window, and it stops refreshing its contents. I didn't know that Linux now copies this "feature". Probably your use case is one of the few where a second thread for the audio processing really makes sense.
Disclaimer: I have not done that so I can't tell you much about this topic.
Regards
-
-
Using the 2nd thread is a good suggestion, but the documentation does not say anything about this being valid or not and all the question I saw about this went unanswered
-
the difference between push and pull is not explained very well I believe. I read the code for the pulseaudio case and I have understood that the only difference is who owns the timer.
In pull mode, the AudioOutput owns the timer and will call you to get the data. In push mode your application will require a timer (if one is not already present) and will do exactly the same, ie write the data.
-
