[Clam-devel] clam and max
parumi at iua.upf.edu
Wed Jan 30 15:28:00 PST 2008
On dj, 2008-01-31 at 00:00 +0100, David García Garzón wrote:
> On Dimecres 30 Gener 2008, Greg Kellum wrote:
> > Hi all,
> > I tried to create a clam object for Max/MSP so that one could CLAM
> > classes within the Max/MSP environment, but it seems that this isn't
> > possible. The problem lies in the fact that Max doesn't allow you to
> > allocate memory when audio processing is running.
> > Typically, a Max object is supposed to allocate all of the memory it
> > needs when the object is created, and then, when one turns on audio
> > processing, the object just uses this preallocated memory. This is
> > part of what makes Max fast. Max was for instance one of the first
> > applications that were able to do a real time FFT on a desktop. (That
> > was over ten years ago...)
> > Due to this constraint, I knew that it wouldn't be possible to run
> > CLAM networks in Max. The networks are allocating new memory every
> > time something is passed from one CLAM object to another over a
> > network connection. But I had hoped that by simply preallocating all
> > of the objects I needed beforehand and calling them with their public
> > methods that I could avoid having new memory being allocated during
> > audio processing. I tried this, and Max crashed. I opened it up again
> > in a debugger to see what happened. And within CLAM's processing
> > objects, objects are being copied by assignment, and Max was crashing
> > in the middle of a call to an object's copy constructor where it was
> > calling new.
> > So, I've given up on the idea of running CLAM inside of Max, because
> > this would only be possible by making some major changes to CLAM.
> Hi, Greg, nice to read you again despite those are sad news.
> By design, to be real-time safe, CLAM should avoid allocations after Start but
> can allow them while before (module creation, port binding,
> configuration...). I know that, currently, running time is not alloc free,
> but all those allocs are bugs that should be fixed.
to put it simple: the framework infrastructure is designed to not
allocate memory during running state. and we were specially carefull in
port buffers allocation.
a different story is that *some* processings do not behave correctly (do
allocate in their Do() ), and should be fixed.
so, it would be very useful to see a back-trace of such allocations
using a very simple network. are you sure that you don't call
configure() nor start() while max is in "running" state?
More information about the clam-devel