Difference between revisions of "OpenTasks"

OpenTasks (view source)

Revision as of 21:56, 23 February 2010

2,999 bytes added , 21:56, 23 February 2010

Rewrite (Audio) output selection section a bit

Fingolfin

1,079

edits

@@ Line 237: / Line 237: @@
 * Add support for sound format used by Macintosh version of Loom to SCUMM engine. Known [http://sourceforge.net/tracker/index.php?func=detail&aid=824221&group_id=37116&atid=418823  information] about the structure of the sound resources used is available. If you don't own the game, the LucasArts Mac CD Game pack is usually available via eBay.
-=== Output selection ===
+=== Audio output selection ===
-''Technical Contact'': [[User:LordHoto|Johannes Schickel]]
+''Technical Contact'': [[User:LordHoto|Johannes Schickel]], [[User:Fingolfin|Max Horn]]
 ''Background:''
-Right now, our API for selecting an audio output is pretty limited. It basically does not differentiate between the different output types (think of MIDI, AdLib, (PC) Speaker, Amiga etc.), which results in a rather confusing way to select the output device, both for the engine code and for the user in the GUI.
+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, 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 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".
-Currently we use some (pretty simple and stupid) detection method based on audio output flags given by the engine. These flags contain the supported output types. While that is theoretically fine, the problem is 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 backend implementation (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).
+These different concepts are currently not properly distinguished. Furthermore, the approach we use to deal with MIDI variants like GM, MT-32 and Roland, is rather weird and irregular.
+This all results in a rather confusing way to select the output device -- for engine developers, for audio output developers, and for the user in the GUI. Clearly, this is a bad thing for all involved parties and hence the goal of this task is to fix this mess.
+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 the user can select "Amiga" sound for a game which does not contain any Amiga sound data. This is rather annoying.
-For the user we currently always show all concrete output implementations (except digital sound!) in the GUI. This is rather annoying, especially since it also shows outputs, which may not be supported by a specific game.
 To overcome these issues it would be best to change our audio output configuration API to use different layers of configuration:
-* The first layer would be the output type. This might be for example MIDI (or maybe even General MIDI and MT-32 MIDI), AdLib (or generic OPL* output), (PC) Speaker (this might also include PCjr and CMS that would need to be determined in detail), Amiga, Digital Output etc. Note that this is no final list, this would need to be rechecked when working on the task later!
+* The first layer would be the output ''type''. As described above, this could include General MIDI, MT-32 MIDI, AdLib (or generic OPL* output), (PC) Speaker (this might also include PCjr and CMS, to be determined later on), Amiga, FM-TOWNS, Digital Output etc. Note that this is no final list, rather making this list concrete is part of the task! For example, one might want to have a single MIDI output type, and introduce a notion of ''subtype'' to distinguish between GM, MT-32 and Roland MIDI.
-* The next layer would probably be a concrete output implementation, like Windows MIDI or ALSA for MIDI. Or some sub-type, for example MIDI usually comes in either MT-32 MIDI or General MIDI (or both!). Here would be thought required to determine what would be the best solution. For example some games might just support either MT-32 MIDI or General MIDI, thus this might be a first layer type. Maybe it would also be possible that we have another layer just for the GUI, i.e. not visible to the engine code, which covers this. So if you plan to take this task, you will still have a lot of research to do, to find the best separation :-).
+* The next layer would probably be a concrete output implementation, i.e. output drivers. Examples include Windows MIDI or ALSA for MIDI. Note that a single driver could potentially support multiple types: A user may usually use the Windows MIDI driver for GM output, via software synthesis, but may also own a real MT-32. This user may then wish to use the MT-32 via the Windows MIDI driver. Hence, depending on the output device resp. the user choice, the Windows MIDI driver would accept any MIDI variant. On the other hand, the MT-32 software emulator might only support MT-32 data.
+* One could also insert an extra conversion layer which tries to (optionally) translate between the various MIDI variants: So if a game requires MT-32 output but the user only has a GM device available, the MT-32 data could be translated on the fly (as good as possible) to GM before being sent to the actual output driver. Such conversions currently happen in engines. Sharing this code might be beneficial; on the other hand, it might turn out that each engine knows best how to perform this translation, in which case we should leave it up to the engines to perform such a conversion (or not). Once again, deciding this is part of the task.
+So if you plan to take this task, you will still have a lot of research to do, to find the best separation :-). Of course the technical contacts, as well as the rest of the ScummVM team, would collaborate with you on this.
-Roughly the same layers should also be visible in the GUI configuration to allow for a much more user friendly output configuration. The user might additionally configure a concrete output like ALSA to use a specific implementation specific setting (like in the output port for ALSA) though. See the [[OpenTasks#MIDI_device_configuration|MIDI_device_configuration]] task for more information about this. (Note that it would probably best to tackle both tasks in a single Google Summer of Code project!).
+Roughly the same layers should also be visible in the GUI configuration to allow for a much more user friendly output configuration. The user might additionally configure a concrete output driver like ALSA to use a specific implementation specific setting (like in the output port for ALSA); think of this as a baby version of output devices (for true output devices, one would have to support multiple such configurations for each driver, configurable and selectable via the command line, GUI and the internal API). See the [[OpenTasks#MIDI_device_configuration|MIDI_device_configuration]] task for more thoughts about this. (Note that it would probably best to tackle both tasks in a single Google Summer of Code project!).
 Of course this is not set in stone yet; if you have some other great idea how to tackle this, we are happy for your feedback :-).