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

[Steve Kann]

Jonathan,

    Check out http://svn.digium.com/view/asterisk/team/file/coremedia/  
-- Josh Colp has a branch (don't know how maintained it is), which 
implements something like this.

-SteveK


Johnathan Corgan wrote:

>[Resending, original didn't seem to make the list. -JC]
>
>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
>
>_______________________________________________
>--Bandwidth and Colocation provided by Easynews.com --
>
>asterisk-dev mailing list
>To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-dev
>
>  
>