Quick Sign In:  

Forum: Old versions

Topic: **MEMORY LEAK 2 /CPU usage -The "Problem" ** - Page: 1

This part of topic is old and might contain outdated or incorrect information

apopsisdjPRO InfinitySenior staffMember since 2003
Ok, i made some tests too...
What i found is really interesting.
First, i can confirm the "problem"

1. The "problem" affects both: djconsole 1.08 and 2.02(demo)
versions ---> so it is an old problem, NOT ver. 2 related.

2. The "problem" is the SAME "problem" that does not allow
"big" files played without skipping...

3. When i say "big" files here i dont mean 60+ min files...
"Big" file for Vdj .. is every file not loaded in ram,
example : set the max load to 5 min and load a song with 5.01 min ...!!!
Then the "problem" exist ....

Now... The "problem" (description) :
Open Vdj.
Alt+control+del to see Task manager and CPU usage "%"
Load a "normal" file in vdj (a file that loads in memory, lets say 4.30 min in our example-max load set to 5min) -->
During the loading process (3 sec) the CPU usage will jump to 100%, but will relax after this, coming back to a normal 10-20%.
Although, this seems normal because vdj try to load a song as quick as possible using all the cpu power, this can make the
computer temporary unstable, and already i've seen crashes
when loading a song. There must be a cpu % limit.

NOW the REAL "problem" :

Load a "big" file in vdj (..every song >5 min in our case...)
-->The CPU usage will jump to 100% and stays
there even if you don't press play.., even if you don't touch
vdj at all.
The only way to relax the cpu is to load songs in memory.
If any of the 2 players (or both) are playing songs from disk
(even in stop or cue mode) the cpu usage will be 100%.

So if one, load such a song and forget it there whille ...let's say being home ...watching tv, or read this wonderful forum !
the cpu will have hard times.. and the computer will, sooner
or later crash ...
There is an easier way to reproduce the "problem" :
Just set max load to "none".
Then with every song you load and play (no matter its lenght)
cpu usage will always be 100%
I think there must be a warning for the user when he set
the max load to "none" or when he try to load a "big" file , ...something like : "Your cpu will burn... !"
(I'm not kidding... it's serious.)

2 POSSIBLE SOLUTIONS:
1. Fix the "problem" (the best solution), and allow vdj to behave like atomixmp3 (or other dj progs) when a song not loaded in memory (even if this increase latency)
2. Not allow to set the max load to "none" or loading "big" files at all, to avoid the risc of a crush.

#1 solution is the preferable one, will keep both cpu and users
happy ...
#2 let the users accept that vdj is "not designed" to play
songs directly from hard disk, and force them to upgrade memory at last to 1Gb (again not big files as 60+ mixes...)

As you can see this can affect every pc including the most
powerfull. I already tested with AMD 2.6/1gb, P4 / 768mb
Celeron 1.8 / 256 mb before posting the results.
Adding ram is only a partial solution, don't replay saying that.
Just do my tests.

Best regards.

