Subject: Re: [linux-audio-dev] GLAME supports LADSPA now.
From: Juhana Sadeharju (kouhia_AT_nic.funet.fi)
Date: Tue May 23 2000 - 11:04:45 EEST
>From: Richard Guenther <richard.guenther_AT_student.uni-tuebingen.de>
>
>And why the hell does LADSPA need those 99999 different delay and fbdelay
>plugins??? I'm sure its because of "malloc()" is broken wrt RT. But, hey,
>this can be fixed in other ways! Cant you just tell the plugin at
>activation time what the maximum delay should be?
RT audio engine could lock up memory in larger pieces and each plug-in
should request memory from there via our own malloc-replacement. If audio
engine runs short of memory, a new big memory block could be malloced
and locked up -- that can be done on-the-fly as far as I can tell.
For non-RT systems the mallocs could be enough.
So, should we recommend to use ladspa_malloc() instead of malloc()?
By the way, we could also have ladspa_srand() which either perform srand()
or not depending on if host wants to init the random function.
Those functions should be part of the standard --- not part of any
volunteerly used library. Right?
My to-be-ladspa plug-ins has 41 mallocs because I have divided delay line
etc. handlings to subroutines with their own API. I think only good
way to remove them would be to use our own malloc-replacement. I guess
I could alternatively perform a delayed one-time malloc if I write the
routines differently but that makes it more complicated: I would need
to delay all initializations at the time when all the plug-in system is
build. That would make the memory issues transparent which is what I want
more than a messy code.
Juhana
This archive was generated by hypermail 2b28 : Tue May 23 2000 - 11:50:20 EEST