[Sumover-dev] Re: an AccessGrid question from Leon...

[Piers O'Hanlon]

Hi,

I'd agree that echo cancellation would be very handy - I've always
understood it to be very computationally intensive function - especially
when providing echo cancellation for a large room where one has to match and
remove audio from a relatively large time slot in real-time. They usually
seem to contain custom DSPs - but maybe one could utilise GPGPU/CUDA/OpenCL
to speed such things up on general purpose hardware? But if Leon has been
working on software DSP implementations then that is great! I know that the
Speex project has an echo canceller module (which seems to be the best open
source one available) but I've not had a chance to look at it closely. Then
there is the integration work for RAT but that is comparatively simple.

Andrew no offence taken on RAT - sometimes it can be good develop new tools
but as we have seen in the history of AccessGrid the work required to
develop replacements often too much for a single project or institution and
the projects never quite get finished. This probably down to the fact that
tools are rather complex beasts and do require a substantial effort to copy
or better. But if someone has effort then they're welcome to give it a shot.
When one is developing [open source] software it is often a choice between
modifying an existing tool or canabalising it and/or developing a totally
new tool.

On RAT and JACK - one can use the alsa driver to connect to jack:
http://alsa.opensrc.org/index.php/Jack_(plugin)
However on Unbuntu you'll have to buil the libasound_module_pcm_jack.so from
source as it isn't currently included:
https://wiki.ubuntu.com/MainInclusionReportJACK

As Leon mentions - there are nasty issues when one attempts to use two
separate cvards for input and output - though it is possible to resolve them
one needs some extract tricks to do so. Again ALSA can help - it is possible
to use your asounrc config to get ALSA to combin two sounds devices into
one:
http://alsa.opensrc.org/index.php/Asoundrc

As regards multiple sources for an E/C - as Leon mentioned I tend to agree
that the E/C itself doesn't need multiple inputs - one needs a mixer to
provide that. The mixer could be a software thing that controlls a
multichannel card like the RME Hammerfall or Delta 410 etc.

Piers

2009/6/1 Andrew Ford <acf0659 at rit.edu>

> Hi,
>
> Yes, software echo cancellation would be incredibly useful! As far as I
> know, most hardware echo cancelling solutions (beyond things like personal
> tabletop mics like the Chat50) end up being US$2000+, which might not be a
> problem for some big-budget institutions, but tends to be an issue for us :)
> It may also make things like AG more accessible to people at home due to not
> having to buy extra audio equipment, bridge/network issues notwithstanding.
>
> Polycom PVX, the drivers for Logitech webcams that have built-in mics, and
> Skype I think, all do software echo cancellation themselves, and I've heard
> of a Max/MSP implementation as well (but haven't been able to find much info
> on it), so it definitely seems possible.
>
> In fact, I've been toying around with the idea of developing an entire
> replacement for RAT (no offense Piers/other UCL devs :) since I think there
> are a lot of issues and room for improvement: the Mac audio code needs to be
> rewritten to use the new API, it has no way of using multiple audio devices,
> even just 2 for separate input/output, it has no way of sending multiple
> streams, it doesn't support any kind of routing to external programs (ie
> JACK - could be very useful for compression, limiting, EQ), it tends to
> crash often (on Windows at least) due to Mbus (side note: are there any
> other nice ways for it to communicate with vic or other video apps?), and
> the interface should probably be redesigned. Software AEC and JACK-esque
> routing to external programs could make things like the XAP, Converge, etc.
> entirely unnecessary.
>
> Let me know if there's any opportunity for any project like this - I do
> have experience with audio, and I'd love to be able to work on it. I'd start
> it up right now if I weren't somewhat busy with video stuff :)
>
> --Andrew
>
> 2009/5/29 leon zadorin <leonleon77 at gmail.com>
>
> Hello AccessGrid developers and visionaries :-)
>>
>> I have a quick question to ask...
>>
>> I was thinking of the nature of some R&D projects that I could propose
>> to various organisations/universities/etc for undertaking et al and
>> recalled the issue of audio 'echo-cancellation' when it comes to
>> network-distributed, collaborative meetings.
>>
>> I am not sure of the current status of 'echo-canceling' solutions but,
>> if my memory serves me right, there were numerous attempts to create
>> an open-source, software-based solution for 'echo-cancellation' --
>> with the majority of such attempts having come short of being
>> comparable to hardware-based, proprietary products (in terms of
>> quality, dynamic self-tuning etc).
>>
>> Presuming the above still holds and applying one's 'lateral thinking',
>> I was wondering: if I was able to make such a self-tuning,
>> dynamically-updating solution (both in software and deployable on
>> regular computers -- without the need for any special graphics cards
>> for extra processing power) -- how exactly useful or valuable would
>> this solution be? I mean -- is there any use for it nowdays at all?
>>
>> I am asking because I remembered that during my days of
>> forensic-analysis work there was a device which was doing a very
>> similar thing (in fact such concepts are not new to the digital signal
>> processing theory by a long shot and have been in public debate/view
>> for quite some time now) and I think know how to make one (i.e. how to
>> implement this theory in real-time on a modern computer) -- so there
>> is a reasonable degree of expectation for the solution to work (i.e.
>> self-tuning -adjusting software-based solution to cancel echoes in
>> real-time network collaborations)... to this extent, I suppose, the
>> whole uncertainty of "R" in "R&D" is somewhat reduced (albeit not
>> completely eliminated).
>>
>> Anyway -- no point in considering anything unless it is actually
>> needed :-) :-) :-)
>>
>> Kind regards
>> Leon Zadorin.
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oakham.cs.ucl.ac.uk/pipermail/sumover-dev/attachments/20090602/9173ccc0/attachment.html