ranostaj at stud.uni-frankfurt.de
Wed Jun 26 12:48:05 EDT 2002
>>> 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?
>> We already deviate from SDL's current behaviour, since converting
>> arbitrary sample frequencies violates the "buffer length has to be a
>> of two" rule. So I don't see any reason to needlessly cling to the
>> SDL way,
>> if we can think of any better one. I doubt this code will make it
>> back into
>> any 1.x version of SDL anyway.
> We can do some kind of zero padding. Hmm... it doesn't combine with
> the loop stuff :-(
> Did you think, the later is useful, anyway? Is it used in games?
> Perhaps for some repeating sound,
> like walking, raining, machine-gun fire or something like that. I
> think I've seen a similar function
> in the win32 api.
I'll address the issue regarding the len_mult. Currently it is broken
for cases when we change
the format in a way which increases the buffer footprint and reduce the
buffer size afterwards.
I'am not shure if I read the above correctly: given the case we have a
sample with a buffer
length of 135k - is it right that we allocate a buffer of 256k?
More information about the sdlsound