Important: Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct
QAudioOutput hangs when issuing stop() in IdleState.
I wrote a small application which uses the QAudioOutput class which worked perfectly fine on 2 other development computers I used (one was a now defunct Windows 7 machine, the other a temporary Windows 10 replacement machine). Now, I tried to build and run the same application on my new Lenovo P51 laptop running Windows 10, but the app hangs i.e. becomes unresponsive, apparently when issuing the
stop()command while the device is in
IdleState. The debugger does not catch anything, and I need to force the app to terminate. This did not happen on the other 2 machines as it should, since it is perfectly OK to issue
On all 3 machines, I used Qt 5.9.2, and compiled with Visual Studio Community 2015 or 2017. How can I proceed to find the cause to this hang, as the debugger does not trigger any exception and is of no help.
Thanks for any suggestions you may have!
I got a little further by enabling source debugging (by setting the Source and Target paths in the General debugger settings),
and stepping through the code of
. Apparently, it waits indefinitely for a mutex to unlock...
1 QMutexPrivate::wait qmutex_win.cpp 64 0x6ae976ad 2 QBasicMutex::lockInternal qmutex.cpp 575 0x6ae96fa3 3 QBasicMutex::lockInternal qmutex.cpp 492 0x6ae96cf8 4 QMutex::lock qmutex.cpp 230 0x6ae974bd 5 QWasapiAudioOutput::stop qwasapiaudiooutput.cpp 402 0x7ffb9bc2fb15 6 QAudioOutput::stop qaudiooutput.cpp 211 0x7ffb9c931011 7 AudioEngine::setOutputState audioengine.cpp 208 0x7ff62b81186f 8 AudioEngine::setState audioengine.cpp 242 0x7ff62b81241e 9 AudioEngine::qt_static_metacall moc_audioengine.cpp 189 0x7ff62b96117a 10 QMetaObject::activate qobject.cpp 3768 0x6b2c103a 11 QMetaObject::activate qobject.cpp 3629 0x6b2c07a8 12 QAudioOutput::stateChanged moc_qaudiooutput.cpp 152 0x7ffb9c93140a 13 QAudioOutput::qt_static_metacall moc_qaudiooutput.cpp 76 0x7ffb9c930b8e 14 QMetaObject::activate qobject.cpp 3768 0x6b2c103a 15 QMetaObject::activate qobject.cpp 3629 0x6b2c07a8 16 QAbstractAudioOutput::stateChanged moc_qaudiosystem.cpp 245 0x7ffb9c93361d 17 QWasapiAudioOutput::processBuffer qwasapiaudiooutput.cpp 256 0x7ffb9bc3162e 18 QWasapiAudioOutput::qt_static_metacall moc_qwasapiaudiooutput.cpp 76 0x7ffb9bc3d6c3 19 QMetaCallEvent::placeMetaCall qobject.cpp 504 0x6b2ca2c1 20 QObject::event qobject.cpp 1246 0x6b2c2c1f ... <More>
Before going further you should consider updating to 5.9.4. It has just been released.
ting to 5.9.4. It has just been released.
Thanks SGaist! I'll give it a try.
This post is deleted!
Hmm... Installed 5.9.4, and I thought the problem was gone as things seemed to work again.
However, upon the next launch, the same problem re-occured.
It seems that it has something to do with my initial settings. At the first launch, when there is no .ini file and only defaults are used, things seem to be OK. But upon closing it (upon which a new .ini file is saved), and restarting (upon which the app is initialized according to the settings in the .ini file), the app starts to misbehave again.
Apparently something goes wrong there.
I need to dig further.
I isolated the problem in the selection of the audio device. Selecting anything other than
QAudioDeviceInfo::defaultOutputDevice()results in the lockup as described in my 2nd post of this thread.
AudioDeviceInfo::availableDevices(QAudio::AudioOutput)lists two identical names
"Speaker/HP (Realtek High Definition Audio)" "Speaker/HP (Realtek High Definition Audio)"
Since I have only 1 audio device, these two listed must also be equal to the default device. However, using any of these as returned by
AudioDeviceInfo::availableDevices(QAudio::AudioOutput)results in the lockup.
In my .ini file, I used to save the full name of the device, i.e.
Speaker/HP (Realtek High Definition Audio)in my case, and this caused the problem when an existing .ini file was being used by my app. When the .ini file does not exist, and defaults are used (here
QAudioDeviceInfo::defaultOutputDevice()), there were no problems. This explains my findings above about the .ini file.
Did you check in the device manager whether you have an invalid device ?
No invalid devices nor problems are reported in the device manager.