eating memory

n-track 4.1.6

I was having a problem with n-track 4.1.6 being a bit sluggish, so I decided to see what it was doing to the memory on my machine. I have a simple 2 track song and EVERY time I play the song I lose about 20 meg of ram. Not even recording!!! Stopping the playback does not get me back to where I started memory-wise. So needless to say, after an hour or two of working on the song, recording, playing back, jamming on the track, my machine is down 200-300+ meg of RAM. There is a VERY serious memory leak in this program. Can I swap my registration for a 3.x verison of n-track, please???

I could be wrong but I think you can use newer codes for older versions, but not vice versa.

Although what your describing sounds like a trojan, or virus at work, they are memory eaters, and using Ntrack might be stimulating there appetite!

keep shinin’

jerm :cool:

The codes are not backwards compatible but Flavio has given V3 codes to V4 owners.

I deal with a lot of memory leaks in software and I suspect that if n-track did have a memory leak then we would all be seeing it - especially one of that magnitude.

Taking n-track out of the equation my guess would be a driver problem. I suggest you check for updated soundcard drivers.

What soundcard are you using, and what version of n-track?

Eyup!

I am pretty new to the .NET stuff, but isn’t it supposed to be immune to these kind of problems.
Does it not allocate and reclaim memory on-the-fly automatically?

Steve

I am running he 4.1.6 version of n-track.
I have a Creative SB Live card, with the latest drivers installed.

I am just watching n-track in the task manager, no wondering where my memory went, I can see where is is going, n-track is eating it up. Has anyone else ever watched the memory that n-track uses? Just because no one else has ever noticed it, does not mean that it is not happening. Check it out, someone please tell me that when they monitor the memory usage of n-track that all of the memory is reclaimed after you hit the stop button, because it is not on my machine. Not even all of the memory, but I am telling you after an hour or two, I am missing a TON of memory. I am actually a software developer and I have been for years, I COULD bust out some tools to see exactly what is going on, but I would rather spend my time with music, I do enough work at work.

<!–QuoteBegin>

Quote
I am running he 4.1.6 version of n-track.



Ahhh, I guess most of us are probably still using earlier versions for “real” work. Perhaps you’ve found a bug. Can you use your Programmer skill to do some tests to find out when/why/when/how - that should help Flavio track it down. If I get a chance I’ll have a look later too.


Mark

I’m using 4.1.6. build 2062.
When I play two tracks and hit stop all used extra memory is returned to system. No leak there. Are you using any plugins?

When I summoned the about-screen to get the build # though, I noticed that this claims ~700k of memory that is NOT being returned when I close the about-screen.
Trying again claims another 700k that’s not being returned, etc. etc.
So, while not likely to cause any serious problems, this IS a real memory leak.
Maybe more of these exist.
Let’s all keep an eye on it.

I wasn’t able to reproduce the 20 Mb memory leak when starting and stopping playback. Perhaps it is related to a particular combination of song settings, plug-ins or soundcard drivers.
If you have registered version 4.x and want to use version 3.x instead, send me an email and I’ll send you the 3.x registration codes.

The about box is a .Net window and its memory is managed by .Net (most of the other parts of the program are not managed by .Net, including the audio streaming and processing parts). I did a test and created and detroyed the windows repeatedly (hundreds of times) and the memory was freed (garbage collected) all at once when the memory usage of the program reached 195 Mb. After that the memory went back to ~30 Mb. So this is not technoically a memory leak, it’s just that the garbage collector delays freeing memory as long as possible, until the memory is needed for other things.
The next version of the program will force the recollection of memory when the about box is closed.

Flavio.



I wasn’t able to repro the leak either, in a way that pointed to n-Tracks, at least not yet. I was using PerfMon (it’s installed with Windows) to show memory usage for the ntrack.exe process. My machine has 1 gig of RAM.

(1) I created a new song with one wave track and no plug-ins. I started and stopped it hundreds of times. There was no memory leak at all. When the master EQ window was open there was a bit more memory used when the spectrum analyzer created the display, but memory used went away when the window was closed and it didn’t ramp up.

(2) I used an existing full song. When the song is opened it uses pretty close to 200 megs after one playback. Further playbacks seems to show a leak of 2 megs per play. That’s an obvious leak somewhere - maybe. While this seems to be a leak it does peak and level off at about 240 megs. A true leak wouldn’t level off. This project has many plug-ins and 20 something tracks.

I plan on removing the plug-ins one at a time to see if the 2 meg ramp up goes away with any of them, or changes in some way. At this point I don’t know if it’s a plug-in or something else. My guess is that it is a plug-in but who knows? Anyway, since there appears to be an upper limit this could be something related to .NET, but I don’t think that’s possible with simple playback and not using any of the parts on n-Tracks that use .NET that I know of.

What Flavio says backs up what I’ve seen so far. .NET will make apps appear to be leaking by holding off on garbage collection. Even forcing garbage collection doesn’t guarantee the freed memory will be returned when you think it will be, or should be.

I know there was a bug in Creative’s Live drivers a few years ago where it wasn’t releasing hardware buffers. After 1000 buffers had been opened hardware buffer creation would and sound would stop. The fix was to exit the app (a game in this case) to force recreation of the output audio device. I can see that if the n-Tracks option to leave devices open may have an affect on memory used if this is happening with the Creative drivers being used. I don’t know the current state of the Live drivers when it comes to this. Since this was years ago I’d hope it was fixed by now. That would be something n-Tracks can’t work around if it’s the case.