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 >
