This allows us to change the volume of sounds in filters ("volume",
"fade" properties) without quantizing the audio prematurely. Previously,
we had a hack to apply volume changes as a mixing-time step. This
can be done at any point in the filter chain now.
This also means we only need to worry about clipping at the very
last mixing step, instead of at every place we change sound.
Dithering for 16-bit audio and more intelligent gain control
is possible, as we have full-resolution, unclipped sound at the
mixing phase.
We support high resolution source sounds; both Vorbis and MAD
supply more than 16 bits.
Several filters, such as resampling, are easier to implement as
floats; these no longer need to convert back and forth.
Negatives:
- More memory use. The main case of this is in RageSoundReader_Preload,
which will be fixed: we can preload in 16-bit without losing most of the
above.
- Some extra overhead for accessing more memory.
different rate than the source it's reading from; one second
of returned data may correspond to two seconds in the source
material.
GetStreamToSourceRatio returns the ratio of returned data in
the next Read() call to source data. This is propagated
upwards in the filter tree, so rate changes by a speed changer
in the middle of the tree will be reflected in the final
GetStreamToSourceRatio().
This means that whenever the ratio changes, Read() stops
returning data; it returns whatever it has, so the caller
has an opportunity to call GetStreamToSourceRatio again
and notice the change.
These semantics can be annoying to implement in some
cases, where only the processing of Read() may notice
a ratio change. Read() may want to return 0, to say
"something changed, call GetStreamToSourceRatio again",
but 0 means EOF.
Add RageSoundReader::END_OF_FILE. 0 is now no
longer a special case; it means "there's more data, I
just didn't return any this time". This is functionally
equivalent to errno EINTR.
that are loaded in advance, which excludes sample music
and some announcers.
Disable "sound volume". That's not what that variable is for; setting
it to higher values will result in clipping on a lot of hardware, causing
people to report it as a "bug" (which it's not). Setting it to lower values
results in lower quality sound. To do this correctly, we'd need to add
an interface for accessing the real hardware mixer volume, which I
don't really want to do right now ...
Glenn Maynard