[asterisk-dev] Correct abstraction for "audio processing" module

[Steve Underwood]

Johnathan Corgan wrote:

>I'm interested in developing one or more modules that would modify audio
>in a pass-through way, in real-time, and controllable via the dial plan.
>
>In effect, said module would receive audio frames, do some sort of
>arbitrary processing on them, and send a stream of frames out.
>
>In the dialplan, the module (if implemented as an application, which
>would be preferred) would be invoked sometime before the Dial() or
>Answer() applications and insert itself into the packet stream as
>appropriate to translate audio frames when receiving or dialing a call.
>
>Some applications for this would be things like:
>
>Audio Filtering (noise reduction, high/low pass)
>
>Pop-Click suppression
>
>Voice Scrambling/Encryption
>
>Pitch Shifting
>
>Transport protocol (but not codec) independent PLC
>
>Speaker identification--only let frames through that correspond to a
>recognized speaker identity
>
>etc.  More science fictiony things would be things like automated
>language translation.
>
>Anyway, are there "hooks" that * provides to inject oneself into a frame
>processing pipeline?  Or other way to accomplish the above (not the
>voice processing steps, but the * frame passing "glue").
>
>One thing that occurred to me would be to add this to chan_local, and
>intercept reads/writes, but that makes usage more difficult in the dialplan.
>  
>
There isn't really a mechanism for doing this kind of thing in a general 
way right now. Also, the specialised things, like codecs and smoothers, 
which are plugged into the audio path are one way things. If you want to 
implement something that works with both directions of audio, it will be 
something completely new, but quite useful.

Transport protocol (but not codec) independent PLC already exists, so you can cross that one off your list.

Regards,
Steve