Sorry--I left out this one: xcov-2048
On Thu, May 7, 2015 at 5:11 PM, Charles Z Henry <[email protected]> wrote: > Hi Mario, > > I know how to solve this problem, but I'm only part-way there. I have a > similar problem, rejecting feedback when processing acoustic instruments. > I'm sorry I didn't post what I've got sooner--it needs some more work. I > can't really tell if I'll be finished with a decent patch soon. > > I'm almost through with the derivation in high-level symbolic math, so you > can follow along with the patch and work on it too. > > > See the latency tester first. It plays noise from to [dac~] and pics up the > signal from [adc~]. If you want to get a really clean graph for measuring > your system latency, do a loopback test with the cable running from output > to input on your audio interface. It should run reasonably well over > loudspeakers and will tell you the round trip latency. There are two > sliders where you can adjust delay to the input (mic) signal or the output > (speaker) signal. > > > Next, there's the spectrum analyzer patch. Open the spect-2048_test.pd > patch, then right click on [spect-2048] and open it. This solves the > spectrum analysis problem on block size 2048. The result is just written to > some tables in [spect-2048], for you to visually see it. > > When it's set to run on block size 16384, it needs to have about 90-100 ms > of latency (don't even try opening it, without the audio buffer length > turned up). > > Once you've captured an impulse with the spectrum analyzer as it is now, > you'd have to save the impulse to a file and then re-open with your runtime > patch (and lower latency settings). The patch spect-16384_test.pd patch > does a better job of calculating the impulse response than the 2048 block > size patch. > > > I'd like to have reduced latency to run the spectrum analyzer patch with > larger block sizes (for which I need a different [xcov~] that works well on > overlapped block sizes). The syntax of [xcov~] is already so ugly and will > get worse with overlapped blocks. > > Also, the spectrum analyzer math needs a little work. More to come... > > > Chuck > > > > On May 7, 2015 7:15 AM, "Mario Mey" <[email protected]> wrote: >> >> Yes, as I said in the mail, not only the the time of the delay is very >> very short that it would be very difficult for me to find "at hand", also, >> as you say, this time would be variable. My system don't work... I knew it. >> >> I took a look to some pages (*), but I only understand... the title of the >> mails and the PDF filename. The texts are chinese for me. I didn't know that >> echo cancellation is, as Peter Parker said, "quite a substantial topic"... >> and it is out of my hands to try different EC systems. No time, no >> knowledge, no time... no time. >> >> Also, there's http://grh.mur.at/software/adaptive.html... but I don't know >> how to test it. >> >> I made a diagram of my system... if anyone knows which echo cancellation >> system would work for me... I would reallly appreciate it. >> >> Thank you. >> >> (*) >> http://comments.gmane.org/gmane.comp.multimedia.puredata.general/63658 >> >> https://ccrma.stanford.edu/~eberdahl/Projects/FeedbackCancellation/FeedbackCancellation.pdf >> Peter Parker sent me this link, but I have to pay to see it: >> http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=1146062. >> >> El 04/05/15 a las 13:48, Spencer Russell escibió: >> >> You're not likely to get very good results with just a single delay. The >> way these systems normally work (e.g. on phones and conferencing >> systems) is to continuously estimate the transfer function between the >> speaker and the microphone (impulse response in the time domain). Then >> you take the received signal, convolve it with the inverse of the >> impulse response, and mix it into the signal you receive from the >> microphone. >> >> The diagram at the bottom of this page[1] is a pretty good one to >> understand what's going on. >> >> -s >> >> http://www.speex.org/docs/manual/speex-manual/node4.html >> >> >> >> On Mon, May 4, 2015, at 10:18 AM, Mario Mey wrote: >> >> Hi, there. 2 years ago, I created this thread on the forum: >> http://forum.pdpatchrepo.info/topic/7340/echo-supressor. After talking about >> dBs, I thought I acchived what I was looking for. But no. Nor close. >> >> My last non-replied post on september 2014 says: >> >> >> Bringing back to life an old thread... I tried to make this patch work >> LIVE... and it is not as thought. >> >> To make this patch work (*1), I should find the perfect delay to suppress >> the audio. Using 44100, the delay time can vary in 0.0226ms. So... it's >> almost impossible to get that. I only acchieve a flanger, nothing else. >> >> In the first Patch-Circle done in Argentina last Saturday, I talked with >> Pablo E. Riera about this and he told me about the adaptive external and the >> echo cancellation example... but there is no example like that (only >> intereference cancellation). >> >> I will explain again (*2): the operator has a microphone (using one >> channel of input) and it sounds in a LCD (far away) (using one channel of >> output). Above the LCD I have a mic (second channel of input). This mic >> takes what the audience says and send to the operator headphones (second >> channel of output). The operator hears her own voice (with a delay). I want >> to supress this "return". It doesn't matter the latency, I just don't want >> the operator to hear her/him voice. >> >> I would need something that learn from the first microphone and get rid of >> what the second mic takes. >> >> I hope being clear in my explanation. Thanks in advace. >> >> >> >> (*1): the patch is in the thread. It does something like this: it takes >> the microphone (channel one), invert the wave (by using [*~ -1]), it uses a >> delayline to synch (because of the latency) and mix with the output. The >> intention is, obviously, suppress the microphone after been listened by the >> second microphone. >> >> >> [adc~] >> | \ >> | [delwrite~ echo-supressor-A 1000] >> | >> [delwrite~ echo-supressor-B 1000] >> >> >> >> >> [Hslider] # to synch. It depends on latency (it would have to be exact, >> here is the problem!) >> | >> [vd~ echo_supressor-A] >> | >> [*~ -1] >> | >> | [vd~ echo_supressor-B 1] >> | / >> [+~] >> | >> [dac~] >> >> (*2): I just updated the explanation >> >> How can I acchieve an echo suppresor? Is this possible? >> If I'm not clear in my explanation, please tell me. Thanks. >> _______________________________________________ >> [email protected] mailing list >> UNSUBSCRIBE and account-management -> >> http://lists.puredata.info/listinfo/pd-list >> >> >> >> >> _______________________________________________ >> [email protected] mailing list >> UNSUBSCRIBE and account-management -> >> http://lists.puredata.info/listinfo/pd-list >> >> >> >> _______________________________________________ >> [email protected] mailing list >> UNSUBSCRIBE and account-management -> >> http://lists.puredata.info/listinfo/pd-list >> >
xcov-2048.pd
Description: Binary data
_______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
