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

[Johnathan Corgan]

Christian Richter wrote:

> sounds cool, look at ast_read and ast_write, these are the places where
> the frames go through :-)
> 
> Look at how the spying stuff is implemented this may help.

I know about ast_read and ast_write.

What I'm looking to understand is how to implement an audio "hook" into
an existing or soon to exist bridge between two channels or between a
channel and an application.

Heres my (limited) understand of how a call works:

A channel comes up and lands in a context in the dialplan.  The dialplan
executes, and eventually gets to a dial application or to an application
that answers the call.  Either way, some thread in * will read frames
from the first channel and write them to the dial-created second channel
via a bridge, or to the application that answered the call.  And the
same in the other direction.

What I want to implement is an application that would run in the
dialplan before the call is answered, that says, "hey, *, can you insert
me in the processing path?  Those frames you were going to send to that
other channel?  Send them to me instead, and I'll give them back to you,
possibly changed, and you can do whatever you were going to do
originally with them."

I'll look into the source code for the spying stuff .I'm not at all
familiar with how or what that does, other than what the name implies
and seeing references to it on the users list.

One brute force way I see to do this is to implement something like
chan_local, where my application would be called in the dialplan, and it
would call into another context.  But this carries all the overhead of
being a full channel and having to deal with all the states and events
around that.  This could also be done by patching chan_local itself,
which already does all this, but now I'd be stuck with somehow having to
add functionality to chan_local for every different audio processing
application I'm thinking of.

So I'm back to--can I write an application that "masquerades" its audio
read/write functions on top of the existing channel that is up when it
gets called, and then stays running as a thread as the dialplan proceeds?

-Johnathan