1,079
edits
Difference between revisions of "TODO"
Jump to navigation
Jump to search
→Mixer
(Update) |
(→Mixer) |
||
| Line 96: | Line 96: | ||
* 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 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. | |||
==== Audio streams ==== | ==== Audio streams ==== | ||