[Asterisk-Users] chan_capi-cm-0.5 release announcement

[Armin Schindler]

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