Also added a dedicated debugSound channel for debugging
Fixes include closer conformance to original code (for entering/exiting ESPER and VK), and a change in assigning a track slot to a new track with priority equal to the lowest existing (it will now take the place of the old stored track). Also Music::adjustVolume() now takes the target volume as argument and stores it in the track volume field similar to how Music::adjustPan works.
The timers are replaced with "application" timers, which are checked in AudioMixer::tick()
The timerprocs for next and fadeout could potentially cause a game freeze.
This is because they could, under certain race conditions, come to a deadend
while trying to lock the mutexes for access to AudioMixer and Music methods.
The particular use case (non-deterministic) for this was loading a save game
while playing a game that had a music track playing (eg. at MA05, McCoy's balcony).
Here's a rough explanation of a possible lock situation (others could also be possible)
The "Main Thread" and "SDLTimer" threads (as reported from MSVC debug) could become hardlocked.
::Main Thread::
A. LoadGame() calls _music->stop(0u);
A1. Locks a Music::_mutex
A2. Calls vm->_audioMixer->stop()
A3. AudioMixer::stop() locks AudioMixer::_mutex [THIS DONE]
A4. calls the endCallback for the music which is Music::ended()
at Music::ended,
A41. lock a Music::_mutex (presumably this is ok, even though it's a second lock, because it's the same thread(?))
A42. call installTimerProc()
A421. which tries to lock DefaultTimerManager::_mutex from default-timer [THIS FREEZES] - conflict with B11
::SDLTimer::
B. calls timer_handler,
B1. calls DefaultTimerManager::handler()
B11. locks the DefaultTimerManager::_mutex from default-timer [THIS IS DONE]
B12. we try to service the callbacks from TimerProcs that are currently entered in the TimerSlots queue
B121. Such a slot is the AudioMixer BladeRunnerAudioMixerTimer, which has the AudioMixer::timerCallback()
B1211. which calls the at AudioMixer::tick().
tick() tries to lock the AudioMixer::_mutex [THIS FREEZES] conflict with A3
Bug #11294 is a case where output audio hardware is disabled
If the output sound device is disabled or no hardware output device is connected (eg. Windows 10 may disable output audio hardware when no output device is attached/available), then the game should still be playable. We now use the duration of the tracks (in ms) to detect a track's ending.
Also isReady is checked for mixer when playing VQA videos (it wasn't before).
LABBUZZ sound for the maze and Animoid sounds
Moved lab buzz in next scene's (PS10) init, and increased size of track buffer to compensate for frequently dropping sounds in places with mayne sound effects (eg Animoid Row, Izo's door and trapdoor)
Settings works
Help works
Clue database works
Fixed code for inserting objects into scene
Reorganization of few files
Unification & code formatting of few older files
Audio mixer is supporting fading and pan animation
Added support for skipping speech by pressing Return
Added proper support for ambient sounds
Added more code to the dialogue menu
Added tooltips to the Spinner
Fixed calculation of volume and pan of walk steps
Code cleanup & formatting
