Opened 17 months ago

Closed 9 months ago

#13462 closed defect (fixed)

SCUMM v7-8: DiMUSE: Large audio lag in 2.6git compared to 2.5.1

Reported by: rsn8887 Owned by: AndywinXp
Priority: high Component: Engine: SCUMM
Version: Keywords: Dimuse
Cc: AndywinXp Game:


The audio lag in Full Throttle and probably in other imuse/dimuse games as well is much larger now than it used to be in 2.5.1. Tested using a build of 2.6git from May 2 2022 on PSP and Windows.

For example, the sound in the first scene when hitting the ground after jumping out of the dumpster is now notably delayed. The sound of kicking the dumpster comes after the foot hits, it is not anymore perfectly synchronized. In 2.5.1 and Dosbox the synchronization between graphics and sound is much better.

Example videos using Windows 10:
2.5.1 (no audio lag)
2.6git May 2 2022 (noticable audio lag)

Change History (6)

comment:1 by AndywinXp, 17 months ago

Cc: AndywinXp added
Component: AudioEngine: SCUMM
Summary: Large audio lag in 2.6git compared to 2.5.1SCUMM v7-8: DiMUSE: Large audio lag in 2.6git compared to 2.5.1

comment:2 by rsn8887, 17 months ago

After some testing on PSP with Bosca's help on Discord, we found out that, on PSP, changing "samples = 8192" to "samples = 16" or lower in osys_psp.cpp and changing "_mixer = new Audio::MixerImpl(samplesPerSec);" to "_mixer = new Audio::MixerImpl(samplesPerSec, samples);" seems to reduce the audio lag in Full Throttle to 2.5.1 levels of imperceptibly small lag, or at least very close.

The funny thing is that changing samples to 1024 or even 128 seems to cause no change. The change only happens at really low numbers.

I am not sure how a 16 sample large buffer can work without producing stuttering, but it seems to work.

Last edited 15 months ago by rsn8887 (previous) (diff)

comment:3 by rsn8887, 15 months ago

The reduction of audio buffer to 16 samples on PSP is not a universal fix. Other games such as Dreamweb have audio stutter with this setting.

comment:4 by AndywinXp, 11 months ago

Priority: normallow

I haven't been able to replicate this on any of my devices nor anyone else reported this, dropping the priority to low...

It is highly unlikely that we'll ever achieve the original MS-DOS low level of latency in sound for Full Throttle, as the interpreter originally has a different way of sending audio to the hardware (namely, low level audio code which is pretty much only targeted towards the target platform without too much room for portability, which is the exact opposite of what we do).

comment:5 by AndywinXp, 9 months ago

Owner: set to AndywinXp
Priority: lowhigh
Resolution: fixed
Status: newpending

Supposedly fixed in Raising priority to high in the hope that this can be tested and merged before the next release cycle.

comment:6 by AndywinXp, 9 months ago

Status: pendingclosed

PR merged, the issue was confirmed to be fixed! Closing...

Note: See TracTickets for help on using tickets.