[SOLVED] QAudioProbe in Windows is using too much memory
-
Hello,
In Windows, whenever I attach an audio probe to a QMediaPlayer my memory usage (as reported in Task Manager) starts to look like a stopwatch (ever increasing). Here is a simple example that shows what I mean.
@
QMediaPlayer *playerA = new QMediaPlayer(this);
playerA->setMedia(QUrl_to_my.mp3);QAudioProbe *probe = new QAudioProbe(this); probe->setSource(playerA); playerA->play();
@
When executed, the app continuously consumes memory unless I comment out the probe. I noticed in the AudioRecorder example that the memory usage remains stable. Also, the above doesn't have excess memory consumption when run in OSX. Could this be a bug with the Windows implementation of QAudioProbe when set to a QMediaPlayer source?
After 3 hours, the memory usage is so bad that my app crashes. Is there anyway to force the probe to free up the memory? I have already tried deleteLater and delete, then recreating the probe but that didn't do anything. Can anyone suggest any alternatives or workarounds?
Thanks,
-Will -
Hi,
That sounds like a memory leak bug in the Windows implementation (which means you can't reclaim the memory, unfortunately). Please report it to https://bugreports.qt-project.org/ and attach a minimal, compilable example. There's a good chance to get it fixed in time for Qt 5.3 (which is scheduled to be released in April)
But anyway, how do you extract the data from the QAudioProbe?
-
Thanks for the quick response!
I just filed the bug report as you suggested.In answer to your question, I connect to the audioBufferProbed signal. That part all works so I left it out of the example.
Any ideas for a workaround?
-
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.