Interesting problem... is this box going to be some kind of conference bridge only, or should it also have mic and speakers connected to it allowing it to act as a phone as well as a gateway? /Dan Ted Merrill wrote: > Thanks, Dan. > > This is to add VoIP to a gateway box that spends a lot of time in > the kernel doing network processing... even with realtime scheduling, > i'm afraid that preemption by the kernel may result in unwanted latency. > > I would think that this might also be of interest to someone who is > dividing the work between two processors... > but i guess it is not an issue most people would face. > > -Ted > >> Putting pjmedia in kernel space in order to increase performance is the >> wrong way to go IMHO. If the performance and latency isn't what you require >> there are other ways to handle it than porting pjmedia to a kernel module. >> First of all read: >> http://trac.pjsip.org/repos/wiki/FAQ#Performance, and then read: >> http://trac.pjsip.org/repos/wiki/FAQ#media. >> >> If you're still having problems with performance there are(at least) two >> ways that has saved my day a couple of times: >> >> 1. Optimize the source code yourself. Coding the re-sample filter in >> in-line assembler can do wonders with the performance ;-) >> >> 2. When the sound device port is used as a clock source it is important >> that the thread handling the audio is interrupted as little as possible. To >> do this you may write you own audio back end that handles the sound in a >> thread with a high scheduling priority and a real-time scheduling >> policy(SCHED_RR or SCHED_FIFO). Note that the application needs to have >> superuser privileges in order to set the schedule policy to SCHED_RR or >> SCHED_FIFO. >> >> Regards, >> Dan >> >> Ted Merrill wrote: >>> Does anyone have opinions on whether putting putting pjmedia >>> into the linux kernel (with the remainder of pj stack in user >>> space for safety) would significantly reduce latency on a busy >>> system? The theory is that, in addition to avoiding round trips to >>> user space, the code in the kernel could be made to run at >>> signicantly higher priority than would be possible in user space >>> (aided by some suitable locking). >>> >>> Although the entire pj stack seems to have been ported to linux >>> kernel, there is no code provided to run pjmedia in a different >>> process (or processor!) than the upper part of the stack... >>> some sort of system of messages would need to be used to "remotely" >>> connect pjmedia with the upper stack. >>> Has anyone thought about issues involved with this? >>> >>> Has anyone recently run the entire pj stack in the linux kernel? >>> recently run parts of it? Is it still working? >>> >>> Thanks >>> Ted Merrill >>> >>> _______________________________________________ >>> Visit our blog: http://blog.pjsip.org >>> >>> pjsip mailing list >>> pjsip at lists.pjsip.org >>> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org >> _______________________________________________ >> Visit our blog: http://blog.pjsip.org >> >> pjsip mailing list >> pjsip at lists.pjsip.org >> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org > > > _______________________________________________ > Visit our blog: http://blog.pjsip.org > > pjsip mailing list > pjsip at lists.pjsip.org > http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org >
