Opened 3 years ago

Closed 3 years ago

#9700 closed defect (fixed)

SCI: Audio settings sync is not quite right

Reported by: csnover Owned by: csnover
Priority: normal Component: Engine: SCI
Keywords: Cc:


Volume changes are automatically synchronised to ScummVM whenever kDoSound and kDoAudio volume subops are invoked, but these ops are used by game scripts during the normal course of a game, not just by the user changing audio settings. As a result, syncing whenever the volume is changed via these kernel calls can cause the user’s audio settings to be broken. For example, quitting a game in the middle of speech will cause the normal music volume level to be restored at the reduced speech volume level.

So, the only time that the audio settings should be synchronised from the game is when the user is actually interacting with the in-game audio settings. There is no 100% consistent way to check this across all engines, but I will elaborate on potential approaches I have discovered so far in the comments on this ticket, in case anything sounds particularly good or particularly bad.

Change History (5)

comment:1 by csnover, 3 years ago

There are a few different ways to determine whether a volume change is one that should be synced. The most consistent and reliable way to do this for SCI16 appears to be to check objects on the call stack:

For the text menu bar SCI16 games, check the call stack for an object named TheMenuBar or MenuBar.

For icon bar SCI16 games, check the call stack for an object named volumeSlider in almost all the games. MG256 does its own thing with a control named soundBut. LSL6 CD-lores uses menuBar. Slater & Charlie uses volButton.

Considered alternatives were to look at the port name (not all the volume/control dialogues have a port name), or look to see if the control panel at global 63 is active (not all games use global 63).

comment:2 by csnover, 3 years ago

SCI32 is a little more difficult because audio control was taken over by game scripts as time went on.

GK1: Handles music volume by calling kDoSoundSetVolume on gkMusic1 and gkMusic2 objects, and sound volume by calling kDoSoundSetVolume on gkSound1, gkSound2, and gkSound3 objects. It does not call to master volume.

PQ4: pqGameControls, or increaseVolume and decreaseVolume.

QFG4: volumeSlider.

KQ7: volumeUp and volumeDown.

LSL6hires: hiResMenu and volumeDial.

GK2: Writes to global 76 (music volume).

Hoyle: volumeSlider.

MGDX: MgButtonBar.

Phant1: midiVolDown, midiVolUp, dacVolDown, dacVolUp, or globals 187 (music) and 188 (DAC).

PQ:SWAT: volumeDownButn, volumeUpButn.

Shivers: spVolume.

SQ6: soundBar, musicBar.

Torin: Globals 227 (music), 228 (sfx), 229 (speech).

Alternate approaches considered include looking to see if the control panel plane is visible (doesn’t work with MGDX, and some planes had to be identified indirectly by priority+pictureId instead of by name).

comment:3 by csnover, 3 years ago

GK1: musicBar and soundBar, or GKControls.

comment:4 by csnover, 3 years ago

Owner: set to csnover

comment:5 by csnover, 3 years ago

Resolution: fixed
Status: newclosed

Fixed in 3303a881397beff1753fba237a5da735de03edb5.

Note: See TracTickets for help on using tickets.