memory usage incrementation while playback

memory usage incrementation while playba

Hi,

I’m relatively new to n-track. Anyway, I upgraded from 5.0.1 to the actual 5.0.6.
I now recognize an unusual (hopefully) incrementation of the memory usage when I’m just playing one of my former recorded songs. In the task manager, the memory usage of the n-track process increases round about 100-200kbyte per second while playing! Well, my machine has 2Gig RAM, so it took some minutes, but than n-track tells me, that it is not able to play my song anylonger. Reloading the song helps.
Hmm, is this a normal behaviour?
Anybody out there, who recognized the same?
I’m quite sure, that in my former version I haven’t seen such a behaviour.

Thanks and regards.
mikel

Sounds like a memory leak. Flavio fixed some big ones that happened while editing a few builds. This may be something new. While buffers are allocated and filled while playing there shouldn’t be a constant rise in memory usage while playing after a few seconds.

Thanks phoo,
but that’s exactly, what happens. Continuesly increasing memory until the system says “Thats it!” :slight_smile: . Any idea, what I should do/test/adjust ?

Yep…file a bug report with Flavio. You shouldn’t have to do anything to workaround something like that. :)

Other than that, try resetting your preferences to the defaults (there’s a button in the preferences to do this) to start over once just in case there’s something funny happening there. Occasionally, the settings can go flewey and cause odd problems when upgrading. Then set them back to where you want them, remembering anything that was changed that might trigger the leak…if resetting the preference got rid of it.

Quote (mikelm @ Mar. 21 2007,12:03)
Hi,

I’m relatively new to n-track. Anyway, I upgraded from 5.0.1 to the actual 5.0.6.
I now recognize an unusual (hopefully) incrementation of the memory usage when I’m just playing one of my former recorded songs. In the task manager, the memory usage of the n-track process increases round about 100-200kbyte per second while playing! Well, my machine has 2Gig RAM, so it took some minutes, but than n-track tells me, that it is not able to play my song anylonger. Reloading the song helps.
Hmm, is this a normal behaviour?
Anybody out there, who recognized the same?
I’m quite sure, that in my former version I haven’t seen such a behaviour.

Thanks and regards.
mikel

How are you exactly measuring the memory usage of the n-Track process? It sounds like you’re measuring the ‘working set’ parameter, which is not directly related to memory usage as it basically represent the portion of physical memory that the program is using, and there may be other portions of allocated memory that have been swapped to the virtual memory on disk (i.e. the paging file).
The big decrease in the memory usage that you measured when you minimize the program is probably caused by Windows thinking that the minimized program is not being actively used and its memory gets saved to the paging file.
You can try using “Process explorer” from
http://www.microsoft.com/technet…er.mspx

which lets you watch many memory usage parameters, including “working set” and “private bytes”, which as far as I know is the closest thing to the actual allocated memory of a process and is the thing to monitor in detecting memory leaks.

I was able to reproduce the ~150 kb increase in “private bytes” usage during playback with the Navigator window open. That’s not a memory leak as the Navigator window uses .Net managed memory. The memory will eventually be freed by the garbage collector when there’s an actual need for it.

If the leak occurs on your system without the Navigator window open, does it occur with a specific song or even with a simple 1 track song created from scratch?

You mentioned that after a while the program refuses to play the song. What is the exact text of the error message you get?

Also try to see if the problem occurs after restoring the program’s default settings with the ‘Revert preferences to default settings’ button in the Preferences dialog box.

Flavio

Thanks for the very fast response :)! And sorry for my late repsonse :(

I measured the memory usage through the process list in the Task Manager.
I tried your advise to use the ProcessExplorer. Much more information there and you were right: seems to be the “working set” the process list is displaying.
As I said before, my concern is regarding the ~150kb increase, and !!! it is related to the navigator window !!! As soon the navigator window is closed or not visible, because partial overlays by another window, the increment stops. ( By the way, the navigator window is a very use full thing !)

The “leak” occurs only, if the navigator window is visible, regardless which song is playing ( 1 track, many tracks, … it doesn’t matter)
The error message which comes up aftere a while looks like :
<!–QuoteBegin>

Quote

Window Title : Out of resources
n-Track has detected that the computer isn’t able to handle the current number of tracks and DSP effects. The playback has been halted in order to avoid possible locks up.
To prevent this message from appearing again in you may:
- Increase the playback buffering(in the Prferences/Recording settings dialog box)
- Decrease the number of tracks or effects
- You may want to do a partial rendering (i.e. mixdown) of some track so to use a single wave file in place of the original tracks.
You can make the detection of this ‘out of resources’ condition less sensitive increasing the “maximum tolerated number of buffer underruns” value in the Preferences/Options dialog box.
Select Cancel if don’t want this message to appear again.

I revert the preferences settings, but the “leak” was still there.
Hmm, you’ve said, that the navigator window uses .Net managed memory. It seems, that .Net doesn’t release the memory, unless the window is invisible.
Hmm, it’s not clear to me, why there is a continuously increasing memory usage.

Thanks a lot so far and I already have a workaround: not using the navigator window. I’d like to know, if I’m the only one, who have this behaviour.

Kind regards.
Michael