Core Audio vs. MT32 Emu on a MAC

[Nagra]

Hi folks,

I am a MAC OSX user and just tested MI2 with "Core Audio" + "Mixed Adlib Midi Mode".

The music sounds absolutely superior, if not better than years ago with my original LAPC-I soundcard!!!

I am beginning to think, that the core audio option provides almost the same quality than the roland mt32 emu.


I tested the roland emu as well (yes, with the two rom-files). But I was very dissapointed with it: The music plays like in slowmotion and there are strange "disturbing" noises all the time.

The readme told me that I need a fast computer for the emu-mode. I have a Powermac G4, with 1.25 Ghz and 1.25 GB of RAM. No other Apps are running while executing SCUMMVM. So, what kind of a Mac do I need for a proper Roland MT32-emu - a G5 QUAD?

Nagra

[sev]

It sucks 1-1.5GHz of raw x86 power. And that's not just x86 but either MMX or 3dNow! instructions set. I.e. if somebody would write Altivec routines, it may run on your Mac.


Eugene

[Jimbob]

Hi folks,

I am a MAC OSX user and just tested MI2 with "Core Audio" + "Mixed Adlib Midi Mode".

The music sounds absolutely superior, if not better than years ago with my original LAPC-I soundcard!!!

I am beginning to think, that the core audio option provides almost the same quality than the roland mt32 emu.


I tested the roland emu as well (yes, with the two rom-files). But I was very dissapointed with it: The music plays like in slowmotion and there are strange "disturbing" noises all the time.

The readme told me that I need a fast computer for the emu-mode. I have a Powermac G4, with 1.25 Ghz and 1.25 GB of RAM. No other Apps are running while executing SCUMMVM. So, what kind of a Mac do I need for a proper Roland MT32-emu - a G5 QUAD?

Nagra

I can also tell you that the Fluidsynth driver (after I finally got Fluidsynth to compile correctly on OS X) also sounds pretty awful using freeware SoundFont collections that I've tried. In my case it's probably down to the speed of my machine, a wee 900MHz iBook G3

Jimbob

[eriktorbjorn]

I can also tell you that the Fluidsynth driver (after I finally got Fluidsynth to compile correctly on OS X) also sounds pretty awful using freeware SoundFont collections that I've tried. In my case it's probably down to the speed of my machine, a wee 900MHz iBook G3

FluidSynth works much of the time on my 450 MHz PIII, and doesn't sound that different to me from my soundcard using the same SoundFont. But I'm still glad I don't have to use it.

One problem is that the default output level was almost inaudible for me, so I hard-coded a "gain" factor which is probably too loud in some cases. I did submit a patch to make the gain factor customizable, but so far there haven't been any feedback.

[Jimbob]

I can also tell you that the Fluidsynth driver (after I finally got Fluidsynth to compile correctly on OS X) also sounds pretty awful using freeware SoundFont collections that I've tried. In my case it's probably down to the speed of my machine, a wee 900MHz iBook G3

FluidSynth works much of the time on my 450 MHz PIII, and doesn't sound that different to me from my soundcard using the same SoundFont. But I'm still glad I don't have to use it.

One problem is that the default output level was almost inaudible for me, so I hard-coded a "gain" factor which is probably too loud in some cases. I did submit a patch to make the gain factor customizable, but so far there haven't been any feedback.

Interesting, maybe I'll go back and try a few different configs. I think part of the problem is probably the SoundFonts I'm using and from memory it was a bit loud, so maybe I'll take a look at the patch.

Jimbob

[Jimbob]

One problem is that the default output level was almost inaudible for me, so I hard-coded a "gain" factor which is probably too loud in some cases. I did submit a patch to make the gain factor customizable, but so far there haven't been any feedback.

I've just tried to apply this patch to the latest daily snapshot and it seems to fail patching one hunk of data, this is the rejected section: -

Code: Select all

***************
*** 411,417 ****
        }
  
        // SoundFont
-       _soundFontButton = addButton(boss, x, yoffset, "SoundFont: ", kChooseSoundFontCmd, 0, ws);
        _soundFont = new StaticTextWidget(boss, x + buttonWidth + 20, yoffset + 3, _w - (x + buttonWidth + 20) - 10, kLineHeight, "None", kTextAlignLeft, ws);
        yoffset += buttonHeight + 2 * spacing;
  
--- 429,435 ----
        }
  
        // SoundFont
+       _soundFontButton = addButton(boss, x, yoffset, "SoundFont:", kChooseSoundFontCmd, 0, ws);
        _soundFont = new StaticTextWidget(boss, x + buttonWidth + 20, yoffset + 3, _w - (x + buttonWidth + 20) - 10, kLineHeight, "None", kTextAlignLeft, ws);
        yoffset += buttonHeight + 2 * spacing;
  

Now I've looked at the patch file to try and fix it but I've failed to solve the problem. I don't fully understand how the diff file works. I think it may be related to incorrect line numbers. Any ideas how I can fix the .diff file? Even though it fails to full patch the options.cpp file it seems to compile fine with the gain bar included in the GUI, I'm not sure whether it actually works or not though - I'm still trying different soundfont libraries.

