SCUMM: Sam and Max: Speech garbled and extremely slowed down

[raziel-]

ScummVM 2.9.0 (Dec 8 2024 19:29:30)
Using SDL backend with SDL 2.0.14
Features compiled in: Vorbis FLAC MP3 RGB zLib MPEG2 FluidSynth Theora VPX AAC A/52 FreeType2 FriBiDi JPEG PNG GIF taskbar TTS cloud (servers, local) ENet SDL2 TinyGL OpenGL (with shaders)
and with 2.10git from today

The intro doesn't play (after the golden boy "screensaver" the intro with the mad scientist should come up), background (midi) music is playing fine, but the screen stays black and i can hear, low volumed, extremely garbled speech.

Pressing ESC two times gets me to the "road" credits, which do play, another ESC and Sam & Max arrive in their office.

The speech from both of them are also garbled and heavily slowed downed (the whole scene and the rest of the game, take ages to continue).

This is a regression, but i have no idea when it last worked.
Using the original MONSTER.SOU, no crunching involved.

as far as i can see, only this game is affected

Problem is using real MIDI hardware...this game seems to not like it (see below for more info)

Sam & Max Hit the Road (CD/English)
Windows 10 - 64/32 bit

[AndywinXp]

I personally can't reproduce this... other settings that we have to know of? With which audio settings is ScummVM initialized at startup? You can see that in the console.

[raziel-]

how do I bring the console up in windows?

[raziel-]

I found the culprit (thanks to your settings hint), but no solution (but a workaround)

I have real MIDI hardware hooked up and use it with a Roland UM-1 USB adapter.

All the other games from the scumm engine (Monkley 2 etc) do not have a problem, despite but Sam & Max does.
Seems the MIDI traffic slows everything else down, no idea why, though.

If i set Audio to "Microsoft GS Wavetable Synth" everythings works normal again, but i'd like to use my hardware, please

Maybe someone with real MIDI hardware could cross-check?

I could also provide a debug log (if someone tells me how to bring that console up)?

Lowering priority...

[NMIError]

In fb7e7539:

SCUMM: Fix excessive MIDI messages

The code for reducing music volume levels during speech was sending out volume
change messages every MIDI timer tick, regardless of whether the volume had
actually changed. This caused problems for older MIDI hardware, which can only
process a limited number of MIDI events in a given time period.

Fixed this by checking if any of the volume levels set by musicVolumeReduction
has actually changed before calling update_volumes. Looking at the MIDI output
of the original interpreter, this also seems a better match to the original
behavior.

This fixes issue #15724.

[NMIError]

I've just committed a fix for this; it should be available in the next daily build.
Can you confirm if the issue is fixed for you?

[raziel-]

Awesome, thanks a lot 👍

Will check tomorrow and report back

[raziel-]

@NMIError

Confirmed fixed, thank you very much

[NMIError]

Great; thanks for your feedback!

[NMIError]

In f828a6fd:

SCUMM: Fix excessive MIDI messages

The code for reducing music volume levels during speech was sending out volume
change messages every MIDI timer tick, regardless of whether the volume had
actually changed. This caused problems for older MIDI hardware, which can only
process a limited number of MIDI events in a given time period.

Fixed this by checking if any of the volume levels set by musicVolumeReduction
has actually changed before calling update_volumes. Looking at the MIDI output
of the original interpreter, this also seems a better match to the original
behavior.

This fixes issue #15724.

(cherry picked from commit fb7e7539d4ba735ea5ad30e189a6380d4874667e)