BACKENDS: MacOSX - PPC 2.0.0 release has MT-32 stutter issue

[g5ppc]

Running on a dual 2.0Ghz G5 with OS X 10.5.8.

Previously had 1.8.1, 1.9 and a 1.9 daily from aug 2016. Each ran King's Quest VI start screen with MT-32 without any significant problem.

With the new 2.0.0 build, the MT-32 breaks up in a manner similar to that previously reported during the 2.0 dev-cycle on win32 machines. This was attributed to non-optimized compilation on win32.

Could something similar have occurred on PPC build? I tried adjusting output_rate and the new audio_buffer_size. output rate didn't seem to help at 22050, and audio_buffer_size simply altered the spacing/duration of breakups.

[criezy]

I just checked and the mac PPC release was built with optimizations in exactly the same way as previous releases.

Is this with a real MT-32 or using the MT-32 emulator. The emulator in ScummVM was updated to Munt 2.0 in December 2016, just after the 1.9.0 release, and it is possible that this requires more processing power than before (which would explain the report of issues on win32 while even with debug built we didn't get reports before). And that turns to be too demanding for PPC macs, I don't think much can be done.

The only other change I see that could cause issues would be the reduction of the audio buffer size. For an output rate of 44 kHz, the audio buffer size is now 1024 samples while it was 4096 samples in release 1.9.0. However since you indicate you tried changing it, this seems to indicate this is not the issue.

Maybe you can use munt externally with the Core MIDI setting in ScummVM? In that case it might make better use of the available CPU cores and you could also use an older less power-hungry (but probably less accurate) version.

In ScummVM itself we might be able to improve performances by running the MT-32 emulator in a separate thread. I don't think anybody is planning to work on that currently though.

[g5ppc]

I don't think MUNT was built for Mac PPC; I can't seem to find it.

I tried setting audio_buffer_size to the minimum, 256. This gave the best response. I assume lower values were being rejected.

I compared CPU load as shown in Activity Monitor while loading and changing between a few screens in KQ6. The Aug2016 daily very closely matched 2.0, but never breaks up. Interestingly, Aug2016 actually registered 105% CPU at a couple points. If forced to guess, I think any shortfall was in what you might call frame-rate, as the Sierra fadeout is slower than the real thing. The CPU loads between the two are so close, I can only repeat what should have been obvious on the win32 version of this bug:

I think there is something wrong in how much CPU time the MT32 routines are given or when it is given. I think the build-optimization factor was just covering up an underlying issue.

[g5ppc]

I did some additional testing with Activity Monitor set to update at half second intervals.

The Aug2016 and 2.0.0 seem to be using virtually identical amounts of CPU at various points in KQ6. Both produced spikes to 140% CPU. But only the 2.0.0 consistently breaks up at higher levels of MIDI demand.

This is similar to my observations on the win32 version of this bug: there was always CPU power to spare on the systems involved; the breakups are from something related to the load on munt, but not an increase in CPU demanded by munt from a version change.

How does ScummVM decide that munt is underflowing, and can I get some diagnostics to determine if that is happening?

[sev-]

Unfortunately, MUNT itself switched to more precise but more CPU-intensive sound generation. We cannot fix it :/