[Scummvm-devel] CVS: "added extra flag to mixer so we don't use free() on new'd pointers"

Marcus Comstedt marcus at mc.pp.se
Sat Oct 25 05:52:26 CEST 2003


Max Horn <max at quendi.de> writes:

> First off, that's because the mixer has to work async, and hence the
> caller can't determine when it can free the temporary buffer it may
> have used for the audio data. Hence we leave it to the mixer to free
> that buffer.

Asynchronous I/O is nothing new or magical.  What you typically do is
let the lower layer send a message to the upper layer when it's done,
so that the upper layer knows that it can free or reuse the buffer.
(In this case lower layer = mixer, upper layer = engine.)


> The alternative is that the mixer, when you give it data to play,
> allocates a new buffer and copies all the data.

No.  See above.


> 1) allocate temp sound buffer
> 2) fill sound buffer
> 3) pass buffer to mixer
> 4) mixer allocates yet another buffer and memcpy's the content
> 5) temp sound buffer is free'd
> 6) when the mixer is done playing the sound, that buffer is free'd, too
> 
> That's a lot of memory & CPU time overhead.

And that is why nobody (except you :) have suggested such a solution.


> IMHO this is most of the time true, but certainly not always. Transfer
> of ownership is something one usually avoids, because it makes it
> harder to follow the life time of an object. However, that doesn't
> mean one should do strange things and bend over backwards just to
> avoid it at all times. Sometimes transfer of  ownership of an object
> is in fact the most logical, efficient, and easiest alternative.

Transferring the ownership to the object is fine, as long as it is
transferred back when the mixer is done with it.  It can be really
simple:  The mixer calls a callback provided by the engine with the
buffer as an argument, and then the engine can call free() on it if
that is the right thing to do with it, or return it to its pool of
free buffers or whatever it wants to do.


  // Marcus






More information about the Scummvm-devel mailing list