[Freeswitch-dev] FreeSwitch + ISDN + analog phone adapters - status

Jan Berger janvb at live.com
Fri Jan 30 17:40:58 PST 2009


I would do this very differently.
 
They key to performance is to reduce memcpy and malloc to a minimum. 
 
1. You feed a page from PCI card and swap this over on interrupt/timer - and at this point you copy data to channel buffer or directly to next B channel.
 
The channel buffers can be shared OS memory, meaning that you write from the PCI card in one end and read (directly from buffer) from app in the other end. Also create the channel buffer as a sircular list of packets and you have no malloc involved.
 
You can also use this for messaging between threads and even apps - it is a well known and extremely fast technique. also let the IPC fall back to IP and you could start spreading FreeSWITCH modules across a network.
 
I have some code somewher that does this so I can set up a demo once I return in a weeks time. 
 
Jan
 



Date: Fri, 30 Jan 2009 17:16:19 -0600From: anthony.minessale at gmail.comTo: freeswitch-dev at lists.freeswitch.orgSubject: Re: [Freeswitch-dev] FreeSwitch + ISDN + analog phone adapters - statusI think the goal would be to reduce the number of trips to and from userspace by doing the multiplexing in userspace to avoid the context switches of reading every logical channel as a device.
On Fri, Jan 30, 2009 at 4:45 PM, Jan Berger <janvb at live.com> wrote:

What do you want to achieve by moving the entire span up in user space unprocessed?
 Jan> From: hselasky at c2i.net
> To: freeswitch-dev at lists.freeswitch.org> Date: Fri, 30 Jan 2009 18:11:09 +0100
> Subject: Re: [Freeswitch-dev] FreeSwitch + ISDN + analog phone adapters - status> 


> On Friday 30 January 2009, Michael Jerris wrote:> > Another useful advantage without the latency tradeoff is to read a> > full span or card every 1ms (or whatever sane interval) and chop up> > the bytes in userland. The latency argument dies if you are bridging> > to voip, so if you can handle bridging the tdm to tdm channels in> > kernel space, you could easily get away with 10ms reads to user space> > as well.> >> > Mike> > Hi,> > Got your point.> > In between:> > I see more in Jan's argument. 48x30 bytes = 1440 bytes, which is an > interesting size for full span E1.> > --HPS> > _______________________________________________> Freeswitch-dev mailing list> Freeswitch-dev at lists.freeswitch.org> http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev> http://www.freeswitch.org

What can you do with the new Windows Live? Find out_______________________________________________Freeswitch-dev mailing listFreeswitch-dev at lists.freeswitch.orghttp://lists.freeswitch.org/mailman/listinfo/freeswitch-devUNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-devhttp://www.freeswitch.org-- Anthony Minessale IIFreeSWITCH http://www.freeswitch.org/ClueCon http://www.cluecon.com/AIM: anthmMSN:anthony_minessale at hotmail.comGTALK/JABBER/PAYPAL:anthony.minessale at gmail.comIRC: irc.freenode.net #freeswitchFreeSWITCH Developer Conferencesip:888 at conference.freeswitch.orgiax:guest at conference.freeswitch.org/888googletalk:conf+888 at conference.freeswitch.orgpstn:213-799-1400
_________________________________________________________________
More than messages–check out the rest of the Windows Live™.
http://www.microsoft.com/windows/windowslive/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-dev/attachments/20090131/3ef40094/attachment.html 


More information about the Freeswitch-dev mailing list