Massive memory leaks in 1.3.5

[DrLex]

I have tried 1.3.5 (or 1.3.4, if I have to believe the Finder) but I had to go back to 1.3.3 immediately. The new version's memory usage is staggering. While the old version was happy with an RSIZE of about 112MB when freshly opened, 1.3.5 eats 417MB to just launch the program. And it gets worse when opening sound files or making recordings. Opening a simple 128KB mono WAV file adds 130MB to the RSIZE, but that's not the end of it. Each time I press the play button, about 70MB vanishes down the drain! 1.3.3 appears to have a similar memory leak when playing, but the amount of leakage is much smaller which makes it less obvious and one can actually do quite a lot of editing before it will crash. 1.3.5 will already crash when opening a large file and playing it a few times. It feels like about every free() or delete call was commented out in this version...
I'm using a MacBook Pro with OS X 10.5.2.

[kozikowski]

I bet I know some of this. The early Audacitys were lean, mean, and fast but would routinely trash people's shows because nobody understood how the program managed resources. I wonder if they got around this by never forgetting or leaving any part of the show resource, clip, snippet, or file unmanaged.

I thought memory leaks where when the program closed gracefully, but didn't release all the memory it used.

Koz

[DrLex]

I bet I know some of this. The early Audacitys were lean, mean, and fast but would routinely trash people's shows because nobody understood how the program managed resources. I wonder if they got around this by never forgetting or leaving any part of the show resource, clip, snippet, or file unmanaged.

I thought memory leaks where when the program closed gracefully, but didn't release all the memory it used.

That may have been the case in old DOS/Windows programs, where application memory was not automatically released when the program exited. In modern operating systems this happens automatically so the term 'memory leak' only applies within a program's runtime.
If a program allocates a chunk of memory and then destroys all references to it without freeing it, that's a memory leak. In its most simple form:
while(1) { char *leak = malloc(10000); }
That memory can never be reclaimed unless a garbage collector is implemented or the program exits/crashes.
I don't see why simply playing a sound would require 70MB that is never freed. Running Audacity in valgrind will probably make it cry a river.

[steve]

That seems very strange, memory usage for Windows and Linux is considerably lower. The only way I can get memory usage much over 20MB is to enable memory audio cache in "Edit > Preferences > Directories"

Where it says "Hold recorded audio in memory until recording is stopped" is not quite accurate - it's not just recorded audio, but all audio data.

It may be worth checking to see if this is set or not - by default it should be not selected (as selecting it requires lots of RAM, which is what you are indicating is the case on your Mac).

[DrLex]

That seems very strange, memory usage for Windows and Linux is considerably lower. The only way I can get memory usage much over 20MB is to enable memory audio cache in "Edit > Preferences > Directories"

Where it says "Hold recorded audio in memory until recording is stopped" is not quite accurate - it's not just recorded audio, but all audio data.

It may be worth checking to see if this is set or not - by default it should be not selected (as selecting it requires lots of RAM, which is what you are indicating is the case on your Mac).

It was not set, but in the meantime I found the culprit: it's "Hear", the successor of OSS 3D. It's a system-wide audio plugin which applies all kinds of digital signal processing to audio output. If I uninstall it, Audacity's memory usage is perfectly sane and I can press "Play" as many times as I want. So the memory leak is probably within Hear itself, and the routine that triggers it is used a lot in Audacity 1.3.5 (not in 1.3.3). If it wasn't for the fact that I can turn cheapo airline headphones into pseudo-Sennheisers with Hear/OSS3D, I would have kicked it out for all the bugs it has...

[Leland]

Hey Doc,

I too see the difference on my machine. It's about 300MB here and I do not have Hear installed. Actually, I did try it, but then removed it to see if there was a difference. Audacity (1.3.5) stayed the same at about 420MB. I will backtrack to see which change has caused this incredible jump!

Will let you know.

Leland

[Leland]

Actually, looks like you were correct. After returning home, I started looking into it and realized that I was back down to around 22MB real, so I'm figuring that Hear still had it's fingers in the mix somewhere. I know I stopped the daemon it starts, so I'm guessing that it updates some system parameter that doesn't get reset when it exists, like maybe some global buffer size thing.

Leland

[ihwtechie]

I'm on a PowerBook G4 running Mac OS X 10.3.9.

I use Audacity primarily to change tempo of a batch of files at a time. I had the same problem with 1.3.2 and now with 1.3.3.

A chain I created reads the MP3 file, changes tempo, and exports it back as an MP3. Audacity eats up memory and temp file space!
It releases both when it quits, but while it is running it makes life miserable for all other programs. And it limits the number of files I can process at a time, so I have to run Audacity several times to do the job.

What's odd is the Activity Monitor shows available memory decrease (and inactive increase) while Audacity is processing the batch of files, but it shows Audacity using a modest amount of memory (real and VM) - about 35-40MB real & 210MB VM. Of course, the available memory zooms back up when Audacity quits.
(I recently added 1GB going to the PowerBook's max 2GB RAM, and Audacity can chew up ther additional 1GB in no time with a few modest-sized podcasts. It takes longer now to use up disk space, but it get around to that, I think, when it maxes out on memory.)

I don't have the cache audio box checked in Preferences.

What is going on? Can I stop it?

I read that some of you went to 1.3.3 from 1.3.5. Why don't you have the problem I have with 1.3.3?

Any help is appreciated.

--- Irwin

[steve]

A chain I created reads the MP3 file, changes tempo, and exports it back as an MP3. Audacity eats up memory and temp file space!
It releases both when it quits, but while it is running it makes life miserable for all other programs. And it limits the number of files I can process at a time, so I have to run Audacity several times to do the job.

I can't comment on the memory issues as it's not a problem that I've noticed on my Linux machine, however regarding disk space, Audacity keeps temporary files for storing not only the current data, but also "undo" data. This is the main reason why many audio applications consume vast amounts of disk space - frequently many times more than the actual size of the file being processed. As you have noticed, Audacity does not clear out the temporary files until the session has been closed, therefore care has to be taken when applying "chains" to batches of files.

It has been suggested that future versions of Audacity may empty the temporary folder on completion of a chain when batch processing, but we will have to wait and see if this idea gets implemented in a future version.