[sdlsound] hmm...

ranostaj ranostaj at stud.uni-frankfurt.de
Thu Jun 27 13:50:23 EDT 2002



Ryan C. Gordon wrote:

>> 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?
> 
> 
> In SDL, the conversions are always done in place, which means you might
> need a bigger buffer than the original data needs (since changing from
> mono to stereo would need twice as much space).
> 
> In SDL, len_mult is never less than one, but it is frequently greater than
> it. If the converted data is smaller than the original, you couldn't
> shrink the buffer anyhow, since the original needs that whole block of
> space, and thus, len_mult would be one.


The word "buffer" is mentioned in the Audio_Spec and in Audio_CVT with 
different meaning, I believe.
That's what confused me. Perhaps we should distinct between buffers and 
chunks, where the first one
holds a complete audio file, while the last one is fixed size and is 
accepted by the callback-function.
Anyway that is only a naming issue.
I've coded a padding function, but I am not sure whether it is 
necessary. Does the last chunk has to be
zero padded, or can we rely on returning the length?

Torbjörn, I've have two question: does the attached patch work for you and
does the incereaseRate path decreases the sound quality, or is the other way
round? I've the strong suspicion that's where I went wrong ... 

	Frank


-------------- next part --------------
A non-text attachment was scrubbed...
Name: audio.zip
Type: application/x-zip-compressed
Size: 10551 bytes
Desc: not available
URL: <http://icculus.org/pipermail/sdlsound/attachments/20020627/8314b847/attachment.bin>


More information about the sdlsound mailing list