robert bristow-johnson wrote:
> On Nov 13, 9:24 pm, Dirk Bruere at NeoPax <dirk.bru...@gmail.com>
> wrote:
>> robert bristow-johnson wrote:
> ...
>>> dunno if it will solve your particular low-frequency problem, but i
>>> have found for audio (where the most interesting frequencies are often
>>> 7 or 8 octaves below Nyquist) is to use trig identities to express all
>>> of the terms with (1 - cos(2*pi*f0/Fs)) in terms of something with
>>> sin() instead.  it requires a little change in the architecture of the
>>> filter.
>>
>> Thanks. That's a neat trick!
> 
> well, i didn't really spell it out but all's i was thinking of is the
> same trick i did for accurately expressing frequency response at low
> frequencies.  i posted something about that a while ago:
> 
> http://groups.google.com/group/comp.dsp/browse_frm/thread/8c0fa8d396aeb444/a1bc5b63ac56b686
> 
> where the main idea is to replace
> 
>      cos(w)  <--   1 - 2*(sin(w/2))^2
> 
> where w = 2*pi*f/Fs is the low frequency in the frequency response.
> but now we replace w with w0=2*pi*f0/Fs where f0 is the very low
> resonant frequency of the audio filter so we are replacing
> 
>      cos(w0)  <--   1 - 2*(sin(w0/2))^2
> 
> in the filter coefficients and expressing all of the "1" terms with
> direct paths in the signal flow graph.  then, if you maintain some
> kind of pseudo-floating-point with 2*(sin(w0/2))^2 (shifting bits
> right after multiplying with scaled up versions of those tiny numbers)
> you'll be able to implement an accurate filter even for low values of
> w0.
> 
> that's the trick.
> 
> r b-j
> 

Takes me back 35 yrs to my maths "A" level exams.
I'll have to dig out all my old trig books.
I can certainly see how people make a career out of DSP. It's one thing 
to understand such stuff, but another to think it up. Reminds me why I 
gave up physics.

-- 
Dirk

http://www.transcendence.me.uk/ - Transcendence UK
Remote Viewing classes in London

On Nov 13, 9:24 pm, Dirk Bruere at NeoPax <dirk.bru...@gmail.com>
wrote:
> robert bristow-johnson wrote:
...
> > dunno if it will solve your particular low-frequency problem, but i
> > have found for audio (where the most interesting frequencies are often
> > 7 or 8 octaves below Nyquist) is to use trig identities to express all
> > of the terms with (1 - cos(2*pi*f0/Fs)) in terms of something with
> > sin() instead.  it requires a little change in the architecture of the
> > filter.
>
>
> Thanks. That's a neat trick!

well, i didn't really spell it out but all's i was thinking of is the
same trick i did for accurately expressing frequency response at low
frequencies.  i posted something about that a while ago:

http://groups.google.com/group/comp.dsp/browse_frm/thread/8c0fa8d396aeb444/a1bc5b63ac56b686

where the main idea is to replace

     cos(w)  <--   1 - 2*(sin(w/2))^2

where w = 2*pi*f/Fs is the low frequency in the frequency response.
but now we replace w with w0=2*pi*f0/Fs where f0 is the very low
resonant frequency of the audio filter so we are replacing

     cos(w0)  <--   1 - 2*(sin(w0/2))^2

in the filter coefficients and expressing all of the "1" terms with
direct paths in the signal flow graph.  then, if you maintain some
kind of pseudo-floating-point with 2*(sin(w0/2))^2 (shifting bits
right after multiplying with scaled up versions of those tiny numbers)
you'll be able to implement an accurate filter even for low values of
w0.

that's the trick.

r b-j

robert bristow-johnson wrote:
> On Nov 13, 8:34 am, Dirk Bruere at NeoPax <dirk.bru...@gmail.com>
> 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?
> 
> dunno if it will solve your particular low-frequency problem, but i
> have found for audio (where the most interesting frequencies are often
> 7 or 8 octaves below Nyquist) is to use trig identities to express all
> of the terms with (1 - cos(2*pi*f0/Fs)) in terms of something with
> sin() instead.  it requires a little change in the architecture of the
> filter.
> 
> r b-j
> 

Thanks. That's a neat trick!

-- 
Dirk

http://www.transcendence.me.uk/ - Transcendence UK
Remote Viewing classes in London

On Nov 13, 8:34 am, Dirk Bruere at NeoPax <dirk.bru...@gmail.com>
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?

dunno if it will solve your particular low-frequency problem, but i
have found for audio (where the most interesting frequencies are often
7 or 8 octaves below Nyquist) is to use trig identities to express all
of the terms with (1 - cos(2*pi*f0/Fs)) in terms of something with
sin() instead.  it requires a little change in the architecture of the
filter.

r b-j

Dirk Bruere at NeoPax <dirk.bruere@gmail.com> wrote in 
news:1194960881.866941.52480@19g2000hsx.googlegroups.com:

> 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
> 
> 

In pro audio, its common to implement the filter in fixed point using a 
DFI with either first order error shaping or double precision. 

This works well with a SHARC since it is a 32 bit fixed point processor 
(80 bit accumulator) as well as a floating point DSP.

A high Q at very low frequency is still probably difficult. You might 
need a double precision 64 bit solution. Analog Devices has an 
application note that might be of interest:

www.analog.com/UploadedFiles/Application_Notes/94729852EE270v01.pdf

Al Clark
Danville Signal Processing, Inc.

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.com

Because 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

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

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.com

Thanks.
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

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

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