Re: [Asterisk-Users] chan_capi-cm-0.5 release announcement
On Sun, 26 Jun 2005, Stefan Gofferje wrote: Armin Schindler schrieb: On Sat, 25 Jun 2005, Stefan Gofferje wrote: Armin Schindler schrieb: I have added busy()/congestion() support to CVS HEAD now, can you please test if it works for you? Works perfectly well! Also CallingPres(32) does work! The only thing I wonder about is a delay. I know there is a delay. Currently the calling party is 'alerted' every time by default and this is not correct for calls which shall not be accepted. I noted a number of bugs and a feature-request at SF :-). Yes, maybe you would like to implement some of those feature-requests ? ;-) 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
Re: [Asterisk-Users] chan_capi-cm-0.5 release announcement
On 11:28:09 June 27, 2005 Armin Schindler [EMAIL PROTECTED] wrote: Yes, maybe you would like to implement some of those feature-requests ? ;-) I would love to if I were a bright programmer :-). --Stefan -- (o_ Stefan Gofferje | Linux Systems Specialist //\ Reg'd Linux User #247167 | Network Security Specialist V_/_ Heckler Koch - the original point and click interface ___ 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
Re: [Asterisk-Users] chan_capi-cm-0.5 release announcement
Armin Schindler schrieb: On Sat, 25 Jun 2005, Stefan Gofferje wrote: Armin Schindler schrieb: I have added busy()/congestion() support to CVS HEAD now, can you please test if it works for you? Works perfectly well! Also CallingPres(32) does work! The only thing I wonder about is a delay. I know there is a delay. Currently the calling party is 'alerted' every time by default and this is not correct for calls which shall not be accepted. I noted a number of bugs and a feature-request at SF :-). Regards, Stefan -- (o_ Stefan Gofferje | Linux Systems Specialist //\ Reg'd Linux User #247167 | Network Security Specialist V_/_ Heckler Koch - the original point and click interface ___ 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
Re: [Asterisk-Users] chan_capi-cm-0.5 release announcement
On Thu, 23 Jun 2005, Massimo De Nadal wrote: Have you planned to integrate some echo cancel feature ? Echo cancelling (if the card supports it) is already implemented. As far as I know the Eicon Diva Server cards are the only cards supporting echo cancel via onboard DSPs. Armin Armin Schindler ha scritto: Hi all, I would like to announce the first release of the chan_capi channel driver on sourceforge.net The package is available for download with name chan_capi-cm-0.5 and is the current CVS HEAD. It is derived from the chan_capi-0.4.0PRE1 of kapejod. The main changes are: - complete rework - fix race-conditions - fix call state handling - rework of debug/verbose messages - added capiFax feature (provided by Frank Sautter) - auto-config (compile and work with Asterisk CVS-HEAD and older versions) - use with ELinOS cross-toolbox and project handling For the versioning, I have decided to use the name extention 'cm' to avoid confusion with kapejod's version. This first release is 0.5 (not 0.1) because the base is 0.4.0. Only the major and the minor number will be used. The exception to have a third number (patch-version) will be added for fixup-patches only. Feedback welcome. Armin PS: sorry for cross-posting. ___ 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
Re: [Asterisk-Users] chan_capi-cm-0.5 release announcement
Armin Schindler ha scritto: Have you planned to integrate some echo cancel feature ? Echo cancelling (if the card supports it) is already implemented. I think he was talking about the software echo suppressor As far as I know the Eicon Diva Server cards are the only cards supporting echo cancel via onboard DSPs. AVM active cards do not support it? Sergio ___ 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
Re: [Asterisk-Users] chan_capi-cm-0.5 release announcement
Have you planned to integrate some echo cancel feature ? Besides the Eicon-CAPI feature there is an echosquelch in the driver. Elmar ___ 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
Re: [Asterisk-Users] chan_capi-cm-0.5 release announcement
Yes, I know. I was meaning the software thing. Diva server cancels echo via dsp only with new revisions boards (older boards are not able to run newer drivers with echo cancellation). Fritz cards don't cancel echo anyway. And echo squelch is only a trick that doesn't really solve the problem. Is it possible to port zap echo cancelor to different channels like chan_capi ? Armin Schindler ha scritto: On Thu, 23 Jun 2005, Massimo De Nadal wrote: Have you planned to integrate some echo cancel feature ? Echo cancelling (if the card supports it) is already implemented. As far as I know the Eicon Diva Server cards are the only cards supporting echo cancel via onboard DSPs. 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
Re: [Asterisk-Users] chan_capi-cm-0.5 release announcement
Sergio Chersovani wrote: As far as I know the Eicon Diva Server cards are the only cards supporting echo cancel via onboard DSPs. AVM active cards do not support it? No. Avm active cards are basically multi fritz boards running the same firmware onboard instead of charging pc cpu. They are surely more stable than fritz cards, but offer the same features (even with more channels). ___ 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
Re: [Asterisk-Users] chan_capi-cm-0.5 release announcement
On Thu, 23 Jun 2005, Massimo De Nadal wrote: Yes, I know. I was meaning the software thing. Diva server cancels echo via dsp only with new revisions boards (older boards are not able to run newer drivers with echo cancellation). Which boards don't support that? If DSPs on board, echo-cancel should be available. Fritz cards don't cancel echo anyway. And echo squelch is only a trick that doesn't really solve the problem. Is it possible to port zap echo cancelor to different channels like chan_capi ? Yes, that should be possible. But I don't think a channel driver (and each channel driver) should do that on its own. Software echo cancelling belongs in a common part of Asterisk. Armin Armin Schindler ha scritto: On Thu, 23 Jun 2005, Massimo De Nadal wrote: Have you planned to integrate some echo cancel feature ? Echo cancelling (if the card supports it) is already implemented. As far as I know the Eicon Diva Server cards are the only cards supporting echo cancel via onboard DSPs. 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 ___ 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
Re: [Asterisk-Users] chan_capi-cm-0.5 release announcement
Armin Schindler ha scritto: Which boards don't support that? If DSPs on board, echo-cancel should be available. I have in my hands right now a DIVA Server BRI-2M-PCI (not the 2.0 version) which own its dsp but doesn't echo cancel, due to old capi drivers which don't support this feature. Newer eicon drivers won't run on this board. Yes, that should be possible. But I don't think a channel driver (and each channel driver) should do that on its own. Software echo cancelling belongs in a common part of Asterisk. I strongly agree. But asterisk doesn't seem to work this way. Zap channel has it's own echo cancel engine. Other channels don't. This is so sad :-( Why not implement a really common echo cancel api usable from any channel ?? ___ 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
Re: [Asterisk-Users] chan_capi-cm-0.5 release announcement
On Thu, 23 Jun 2005, Massimo De Nadal wrote: Armin Schindler ha scritto: Which boards don't support that? If DSPs on board, echo-cancel should be available. I have in my hands right now a DIVA Server BRI-2M-PCI (not the 2.0 version) which own its dsp but doesn't echo cancel, due to old capi drivers which don't support this feature. Newer eicon drivers won't run on this board. Do you talk about the driver package from Eicon? What about the driver from melware.net ? Yes, that should be possible. But I don't think a channel driver (and each channel driver) should do that on its own. Software echo cancelling belongs in a common part of Asterisk. I strongly agree. But asterisk doesn't seem to work this way. Zap channel has it's own echo cancel engine. Other channels don't. This is so sad :-( Why not implement a really common echo cancel api usable from any channel ?? Exactly! I'm not familiar with the Asterisk API, but it could be some plugin like res_* ... Maybe this belongs to the Asterisk-Dev list. 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
Re: [Asterisk-Users] chan_capi-cm-0.5 release announcement
Yes, that should be possible. But I don't think a channel driver (and each channel driver) should do that on its own. Software echo cancelling belongs in a common part of Asterisk. I strongly agree. But asterisk doesn't seem to work this way. Zap channel has it's own echo cancel engine. Other channels don't. This is so sad :-( Why not implement a really common echo cancel api usable from any channel ?? Exactly! I'm not familiar with the Asterisk API, but it could be some plugin like res_* ... Maybe this belongs to the Asterisk-Dev list. Armin I strongly disagree. :-) You dont want to do echo cancelation in userspace. Especially not on a non-realtime operating system. To make echo cancelation work it has to be as close to the line interface as possible. Also the frames have to be as small as possible. This rules out capi pretty much. best regards Klaus -- Klaus-Peter Junghanns ___ 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
Re: [Asterisk-Users] chan_capi-cm-0.5 release announcement
On Thu, 23 Jun 2005, Klaus-Peter Junghanns wrote: Yes, that should be possible. But I don't think a channel driver (and each channel driver) should do that on its own. Software echo cancelling belongs in a common part of Asterisk. I strongly agree. But asterisk doesn't seem to work this way. Zap channel has it's own echo cancel engine. Other channels don't. This is so sad :-( Why not implement a really common echo cancel api usable from any channel ?? Exactly! I'm not familiar with the Asterisk API, but it could be some plugin like res_* ... Maybe this belongs to the Asterisk-Dev list. Armin I strongly disagree. :-) You dont want to do echo cancelation in userspace. Especially not on a non-realtime operating system. To make echo cancelation work it has to be as close to the line interface as possible. Also the frames have to be as small as possible. This rules out capi pretty much. If you don't want echo-canceling in user-space, then neither Asterisk nor any chan_* plugin should do it. I don't know the zap channel code, but does the zap echo-cancel-code is inside a kernel module? 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. So the correct way is either the hardware supports it or the application knows what to do with the data received, like DTMF. 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
Re: [Asterisk-Users] chan_capi-cm-0.5 release announcement
Am Donnerstag, den 23.06.2005, 12:41 +0200 schrieb Armin Schindler: I strongly disagree. :-) You dont want to do echo cancelation in userspace. Especially not on a non-realtime operating system. To make echo cancelation work it has to be as close to the line interface as possible. Also the frames have to be as small as possible. This rules out capi pretty much. If you don't want echo-canceling in user-space, then neither Asterisk nor any chan_* plugin should do it. I don't know the zap channel code, but does the zap echo-cancel-code is inside a kernel module? Yes, sir. 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? 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. 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? 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. 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
Re: [Asterisk-Users] chan_capi-cm-0.5 release announcement
On Thu, 23 Jun 2005, Klaus-Peter Junghanns wrote: Am Donnerstag, den 23.06.2005, 12:41 +0200 schrieb Armin Schindler: I strongly disagree. :-) You dont want to do echo cancelation in userspace. Especially not on a non-realtime operating system. To make echo cancelation work it has to be as close to the line interface as possible. Also the frames have to be as small as possible. This rules out capi pretty much. If you don't want echo-canceling in user-space, then neither Asterisk nor any chan_* plugin should do it. I don't know the zap channel code, but does the zap echo-cancel-code is inside a kernel module? Yes, sir. 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. 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. 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? 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
Re: [Asterisk-Users] chan_capi-cm-0.5 release announcement
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
Re: [Asterisk-Users] chan_capi-cm-0.5 release announcement
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
Re: [Asterisk-Users] chan_capi-cm-0.5 release announcement
Have you planned to integrate some echo cancel feature ? Armin Schindler ha scritto: Hi all, I would like to announce the first release of the chan_capi channel driver on sourceforge.net The package is available for download with name chan_capi-cm-0.5 and is the current CVS HEAD. It is derived from the chan_capi-0.4.0PRE1 of kapejod. The main changes are: - complete rework - fix race-conditions - fix call state handling - rework of debug/verbose messages - added capiFax feature (provided by Frank Sautter) - auto-config (compile and work with Asterisk CVS-HEAD and older versions) - use with ELinOS cross-toolbox and project handling For the versioning, I have decided to use the name extention 'cm' to avoid confusion with kapejod's version. This first release is 0.5 (not 0.1) because the base is 0.4.0. Only the major and the minor number will be used. The exception to have a third number (patch-version) will be added for fixup-patches only. Feedback welcome. Armin PS: sorry for cross-posting. ___ 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 ___ 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
