Subject: Re: [linux-audio-dev] XAP spec & PTAF comments [merge]
From: Steve Harris (S.W.Harris@ecs.soton.ac.uk)
Date: Sat Feb 08 2003 - 14:32:55 EET
On Fri, Feb 07, 2003 at 07:25:25 -0800, Tim Hockin wrote:
> > Now, there is a problem here: If you have a chain of plugins, and some
> > of them don't support silence, these will screw things up for the
> > silence aware plugins. However, if we apply silence detectors on the
> > outputs of plugins w/o silence support whenever they're sending to
> > plugins *with* silence support, things will work fine.
>
> Yeah. Or users can beat developers of dumb plugins for wasting CPU.
You guys really haven't thought this through very well, many plugins will
run slower, in all cases, if they have silence support than if they dont,
eg. delays, IIR filters.
Branching to fill your delay line with explit 0.0's intead of reading them
from a buffer of zeros doesn't help. We allready know that reverbs cant
support it at all. Efficieny reasons would also rule out flangers, delays,
most filters and choruses.
It would work OK with ring modulators, waveshapers and ...?
> In my mind this was the WHOLE reason :). I might build up a very
> complicated net of plugins for my track. If I tried to run all those
> plugins for every process-cycle, it would never finish in time. But the
> reality is that at any one time, my tracks are using maybe 35% of the whole
> net. Usually less. An optimization that allows a reverb to return almost
> immediately helps me to ensure I meet the deadline. I hate clicks and
> drop-outs.
>
> For live performance with XAP plugins, it is a big win.
I would never, ever use a silence detecting system live, you never
know when its going to suddenly wake up all the plugins and run out of CPU
power.
All it would take was a bit of unexpected noise on an input line and
suddenly the CPU load goes up 300%.
- Steve
This archive was generated by hypermail 2b28 : Sat Feb 08 2003 - 14:31:21 EET