561
edits
Difference between revisions of "OpenTasks"
Jump to navigation
Jump to search
→Audio output selection: Use "AdLib" instead of "Adlib"
m (→Audio output selection: some minor fix to avoid confusion) |
(→Audio output selection: Use "AdLib" instead of "Adlib") |
||
| Line 243: | Line 243: | ||
Right now, our user interface and our internal API for selecting and controlling audio output are very limited. They do not properly differentiate between the output ''type'', the output ''driver'' and the output ''device''. To explain the difference: | Right now, our user interface and our internal API for selecting and controlling audio output are very limited. They do not properly differentiate between the output ''type'', the output ''driver'' and the output ''device''. To explain the difference: | ||
* An output type could be MIDI, | * An output type could be MIDI, AdLib, (PC) speaker, Amiga, etc.; MIDI could be further split into GM (General MIDI), MT-32, Roland, etc. | ||
* An output driver is a concrete implementation of an output type. For example, we have two | * An output driver is a concrete implementation of an output type. For example, we have two AdLib/OPL drivers right now; and many MIDI drivers. | ||
* Finally, a single driver could control multiple devices; e.g. you might have a General MIDI synthesizer *and* an MT-32 attached to your computer; or you might want to use fluidsynth with two different sound fonts, each shown as a separate "device". | * Finally, a single driver could control multiple devices; e.g. you might have a General MIDI synthesizer *and* an MT-32 attached to your computer; or you might want to use fluidsynth with two different sound fonts, each shown as a separate "device". | ||
| Line 251: | Line 251: | ||
Let's start by reviewing the current state of affairs. Engines specify during a startup a set of [http://doxygen.scummvm.org/dd/d2e/mididrv_8h.html#0b8636a2c41edcf47a84282ba7a00971 audio output flags]. These flags try to describe the output ''types'' supported by the engine resp. the current game. We then use some (pretty simple and stupid) "detection" method based on these to determine the output ''driver'' to use. (There is no support for output ''devices'' in ScummVM right now, and adding support for this is not part of this task, but of course we won't complain if it happens either.) Unfortunately, this detection does not include all the above mentioned output types, for example it does not allow to specify "Amiga", which recently turned out to be a major problem for the WIP SCI engine, since its Amiga games support both MIDI (in this case, MT-32 MIDI) and Amiga sound output. Now there is no (clean) way of checking whether the user wanted to use Amiga sound or MT-32 MIDI. Next it does directly map to some concrete audio ''driver'' (like ALSA or Windows MIDI for MIDI). This results in an unclean way of checking in the engine what exactly the selected output type is (this might be required to load special music data files for the different output types). To further complicate things, the current " | Let's start by reviewing the current state of affairs. Engines specify during a startup a set of [http://doxygen.scummvm.org/dd/d2e/mididrv_8h.html#0b8636a2c41edcf47a84282ba7a00971 audio output flags]. These flags try to describe the output ''types'' supported by the engine resp. the current game. We then use some (pretty simple and stupid) "detection" method based on these to determine the output ''driver'' to use. (There is no support for output ''devices'' in ScummVM right now, and adding support for this is not part of this task, but of course we won't complain if it happens either.) Unfortunately, this detection does not include all the above mentioned output types, for example it does not allow to specify "Amiga", which recently turned out to be a major problem for the WIP SCI engine, since its Amiga games support both MIDI (in this case, MT-32 MIDI) and Amiga sound output. Now there is no (clean) way of checking whether the user wanted to use Amiga sound or MT-32 MIDI. Next it does directly map to some concrete audio ''driver'' (like ALSA or Windows MIDI for MIDI). This results in an unclean way of checking in the engine what exactly the selected output type is (this might be required to load special music data files for the different output types). To further complicate things, the current "AdLib" music driver is also used to emulate MIDI sound (useful on low end system which don't properly support MIDI output on their own), causing several engines which only use MIDI for audio output, and which don't contain and AdLib data, to still specify the MDT_ADLIB audio flag. | ||
For the user we currently always show all concrete output implementations (except digital sound!) in the GUI, without distinguishing between output types and output drivers. We also always show everything, without considering what a given game actually supports. So currently the user can select "AdLib" sound for a game which does not contain any AdLib sound data. This is rather annoying. | For the user we currently always show all concrete output implementations (except digital sound!) in the GUI, without distinguishing between output types and output drivers. We also always show everything, without considering what a given game actually supports. So currently the user can select "AdLib" sound for a game which does not contain any AdLib sound data. This is rather annoying. | ||