ranostaj at stud.uni-frankfurt.de
Tue Jun 25 13:14:37 EDT 2002
> 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
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
More information about the sdlsound