I have a Long variable that i use as a handle to the current background soung (.mid) in a game i’m making. The problem is, everytime i try to change the sound, the amount of memory the game takes up jumps.
Public Sub PlayBGSound(filename As String)
‘Free the current song
‘Load new song
hBGMusic = FMUSIC_LoadSong(App.Path & filename)
What’s wrong with this?
- jmiller asked 15 years ago
Dim x As Long
Private Sub Command1_Click()
x = FMUSIC_LoadSong(“SomeMidiName”)
Private Sub Form_Load()
FSOUND_Init 44100, 32, 0
Private Sub Form_Unload(Cancel As Integer)
This is using version 3.62. Compile it into an exe, and then run it. If you click on the command button you’ll notice that the memory usage keeps going up. The memory is freed at the end, but like i said, having a simple program like this take up 40mb is a little unnerving.
I tried a conversion of your code to Delphi and it worked fine. No growing memory usage. It went up on the first call to FMUSIC_LoadSong, but then it stayed fairly steady after that no matter how many times I pressed the button.
procedure TForm1.FormCreate(Sender: TObject);
FSOUND_Init(44100, 32, 0);
procedure TForm1.FormClose(Sender: TObject; var Action: TCloseAction);
procedure TForm1.Button1Click(Sender: TObject);
FMusic := FMUSIC_LoadSong(’D:\Delphi\fmodapi362win32\media\canyon.mid’);
That’s Windows’ lazy paging system, not FMOD. Windows isn’t like DOS; it doesn’t actually free memory the minute you tell it to. When it feels like it (or is in dire need of more RAM), then your memory usage will drop. This will likely happen in any application that allocates memory, unless the application was specifically designed to FORCE Windows to free the memory (if that’s even possible).
Also remember that both MCI and DirectShow cache MIDIs, so even when FMOD has freed the module, it still exists in the DShow buffer.
Nothing wrong with your code that I can see–as long as you’re calling FreeSong before loading another one, there’s no need to worry. To test my theory, call your sub with the same MIDI that’s currently loaded and tell me if your memory usage goes up that way. If it doesn’t go up drastically from freeing and then loading the same MIDI, then there’s no leak. Like I said, DirectMusic caches MIDIs, so even if FMOD has freed the memory used by the file, Windows is likely still holding its contents. I think DMusic holds about 8 MIDIs in its cache.
the memory jump seems to be a little to drastic to be the result of cached midis. i wrote a separate program that just frees a song and then loads a new one into the same handle, and it jumps by about 800K each time. i’ve gotten this barebones program up to 40 or 50 mb. I’m not sure its really a good thing to have this happening, even if its not a memory leak.
Hmmm, I tested MIDI support with my ST series MIDI player (the ST series GAudioBuffer class is a wrapper for FMOD) and no memory leak. The miniplayer stays around 11MB, give or take depending on the MIDI currently loaded. When I load another MIDI, the memory usage drops to around 9MB for a split second, then goes back up to around 11MB again after the new MIDI is loaded. It’s never gone past 12MB, no matter how many MIDIs I’ve loaded and freed.
I’m testing with the latest version of FMOD 3.62. What version of FMOD you have?
Please login first to submit.