On Thu, 08 Nov 2007 08:08:12 -0800, cyber.fidelity wrote:> On 8 Nov, 15:01, Vladimir Vassilevsky <antispam_bo...@hotmail.com> > wrote: >> Dirk Bruere at NeoPax wrote: >> >> > Can anyone point me to the reasons why IIR peaking filters become >> > unstable at low audio frequencies? >> >> The loss of numeric precision in the 2nd order IIR is proportional to >> Q(Fc/Fs)^2. >>At least if you use a direct-form filter.> > Would going to 64 bit floating point extend the frequency range?From 128 bit floating point? Of course not! Your coefficients need to be accurate enough that _after quantization_ your filter poles are still close enough to their intended locations that your filter will work as you desire. Your data paths need to be wide enough so that the quantization noise that's generated at each arithmetic operation will stay below your desired threshold -- basically this means you need Vladimir's required precision plus the precision of your input data. This made a lot more sense when I wrote about it in my book (see chapter 10), but then I wasn't nodding over the keyboard... -- Tim Wescott Control systems and communications consulting http://www.wescottdesign.com Need to learn how to apply control theory in your embedded system? "Applied Control Theory for Embedded Systems" by Tim Wescott Elsevier/Newnes, http://www.wescottdesign.com/actfes/actfes.html
Audio Low Frequency Instability
Started by ●November 8, 2007
Reply by ●November 9, 20072007-11-09
Reply by ●November 9, 20072007-11-09
On Nov 8, 9:31 am, Dirk Bruere at NeoPax <dirk.bru...@gmail.com> wrote:> Can anyone point me to the reasons why IIR peaking filters become > unstable at low audio frequencies? And, of course, how to get around > this problem? I need a set of peaking filters that operate between > 10Hz and 100Hz.Dirk, it's what everyone else said about arithmetic precision, but here is why it is worse at low frequencies: cos(2*pi*f0/Fs) is the only frequency dependent term that tunes the filter (there is a sin(2*pi*f0/Fs) term in the calculation of Q). the problem with the cos() term is that it gets closer and closer to 1 as f0 gets lower, and the information it contains is express as its *difference* from 1. but those bits might have already fallen off of your word, even if you had floating point. r b-j
Reply by ●November 10, 20072007-11-10
robert bristow-johnson wrote: (snip)> cos(2*pi*f0/Fs)> is the only frequency dependent term that tunes the filter (there is a > sin(2*pi*f0/Fs) term in the calculation of Q). the problem with the > cos() term is that it gets closer and closer to 1 as f0 gets lower, > and the information it contains is express as its *difference* from > 1. but those bits might have already fallen off of your word, even if > you had floating point.I notice "even if you had floating point." As the value is approaching 1.0, there is no advantage to floating point, and you lose some bits (to exponent) that could otherwise be useful significant bits. It seems to me that fixed point is the better choice. -- glen
Reply by ●November 13, 20072007-11-13
On 9 Nov, 16:30, robert bristow-johnson <r...@audioimagination.com> wrote:> On Nov 8, 9:31 am,DirkBruereat NeoPax <dirk.bru...@gmail.com> > wrote: > > > Can anyone point me to the reasons why IIR peaking filters become > > unstable at low audio frequencies? And, of course, how to get around > > this problem? I need a set of peaking filters that operate between > > 10Hz and 100Hz. > > Dirk, it's what everyone else said about arithmetic precision, but > here is why it is worse at low frequencies: > > cos(2*pi*f0/Fs) > > is the only frequency dependent term that tunes the filter (there is a > sin(2*pi*f0/Fs) term in the calculation of Q). the problem with the > cos() term is that it gets closer and closer to 1 as f0 gets lower, > and the information it contains is express as its *difference* from > 1. but those bits might have already fallen off of your word, even if > you had floating point. > > r b-jSo there are presumably two ways of overcoming this problem (assuming 96kHz sampling and filter frequency <100Hz). The first is to use more bits eg 64 bit float. The second is to reduce the sampling frequency eg take only every 10th sample to provide a 'frequency' of 9600Hz and work with that. What method is used in digital pro-audio? Dirk
Reply by ●November 13, 20072007-11-13
Dirk Bruere at NeoPax wrote:> On 9 Nov, 16:30, robert bristow-johnson <r...@audioimagination.com> > wrote: >> On Nov 8, 9:31 am,DirkBruereat NeoPax <dirk.bru...@gmail.com> >> wrote: >> >>> Can anyone point me to the reasons why IIR peaking filters become >>> unstable at low audio frequencies? And, of course, how to get around >>> this problem? I need a set of peaking filters that operate between >>> 10Hz and 100Hz. >> Dirk, it's what everyone else said about arithmetic precision, but >> here is why it is worse at low frequencies: >> >> cos(2*pi*f0/Fs) >> >> is the only frequency dependent term that tunes the filter (there is a >> sin(2*pi*f0/Fs) term in the calculation of Q). the problem with the >> cos() term is that it gets closer and closer to 1 as f0 gets lower, >> and the information it contains is express as its *difference* from >> 1. but those bits might have already fallen off of your word, even if >> you had floating point. >> >> r b-j > > So there are presumably two ways of overcoming this problem (assuming > 96kHz sampling and filter frequency <100Hz). > The first is to use more bits eg 64 bit float. > The second is to reduce the sampling frequency eg take only every 10th > sample to provide a 'frequency' of 9600Hz and work with that. > What method is used in digital pro-audio?Downsampling (decimating) is certainly workable, but you can't do that merely by taking every 10th sample. At 9600 Hz sample rate, the signal being decimated may not have frequencies higher than 4800 Hz, si it has to be filtered first. And you'll discard 9 out of 10 filter outputs, so (with the right kind of filter) they needn't be calculated. Look into "multirate filters" to see how it's done. It's possible that two single-precision filters will run more quickly than one double-precision filter, but I'd have to try it both ways in order to know. Jerry -- Engineering is the art of making what you want from things you can get. �����������������������������������������������������������������������
Reply by ●November 13, 20072007-11-13
Dirk Bruere at NeoPax <dirk.bruere@gmail.com> writes:> On 9 Nov, 16:30, robert bristow-johnson <r...@audioimagination.com> > wrote: >> On Nov 8, 9:31 am,DirkBruereat NeoPax <dirk.bru...@gmail.com> >> wrote: >> >> > Can anyone point me to the reasons why IIR peaking filters become >> > unstable at low audio frequencies? And, of course, how to get around >> > this problem? I need a set of peaking filters that operate between >> > 10Hz and 100Hz. >> >> Dirk, it's what everyone else said about arithmetic precision, but >> here is why it is worse at low frequencies: >> >> cos(2*pi*f0/Fs) >> >> is the only frequency dependent term that tunes the filter (there is a >> sin(2*pi*f0/Fs) term in the calculation of Q). the problem with the >> cos() term is that it gets closer and closer to 1 as f0 gets lower, >> and the information it contains is express as its *difference* from >> 1. but those bits might have already fallen off of your word, even if >> you had floating point. >> >> r b-j > > So there are presumably two ways of overcoming this problem (assuming > 96kHz sampling and filter frequency <100Hz). > The first is to use more bits eg 64 bit float. > The second is to reduce the sampling frequency eg take only every 10th > sample to provide a 'frequency' of 9600Hz and work with that. > What method is used in digital pro-audio?Dirk, Any filter is going to have several different realizations, or architectures of implementation. In addition, there are at least two other issues when implementing filters: coefficient roundoff and datapath roundoff errors. One must pay close attention to datapath roundoff errors in an IIR filter since such errors may get recirculated and can cause limit cycles or other undesirable effects. While you may get a measure of success picking an implementation and doing one or two things to avoid the pitfalls, learning how to design IIR filters is a complex task and it takes most people years to develop the necessary knowledge and experience to deal with these issues properly. Having said all that, here's what I would do: a. convert all incoming data (assuming it's 16-bit) to 32-bit representation inside the filter. b. use 32 bits to represent all coefficients, and scale them properly c. use 32x32->64 bit multiplies for internal multiplies, being careful to scale the result properly to avoid overflow. d. At the last stage requantize to 16 bits for output. Of course step c will require requantizing 64-bit results to 32 bits. By the way, you haven't (that I've seen) mentioned which processor you're working on. It may make a difference in how you approach this. -- % Randy Yates % "Ticket to the moon, flight leaves here today %% Fuquay-Varina, NC % from Satellite 2" %%% 919-577-9882 % 'Ticket To The Moon' %%%% <yates@ieee.org> % *Time*, Electric Light Orchestra http://www.digitalsignallabs.com
Reply by ●November 13, 20072007-11-13
On 13 Nov, 14:40, Jerry Avins <j...@ieee.org> wrote:> Dirk Bruere at NeoPax wrote: > > > > > On 9 Nov, 16:30, robert bristow-johnson <r...@audioimagination.com> > > wrote: > >> On Nov 8, 9:31 am,DirkBruereat NeoPax <dirk.bru...@gmail.com> > >> wrote: > > >>> Can anyone point me to the reasons why IIR peaking filters become > >>> unstable at low audio frequencies? And, of course, how to get around > >>> this problem? I need a set of peaking filters that operate between > >>> 10Hz and 100Hz. > >> Dirk, it's what everyone else said about arithmetic precision, but > >> here is why it is worse at low frequencies: > > >> cos(2*pi*f0/Fs) > > >> is the only frequency dependent term that tunes the filter (there is a > >> sin(2*pi*f0/Fs) term in the calculation of Q). the problem with the > >> cos() term is that it gets closer and closer to 1 as f0 gets lower, > >> and the information it contains is express as its *difference* from > >> 1. but those bits might have already fallen off of your word, even if > >> you had floating point. > > >> r b-j > > > So there are presumably two ways of overcoming this problem (assuming > > 96kHz sampling and filter frequency <100Hz). > > The first is to use more bits eg 64 bit float. > > The second is to reduce the sampling frequency eg take only every 10th > > sample to provide a 'frequency' of 9600Hz and work with that. > > What method is used in digital pro-audio? > > Downsampling (decimating) is certainly workable, but you can't do that > merely by taking every 10th sample. At 9600 Hz sample rate, the signal > being decimated may not have frequencies higher than 4800 Hz, si it has > to be filtered first. And you'll discard 9 out of 10 filter outputs, so > (with the right kind of filter) they needn't be calculated. Look into > "multirate filters" to see how it's done. It's possible that two > single-precision filters will run more quickly than one double-precision > filter, but I'd have to try it both ways in order to know. > > Jerry > -- > Engineering is the art of making what you want from things you can get. > =AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF==AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF= =AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF Thanks. The word I was looking for was "decimation". I've just read up on it and it seems pretty straightforward. Use an FIR filter to maintain constant phase and keep the computation requirements low by (if necessary) cascading FIR filters to reduce the overall number of taps. Then business as usual, interpolate and filter again for the final output. Dirk
Reply by ●November 13, 20072007-11-13
On 13 Nov, 15:14, Randy Yates <ya...@ieee.org> wrote:> Dirk Bruere at NeoPax <dirk.bru...@gmail.com> writes: > > > > > On 9 Nov, 16:30, robert bristow-johnson <r...@audioimagination.com> > > wrote: > >> On Nov 8, 9:31 am,DirkBruereat NeoPax <dirk.bru...@gmail.com> > >> wrote: > > >> > Can anyone point me to the reasons why IIR peaking filters become > >> > unstable at low audio frequencies? And, of course, how to get around > >> > this problem? I need a set of peaking filters that operate between > >> > 10Hz and 100Hz. > > >> Dirk, it's what everyone else said about arithmetic precision, but > >> here is why it is worse at low frequencies: > > >> cos(2*pi*f0/Fs) > > >> is the only frequency dependent term that tunes the filter (there is a > >> sin(2*pi*f0/Fs) term in the calculation of Q). the problem with the > >> cos() term is that it gets closer and closer to 1 as f0 gets lower, > >> and the information it contains is express as its *difference* from > >> 1. but those bits might have already fallen off of your word, even if > >> you had floating point. > > >> r b-j > > > So there are presumably two ways of overcoming this problem (assuming > > 96kHz sampling and filter frequency <100Hz). > > The first is to use more bits eg 64 bit float. > > The second is to reduce the sampling frequency eg take only every 10th > > sample to provide a 'frequency' of 9600Hz and work with that. > > What method is used in digital pro-audio? > > Dirk, > > Any filter is going to have several different realizations, or > architectures of implementation. In addition, there are at least two > other issues when implementing filters: coefficient roundoff and > datapath roundoff errors. One must pay close attention to datapath > roundoff errors in an IIR filter since such errors may get recirculated > and can cause limit cycles or other undesirable effects. > > While you may get a measure of success picking an implementation and > doing one or two things to avoid the pitfalls, learning how to design > IIR filters is a complex task and it takes most people years to develop > the necessary knowledge and experience to deal with these issues > properly. > > Having said all that, here's what I would do: > > a. convert all incoming data (assuming it's 16-bit) to 32-bit > representation inside the filter. > > b. use 32 bits to represent all coefficients, and scale them properly > > c. use 32x32->64 bit multiplies for internal multiplies, being careful > to scale the result properly to avoid overflow. > > d. At the last stage requantize to 16 bits for output. > > Of course step c will require requantizing 64-bit results to 32 bits. > > By the way, you haven't (that I've seen) mentioned which processor > you're working on. It may make a difference in how you approach this. > -- > % Randy Yates % "Ticket to the moon, flight leaves here today > %% Fuquay-Varina, NC % from Satellite 2" > %%% 919-577-9882 % 'Ticket To The Moon' > %%%% <ya...@ieee.org> % *Time*, Electric Light Orchestrahttp://www.digitalsignallabs.comThanks. I'm using the ADI 21262 with 24/96 conversions on an EZLite kit. Default processing is on 32 bit float. The IIR filters aren't a problem above 50Hz, at least when I'm playing around with the system. However, there are to be multiple applications for h/w and s/w derived from this system. One application is subwoofer equalisation where I'll need peaking filters down to about 10Hz, with a max of 150Hz. The other applications are less demanding of filter design. Since I have about 4 weeks cumulative total of DSP design and techniques and a number of projects to get out the door ASAP I don't have the luxury of acquiring those deep skills. As I'm an engineer I'll "steal" the solutions of others and when the results sound "good enough" that's when it goes into production. I've got a book on the maths of DSP and it looks pretty simple - just stuff that I covered in my first year physics degree course years ago eg Fourier and Laplace transforms and complex plane stuff. I've also ordered another book that goes into the details of audio design specifics of the kind I'm involved with. Progress seems good so far in that I can actually listen to the various filter implementations and see/hear what's happening. And in the end I'll know when it sounds good enough, because I have an existing pro-audio DSP system with which to diectly compare. Dirk
Reply by ●November 13, 20072007-11-13
cyber.fidelity@googlemail.com writes:> [...]If it's so simple, why are you here asking for our help? -- % Randy Yates % "How's life on earth? %% Fuquay-Varina, NC % ... What is it worth?" %%% 919-577-9882 % 'Mission (A World Record)', %%%% <yates@ieee.org> % *A New World Record*, ELO http://www.digitalsignallabs.com
Reply by ●November 13, 20072007-11-13
On 13 Nov, 16:23, Randy Yates <ya...@ieee.org> wrote:> cyber.fidel...@googlemail.com writes: > > [...] > > If it's so simple, why are you here asking for our help? > -- > % Randy Yates % "How's life on earth? > %% Fuquay-Varina, NC % ... What is it worth?" > %%% 919-577-9882 % 'Mission (A World Record)', > %%%% <ya...@ieee.org> % *A New World Record*, ELOhttp://www.digitalsignallabs.comBecause I have to know what questions to ask. Because I am only at the beginning of the process. Because I do not know immediately where to look for answers. Because people here have knowledge that can save me a lot of time. Because people here know how other people do things, which is not necessarily the "book way". And probably a few more reasons I can't articulate in less than 20 seconds. Dirk
