1,079
edits
Difference between revisions of "TODO"
Reformated/split the audio TODO
m (adding wanted pages to todo) |
(Reformated/split the audio TODO) |
||
| Line 70: | Line 70: | ||
=== Audio === | === Audio === | ||
* Get the high quality resample code to work | |||
==== Mixer ==== | |||
* Get the high quality resample code to work | |||
* Consider changing the mixer volume to use range 0-255, for sake of consistency (but at a slight loss of efficiency). Note that this requires changes in at least rate.cpp and mixer.cpp. | * Consider changing the mixer volume to use range 0-255, for sake of consistency (but at a slight loss of efficiency). Note that this requires changes in at least rate.cpp and mixer.cpp. | ||
* Some of our engines support the speech_mute / sfx_mute / music_mute options, but most don't. Almost all support the corresponding FOO_volume config keys. All engines use Mixer::setVolumeForSoundType to push those through to the mixer. I am wondering: Maybe it would make sense to remove Mixer::setVolumeForSoundType, and instead leave it up to the mixer to query the ConfigManager for the corresponding FOO_volume/_mute values? That way we'd ensure 100% identical behavior in all engines and actually simplify the code a bit... ? Not sure if this would work smoothly, it needs to be investigated. | |||
==== Audio streams ==== | |||
* Modify our audio stream classes (for MP3/Vorbis/FLAC/... playback) to use SeekableReadStream instead of Files -> allow from-memory-playback. And could take advantage of a new hypothetical "Sub(Seekable)Stream" class. (See below for more info on that). | |||
* Add a "SeekableAudioStream" class, which would allow seeking in an audiostream: Forward / backward; offset is specified in milliseconds. Then, convert at least the MP3/FLAC/Vorbis audiostream classes to subclass that, and also adapt the corresponding factory functions. Converting more would obviously be nice, too. The existing DigitalTrackInfo subclasses already contain seeking code which could be used as a starting point. | |||
* Once SeekableAudioStream has been implemented, this can be used to greatly simplify the DigitalTrackInfo subclasses (like MP3TrackInfo) which are used by the Audio CD manager. In fact, it might then be possible to completely get rid of these special subclasses. | |||
==== CD ==== | |||
* The Audio CD Manager, and especially the DigitalTrackInfo class could stand an overhaul. The system currently is not as easy to extend as one would wish. In particular, it would be nice if arbitrary AudioStream classes could be used here (this then would reduce code duplication and make it instantly possible to use WAV/VOC encoded audio tracks, should we desire to support those). | |||
==== MIDI ==== | |||
* MIDI: Add API to OSystem which allows client code to query for "native" MIDI drivers (like Windows, ALSA, Zodiac, CoreAudio). Then change the MIDI interfacing code (GUI, command line, config file, etc.) and also MidiDriver::createMidi() to use both that list and the list of 'emulated' MIDI devices (Adlib, MT-32, PC Speaker, etc.) in an appropriate way. | * MIDI: Add API to OSystem which allows client code to query for "native" MIDI drivers (like Windows, ALSA, Zodiac, CoreAudio). Then change the MIDI interfacing code (GUI, command line, config file, etc.) and also MidiDriver::createMidi() to use both that list and the list of 'emulated' MIDI devices (Adlib, MT-32, PC Speaker, etc.) in an appropriate way. | ||
* Make it possible to pass options to the midi/music drivers. This would allow us to get rid of the getenv hacks in the alsa & seq drivers. | * Make it possible to pass options to the midi/music drivers. This would allow us to get rid of the getenv hacks in the alsa & seq drivers. | ||
**A simple approach would be to allow the user to specify "extended" driver descriptions. E.g. "alsa:1234" could indicate the alsa driver with port 1234; alternatively, "alsa:port=1234". | **A simple approach would be to allow the user to specify "extended" driver descriptions. E.g. "alsa:1234" could indicate the alsa driver with port 1234; alternatively, "alsa:port=1234". | ||
**This doesn't allow for easy tweaking of those settings via the GUI.... to achieve that, one approach would be to invent a 'parameter description language' which allows a driver to specify which options with which kind of values it supports... very flexible, but possibly overkill. | **This doesn't allow for easy tweaking of those settings via the GUI.... to achieve that, one approach would be to invent a 'parameter description language' which allows a driver to specify which options with which kind of values it supports... very flexible, but possibly overkill. | ||
**Instead, one could add a hook method to MIDI drivers that let's them add a few controls of their own to the options dialog. This is probably a lot easier to implement, though not quite as "clean"... | **Instead, one could add a hook method to MIDI drivers that let's them add a few controls of their own to the options dialog. This is probably a lot easier to implement, though not quite as "clean"... | ||
* Our XMIDI parser seems to have a couple of missing features, but it's unclear which ones are actually needed. For instance, [[Kyra|Kyrandia]] 1 (and probably 2) uses the XMIDI mechanism for looping, which we currently implement through a very simple hack. The [http://exult.sf.net Exult] project may have a good reference implementation. | * Our XMIDI parser seems to have a couple of missing features, but it's unclear which ones are actually needed. For instance, [[Kyra|Kyrandia]] 1 (and probably 2) uses the XMIDI mechanism for looping, which we currently implement through a very simple hack. The [http://exult.sf.net Exult] project may have a good reference implementation. | ||