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 _______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
