> > > > > If yes, then I have to disagree here. Something like 'playing' with > > > audio-data is nothing the kernel should be concerned with. > > > This belongs in user-space and if you need realtime, then you should use > > > a > > > realtime OS or use RT-scheduling. Just putting such a code into > > > kernelspace > > > is a bad idea. > > > > What is so bad about "playing" with audio-data in kernel space? > > Besides preemption or RT-patches, it is not easy (and noboady does it) > to be 'nice' and have a fair scheduling. With such work in kernel, you just > say "I'm at the highest priority, I don't care about others". And that's > just wrong in the kernel.
That is actually what you want to do if your system is a PBX. You want to give as much as priority to your audio quality as you can. Even if this means that userspace applications get unfair scheduling results. If you take care of the critical audio handling (like EC) inside the kernel then your (maybe very unexperienced) users cannot easily disturb this process by causing a high load in user space, e.g. by running webservers, fileservers, mailservers or X on their PBX! It's far better to have good audio quality (with a working EC) and a slowed down webserver than a garbled audio and fast webserver. Just my 2 eurocents. > Normaly, the kernel just should provide access to the hardware > and basic functions for interaction with the hardware. > > > If you "play" with echo cancelation in user space you will need > > to de-jitter the audio first introducing more and more latency, so > > your echo cancelation becomes way more computationally expensive. > > That depends on what scheduling priority this task runs. If you don't want > to get interrupted by other tasks, then you need a higher priority. This is true in a perfect world. :) However there are lots of nasty things in your linux box (like harddisk controllers hogging your cpu, etc...) that make your system a non-realtime system. > > > > So the correct way is either the hardware supports it or the > > > application knows what to do with the data received, like DTMF. > > > > > > > Why should the application have to worry about things like echo > > cancelation? > > In the case of Asterisk and echo-cancel, this application is the > position where is makes sense. Otherwise you need a copy of the echo-cancel > code in each channel driver. > > > Zaptel is not only used by Asterisk but also by other > > projects. With EC in kernel space (which gets switched on and off > > by userspace) there is no need to reinvent the EC-wheel for every > > project. > > Okay, from that point of view it makes sense. On the other hand, something > like echo-cancel and DTMF is not channel specific and therefore should not > be part of that. Or would you add additional codecs into the channel driver? > I would even put more things into kernel space just to reduce latency. There are people that would even enjoy RTP in kernel space. Running things in userspace makes sense from a software architectural point of view. But in real life this can be very dangerous if you dont have control over the complete userspace (e.g. "users on crack" running "make bzImage -j"). > Armin Klaus _______________________________________________ Asterisk-Users mailing list Asterisk-Users@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
