This fixes some issues which caused the fades in the Miles AdLib driver to not
work properly:
- _timerRate was not set
- end of track meta event was not handled, so active fades were not aborted by
deinitializing the source on end of track
The timerProc fields and onTimer function were removed because they duplicate
functionality from the MidiDriver_Multisource base class.
This adds a MidiDriver property which controls the Miles AIL/MSS version to
emulate. This controls the initialization of MT-32 and GM devices. MSS v3 added
GM support, which caused some differences between v2 and v3 in how MIDI devices
are initialized. Some games might rely on certain default settings for correct
playback.
This changes the return type of the Miles AdLib MIDI driver factory function to
the recently introduced superclass MidiDriver_Multisource, which allows for
easier use of multisource functionality for consumers of the factory function.
This adds applying source volume for all sources to the Miles MIDI driver. This
was missing and caused changes to user volume not to be applied for some games.
Adds an implementation of the multisource interface to the Miles AdLib driver.
This partial implementation only supports the volume management functions and
the use of a single source (0), which is sufficient for most games (that only
use MIDI for background music). Full multisource support will be added later.
This adds a MIDI driver for AdLib / OPL2 and OPL3 with support for multiple
simultaneous sources of MIDI data. Additionally, it is easier to subclass the
driver and customize its behavior than the existing AdLib MIDI driver. The
standard behavior matches the Windows 95 SB16 driver.
This is so that individual audio players can share the same mutex as the
mixer. When they have their own, it's apparently quite easy to
accidentally introduce deadlocks. Particularly when the audio player is
shut down.
At least it seems to me that the way e.g. Lure of the Temptress calls
isReady() to see if the driver has finished processing all the custom
sounds, _sysExQueue can be accessed by two threads simultaneously.
Which seems like a bad thing to me!
Identified by coverity - if the module load fails, _mixBufferSamples could be
left as an invalid pointer, which would cause a problem in the destructor.
Moved most things to initailizer list to avoid the problem.
Coverity still identifies a lot of uninitialized members, but they should all
get initialized when playback starts and have less chance of causing real bugs.
