Open main menu

Difference between revisions of "OpenTasks"

1,911 bytes added ,  00:11, 5 March 2007
(Regroup tasks)
Line 83: Line 83:
''Technical Contact'': [[User:Fingolfin|Max Horn]]
''Technical Contact'': [[User:Fingolfin|Max Horn]]


<font color="magenta">TODO</font>
''Background:''


* High quality resampling
Most games we supported need to play sampled audio data (PCM encoded). In addition, some code which emulates certain audio devices (like the MT-32 emulator, the FMOPL code or Amiga MOD players) need to do so. To facilitate this, we provide certain APIs: The so-called Mixer object takes a number of AudioStream objects and mixes the audio data it fetches from these together, taking into consideration various external parameters like volume and pan controls. The abstract AudioStream class in turn provides a convenient and flexible way for code which needs to generate and output sampled audio data.
* reduced latency (e.g. by using double buffering) to avoid stutter issues
 
Audiostreams can provide their data with arbitrary sample rates, and the mixer has to convert these to sample rate by the audio output device provided by the backend (which usually means converting to a sample rate of 22050 Hz or 44100 Hz). Currently, we only have a simple linear rate converter.
 
''The Task:''
 
There are much better ways to resample audio data. It should be band pass filtered and other things done to it. Code to do this exists out there. Integrate such code into ScummVM or roll your own. Make sure to keep resource constraints (CPU, memory) in mind. It should be possible to select which resample to use (the low quality but fast linear filter, or your high quality but not quite so fast fancy filter).
 
Furthermore, on some systems, ScummVM suffers from stutter even though there is plenty CPU power left. The problem here is latency (not throughput). That is, while we can generate data fast, we do so too late. The problem on these system likely could be fixed by using a double buffering approach, i.e. generate audio data slighly before it is requested to avoid latency issues.
 
Finally, our AudioStreams currently only can have a single fixed sample rate. But for some usages (in particular, Amiga MOD players), it would be convenient to allow streams to change their sample rate on the fly. Adding support for this would be nice, but should not slow down streams which have a constant sample rate.


=== Add support for TFMX, and more Amiga MOD formats ===
=== Add support for TFMX, and more Amiga MOD formats ===
1,079

edits