P.S. Maybe you should upgrade my status to : "no licenced but experienced ....or tester" (just kidding - althought i'm already beta tester to other dj programs..)
 

Posted Tue 28 Sep 04 @ 11:13 pm
i tried it out and you right.would be nice if VDJ-Team can change that.
 

Posted Tue 28 Sep 04 @ 11:52 pm
So there you go Jim do you still think this is a hardware problem?Not! its got something to do with a memory leak.If we use short versions of songs there is no problem.
Here is a temporary solution make sure your load setting is
longer than your song.
I wish you were a full version user.APOPSIS
We should not have to dedicate a computer just for vdj.
 

Posted Wed 29 Sep 04 @ 2:44 am
I too noticed this and was kind of shocked that the CPU usage would go to 100% while just LOADING the song!

I don't see a memory 'leak' per say... because the memory used seems to adjust accordingly with the song titles...

However, the larger the file (ie: 128 vs 192) seems to make a difference as well - probably because of the overall file size.

There should be a 'limiter' on the loading of the files that keeps CPU usage below, say, 50-75% so it can prevent crashing.

I would be interested to know if someone with at 3ghz processor is still showing 100% utilization when they load a song (I have a 1.6ghz on my little laptop but will be building/buying a dedicated rack mount system soon).
 

Posted Wed 29 Sep 04 @ 4:46 pm
DJ CyderPRO InfinityModeratorMember since 2003
3.06 cpu still peaking at 100% durring track load

my specs

3.06 p4 800mhz fsb (not prescott)
1024 ram soon to be 2048
dual 300 gb hdds
dual 120gb hdds
dual 80gb hdds
128 mb dual video card
wave terminal 192L
 

Posted Wed 29 Sep 04 @ 8:22 pm
it is not wierd that the cpu uses 100% while loading a song :-|

when a song gets loaded, the mp3 (or other format) gets extracted to straight WAV into the workmemory. the faster your cpu, the faster your song loads.
 

Posted Thu 30 Sep 04 @ 8:49 am
keyonPRO InfinityMember since 2003
i have 2.4 and it always hits 100% on load.

in comparison, even loading 2 songs simultaneously, on pcdj, cpu only goes to 60%. Course, maybe the 2 programs are unfair to compare as vdj i think a much better program. Still, even if djcannonball correct and it a normal thing, it still gets me a little worried when I see the cpu maxxing out at load with vdj.
 

Posted Thu 30 Sep 04 @ 11:37 pm
djjbPRO InfinityMember since 2004
i have something to say about this keyon...
it's already known that vdj is much better than pcdj.
but in my believe, pcdj is much more stable. i used that prog for many years with an old pc (5 years old)and never had a crash. not even a hard time when i used it.
as long as i see this bug....i have a reason for not buying it.

sorry.... it reads like i'm not happy with vdj...but i'm verry happy with it.
and still..every update is a step closer to the top.(where is the top ???)......lol.......
 

Posted Thu 07 Oct 04 @ 3:24 am
I think most of the CPU 100% usage is caused by the song analysis, which gives the nice amplitude display and BPM.. However I can't explain why the song has to be kept uncompressed in the RAM, it should be possible to analyse the the whole song first, then free the memory except for the playing part and decode the mp3 again when playing.
 

Posted Sun 10 Oct 04 @ 5:37 pm
androidi: The song is decompressed not only for analysis, but for many other reasons, such as the effect engine (an effect can request samples from any part of the song), and the fact that you can move to any part of the song instantly (if the song was not decompressed, this could generate a small 'cut' in the song on slower systems).

macourteau
 

Posted Sun 10 Oct 04 @ 6:43 pm
'if the song was not decompressed, this could generate a small 'cut' in the song on slower systems'

If this is true, wouldn't it be a nice feature to have 'decompression' as an option, so people with fast enough computers would benefit from that?
 

Posted Mon 11 Oct 04 @ 12:53 am
There is some process that causes the program to eat up more and more CPU/memory.

==> what we all should do, is open task manager and monitor the amount of memory VDJ uses and CPU utilization. Do this at a live gig (for several hours) and you will see what I saw: It keeps going up and sometimes crashes.

==> I tried an AMD and P4 processor. 256MB and 512MB. It should not need 1GB for a DUAL deck player! fix the code

http://www.virtualdj.com/forum/display.html?topic=6985

WirelessDJ

Not to worry, VDJ will have some tough competition soon that is rock solid stable -- and it is NOT from Visiosonic!
 

Posted Tue 12 Oct 04 @ 2:10 am
DJ CyderPRO InfinityModeratorMember since 2003
whatever louie we heard that a year ago! VDJ is today...not vaporware! I'll believe it when I see it and not a moment sooner.
 

Posted Tue 12 Oct 04 @ 8:46 am
We talked about this so many times.how come we cannot find a solution,seems to me there is defenitly a leak.This happens everynight at work after 2to 3 hrs i have to shut down and rely on back up cd players.
 

Posted Tue 12 Oct 04 @ 3:38 pm
DJ RickPRO InfinityMember since 2003
My home computer is a p-4 1.8 g with only 512 of ram.
My previous laptop (up until July of this year) was an athelon xp 1300 with only 512 of ram.
I just tried on my home computer (max load set to always)
I loaded 2 3 minute songs. During the load, cpu usage went to 100%, as soon as the track was loaded it went back to 16%. There was never a pause or a skip.
Then I loaded up a 30 minute song. The page file usage went up to about 660. Then I loaded a 15 minute song on the other deck while the 30 minutes song was playing. The page file usage went up to 770.
Again, cpu usage maxed at 100% during the load, and went imediately back down where it goes between 4% & 15% while VDJ is playing the track.
Next I loaded a 3:30 minute song where the 30 minute song had been. The page file usage imediately dropped back in the low to mid 400's. Then when I loaded 5:00 minute track into the deck where the 15 minute song had been, the page file dropped again into the low to mid 300's.

Generally the cpu usage fluxuates between 3 & 16-17% while a track is playing.
BUT, the page file size seems to stay pretty consistant depending on the length of the track that's loaded. Example, longer track, more page file. When the longer track is replaced with a shorter track, the page file goes down.
This is not a super computer.
My old laptop was even less of a computer than this one. I used VDJ since well before it was released with the old laptop. I never had to re-boot in the middle of a gig. I use VDJ in bars and clubs 3-4 nights every single week. In fact I had so much faith in the software, that for my bar gigs, I removed the CD players from that console.
I don't know why your machine seems to have problems, but you might want to examine the possibility that it's a problem which is NOT related to this software.
I've let virtualDJ run sometimes for 10-12 hours at a time during the day. Even at the end of that time there is never a problem.
I tell you this not to say that you aren't having problems, but to let you know that for most users, (well for me anyway) VDJ performs as it should without issue. Without a "memory leak".
Good Luck!
:-)

