[SOLVED] QAudioProbe in Windows is using too much memory
-
Can you post the link to your report here, so that others can watch the issue too?
I'm not aware of any workarounds for this, I'm afraid. If there is a memory leak inside the QAudioProbe code, then there's not much we can do in "external" code, except avoid using QAudioProbe.
What are you using the audio probe for?
-
"Link to bug report":https://bugreports.qt-project.org/browse/QTBUG-36670
Basically, I was using the probe to detect when to crossfade into the next song (since a lot of songs end with periods of silence). Everything was working great except for the memory leak.
After your comment about avoiding the probe, I thought about using QAudioDecoder to pre-calculate all my fade out times. Then I discovered that, not only did it result in the same memory leak, but it also doesn't work under OSX (audio decode not implemented!).
Oy vey.
I don't suppose I could reclaim the memory by moving the audio decoder code into a QThread and then destroying the thread when I get my result. Overly wishful thinking?
-
I don’t suppose I could reclaim the memory by moving the audio decoder code into a QThread and then destroying the thread when I get my result.
And the answer turns out to be no. Out of tricks again. Bleh. Guess I just have to seek a solution outside of Qt.
-
What happens if there is a period of silence in the middle of the track?
Would it be acceptable for now to calculated crossfade time based on mediaPlayer->duration() ? (until the bug is fixed)
-
[quote author="oh3netid" date="1391673014"]I don't suppose I could reclaim the memory by moving the audio decoder code into a QThread and then destroying the thread when I get my result. Overly wishful thinking?[/quote]
No, but the same trick in a separate process might work. Not pretty (in fact: quite hacky), but memory leaks in libs you don't control sometimes require desperate measures.
-
[quote author="JKSH" date="1391681951"]What happens if there is a period of silence in the middle of the track?
Would it be acceptable for now to calculated crossfade time based on mediaPlayer->duration() ? (until the bug is fixed)[/quote]
I only start checking for silence towards the end of the track (last 5 seconds or so). Unfortunately, songs vary in how much silence they tack on the end. The audio probe was perfect for the job. I think I'm going to have to poke around inside the library (we are approaching desperate measures time). Thanks for all the advice.
-
[quote author="Andre" date="1391682865"]
No, but the same trick in a separate process might work. Not pretty (in fact: quite hacky), but memory leaks in libs you don't control sometimes require desperate measures.
[/quote]Thanks for the suggestion. I think I'll try to debug the library before I go the worker process route. In the long run, seems like it would be the same amount of work :)
-
Afterward: In the end, I created a helper app that calculates where in an audio track to fade out at before exiting. The leaked memory is indeed reclaimed on app exit. Any time I play a new track I launch the helper app with QProcess and receive the fadeout time with QTcpSocket. Actually not a very bad solution at all and very easy to revert once the memory leak is taken care of.
Fin!
-
A workaround worthy of http://thedailywtf.com/ ! :-D It's not your fault though.
Anyway, I'm glad to hear you've found a solution. Could you please edit your original post and add "[SOLVED]" to your title?
-
Done! Thanks.