Opened 3 years ago
Closed 23 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 , 3 years ago
Cc: | added |
---|---|
Component: | Audio → Engine: SCUMM |
Summary: | Large audio lag in 2.6git compared to 2.5.1 → SCUMM v7-8: DiMUSE: Large audio lag in 2.6git compared to 2.5.1 |
comment:3 by , 2 years 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 , 2 years ago
Priority: | normal → low |
---|
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 , 23 months ago
Owner: | set to |
---|---|
Priority: | low → high |
Resolution: | → fixed |
Status: | new → pending |
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 , 23 months ago
Status: | pending → closed |
---|
PR merged, the issue was confirmed to be fixed! Closing...
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.