Subject: Re: Frequency shift to alleviate acoustic feedback From: Siping Tao <siping.tao@xxxxxxxx> Date: Thu, 24 Jan 2013 15:32:12 +0800 List-Archive:<http://lists.mcgill.ca/scripts/wa.exe?LIST=AUDITORY>--e89a8fb1fc362e380f04d403cfd0 Content-Type: text/plain; charset=ISO-8859-1 Dear Steve, Thanks for your warm response! I cannot fully understand what you said just because of my poor background knowledge, your explaination is excellent. Do you have any papers discussing this tpoic? About how to handle phase when using overlap. Best Regards, Siping On Wed, Jan 23, 2013 at 7:38 PM, Steve Beet <steve.beet@xxxxxxxx> wrote: > Dear Siping, > > I'm sorry but of course what I said below was inaccurate (well just plain > wrong, actually!). The tone corresponding to each bin will go through a > complete number of cycles in one FFT block so the phase at the end will be > the same as the phase at the beginning, regardless of which bin it is in. > However, if you overlap blocks by 50%, then there will be a 180-degree > discrepancy between alternate bins at the point where the next overlapped > block starts. > > Anyway, it might still be worth looking at the phase - the simplest > solution to the 180-degree issue would be to shift the frequency by 2 bins > if you're using 50% overlap on your windows. That way odd bins would map > onto odd bins, and even onto even. > > Sorry for the confusion... > > Steve Beet > > > > > On Wed, 23 Jan 2013 10:48:23 +0000 > Steve Beet <steve.beet@xxxxxxxx> wrote: > > > Dear Siping, > > > > The most likely explanation is that when you shift the FFT by one bin, > you (presumably) just copy the real and imaginary parts, so the initial > phase of the respective components stays the same at the new frequency. > However, by the end of each block, the new signal will have been through a > different number of cycles of each sinusoidal component, so the phase at > the end of the frequency-shifted block will not match up with the phase at > the start of the next block. > > > > Manipulating the phases so that the different components maintain the > "correct" phase relationships with the signal components in subsequent > blocks could be done by converting the phase of each FFT bin to a time > delay (rather than a phase angle), and calculating the phase for the > shifted signal which would give the same time delay. > > > > There may be other issues too (e.g. the handling of the first and last > DFT bins, where there's no phase information), but I would try setting the > phase such that the signal at the centre of each overlapped window is > "correct", and hope that the taper of the Hanning window will minimise the > effect of any discontinuities near the ends of each block. > > > > Let us know how you get on! > > > > Steve Beet > > > > > > On Wed, 23 Jan 2013 11:05:08 +0100 > > Zlatan Ribic <zlatan@xxxxxxxx> wrote: > > > > > M. Hartley Jones: "Frequency Shifter for "Howl" Suppression", Wireless > World, July 1973. 317-322 > > > > > > ----- Original Message ----- > > > From: Siping Tao > > > To: AUDITORY@xxxxxxxx > > > Sent: Wednesday, January 23, 2013 9:56 AM > > > Subject: Frequency shift to alleviate acoustic feedback > > > > > > > > > Dear experts, > > > > > > Acoustic feedback can be removed by several methods: frequency > shift, phase shift, notch filter, adaptive cancellation. I tried the > simplest method I thought, frqeuency shift. However, it's not easy as I > thought. In realtime processing scenario, I need to process every 10ms > audio sample without significant delay, so I do the following > implementation: > > > > > > 1. sampling rate is 16K, so I have 160 samples every 10ms. > > > 2. do DFT for these 160 samples, the DFT length is 512, pending > zeros since I only have 160 samples > > > 3. shift the frequency by one fft coefficient, that is, shift > 16000/512=31.25Hz (DC is not shifted) > > > 4. do IDFT > > > > > > After doing that, I can notice the spectrum is shifted in cool-edit, > but with some processing noise (not the artifacts due to frequency shift). > I guess this noise is caused by different processing for successive10ms > data, I am not sure here. However, I try to use overlap processing in my > code, hanning window, 50% overlap, then the processing noise is reduced > much. Unfortunately, I found that overlap processing sometimes make the > frequency shift useless (e.g. 75% overlap by blackman window), what I mean > useless is I cannot notice spectrum shift in cool-edit. > > > > > > Can anybody help me to understand why overlap processing hurts > frequency shift? Or point out the incorrect parts of my implementation. > > > > > > Thanks, > > > Siping > --e89a8fb1fc362e380f04d403cfd0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear Steve,<br><br>Thanks for your warm response! I cannot fully understand= what you said just because of my poor background knowledge, your explainat= ion is excellent.<br><br>Do you have any papers discussing this tpoic? Abou= t how to handle phase when using overlap.<br> <br>Best Regards,<br>Siping<br><br><div class=3D"gmail_quote">On Wed, Jan 2= 3, 2013 at 7:38 PM, Steve Beet <span dir=3D"ltr"><<a href=3D"mailto:stev= e.beet@xxxxxxxx" target=3D"_blank">steve.beet@xxxxxxxx</a>></span> wrote= :<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex">Dear Siping,<br> <br> I'm sorry but of course what I said below was inaccurate (well just pla= in wrong, actually!). The tone corresponding to each bin will go through a = complete number of cycles in one FFT block so the phase at the end will be = the same as the phase at the beginning, regardless of which bin it is in. H= owever, if you overlap blocks by 50%, then there will be a 180-degree discr= epancy between alternate bins at the point where the next overlapped block = starts.<br> <br> Anyway, it might still be worth looking at the phase - the simplest solutio= n to the 180-degree issue would be to shift the frequency by 2 bins if you&= #39;re using 50% overlap on your windows. That way odd bins would map onto = odd bins, and even onto even.<br> <br> Sorry for the confusion...<br> <br> Steve Beet<br> <br> <br> <br> <br> On Wed, 23 Jan 2013 10:48:23 +0000<br> <div class=3D"HOEnZb"><div class=3D"h5">Steve Beet <<a href=3D"mailto:st= eve.beet@xxxxxxxx">steve.beet@xxxxxxxx</a>> wrote:<br> <br> > Dear Siping,<br> ><br> > The most likely explanation is that when you shift the FFT by one bin,= you (presumably) just copy the real and imaginary parts, so the initial ph= ase of the respective components stays the same at the new frequency. Howev= er, by the end of each block, the new signal will have been through a diffe= rent number of cycles of each sinusoidal component, so the phase at the end= of the frequency-shifted block will not match up with the phase at the sta= rt of the next block.<br> ><br> > Manipulating the phases so that the different components maintain the = "correct" phase relationships with the signal components in subse= quent blocks could be done by converting the phase of each FFT bin to a tim= e delay (rather than a phase angle), and calculating the phase for the shif= ted signal which would give the same time delay.<br> ><br> > There may be other issues too (e.g. the handling of the first and last= DFT bins, where there's no phase information), but I would try setting= the phase such that the signal at the centre of each overlapped window is = "correct", and hope that the taper of the Hanning window will min= imise the effect of any discontinuities near the ends of each block.<br> ><br> > Let us know how you get on!<br> ><br> > Steve Beet<br> ><br> ><br> > On Wed, 23 Jan 2013 11:05:08 +0100<br> > Zlatan Ribic <<a href=3D"mailto:zlatan@xxxxxxxx">zlatan@xxxxxxxx= COM</a>> wrote:<br> ><br> > > M. Hartley Jones: "Frequency Shifter for "Howl" Su= ppression", Wireless World, July 1973. 317-322<br> > ><br> > > =A0 ----- Original Message -----<br> > > =A0 From: Siping Tao<br> > > =A0 To: <a href=3D"mailto:AUDITORY@xxxxxxxx">AUDITORY@xxxxxxxx= S.MCGILL.CA</a><br> > > =A0 Sent: Wednesday, January 23, 2013 9:56 AM<br> > > =A0 Subject: Frequency shift to alleviate acoustic feedback<br> > ><br> > ><br> > > =A0 Dear experts,<br> > ><br> > > =A0 Acoustic feedback can be removed by several methods: frequenc= y shift, phase shift, notch filter, adaptive cancellation. I tried the simp= lest method I thought, frqeuency shift. However, it's not easy as I tho= ught. In realtime processing scenario, I need to process every 10ms audio s= ample without significant delay, so I do the following implementation:<br> > ><br> > > =A0 1. sampling rate is 16K, so I have 160 samples every 10ms.<br= > > > =A0 2. do DFT for these 160 samples, the DFT length is 512, pendi= ng zeros since I only have 160 samples<br> > > =A0 3. shift the frequency by one fft coefficient, that is, shift= 16000/512=3D31.25Hz (DC is not shifted)<br> > > =A0 4. do IDFT<br> > ><br> > > =A0 After doing that, I can notice the spectrum is shifted in coo= l-edit, but with some processing noise (not the artifacts due to frequency = shift). I guess this noise is caused by different processing for successive= 10ms data, I am not sure here. However, I try to use overlap processing in = my code, hanning window, 50% overlap, then the processing noise is reduced = much. Unfortunately, I found that overlap processing sometimes make the fre= quency shift useless (e.g. 75% overlap by blackman window), what I mean use= less is I cannot notice spectrum shift in cool-edit.<br> > ><br> > > =A0 Can anybody help me to understand why overlap processing hurt= s frequency shift? Or point out the incorrect parts of my implementation.<b= r> > ><br> > > =A0 Thanks,<br> > > =A0 Siping<br> </div></div></blockquote></div><br> --e89a8fb1fc362e380f04d403cfd0--