[SOLVED] QAudioProbe in Windows is using too much memory

oh3netid

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

JKSH

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?

oh3netid

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?

JKSH

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?

oh3netid

"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?

oh3netid

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.

JKSH

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)

andre

[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.

oh3netid

[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.

oh3netid

[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 :)

oh3netid

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!

JKSH

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?

oh3netid

Done! Thanks.