Hi Stefan, Preliminary work was started last year to allow a completely separated memory manager to be used, look at the dsp_memory_manager class in dsp.h header file as well as setMemoryManager/getMemoryManager method in the dsp_factory class (see https://github.com/grame-cncm/faust/blob/master-dev/architecture/faust/dsp/dsp.h). The idea is to give the developer control of all memory allocation done in createDSPFactory/createDSPInstance.
But the internal code is not yet fully implemented and tested, and as you found out some STL related allocation have probably to be reworked. Can you possibly use this method in your application? Stéphane > Le 27 déc. 2018 à 12:01, Stefan Kersten <s...@k-hornz.de> a écrit : > > Hi there! > > After a long hiatus I'm picking up Faust again and I'd like to integrate > libfaust into an audio engine I wrote some time ago [1]. > > The engine allocates DSP instances in the audio thread (like e.g. > SuperCollider) but I noticed that llvm_dsp_factory::createDSPInstance() > and llvm_dsp::~llvm_dsp() make calls to methods in the global DSP > factory table, which in turn call STL methods that allocate memory. > > AFAICS, the global factory table would not be strictly necessary for > using libfaust and could be replaced by a dummy table (e.g. via a > compile-time switch). Do you think that would be a good way forward or > are there any other means of making calls to libfaust real-time safe I'm > not aware of? > > Thanks for any pointers, and best, > Stefan > > [1] https://github.com/samplecount/methcla > > > _______________________________________________ > Faudiostream-devel mailing list > Faudiostream-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/faudiostream-devel _______________________________________________ Faudiostream-devel mailing list Faudiostream-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/faudiostream-devel