0
0

Greetings.

I am trying to play a MIDI file on the OS X port. I find that if I copy the gm.dls file exactly from Windows, I can point Fmod to it, and it works. However, if I point it instead at the gs_instruments.dls file that ships with OS X, it crashes.

Is there something incompatible about this OS X-native file? I can’t use the gm.dls file from Windows, since there are copyright issues associated with it. How else can I obtain a legitimate dls file that I can use on OS X?

Many thanks,
David

  • You must to post comments
0
0

And midi’s being cut off at the END?
Brett already said this was solved though…Just to let other people know :)

-Stenny

  • You must to post comments
0
0

No specific bug fix was done for the issue of MIDI being cut off at the end, the 3 fixes so far were as I outlined in my last post in this thread, the cutoff issue may have been resolved by my 3rd mentioned fix though.

I haven’t encountered a case where a MIDI is cut off at the end, if you could send a MIDI file to support@fmod.org or post a link here to a file that you know gets cut off at the end I can make sure it’s working correctly.

  • You must to post comments
0
0

Hi,

I just tried playing a midi on Mac OSX as well as Win32 using the gs_instruments.dls file and it works fine without any crashes.

I’m not sure why your version would be crashing. What version OS X are you using? Perhaps the gs_instruments file is different or something. Try using the gs_instruments.dls from OS X in win32 and see if that works.

  • You must to post comments
0
0

I will. I’m currently at my dads (while my computers at my mum’s), so I’ll probably send it Monday :)

-Stenny

  • You must to post comments
0
0

I am using OSX 10.4.8. The gs_instruments.dls file on that version has the following md5 hash:
[code:2a078ft0]MD5 (/System/Library/Components/CoreAudio.component/Contents/Resources/gs_instruments.dls) = 94660977369dd6298a16802f9ac3436a[/code:2a078ft0]
How does this compare with the md5 hash on your version?

I have verified that the crash also occurs on Linux when I copy the gs_instruments.dls file there. (For some reason, I am not able to test this on my Windows box. In fact, I am not able to run MIDI files at all on Windows–it always returns FMOD_ERR_PLUGIN_RESOURCE, even though I’m certain I have set the correct path to the dls file, either dls file. I even get this when I leave the path unspecified, which I though was supposed to work on Windows. But that appears to be a different, unrelated problem.)

Anyway, although it’s copyrighted by Apple, surely it falls within fair use for me to send a copy of my gls_instruments.dls file to you to help discover the source of the crash. Let me know if you need me to do this, and I’ll PM you a link.

Thanks!

David

  • You must to post comments
0
0

Any progress on this?

Thanks,
David

  • You must to post comments
0
0

Hi,

Looks like my gs_instruments.dls has the same md5 hash:

MD5 (/System/Library/Components/CoreAudio.component/Contents/Resources/gs_instruments.dls) = 94660977369dd6298a16802f9ac3436a

so i’m not sure why yours is crashing.

Perhaps you can send a repro to support@fmod.org and I can take a closer look at it.

  • You must to post comments
0
0

Same behavior here with different files, on OSX 10.4.8 and gs_instruments.dls; the application always crash in the same position for the same file, but in different position for different file.

  • You must to post comments
0
0

Same problem on Mac OS X 10.4.9 with FMOD 4.06.16.

For Example: Back_In_Black.mid from http://rock.mididb.com/acdc/ hangs after ~12 seconds.

:roll:

  • You must to post comments
0
0

So I tried getting MIDI to work today, and just a few minutes ago, it worked.

First, it is important to note that MIDI does not work (at least, not on Mac) without using the FMOD_CREATESOUNDEXINFO structure. I set the dlsname and the suggestedsoundtype, you might be able to get away with just setting the dlsname, otherwise you get an unsupported file format error (it would have been nice if it had been a "missing resource" or something more specific).

Second (and the reason I posted to this thread) is that I, too, was getting crashers. But for me, it crashed regardless of whether I used the instruments from Mac or Windows. The stack trace looked like this (ymmv):

(gdb) where

0 0x30000000 in ?? ()

Cannot access memory at address 0x30000000
Cannot access memory at address 0x30000000
Cannot access memory at address 0x30000000
Cannot access memory at address 0x30000000
Cannot access memory at address 0x30000000
Cannot access memory at address 0x30000000

1 0x00540638 in FMOD::DSP::getUserData ()

Cannot access memory at address 0x30000000
Cannot access memory at address 0x30000000
Cannot access memory at address 0x30000000
Cannot access memory at address 0x30000000
Cannot access memory at address 0x30000000

2 0x0053d920 in FMOD::DSP::getUserData ()

Cannot access memory at address 0x30000000

3 0x00554c88 in FMOD::SystemI::createSoundInternal ()

4 0x00559e0c in FMOD::SystemI::SystemI ()

5 0x00552860 in FMOD::System::createSound ()

Clearly, address 0x30000000 is bogus, but where did it come from? As it turns out, the issue is that I was creating my FMOD_CREATESOUNDEXINFO on the stack, and it was getting corrupted:

$3 = {
cbsize = 92,
length = 3221223120,
fileoffset = 206816,
numchannels = -1073744048,
defaultfrequency = 603980324,
format = 207176,
decodebuffersize = 207228,
initialsubsound = -1073744048,
numsubsounds = 35619248,
inclusionlist = 0xbffff720,
inclusionlistnum = 34641776,
pcmreadcallback = 0x71376ec,
pcmsetposcallback = 0xbffff708,
nonblockcallback = 0,
dlsname = 0x57cb0 "/System/Library/Components/CoreAudio.component/Contents/Resources/gs_instruments.dls",
encryptionkey = 0xa0001fac "",
maxpolyphony = 1,
userdata = 0x712f85c,
suggestedsoundtype = FMOD_SOUND_TYPE_MIDI,
useropen = 0x30000001,
userclose = 0x1,
userread = 0x712494c,
userseek = 0x712f85c
}

If I create it as a static variable (which I can get away with, given the way I wrote the code), it loads fine.

I have no idea if this will solve all the other crashes mentioned in this thread, but it solved mine. Hopefully it will help someone.

  • You must to post comments
0
0

Quick followup: even with the stack corruption workaround in place, FMOD still crashes on most MIDI’s when using the gs_instruments – in my testing, it can play canyon.mid ok and that’s about it. The only way I’ve found to get reliable MIDI playback is to use the gm.dls from Windows, which isn’t a viable solution due to licensing, and effectively limits MIDI to Windows regardless of the software synth supposedly being cross-platform. Which is too bad, since I was hoping to use MIDI to keep file sizes down.

  • You must to post comments
0
0

Hey guys, I have taken a good look at the MIDI playback both on Windows and MacOSX and put 3 fixes into the next release.

  1. The sound quality when using the Mac DLS file was pretty poor, this has been improved.

  2. The crash with "back in black.mid" at ~12 seconds has been identified and fixed. You can now play all the way through that file with no problems.

  3. There was an issue with notes playing late and getting bunched up when first starting playback, this has also been fixed.

Currently you need to use FMOD_CREATESOUNDEXINFO to specify the DLS file on MacOSX, I will have a look at putting a default in for the gs_instruments.dls file tomorrow, that should make things simple on Mac.

All of this should be available in the next release, I can’t give any specific details as to when that will be at this stage though.

  • You must to post comments
Showing 12 results
Your Answer

Please first to submit.