Jimbob

[sev]

I don't fully understand how the diff file works.

Use patch utility:

patch < file.diff

Then watch for *.rej files which could contain rejected patch chunks when lines to be patched were modified. Then you should apply those chunks manually with text editor.


Eugene

[Jimbob]

I don't fully understand how the diff file works.

Use patch utility:

patch < file.diff

Then watch for *.rej files which could contain rejected patch chunks when lines to be patched were modified. Then you should apply those chunks manually with text editor.


Eugene

This is what I'm doing but when I try to determine where the rejected output should go I get a bit confused and I don't know exactly where it should go. I'm trying to work backwards from viewing the original options.cpp file but it still not 100% clear what goes where. It's probably me being a bit of a dunce!!!


Jimbob

[eriktorbjorn]

I've just tried to apply this patch to the latest daily snapshot and it seems to fail patching one hunk of data, this is the rejected section: -

That part of the patch was just a cosmetic change: removing a space after "SoundFont:" to keep the text from being truncated in the small version of the GUI. I made that change on its own some time after making the patch, I believe, so it should be perfectly safe to ignore it.

[Jimbob]

I've just tried to apply this patch to the latest daily snapshot and it seems to fail patching one hunk of data, this is the rejected section: -

That part of the patch was just a cosmetic change: removing a space after "SoundFont:" to keep the text from being truncated in the small version of the GUI. I made that change on its own some time after making the patch, I believe, so it should be perfectly safe to ignore it.

Ah, OK ... maybe that's the reason it compiled fine!

Cheers,

Jimbob

[Nagra]

Interesting Stuff but please let´s get back to what I was asking for.


So, what about the MT32-emu compared to Core-Audio under Mac OSX?

Yesterday I tested the Core-Audio and Mixed-Adlib-Midi-Mode with Indy4 Non-Talkie. I have a very strong feeling that it sounded exactly like 12 years ago with the LAPC-I roland-card.

Am I right with this assumption? If so, MAC users wouldn´t need the mt32-emu, would they?

Thanks, Nagra

[Jimbob]

Interesting Stuff but please let´s get back to what I was asking for.

Yes, sorry about that.

So, what about the MT32-emu compared to Core-Audio under Mac OSX?

Yesterday I tested the Core-Audio and Mixed-Adlib-Midi-Mode with Indy4 Non-Talkie. I have a very strong feeling that it sounded exactly like 12 years ago with the LAPC-I roland-card.

Am I right with this assumption? If so, MAC users wouldn´t need the mt32-emu, would they?

Thanks, Nagra

As sev mentioned, the MT-32 emu needs a fast computer to work correctly with x86. With no Altivec routines / optimisations the Mac version is going to suffer badly. So to answer your original question a nice fast G5 may be able to cope with the MT-32 option. Things may get a bit better with the switch to Intel but this is only a guess!

Currently I've found the CoreAudio or the Quicktime sound drivers to be the better options for MacOS X. So far I've been unable to get anything decent from the MT-32 or the Fluidsynth drivers but this is probably due to the speed of my machine.

Jimbob

[sev]

Yesterday I tested the Core-Audio and Mixed-Adlib-Midi-Mode with Indy4 Non-Talkie. I have a very strong feeling that it sounded exactly like 12 years ago with the LAPC-I roland-card.

No, it couldn't be so. First. Since you specified an usual MIDI device, ScummVM remapped some MT-32 instruments for you. MT-32 is not a General MIDI, so it has to be remapped. Second, MT-32 is more than a usual MIDI device. It's power is in patching, i.e. creating completely new instruments, and it does that on-the-fly. There is just no analogs in MIDI for that, you will need to create different instruments for each patch and modify MIDI messages so they will use those new instruments.

Just for your comarison, here are several MI tunes pre-recorded from a real MT-32:

http://www.crossfire-designs.de/downloa ... island.ogg
http://www.crossfire-designs.de/downloa ... sland2.ogg

I also recommend to read this whole great article.


Eugene

[Nagra]

Ok, then there must be a difference. But I still believe that it sounds almost like my internal roland card years ago

Two days ago I got a real MT32 on ebay. Should arrive here within the next week. After successfully connecting it to my MAC and several test I will post the results.

Thanks
Nagra

[fingolfin]

Yeah, right. You could have saved that money by just asking the right persons ...

I am the Mac OS X maintainer of ScummVM, and wrote large parts of the current CoreAudio driver. I also have an MT-32.

The CoreAudio output sounds very differently from the real MT-32.
The MT-32 won't work with ScummVM, unless you enabled a certain hack in the ScummVM source code, recompile it, and then do the right things in the Apple MIDI setup. So, unless you want the MT-32 just to rip the ROMs, it won't be of any use to you for now, I am afraid.

Finally, the MT-32 emu sucks up large amounts of CPU power. It's barely usabel on my 1.5Ghz G4, with all optimisations one; and 'barely' means that often it still produce stutters etc. Unless somebody optimizes it (e.g. by providing mac specific implementations of certain core routines), this won't change.