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

Reply via email to