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).
Separated audio cache.
Fixed bug in the audio cache where still used sound might get freed.
Fixes crashes when engine is unloading which were caused
by a race condition between the timer code and engine teardown code.
Fixed isseue of duplicating items in world
Fixed fog issue with incorrect rendering in special occasions
Added basic debugger console
Refactored looping code for better readability
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
