Ecasound support in FreeSWITCH?
Hello everyone, I started a project using Asterisk + Ecasound to do call quality analysis: http://www.voip-info.org/wiki/view/Recqual I'd like to expand on this concept (that's about all there is). I just don't have as much time to spend on this as I'd like. It seems to me that Ecasound could be built into FreeSWITCH as a mod: http://ecasound.seul.org/ecasound/developer.php What I'm thinking is FreeSWITCH could dial a remote resource and give some params to mod_ecasound with the quality/type of audio it is expecting. Mod_ecasound could report what it's getting. For instance, you could dial any standard milliwatt test line and mod_ecasound would tell you how mangled the received audio is. Obviously you could also call your own resources, loop back into other areas of the dialplan, etc. I don't know how well suited ecasound is to doing this kind of analysis in real time or if it's the best way of going about this but it does seem like FreeSWITCH is an ideal platform for any future recqual development. Thoughts? -- Kristian Kielhofner http://blog.krisk.org http://www.submityoursip.com http://www.astlinux.org http://www.star2star.com
Ecasound is GPL so direct integration is out of the question if it requires linking to anything provided by Ecasound. /b On Feb 9, 2009, at 2:02 AM, Kristian Kielhofner wrote:
Hello everyone,
I started a project using Asterisk + Ecasound to do call quality analysis:
http://www.voip-info.org/wiki/view/Recqual
I'd like to expand on this concept (that's about all there is). I just don't have as much time to spend on this as I'd like.
It seems to me that Ecasound could be built into FreeSWITCH as a mod:
http://ecasound.seul.org/ecasound/developer.php
What I'm thinking is FreeSWITCH could dial a remote resource and give some params to mod_ecasound with the quality/type of audio it is expecting. Mod_ecasound could report what it's getting. For instance, you could dial any standard milliwatt test line and mod_ecasound would tell you how mangled the received audio is. Obviously you could also call your own resources, loop back into other areas of the dialplan, etc.
I don't know how well suited ecasound is to doing this kind of analysis in real time or if it's the best way of going about this but it does seem like FreeSWITCH is an ideal platform for any future recqual development.
Well placing calls and analyzing the results after the fact would avoid any licensing issues. As long as you have recordings that could be processed the concept should still work. - W PS: Yes haven't had any coffee yet so might me out of my mind =)
William, That's what I do now and it's somewhat clunky. There is one advantage: you can continually tweak ecasound params to look for other audio issues and reprocess the files. Other than that it seems like a module is the way to go. On Mon, Feb 9, 2009 at 9:35 AM, William Suffill <william.suffill@gmail.com> wrote:
Well placing calls and analyzing the results after the fact would avoid any licensing issues. As long as you have recordings that could be processed the concept should still work.
- W
PS: Yes haven't had any coffee yet so might me out of my mind =)
_______________________________________________ Freeswitch-dev mailing list Freeswitch-dev@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev http://www.freeswitch.org
-- Kristian Kielhofner http://blog.krisk.org http://www.submityoursip.com http://www.astlinux.org http://www.star2star.com
Hi Kristian, What you are doing now looks very elementary, and there is no real reason to use ecasound. I don't know what you intend to do as you flesh out this quality assessment, but its not clear to me where ecasound would ever be a big benefit in such a tool. Not using ecasound certainly simplifies its licencing issues. :-) Regards, Steve Kristian Kielhofner wrote:
William,
That's what I do now and it's somewhat clunky.
There is one advantage: you can continually tweak ecasound params to look for other audio issues and reprocess the files. Other than that it seems like a module is the way to go.
On Mon, Feb 9, 2009 at 9:35 AM, William Suffill <william.suffill@gmail.com> wrote:
Well placing calls and analyzing the results after the fact would avoid any licensing issues. As long as you have recordings that could be processed the concept should still work.
- W
PS: Yes haven't had any coffee yet so might me out of my mind =)
_______________________________________________ Freeswitch-dev mailing list Freeswitch-dev@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev http://www.freeswitch.org
Steve, At the moment it is very elementary and probably easily reproduced. It's also the first check I could come up with and it was good enough to help me identify my issues. As this tool/concept gets exposed to the real world and used in different applications, scenarios, etc it would be /very/ convenient to have the full power of ecasound and the LADSPA plugin architecture available at our disposal from FS. There are plenty of people out there (hint, hint) that know far more about audio processing, etc than I do. I'm sure they could come up with some very, very cool applications once FS audio can be put through ecasound/LADSPA (think mod_soundtouch on steroids). I don't want my lack of understanding and foresight to get in their way. Ecasound looks like the right tool for job and I'd hate to let something small like "licensing" get in the way ;) I've already e-mailed the creator for an LGPL exception but the message bounced. I'm looking for other addresses and contacts. Hmmm... Maybe we could skip ecasound and just implement a LADSPA host in FS (LADSPA is LGPL). My only concern here is the ability to write LADSPA plugins. The barrier to entry and learning curve is certainly higher than some basic ecasound params. On Fri, Feb 13, 2009 at 6:56 AM, Steve Underwood <steveu@coppice.org> wrote:
Hi Kristian,
What you are doing now looks very elementary, and there is no real reason to use ecasound. I don't know what you intend to do as you flesh out this quality assessment, but its not clear to me where ecasound would ever be a big benefit in such a tool.
Not using ecasound certainly simplifies its licencing issues. :-)
Regards, Steve
-- Kristian Kielhofner http://blog.krisk.org http://www.submityoursip.com http://www.astlinux.org http://www.star2star.com
Kristian Kielhofner wrote:
Steve,
At the moment it is very elementary and probably easily reproduced. It's also the first check I could come up with and it was good enough to help me identify my issues. As this tool/concept gets exposed to the real world and used in different applications, scenarios, etc it would be /very/ convenient to have the full power of ecasound and the LADSPA plugin architecture available at our disposal from FS.
There are plenty of people out there (hint, hint) that know far more about audio processing, etc than I do. I'm sure they could come up with some very, very cool applications once FS audio can be put through ecasound/LADSPA (think mod_soundtouch on steroids). I don't want my lack of understanding and foresight to get in their way.
Ecasound looks like the right tool for job and I'd hate to let something small like "licensing" get in the way ;) I've already e-mailed the creator for an LGPL exception but the message bounced. I'm looking for other addresses and contacts.
Hmmm... Maybe we could skip ecasound and just implement a LADSPA host in FS (LADSPA is LGPL). My only concern here is the ability to write LADSPA plugins. The barrier to entry and learning curve is certainly higher than some basic ecasound params.
Well, I had a look through ecasound, and it looks pretty useful for someone doing recording. It looks pretty useless for call analysis, though. As for mod_soundtouch, the current version is largely a toy, as it takes too much compute time for serious application. There will probably be a more telephony oriented version of the same concept available in the not too distant future. Steve
On Fri, Feb 13, 2009 at 12:38 PM, Steve Underwood <steveu@coppice.org> wrote:
Well, I had a look through ecasound, and it looks pretty useful for someone doing recording. It looks pretty useless for call analysis, though.
As for mod_soundtouch, the current version is largely a toy, as it takes too much compute time for serious application. There will probably be a more telephony oriented version of the same concept available in the not too distant future.
Steve
Steve, It proved to be quite useful for my application (analyzing recorded calls from Asterisk). I don't understand how it is useless for call analysis. Calls are just audio after all, right? I'm looking to build on this with FreeSWITCH. I can continue to analyze recorded files but it would be much cooler to do it in FS with a mod. I was just comparing functionality (manipulating the audio stream) with mod_soundtouch. -- Kristian Kielhofner http://blog.krisk.org http://www.submityoursip.com http://www.astlinux.org http://www.star2star.com
Maybe they are not as religious as some about why it's GPL, you can always ask them if they are interested in cooperating and perhaps grant lgpl in our case. MPL after all is even less restrictive than GPL, it's only up to the GPL author if it's compat with us or not. On Mon, Feb 9, 2009 at 2:27 AM, Brian West <brian@freeswitch.org> wrote:
Ecasound is GPL so direct integration is out of the question if it requires linking to anything provided by Ecasound.
/b
On Feb 9, 2009, at 2:02 AM, Kristian Kielhofner wrote:
Hello everyone,
I started a project using Asterisk + Ecasound to do call quality analysis:
http://www.voip-info.org/wiki/view/Recqual
I'd like to expand on this concept (that's about all there is). I just don't have as much time to spend on this as I'd like.
It seems to me that Ecasound could be built into FreeSWITCH as a mod:
http://ecasound.seul.org/ecasound/developer.php
What I'm thinking is FreeSWITCH could dial a remote resource and give some params to mod_ecasound with the quality/type of audio it is expecting. Mod_ecasound could report what it's getting. For instance, you could dial any standard milliwatt test line and mod_ecasound would tell you how mangled the received audio is. Obviously you could also call your own resources, loop back into other areas of the dialplan, etc.
I don't know how well suited ecasound is to doing this kind of analysis in real time or if it's the best way of going about this but it does seem like FreeSWITCH is an ideal platform for any future recqual development.
_______________________________________________ Freeswitch-dev mailing list Freeswitch-dev@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev http://www.freeswitch.org
-- Anthony Minessale II FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ AIM: anthm MSN:anthony_minessale@hotmail.com <MSN%3Aanthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com<PAYPAL%3Aanthony.minessale@gmail.com> IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888@conference.freeswitch.org <sip%3A888@conference.freeswitch.org> iax:guest@conference.freeswitch.org/888 googletalk:conf+888@conference.freeswitch.org<googletalk%3Aconf%2B888@conference.freeswitch.org> pstn:213-799-1400
This is true... I have in the past asked authors of libs if they would do LGPL and in most cases they do so. ;) /b On Feb 9, 2009, at 9:30 AM, Anthony Minessale wrote:
Maybe they are not as religious as some about why it's GPL, you can always ask them if they are interested in cooperating and perhaps grant lgpl in our case. MPL after all is even less restrictive than GPL, it's only up to the GPL author if it's compat with us or not.
I've asked... On Mon, Feb 9, 2009 at 11:22 AM, Brian West <brian@freeswitch.org> wrote:
This is true... I have in the past asked authors of libs if they would do LGPL and in most cases they do so. ;)
/b
On Feb 9, 2009, at 9:30 AM, Anthony Minessale wrote:
Maybe they are not as religious as some about why it's GPL, you can always ask them if they are interested in cooperating and perhaps grant lgpl in our case. MPL after all is even less restrictive than GPL, it's only up to the GPL author if it's compat with us or not.
_______________________________________________ Freeswitch-dev mailing list Freeswitch-dev@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev http://www.freeswitch.org
-- Kristian Kielhofner http://blog.krisk.org http://www.submityoursip.com http://www.astlinux.org http://www.star2star.com
One more thing... Would it matter if the code for the module lives out of tree? Or is it the compiling, linking, loading, etc that's the problem? On Mon, Feb 9, 2009 at 11:37 AM, Kristian Kielhofner <kristian.kielhofner@gmail.com> wrote:
I've asked...
On Mon, Feb 9, 2009 at 11:22 AM, Brian West <brian@freeswitch.org> wrote:
This is true... I have in the past asked authors of libs if they would do LGPL and in most cases they do so. ;)
/b
On Feb 9, 2009, at 9:30 AM, Anthony Minessale wrote:
Maybe they are not as religious as some about why it's GPL, you can always ask them if they are interested in cooperating and perhaps grant lgpl in our case. MPL after all is even less restrictive than GPL, it's only up to the GPL author if it's compat with us or not.
_______________________________________________ Freeswitch-dev mailing list Freeswitch-dev@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev http://www.freeswitch.org
-- Kristian Kielhofner http://blog.krisk.org http://www.submityoursip.com http://www.astlinux.org http://www.star2star.com
-- Kristian Kielhofner http://blog.krisk.org http://www.submityoursip.com http://www.astlinux.org http://www.star2star.com
Well the end user is free to combine anything they wish... its the distribution that gets you! ;) /b On Feb 9, 2009, at 12:00 PM, Kristian Kielhofner wrote:
One more thing...
Would it matter if the code for the module lives out of tree? Or is it the compiling, linking, loading, etc that's the problem?
So, for example: mod_ecasound could live out of tree and it would be up to the user to download, compile, and install it? Is there currently much of a mechanism for building out of tree modules for FreeSWITCH (like Apache apxs)? I hate to see good technology be stifled by licensing issues and it seems to me the MPL vs. GPL issue comes up quite a bit. Don't get me wrong; I'd much rather see everything in tree for a variety of reasons. However, licensing is licensing. On Mon, Feb 9, 2009 at 1:04 PM, Brian West <brian@freeswitch.org> wrote:
Well the end user is free to combine anything they wish... its the distribution that gets you! ;)
/b
On Feb 9, 2009, at 12:00 PM, Kristian Kielhofner wrote:
One more thing...
Would it matter if the code for the module lives out of tree? Or is it the compiling, linking, loading, etc that's the problem?
_______________________________________________ Freeswitch-dev mailing list Freeswitch-dev@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev http://www.freeswitch.org
-- Kristian Kielhofner http://blog.krisk.org http://www.submityoursip.com http://www.astlinux.org http://www.star2star.com
fsxs exists for such a purpose. /b On Feb 9, 2009, at 12:24 PM, Kristian Kielhofner wrote:
So, for example:
mod_ecasound could live out of tree and it would be up to the user to download, compile, and install it?
Is there currently much of a mechanism for building out of tree modules for FreeSWITCH (like Apache apxs)?
I hate to see good technology be stifled by licensing issues and it seems to me the MPL vs. GPL issue comes up quite a bit. Don't get me wrong; I'd much rather see everything in tree for a variety of reasons. However, licensing is licensing.
What haven't you guys thought of? ;) On Mon, Feb 9, 2009 at 1:28 PM, Brian West <brian@freeswitch.org> wrote:
fsxs exists for such a purpose.
/b
-- Kristian Kielhofner http://blog.krisk.org http://www.submityoursip.com http://www.astlinux.org http://www.star2star.com
Also, you can just unpack an out of tree mod into src/mod/mod_foo folder , add it to modules.conf and build it. mod_openzap works that way we check it out separately with the openzap lib and reference the folder in modules.conf When you said you asked, was that just today you asked and they did not answer yet? or, you have asked in the past and they said no? You can also defeat gpl/mpl linking issues by doing it over a socket which is kinda dumb and should be all you need to prove it's not worth bothering to try and outlaw any 2 open source applications from being linked regardless of the license. On Mon, Feb 9, 2009 at 12:49 PM, Michael Collins <msc@freeswitch.org> wrote:
On Mon, Feb 9, 2009 at 10:38 AM, Kristian Kielhofner <kristian.kielhofner@gmail.com> wrote:
What haven't you guys thought of? ;)
Not much, at least from my 3 years of interacting with the FS devs... :) -MC
_______________________________________________ Freeswitch-dev mailing list Freeswitch-dev@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev http://www.freeswitch.org
-- Anthony Minessale II FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ AIM: anthm MSN:anthony_minessale@hotmail.com <MSN%3Aanthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com<PAYPAL%3Aanthony.minessale@gmail.com> IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888@conference.freeswitch.org <sip%3A888@conference.freeswitch.org> iax:guest@conference.freeswitch.org/888 googletalk:conf+888@conference.freeswitch.org<googletalk%3Aconf%2B888@conference.freeswitch.org> pstn:213-799-1400
On Mon, Feb 9, 2009 at 2:31 PM, Anthony Minessale <anthony.minessale@gmail.com> wrote:
Also, you can just unpack an out of tree mod into src/mod/mod_foo folder , add it to modules.conf and build it. mod_openzap works that way we check it out separately with the openzap lib and reference the folder in modules.conf
Ah yes, I've seen that.
When you said you asked, was that just today you asked and they did not answer yet? or, you have asked in the past and they said no?
I asked today and I have not heard back yet.
You can also defeat gpl/mpl linking issues by doing it over a socket which is kinda dumb and should be all you need to prove it's not worth bothering to try and outlaw any 2 open source applications from being linked regardless of the license.
I don't want no sockets! ;) -- Kristian Kielhofner http://blog.krisk.org http://www.submityoursip.com http://www.astlinux.org http://www.star2star.com
participants (6)
-
Anthony Minessale
-
Brian West
-
Kristian Kielhofner
-
Michael Collins
-
Steve Underwood
-
William Suffill