Subject: Re: [linux-audio-dev] LADSPA hard_rt_capable
From: Benno Senoner (sbenno_AT_gardena.net)
Date: Mon Dec 11 2000 - 17:48:30 EET
Hi,
yes these plugins are a bit a dilemma, especially when it comes to
small block sizes.
How does one know for example that a plug can work with
a block size of X on a CPU with Y Mhz during worst case scenarios ?
(user/audiomation software varies parameters like mad (and thus causing
recalculation of tables during each run() cycle)
In LADSPA it will probably not make sense, but on MAIA we could implement
a system where these calculations are performed in a lower priority thread
and where the results are delivered in an atomic way to the run() callback.
Otherwise we will need to be very careful about these forms of non-determinisms
or as you said it would probably be useful to have some hints about the CPU
consumption (in cycles) of these parameter changing functions,
so that the host can take appropriate actions.
(eg: changing the resonance of a filter takes 2msec on a P133 (just an
example), thus running the plug with 2msec buffersize will probably lead to
drop outs.
I think if a plugin architecture supplies estimates about CPU consumption,
then it should provide both the CPU usage of the DSP algorithm and parameter
recalculation.
That way the host app could figure out quite precisely if the CPU can
tolerate the DSP load and/or heavy parameter changes.
Steve, I was wondering if you measured the CPU consumption of some
of these problematic parameter recalculation functions.
I mean: assuming you've got a 400-800Mhz CPU, would some of these recalculation
functions cause audio disruptions (runnnig with 3-5msec latencies) in the case
of the parameter changing during each iteration ?
cheers,
Benno.
On Mon, 11 Dec 2000, Steve Harris wrote:
> Hi, more LADPSA stuff I'm afraid.
>
> I've a few plugins that can't be marked as HARD_RT_CAPABLE because thier
> cycle consumption varies too much when you change parameters (ie. they
> use parameter watching and only rebuild tables if they need to) otherwise
> they would be too slow with small chunk sizes. But this means that they
> can't be flagged as RT_CAPABLE, even though they don't use malloc or
> anything nasty like that.
>
> Is thier any advantage to allowing them to flag that they have
> unpredictable CPU consumption, but are otherwise safe? I'm not sure if
> that helps the host.
>
> - Steve
-- http://www.linuxaudiodev.com The Home of Linux Audio Development
This archive was generated by hypermail 2b28 : Mon Dec 11 2000 - 16:46:50 EET