Open main menu

Difference between revisions of "TODO"

230 bytes added ,  08:44, 12 April 2010
→‎Mixer: update isReady() comment, add some stuff from my personal TODO
(→‎Mixer: update isReady() comment, add some stuff from my personal TODO)
Line 106: Line 106:
* 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.
* 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.
* change the way the mixer is instantiated by the backend. In particular, it would be nice if the sample rate could be passed in via the constructor
* the "isReady" code is irritating. Most engines ignore it anyway. It's primary purpose is to allow ScummVM to run even if not digitial audio out is available. A better solution would likely be to enforce that all backends always return a valid mixer. In the worst case, if a backend cannot produce audio output, it should still instantiate an Audio::MixerImpl, with some arbitrary sample rate (I recommend 22050 Hz), and a fake playback thread, which acts like an audio output callback but simply discards the generated audio data. (Note: It doesn't suffice to just throw away input data in Mixer::playInputStream, as this breaks with QueuingAudioStream).
* the "isReady" code is irritating. Most engines ignore it anyway. It's primary purpose is to allow ScummVM to run even if not digitial audio out is available. A better solution would likely be to implement a fake mixer class, which simply discards audio data which is passed to it immediately. This means that the normal mixer will always consider itself to be "ready", and that it will be up to the backend to use the "fake mixer" if it can't provide audio out for some reason.
* document the semantics of sound handles and sound ids
* Are there backends which could benefit from a 'custom' mixer? If so, what would be required to implement such a thing? Needs talking to porters


==== CD ====
==== CD ====
1,079

edits