[PD] Pd + asterisk?

[Hans-Christoph Steiner]

On Dec 2, 2007, at 8:19 PM, Russell Bryant wrote:

> drh270 wrote:
>> This sounds great!
>
> Cool, thanks for the interest.  :)
>
>> Chris, in an earlier post mentioned using OSC, he was using a Python
>> script, so communicating via OSC may be a starting point.
>
> Yeah, I saw that.  Thanks for bringing up OSC again.  The trick is  
> going to be
> to have a real-time interface that provides both media and call  
> signaling
> access.  I could put together a native interface in Asterisk for  
> OSC so that
> digit presses could be sent out as OSC messages.  Then, optionally,  
> at the same
> time, the audio could be flowing in and out of Pd, as well.
>
>> Seems to me that perhaps a SIP soft phone may be trickier because rtp
>> audio comes in on many ports, what about a Pd iax2 phone object and
>> have it listen to the audio on port 4569?
>
> SIP is definitely much more complicated than IAX2, and you won't  
> see me writing
> a SIP interface.  I would definitely go for IAX2.  However, I would  
> say that
> it's not quite for the reason that you mentioned.  For RTP with  
> SIP, ou always
> know what port the audio is going to come in on, because you're in  
> charge of
> picking it.
>
> One issue that is on my mind, is scalability.  It's clear to me how  
> I could
> implement a Pd patch that could process 1, 2, 3, ... calls, but it  
> is not yet
> clear to me how it could support any number N calls, up to what the  
> network and
> processing power can support.  However, it may be just be that my  
> Pd knowledge
> is still very lacking.  :)

That is Pd's weak point in general: multiple instances of processes.   
Since everything running has a physical representation, that means  
that each instance of a call in Pd would need it's own physical  
representation in Pd.  Currently, it isn't possible to load a new  
patch without an interruption in the DSP.  That interruption could be  
just a click, but it's there nonetheless.

Whenever I need something that dynamically allocates new voices,  
which is probably the most common Pd parallel to Asterisk's calls, I  
use an "nqpoly4" which pre-allocates a number of instances of the  
objectclass I am using.  Then messages to processed are sent to that  
already existing pool.  It works well, in practice, but it is not  
very resource-efficient.

There has been talk in the past about some optimizations that would  
allow dynamic allocation without the interruption, but not a lot of  
work done in that regard since it's pretty complicated.  In  
particular, the ideas I remember were building a new DSP chain in the  
background, then swapping it in.  The other was figuring out how to  
only rebuild the parts of the DSP chain that changed.

.hc



------------------------------------------------------------------------ 
----

As we enjoy great advantages from inventions of others, we should be  
glad of an opportunity to serve others by any invention of ours; and  
this we should do freely and generously.         - Benjamin Franklin