Subject: Re: Frequency shift to alleviate acoustic feedback From: Siping Tao <siping.tao@xxxxxxxx> Date: Mon, 28 Jan 2013 09:52:03 +0800 List-Archive:<http://lists.mcgill.ca/scripts/wa.exe?LIST=AUDITORY>--e89a8fb1f07c13fed604d44f866e Content-Type: text/plain; charset=ISO-8859-1 Hi Julius and Steve, Thanks for your help, my application scenario requires real-time processing, i.e. delay should be kept below 10ms at most. Anyway, I think the code of Julius is helpful, to give me a good reference. Steve, I will read the paper you recommended, thanks, your explaination is very clear. Frequency shift is absolutely harder than I thought :) Thanks, Siping On Sun, Jan 27, 2013 at 5:48 AM, Steve Beet <steve.beet@xxxxxxxx> wrote: > Hi Julius, > > That looks like a pretty good implementation of the block-based approach > which Siping wanted to implement. The only problem from Siping's point of > view is that it uses the two functions PV_BinShift() and PV_PhaseShift(), > which are not defined here and may rely on the fact that (in this example) > the FFT size is an exact multiple of the window length. If that is an issue > (or if the 2048-sample length window is important) then Siping would have > to > redefine the problem. > > I presume the 160-sample blocks were originally specified to keep the > real-time processing delay short. Is that correct, Siping? If so then a > 2048-sample window is probably not acceptable. > > Steve > > > -----Original Message----- > > From: Julius Smith [mailto:jos@xxxxxxxx > > Sent: Saturday, January 26, 2013 8:08 PM > > To: Steve Beet > > Cc: AUDITORY@xxxxxxxx > > Subject: Re: Frequency shift to alleviate acoustic feedback > > > > Hi All, > > > > I don't know if this will help or confuse things, but here is > > a pretty smooth frequency-shifting implementation in SuperCollider: > > > > // Frequency-Shifting Example 5: Add phase-correction > > // MouseX = amplitude > > // MouseY = frequency shift (400 * (2 ** MouseY(-1,1)) in [200,800]) > > // MouseButton = clear frequency shift > > // START WITH MOUSE NEAR THE LEFT OF YOUR SCREEN > > ( > > x = { > > var in, out, amp, f0=400, fftSize=8192, winLen=2048, hopFrac=0.5, > > chain, mexp, fScaled, df, binShift, phaseShift, > > inWinType=0, outWinType=0; > > amp = MouseX.kr(-60,10).dbamp; > > in = SinOsc.ar(f0,0,amp); > > chain = FFT(LocalBuf(fftSize), in, hopFrac, inWinType, 1, winLen); > > mexp = MouseY.kr(-1.0,1.0); > > mexp = mexp*(1-MouseButton.kr); > > fScaled = f0 * (2.0 ** mexp); > > df = fScaled - f0; > > binShift = fftSize * (df / s.sampleRate); > > chain = PV_BinShift(chain, stretch:1, shift:binShift, interp:1); > > phaseShift = 2 * pi * binShift * hopFrac * (winLen/fftSize); > > chain = PV_PhaseShift(chain, phaseShift, integrate:1); > > out = IFFT(chain,outWinType,winLen); > > Out.ar(0, out.dup); > > }.play > > ) > > > > - Julius > > > > At 04:48 AM 1/25/2013, Steve Beet wrote: > > > > > > Dear Siping, > > > > I'd agree with Dick's simplification, except to note > > that *if* you can assume that the listeners are not sensitive > > to phase, then frequency shifting is actually very easy - you > > merely have to ensure phase continuity at block boundaries, > > or (my preferred approach) do the processing sample-by-sample > > using a direct analogue of the traditional EE approach: > > heterodyning followed by linear filtering. > > > > I've also just remembered one reference which is > > relevant to this, and should give you some idea of the issues > > involved in manipulating an audio signal in terms of the > > frequencies, amplitudes and phases of its components: > > > > R.J. McAulay, T. F. Quartieri; "Speech > > analysis/synthesis based on a sinusoidal representation"; > > IEEE Trans. on Acoust., Speech and Signal Proc., vol ASSP-34, > > pp. 744-754, 1986. > > > > Good luck, > > > > Steve > > > > > > > > > > On Thu, 24 Jan 2013 22:41:05 -0800 > > "Richard F. Lyon" <dicklyon@xxxxxxxx> wrote: > > > > > To put it more simply, the original assumption that > > frequency shifting > > > would be "the simplest method" was unfounded. > > > Frequency shifting is actually quite complicated, > > subtle, error prone, and > > > not so well defined. > > > > > > Dick > > > > > > > > > Julius O. Smith III <jos@xxxxxxxx> > > Prof. of Music and Assoc. Prof. (by courtesy) of Electrical > > Engineering > > CCRMA, Stanford University > > http://ccrma.stanford.edu/~jos/ <http://ccrma.stanford.edu/~jos/> > > > --e89a8fb1f07c13fed604d44f866e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Julius and Steve,<br><br>Thanks for your help, my application scenario r= equires real-time processing, i.e. delay should be kept below 10ms at most.= <br><br>Anyway, I think the code of Julius is helpful, to give me a good re= ference.<br> <br>Steve, I will read the paper you recommended, thanks, your explaination= is very clear. Frequency shift is absolutely harder than I thought :)<br><= br>Thanks,<br>Siping<br><br><div class=3D"gmail_quote">On Sun, Jan 27, 2013= at 5:48 AM, Steve Beet <span dir=3D"ltr"><<a href=3D"mailto:steve.beet@xxxxxxxx= ieee.org" 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">Hi Julius,<br> <br> That looks like a pretty good implementation of the block-based approach<br= > which Siping wanted to implement. The only problem from Siping's point = of<br> view is that it uses the two functions PV_BinShift() and PV_PhaseShift(),<b= r> which are not defined here and may rely on the fact that (in this example)<= br> the FFT size is an exact multiple of the window length. If that is an issue= <br> (or if the 2048-sample length window is important) then Siping would have t= o<br> redefine the problem.<br> <br> I presume the 160-sample blocks were originally specified to keep the<br> real-time processing delay short. Is that correct, Siping? If so then a<br> 2048-sample window is probably not acceptable.<br> <br> Steve<br> <div><div class=3D"h5"><br> > -----Original Message-----<br> > From: Julius Smith [mailto:<a href=3D"mailto:jos@xxxxxxxx">j= os@xxxxxxxx</a>]<br> > Sent: Saturday, January 26, 2013 8:08 PM<br> > To: Steve Beet<br> > Cc: <a href=3D"mailto:AUDITORY@xxxxxxxx">AUDITORY@xxxxxxxx= CA</a><br> > Subject: Re: Frequency shift to alleviate acoustic feedback<br> ><br> > Hi All,<br> ><br> > I don't know if this will help or confuse things, but here is<br> > a pretty smooth frequency-shifting implementation in SuperCollider:<br= > ><br> > // Frequency-Shifting Example 5: Add phase-correction<br> > // =A0 MouseX =3D amplitude<br> > // =A0 MouseY =3D frequency shift (400 * (2 ** MouseY(-1,1)) in [200,8= 00])<br> > // =A0 MouseButton =3D clear frequency shift<br> > // START WITH MOUSE NEAR THE LEFT OF YOUR SCREEN<br> > (<br> > x =3D {<br> > var in, out, amp, f0=3D400, fftSize=3D8192, winLen=3D2048, hopFrac=3D0= .5,<br> > chain, mexp, fScaled, df, binShift, phaseShift,<br> > inWinType=3D0, outWinType=3D0;<br> > amp =3D MouseX.kr(-60,10).dbamp;<br> > in =3D SinOsc.ar(f0,0,amp);<br> > chain =3D FFT(LocalBuf(fftSize), in, hopFrac, inWinType, 1, winLen);<b= r> > mexp =3D MouseY.kr(-1.0,1.0);<br> > mexp =3D mexp*(1-MouseButton.kr);<br> > fScaled =3D f0 * (2.0 ** mexp);<br> > df =3D fScaled - f0;<br> > binShift =3D fftSize * (df / s.sampleRate);<br> > chain =3D PV_BinShift(chain, stretch:1, shift:binShift, interp:1);<br> > phaseShift =3D 2 * pi * binShift * hopFrac * (winLen/fftSize);<br> > chain =3D PV_PhaseShift(chain, phaseShift, integrate:1);<br> > out =3D IFFT(chain,outWinType,winLen);<br> > Out.ar(0, out.dup);<br> > }.play<br> > )<br> ><br> > - Julius<br> ><br> > At 04:48 AM 1/25/2013, Steve Beet wrote:<br> ><br> ><br> > =A0 =A0 =A0 Dear Siping,<br> ><br> > =A0 =A0 =A0 I'd agree with Dick's simplification, except to no= te<br> > that *if* you can assume that the listeners are not sensitive<br> > to phase, then frequency shifting is actually very easy - you<br> > merely have to ensure phase continuity at block boundaries,<br> > or (my preferred approach) do the processing sample-by-sample<br> > using a direct analogue of the traditional EE approach:<br> > heterodyning followed by linear filtering.<br> ><br> > =A0 =A0 =A0 I've also just remembered one reference which is<br> > relevant to this, and should give you some idea of the issues<br> > involved in manipulating an audio signal in terms of the<br> > frequencies, amplitudes and phases of its components:<br> ><br> > =A0 =A0 =A0 R.J. McAulay, T. F. Quartieri; "Speech<br> > analysis/synthesis based on a sinusoidal representation";<br> > IEEE Trans. on Acoust., Speech and Signal Proc., vol ASSP-34,<br> > pp. 744-754, 1986.<br> ><br> > =A0 =A0 =A0 Good luck,<br> ><br> > =A0 =A0 =A0 Steve<br> ><br> ><br> ><br> ><br> > =A0 =A0 =A0 On Thu, 24 Jan 2013 22:41:05 -0800<br> > =A0 =A0 =A0 "Richard F. Lyon" <<a href=3D"mailto:dicklyon= @xxxxxxxx">dicklyon@xxxxxxxx</a>> wrote:<br> ><br> > =A0 =A0 =A0 > To put it more simply, the original assumption that<b= r> > frequency shifting<br> > =A0 =A0 =A0 > would be "the simplest method" was unfounde= d.<br> > =A0 =A0 =A0 > Frequency shifting is actually quite complicated,<br> > subtle, error prone, and<br> > =A0 =A0 =A0 > not so well defined.<br> > =A0 =A0 =A0 ><br> > =A0 =A0 =A0 > Dick<br> > =A0 =A0 =A0 ><br> ><br> ><br> > Julius O. Smith III <<a href=3D"mailto:jos@xxxxxxxx">jos@xxxxxxxx= ccrma.stanford.edu</a>><br> > Prof. of Music and Assoc. Prof. (by courtesy) of Electrical<br> > Engineering<br> > CCRMA, Stanford University<br> </div></div>> <a href=3D"http://ccrma.stanford.edu/~jos/" target=3D"_bla= nk">http://ccrma.stanford.edu/~jos/</a> <<a href=3D"http://ccrma.stanfor= d.edu/~jos/" target=3D"_blank">http://ccrma.stanford.edu/~jos/</a>><br> ><br> </blockquote></div><br> --e89a8fb1f07c13fed604d44f866e--