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