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