On Thu, 23 Jun 2005, Klaus-Peter Junghanns wrote: > > > > 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.
You can do this by just setting your PBX(audio stuff) process the highest priority and no mail-server will steal process time from it. That is no real reason to put code into kernel. > > 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. You have the same status when you are in kernel. > > > > > > 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. And then you will have one big kernel... That sounds like some poeple are not aware of scheduling priorities. > 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"). That's just not true. Set your critical application to SCHED_FIFO and priority 99 and no one can interrupt it. This even stops kernel-threads (in 2.6). Just because the administrator does not have the knowledge of how to set up correct priorities, is not a reason for going over the user-kernel boundary. If you need to respond to a hardware event (Interrupt) in a specific time, then the 'latency' reason is correct. By putting all these non-real-latency-relevant code into the kernel, you create exactly that kernel, which cannot be setup correctly when you really need low-latency on a specific part. Armin _______________________________________________ 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