[sdlsound] hmm...

[ranostaj]

> 
> Aha! Here's the problem (SDL_sound.c, line 575):
> 
>      internal->buffer_size = sample->buffer_size / internal->sdlcvt.len_mult;
> 
> We do this in three places (sample creation, decodeall, and
> setbuffersize). We're assuming that sdlcvt.len_mult is an _integer_ that
> is >= 1. This is no longer true. The first test has len_mult set to 0.5.
> 
> This means that WAV_read will read 32k into a 16k buffer.
> 
> We also have sample->buffer and internal->buffer as the same memory
> address, since SDL does the audio conversion in-place. SDL_sound, inside
> the decoders, doesn't make this promise, so if we need to change it in the
> base of the library it won't break anything else.
> 
> Historically, len_mult was meant to be a guide to let you know if you
> needed more memory allocated than your original sound data required.
> Should we deviate from SDL's current behaviour? Thoughts? Patches?  :)


On the way... But I didn't have the compiler with me, so it may be not 
syntactical correct.
Fixed some more bugs, adressed the issue with possible miscompile and 
speed the increaseRate decreaseRate
functions up a bit. They sound a bit metallic - not sure why.

Regarding the (un)signed StereoToMono - while the addition does not 
differ between s/u the following shift
does.  I am not sure if we should ommit the shift, I prefer to not 
change it.

   Frank