Re: [linux-audio-dev] GLAME supports LADSPA now.

New Message Reply About this list Date view Thread view Subject view Author view Other groups

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


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Tue May 23 2000 - 11:50:20 EEST