[Asterisk-Users] Re: Audio filters (was: feature - VM gain adjust?)

[Steven Critchfield]

On Wed, 2004-07-14 at 09:11, John Todd wrote:
> At 2:11 PM +0200 on 7/13/04, Holger Schurig wrote:
> >  > liarliar.sourceforge.net gives you something, its still in development.
> >
> >Hehe, imagine a phone where you see a red LED flashing if the other person
> >lies to you.
> >
> >
> >
> >When you thing about audio-plugins, you should think more into the
> >direction of LADSPA, see http://www.ladspa.org/
> >
> >Amplifier: http://plugin.org.uk/ladspa-swh/docs/ladspa-swh.html#tth_sEc2.5
> >Compressor:
> >http://plugin.org.uk/ladspa-swh/docs/ladspa-swh.html#tth_sEc2.35
> >
> >There are possible others there as well.
> 
> 
> LADSPA does indeed seem to be a good fit for such a project, though 
> it is LGPL'ed and would thus be problematic to include into *'s main 
> CVS tree.  However, perhaps some generic filter hooks could be built 
> into * to allow insertion of LADSPA or LADSPA-like loops.

LGPL should be good. As I understand LGPL, it is like a cross of BSD and
GPL. It allows you to use it in any product without the product becoming
GPLed but any modification of the API needs to be shared back. 

> Even if LADSPA were to be integrated, the API would probably need to 
> be modified such that it could be controlled by "external" programs.
> 
> Live manipulation of the stream parameters could be done in two ways 
> (maybe more, haven't thought about it much):  Asterisk's RTP stack 
> would have to intercept DTMF (because it's RFC2833, or INFO, or 
> whatever) and then call out to some API that would permit 
> manipulation of the stream.  That's difficult.  An alternate method 
> would be to intercept DTMF within Asterisk, close the LADSPA stream 
> down, and launch the API call again with different parameters (this 
> would be easier, I suppose.)  This second method might even be 
> transparent to the end user(s) if done fast enough.  This second 
> method also assumes that Dial is capable of intercepting DTMF, doing 
> some dialplan logic, and then re-connecting the two legs together 
> without hanging up either leg (see my many, many previous discussions 
> on this topic.)

As you come to the conclusion late in this last paragraph, you are
looking at a seperate problem. DTMF modifications and all is a feature
that isn't _necessary_ for this. For a great majority of us, it would be
nice enough to be able to apply filters to the stream from the dialplan
and let them stay static. 

Specifically the origination of this thread was normalization.
Normalization shouldn't need any modification after it is started. The
other mentioned filter was stress analysis, again no need to modify it's
params after it starts. 

> All in all, not a simple project, but probably a good project for a 
> graduate student who is working on practical applications of audio 
> filtering programs.

Guess we need to look at app_monitor and see how it wedges itself into
the audio stream and then maybe just start there and move the actuall
writing of audio out to a filter to be pluged in. Thinking of it like
that, it shouldn't take too much effort probably. 
-- 
Steven Critchfield <critch at basesys.com>