My new laptop is a p-4 3.2g with 1 gig of RAM. I'll have to have a look at it tomorrow night when I'm working and see if the cpu usage and the mem usage are about the same.
 

Posted Tue 12 Oct 04 @ 5:17 pm
My machine is fine Thanks it seems that some of you still dont get it.There is a problem with the memory release.Someone forgot to add it now they have to explore millions of code to find the missing one.Ive been directly to IBM since my notebook is still under warranty.My machine is clean.Ran vdj at service center and after only a few minutes it started eating up the ram but not giving any back.

I spoke to several DJ's and they have the same problem
 

Posted Wed 13 Oct 04 @ 8:22 pm
I've to put myself in line with the users who are expiriencing the same problem.

Even after loading a file, not playing it - the CPU usage is on 100% and stays on that level till I close the program.

Is this really hardware related?

I can't believe it.

Cheers,
Mark
 

Posted Thu 14 Oct 04 @ 7:11 pm
it is NOT hardware related, it is how they wrote VDJ. I am not sure what programming language VDJ was written in. If VDJ was written in C++ then this might help...


The primary tools for detecting memory leaks are the debugger and the CRT debug heap functions. To enable the debug heap functions, include the following statements in your program:

#define _CRTDBG_MAP_ALLOC
#include
#include

The #include statements must be in the order just shown. If you change the order, the functions you will use may not work properly. Including crtdbg.h maps the malloc and free functions to their debug versions, _malloc_dbg and _free_dbg, which keep track of memory allocation and deallocation. This mapping occurs only in a debug build (that is, only when _DEBUG is defined). Release builds use the ordinary malloc and free functions.

The #define statement maps the base versions of the CRT heap functions to the corresponding debug versions. This statement is not required, but without it, the memory leak dump will contain less useful information.

Once you have added the statements just shown, you can dump memory leak information by including the following statement in your program:

_CrtDumpMemoryLeaks();

When you run your program under the debugger, _CrtDumpMemoryLeaks displays memory leak information in the Debug tab of the Output window. The memory leak information looks like this:

Detected memory leaks!
Dumping objects ->
C:PROGRAM FILESVISUAL STUDIOMyProjectsleaktestleaktest.cpp(20) : {18}
normal block at 0x00780E80, 64 bytes long.
Data: < > CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD
Object dump complete.

If you did not use the #define _CRTDBG_MAP_ALLOC statement, the memory leak dump would look like this:

Detected memory leaks!
Dumping objects ->
{18} normal block at 0x00780E80, 64 bytes long.
Data: < > CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD
Object dump complete.

As you can see, _CrtDumpMemoryLeaks gives you much more useful information when _CRTDBG_MAP_ALLOC is defined. Without _CRTDBG_MAP_ALLOC defined, the display shows you:

the memory allocation number (inside the curly braces).
the type of block (normal, client, or CRT).
the memory location in hexadecimal form.
the size of the block in bytes.
the contents of the first 16 bytes (also in hexadecimal).
With _CRTDBG_MAP_ALLOC defined, the display also shows you the file where the leaked memory was allocated. The number in parentheses following the file name (20, in this example) is the line number within the file. If you double-click the output line containing the line number and file name

C:PROGRAM FILESVISUAL STUDIOMyProjectsleaktestleaktest.cpp(20) : {18}
normal block at 0x00780E80, 64 bytes long.

the cursor will jump to the line where the memory is allocated in the source file (in this case, line 20 of leaktest.cpp). Selecting the output line and pressing F4 will have the same effect.

Also, there is a tool called CMemLeak for detecting memory leaks in C programs. It does not replace and is not as good as the commercially available tools. However, it is free and can be used in any environment.

Bottom line, it appears that VDJ is using up the memory and not releasing it when done with it.

WirelessDJ

 

Posted Thu 14 Oct 04 @ 11:29 pm
I rest my case your honor....Thank you gentlemen
Again tonight at work i had to close 4 times during the night
to release the memory.
Its not all bad 2.04 has not crashed at work yet!

Regards
 

Posted Fri 15 Oct 04 @ 9:14 am
Phenomenas from the twighlight zone...

I found a way to cut down the CPU usage while VDJ is running (which does not mean that this clears up the memory issue).

I configured the preloading of a track to "max load", and suddenly (after loading a track to a desk), the CPU usage is down to 7-20 %.

And I see the blue bar again.

Strange...

Cheers,
Mark
 

Posted Fri 15 Oct 04 @ 5:19 pm
39%