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

Andrew Ford acf0659 at rit.edu
Thu Jun 4 18:29:56 BST 2009


You're right - I was thinking of just doing single-delay echo cancellation.
I was under the impression that in that case, processing each mic input
separately makes it easier/simpler to deal with algorithmically. If what
you're considering can cancel any arbitrary reflection, though, then that
sounds very promising. I'll defer to you on the details since my audio
knowledge does not go quite that low-level :)

--Andrew

2009/6/3 leon zadorin <leonleon77 at gmail.com>

> On 6/4/09, leon zadorin <leonleon77 at gmail.com> wrote:
>
> > Laterally-speaking and talking about a given room: tell me what is the
> > difference between adding another mic to a mono session vs adding
> > another very lively reflection surface in a room? Both will cause
> > comb-filtering, both will add delays, both will add a spectrally
> > modified signal with a non-linear phase characteristics. I mean one
> > may abuse the above question by stating that mic's gain could be
> > turned way way way up (i.e. reflection surface equivalent is to
> > reflect w/o any energy loss) but I think even so -- the parts of
> > causing more reflections/delay/etc. will hold. The point being -- be
> > it a reflection surface or a mic -- all those things do is to filter
> > and delay (in an LTI fashion). In fact a reflection surface would
> > cause more issues because it would introduce a 'feedback' of bouncing
> > waves between other surfaces before the whole thing even gets to a
> > mic.
>
> One minor addition w.r.t. the above example -- even if one was to add
> a mic and then speak into it really really closely :-) this would not
> cause any difference to the system -- because what we are mainly
> interested in is the
>  "communicated data->loudspeaker->ambience->mic" path (so that
> external sources, other than from communicated data are not a part of
> the 'concern equation' -- i.e. they don't need to be canceled, in fact
> -- doing so would be very very very bad indeed :-) :-) :-)
>
> OK -- that's it, no more DSP talk, period :-)
>
> Kind regards
> Leon Zadorin.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oakham.cs.ucl.ac.uk/pipermail/sumover-dev/attachments/20090604/03a95384/attachment.html


More information about the Sumover-dev mailing list