AudioThumbnail is coming across as being unusable with mp3’s via QTAudioReader. High level drawing seems to be fine, but as soon as it drops down to a lower level the app hangs as it loops through AudioThumbnail::getLevels. I’ve noticed that the reader is continually reset to 0 but I haven’t studied the code well enough to understand the significance of that. What I can say is that the other readers don’t seem to do this. At one point when trying to draw a stereo mp3 it managed to suck up all the ram in the machine to the point where my app was at 2.19 GB’s of RAM usage. Normally it runs at about 12 MB’s.
The reader doesn’t actually allocate any memory while it’s reading so if there’s a leak, my guess would be that it’s QuickTime itself that’s leaking. When you zoom in, the reader will be getting continuously hammered to read all the samples, so an mp3 reader isn’t particularly suitable for that, as seeking is very very slow (and the QT one does seem particularly bad at that). You might just want to avoid the problem by not allowing your thumbnail to zoom far enough that it needs to start reading the file directly.
Ok but it has to read the file at some point right? I can create the AudioThumbnail with a sample size of 1 and it will slowly chug away in the background and generate the waveform with no apparent issues from QT. It’s when the thumbnail has to rescan that things go bad.
Yes, I guess that’d work because it just reads it once. The performance hit would happen when it has to repeatedly re-read the same bits of the file every time it draws the waveform.
I’m only calling drawChannel once but I guess it’s reading real time at that point. Maybe a rescan option on the thumbnail would be helpful. If set to false it would just stretch out the cached waveform to fit the zoom level.
Btw…further testing shows that the system memory outage only happens when using a FileInputSource. Directly setting a reader seems to avoid that full out disaster, but it still hangs for a number of seconds and the resulting wave form is flat.
When you give it a fileinputsource, then instead of opening it with juce classes, the filename just gets passed directly to QT for reading, so presumably it’s a leak/bug/whatever inside QT’s own file handling.
(Bear in mind that QT has always been very buggy, and Apple are phasing it out in favour of CoreCodec. To hear about it behaving oddly is no big surprise).
