Opened 2 years ago

Closed 15 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:

Description

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)
https://youtu.be/TYEioBrw8YE
2.6git May 2 2022 (noticable audio lag)
https://youtu.be/JDcykC2WN8Q

Change History (6)

comment:1 by AndywinXp, 2 years 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, 2 years ago

After some testing on PSP with Bosca's help on Discord, I 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.

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

Version 1, edited 2 years ago by rsn8887 (previous) (next) (diff)

comment:3 by rsn8887, 22 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, 18 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, 16 months ago

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

Supposedly fixed in https://github.com/scummvm/scummvm/pull/4596. Raising priority to high in the hope that this can be tested and merged before the next release cycle.

comment:6 by AndywinXp, 15 months ago

Status: pendingclosed

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

Note: See TracTickets for help on using tickets.