Hello everyone! Long time user, first time poster etc etc...
I'm experiencing performance issues with the MT-32 emulation in ScummVM - crackling and scratching noises with the sound. I always thought it was because my old dual G4 simply didn't have the horses. So I used my real MT-32 with a USB midi i/f and all was well.
Now I've finally taken the plunge and bought a shiny shiny Macbook Pro. But the problem is still there - it's better, but it's still not listenable to.
To see if it was the OSX port, I fired up VMWare and ran the XP version. Perfect. And that's only allowed a single core! So are there any known issues with the embedded MUNT in ScummVM for OSX?
Cheers!
OS X, built in MT-32 emulation - Poor performance?
Moderator: ScummVM Team
As far as I can, the main problem is CoreAudio -- it reacts extremely sensitive to sound latency. And client code like ours is expected to implement double buffering to avoid that. For high-end ultra-expensive audio software, this might be the right thing to do, but for client code like ScummVM (and SDL in general), this is very annoying.
For the SDL CD playback code, I implemented double buffering, else it would have the same problems. Back then I was considering extending SDL for Mac OS X with generic audio double buffering, but in the end we decided against this, since while it helps portably apps, it would have had to be possible to turn it off, because it might have hurt other apps a lot (e.g. apps which already implement some kind of double buffering etc.).
Note: I *believe* that this is the cause for the MT-32 badness under Mac OS X, and various data seems to support that believe, but I admit that I have not actually tested it. In any case, since apparently nobody is working on the MT-32 emu code these days, there is little to be hoped for here, unless a volunteer turns up to improve it (e.g. by adding double buffering to it, at least as a hack, so that we can verify this is the cause).
For the SDL CD playback code, I implemented double buffering, else it would have the same problems. Back then I was considering extending SDL for Mac OS X with generic audio double buffering, but in the end we decided against this, since while it helps portably apps, it would have had to be possible to turn it off, because it might have hurt other apps a lot (e.g. apps which already implement some kind of double buffering etc.).
Note: I *believe* that this is the cause for the MT-32 badness under Mac OS X, and various data seems to support that believe, but I admit that I have not actually tested it. In any case, since apparently nobody is working on the MT-32 emu code these days, there is little to be hoped for here, unless a volunteer turns up to improve it (e.g. by adding double buffering to it, at least as a hack, so that we can verify this is the cause).
- I guess it's the real thing or nothing!See this thread: http://forums.scummvm.org/viewtopic.php?t=462
Yes, the machine is fast enough. The reason it works on Windows but not under Mac OS X is that the audio APIs of the two systems are fundamentally different, and SDL does not sufficiently abstract away this difference (and probably for good reasons, too, but that is totally off-topic here).
Yes, the machine is fast enough. The reason it works on Windows but not under Mac OS X is that the audio APIs of the two systems are fundamentally different, and SDL does not sufficiently abstract away this difference (and probably for good reasons, too, but that is totally off-topic here).
