MT-32 emulator music stutters badly (many if not all games)

[Laylia27]

ScummVM version: 1.10.0git5070-g1351189575 (Sep 28 2017 13:10:49)
OS: Windows 10

Playing games using MT-32 emulation causes severe stuttering of music playback. I've so far confirmed that this happens in Space Quest 3, Indiana Jones and the Fate of Atlantis, Quest for Glory 4, and Space Quest 6. I'm assuming it's the case for all MT-32-supported games.

I did not encounter this problem in stable version 1.9.0.2

[g5ppc]

I believe I can confirm this. I previously had 9/21 daily, and hadn't noticed anything, so it could be there too. But I installed 9/29 daily to check this report, and can confirm slight glitches (stutters) in SCI and SCUMM games using MT-32 emu. I am running Win 7 x64.

[csnover]

Thanks for your report! Daily builds from buildbot are compiled without optimisations, which means they are slower than normal release builds. In the case of the MT-32 emulator, compiler optimisations are critical for performance, so it is not surprising to learn that the MT-32 emulator isn’t able to generate samples in real time in the daily builds.

I’m currently investigating whether enabling optimisations in daily builds makes sense. Optimised compilation is slower and destroys information which can be important when trying to troubleshoot bugs, but at the same time it is unhelpful to be generating builds for users to test which don’t match the release builds.

[g5ppc]

Another test on a Win 8.1 machine showed no problem.

If the cause is CPU throughput, it might be worth increasing the audio output buffer, for the benefit of those with lower CPU power. I know in my case there isn't a lack of overall CPU, but I also realize that increasing the buffer may have downside too. In my case it does seem content sensitive, which could be varying load on the MT-32 emu code on small time scales.

[csnover]

The ScummVM audio buffer size is ​configurable as an advanced preference in ScummVM 1.10 by directly editing the ScummVM configuration file, but the real problem here is simply the lack of optimisations. An increased buffer size only helps if enough samples can be generated faster than real time to offset generation of samples that cannot be generated at real time within the buffering window. Without optimisations, even a 2.3GHz Core i7 cannot always generate samples fast enough to avoid buffer underflows.

[g5ppc]

That's good to know about the buffer.

Could it be that there is a hard-coded CPU time choke or quantum setting that is starving the MT-32 routine of the time it would need? If there is spare CPU, letting the MT-32 have it wouldn't hurt.

In my case, scummvm.exe is reading no higher than 6% in Task Manager while audio breakups can be heard. The graphs don't show any core higher than 20%. I know that isn't a great measuring method, but it looks like a limiter in effect somewhere.

[csnover]

Certainly I would expect to see the core responsible for running the MT-32 emulator reaching 100% periodically since that is the behaviour that I see here (on macOS) during MT-32 emulator drop-outs, but unfortunately I do not know enough about Windows scheduling or how Task Manager does performance sampling to speak with authority on why it appears to be running well below the maximum limit. My guess is that Task Manager’s CPU sampling isn’t granular enough to see the CPU spikes, but I think the best thing to do here is just to test later on Windows with an optimised build and then see if this problem continues to occur or not, and if it does, then to use an actual performance profiler instead of guessing at what Task Manager thinks is happening.

At some point I would really like to move the emulator to its own thread, which would reduce the risk of drop-outs as low as it could probably ever go, but this probably requires some larger discussion and architectural changes to OSystem since the ability to create new threads was removed several years ago and using a timer instead doesn’t really solve the problem.

[Laylia27]

I don't know if this helps: I'm using a PC with an i5-6500 3.20 Ghz quad-core with 16GB of RAM, and I've been in the habit of using snapshots of ScummVM for over a decade (over half a dozen computers) without ever getting audio stutters with the MT-32 emulator. This is the first time I've ever encountered this.

[Laylia27]

"I’m currently investigating whether enabling optimisations in daily builds makes sense. Optimised compilation is slower and destroys information which can be important when trying to troubleshoot bugs, but at the same time it is unhelpful to be generating builds for users to test which don’t match the release builds."

I think it does make sense. 99% of the time I'm using a daily build instead of a stable one.

[g5ppc]

I notice the output rate config seems to have disappeared in the GUI Audio tab between Sep 5 and Sep 29.

On my system that stutters, there is an config file output_rate=44100 line, which I believe I set on prior versions in the GUI. I am running on a 2.93Ghz i7.

Related?

[Laylia27]

You're right! That setting has disappeared for me too.

[csnover]

That setting was removed because it didn’t actually work. The default buffer size is also reduced, which is necessary for games with FMV to have correct lip sync. This change, by extension, reduces the amount of time available to the MT-32 emulator to catch up if it cannot produce samples in real time, but the primary reason why the MT-32 emulator can’t generate samples in real time is because these builds are not optimised. So please, accede to my earlier request and don’t continue to speculate here until an optimised build is available, which will be a short while as my time is limited. Thank you for your patience and understanding.

[Laylia27]

Apologies. Thanks for all your efforts, csnover. You do great work, and I greatly appreciate it.

[csnover]

Fear not, I have not forgotten about you.

I’ve prepared some optimized Windows builds. These builds contain only SCUMM and SCI engines, for the sake of reducing compilation time. Please let me know how they work.

32-bit: ​https://www.dropbox.com/s/8jkuq0xjvtt90vd/scummvm-2.0.0git-43-g2ecdef2790-i686.zip?dl=1
64-bit: ​https://www.dropbox.com/s/ztit3ylppltbd2h/scummvm-2.0.0git-43-g2ecdef2790-x86_64.zip?dl=1

[csnover]

I will need time to make changes prior to the next release if there are still problems, so prompt testing here is appreciated. Thanks!

[g5ppc]

I tested the 32-bit build, on the machine that previously had glitches, and I can't hear any problems.

Do you know if there will be Mac PPC build for the next release?

[Laylia27]

Just tested the 32-bit build. Everything sounds great and runs smoothly! I made sure to try a range of SCUMM, SCI, and SCI32 games. Thanks!

[csnover]

Thank you for confirming that optimised release builds have no problem.

[Laylia27]

Sure thing. I just tested the 64-bit build. Same good results.

[Laylia27]

I just tried running games with the MT-32 emulator on the new stable 2.0.0 release, and the music still stutters.

[csnover]

Hmm, that’s confusing. Are you testing the same games as you did with the pre-release build that I posted earlier on this ticket? Since they were both generated with the same optimisations with the same build system, there shouldn’t be any difference between the two in this regard.

[Laylia27]

Yes, it's happening with the same games. I went back and tried those games (and more) on the pre-release builds above, and they all sound perfect. Then I went back to the stable 2.0.0 release, and the music is full of pops, static, and stutters.

Is there maybe something I'm missing when testing them out?