DSPRelated.com
Forums

Peaking equalization - low phase delay

Started by FatScouser March 22, 2011
> > >FatScouser wrote: > >>>0. Abandon the cookbooks; cookbooks are for the folks who already know >>>how to cook and what to cook. >>> >>>1. Formalize your requirements and constraints. >>> >>>2. Generate the desired filter by brute force optimization. >>> >>>3. Since you don't seem to be limited in CPU resources, stay with FIR. >>> >> >> Thanks for that. I don't claim to be a DSP chef: I can just about boil
a
>> filter. > >Sorry. Things don't work that way. > >> As for scrambled filters: I'm good at that. But am keen to learn - >> if anyone's keen to teach. > >Get a textbook. R. Lyons's "Understanding DSP" would be a good start. > >> Do you think it's valid, then, to replace my IIR bandpass filters with
FIR
>> ones? My general understanding was that FIR responded slower than IIR;
and
>> I already had IIR code to work with, hence the implementation. > >Any response could be approached either from FIR or from IIR >perspective; it is the matter of the application preference. It is >simpler in many ways to build an arbitrary response as FIR. > >> And are you inferring that peaking filters are IIR, so I should abandon >> that type? > >Different things are good for different purposes; it is up to you to >decide what to use and when. > > >Vladimir Vassilevsky >DSP and Mixed Signal Design Consultant >http://www.abvolt.com > >
OK, many thanks for your feedback. Best regards, John
On Mar 22, 6:55&#4294967295;am, Vladimir Vassilevsky <nos...@nowhere.com> wrote:
> FatScouser wrote: > > Hi all, > > > I'm trying to implement a graphic equalizer tool (in c++) for a non-audio > > system with bandwidth 0 - 40 Hz, and hoped someone in the Comp.DSP > > community would be kind enough to offer helpful advice? > > > We have a quasi-realtime system in which minimal phase delay is of critical > > importance, but minimal signal distortion is also a requirement > > (obviously). We want to keep delays below about 75 ms, and we don't want > > excessive 'ringing' under/overshoot, so I _think_ Q factor must be below > > about 2.0. > > > I have implemented an EQ comprising a cascade of band filters with these > > properties: bandpass, IIR, Bessel, 3rd order. Each band supports the > > following three inputs: f1, f2, and gain. Since I have no direct control > > over Q, the unfortunate result is that narrow bands cause too much > > resonance. (Presumably this is because Q is too high. Q = fc/(f2-f1) = > > 0.5*(f2+f1)/(f2-f1). So, a 4 Hz - 6 Hz band equates to Q=2.5, and the > > impulse response causes a couple of secondary after-peaks: please correct > > me if I'm wrong!. Phase delay is OK for this case, however.) > > > Looking at other postings (I've downloaded r-bj's Audio-EQ-Cookbook.txt), I > > suspect a parametric/peaking equalizer should be investigated because it > > will allow me to trade off ringing against phase delay? Finally, the crux > > question ;o) : > > >>>Is a parametric/peaking equalizer likely to offer lower phase delay > > > and/or ringing for our application, when compared with our existing > > bandpass filter implementation? > > > A lot of detail there: hopefully someone can help. > > 0. Abandon the cookbooks; cookbooks are for the folks who already know > how to cook and what to cook. > > 1. Formalize your requirements and constraints. > > 2. Generate the desired filter by brute force optimization. > > 3. Since you don't seem to be limited in CPU resources, stay with FIR. > > Vladimir Vassilevsky > DSP and Mixed Signal Design Consultanthttp://www.abvolt.com
I suspect that the OP may be able to get less group delay with IIR than with FIR. In either case the 75ms requirement is going to be tough. How many bands are you going to be dividing this 40Hz range into? What are the edges of the lowest band?

cassiope wrote:

> I suspect that the OP may be able to get less group delay with IIR > than with FIR.
I suspect you are idiot. FIR doen't have to be linear phase. VLV
On 03/22/2011 08:51 AM, cassiope wrote:
> On Mar 22, 6:55 am, Vladimir Vassilevsky<nos...@nowhere.com> wrote: >> FatScouser wrote: >>> Hi all, >> >>> I'm trying to implement a graphic equalizer tool (in c++) for a non-audio >>> system with bandwidth 0 - 40 Hz, and hoped someone in the Comp.DSP >>> community would be kind enough to offer helpful advice? >> >>> We have a quasi-realtime system in which minimal phase delay is of critical >>> importance, but minimal signal distortion is also a requirement >>> (obviously). We want to keep delays below about 75 ms, and we don't want >>> excessive 'ringing' under/overshoot, so I _think_ Q factor must be below >>> about 2.0. >> >>> I have implemented an EQ comprising a cascade of band filters with these >>> properties: bandpass, IIR, Bessel, 3rd order. Each band supports the >>> following three inputs: f1, f2, and gain. Since I have no direct control >>> over Q, the unfortunate result is that narrow bands cause too much >>> resonance. (Presumably this is because Q is too high. Q = fc/(f2-f1) = >>> 0.5*(f2+f1)/(f2-f1). So, a 4 Hz - 6 Hz band equates to Q=2.5, and the >>> impulse response causes a couple of secondary after-peaks: please correct >>> me if I'm wrong!. Phase delay is OK for this case, however.) >> >>> Looking at other postings (I've downloaded r-bj's Audio-EQ-Cookbook.txt), I >>> suspect a parametric/peaking equalizer should be investigated because it >>> will allow me to trade off ringing against phase delay? Finally, the crux >>> question ;o) : >> >>>>> Is a parametric/peaking equalizer likely to offer lower phase delay >> >>> and/or ringing for our application, when compared with our existing >>> bandpass filter implementation? >> >>> A lot of detail there: hopefully someone can help. >> >> 0. Abandon the cookbooks; cookbooks are for the folks who already know >> how to cook and what to cook. >> >> 1. Formalize your requirements and constraints. >> >> 2. Generate the desired filter by brute force optimization. >> >> 3. Since you don't seem to be limited in CPU resources, stay with FIR. >> >> Vladimir Vassilevsky >> DSP and Mixed Signal Design Consultanthttp://www.abvolt.com > > I suspect that the OP may be able to get less group delay with IIR > than with FIR.
People get used to making FIR filters that are symmetrical around some point, then they forget that a FIR filter doesn't have to be symmetrical around that point. -- Tim Wescott Wescott Design Services http://www.wescottdesign.com Do you need to implement control loops in software? "Applied Control Theory for Embedded Systems" was written for you. See details at http://www.wescottdesign.com/actfes/actfes.html
On 03/22/2011 06:44 AM, FatScouser wrote:
>> Not helpful, you've only reformulated what you already >> said. >> >> Again: What is it you attempt to do? Why do you think >> phase delay is important? How / why did you end up >> with the spec you stated? >> >> Rune >> > > Hi Rune (et al), > > OK, I can't give details for privacy reasons that are out of my control. > Suffice to say phase delay _must_ be<75 ms: you'll just have to just take > my word on that (isn't that enough?) > > But I can tell you that the application is mechanical, and the purpose of > the graphic equalizer is to enhance frequency ranges that the system is > poor at reproducing. We would like to dial up/down gains at arbitrary bands > in the 0-40 Hz range. Unfortunately we don't have a model of our system - > nor will we be able to generate one - hence the graphic equalizer will be a > manual method for achieving a flat frequency response. > > That's essenially it. I don't want to sound secretive just for the sake of > it: I have my very good reasons. Nor do I want to sound ungrateful for any > help ...
You may do better to look at this as a time domain problem: acquire an impulse response from your system (assuming that it's linear or close to it), then look for the best filter in the time domain that deconvolves that impulse. This also gives you a direct measure of feasibility: if your impulse response has significant energy beyond 75ms, then you know you're screwed right off, and you can put your energy into a resume rather than trying to make the boss happy :-). If this is going inside a control loop, then you're building a compensator, not a filter, and you should consider splitting it up into a feed-forward section and a feed-back section, with a goal of getting the best response you can get with some known, fixed delay (that you then have a chance to compensate for elsewhere in your machine). You can often do a much better job this way than you can either with a compensator in front of a loop, or with a single compensator inside a loop. -- Tim Wescott Wescott Design Services http://www.wescottdesign.com Do you need to implement control loops in software? "Applied Control Theory for Embedded Systems" was written for you. See details at http://www.wescottdesign.com/actfes/actfes.html
>You may do better to look at this as a time domain problem: acquire an >impulse response from your system (assuming that it's linear or close to >it), then look for the best filter in the time domain that deconvolves >that impulse. This also gives you a direct measure of feasibility: if >your impulse response has significant energy beyond 75ms, then you know >you're screwed right off, and you can put your energy into a resume >rather than trying to make the boss happy :-). > >If this is going inside a control loop, then you're building a >compensator, not a filter, and you should consider splitting it up into >a feed-forward section and a feed-back section, with a goal of getting >the best response you can get with some known, fixed delay (that you >then have a chance to compensate for elsewhere in your machine). You >can often do a much better job this way than you can either with a >compensator in front of a loop, or with a single compensator inside a
loop. Hi Tim, Thanks a lot for the info. Interesting ideas with the time domain approach, and also the compensator. I wasn't intending to create adaptive filters/compensators in a control loop, however: the settings would be fixed. I was hoping to come to a reasonable - albiet not perfect - solution to the problem, and present my boss with a GEQ comprising many bands in the 0-40 Hz range. Hmmmm... I think we need to hire the service of experts - like yourself ;o) - if we really want this. Appreciate your feedback, John
> > >cassiope wrote: > >> I suspect that the OP may be able to get less group delay with IIR >> than with FIR. > >I suspect you are idiot. FIR doen't have to be linear phase. > >VLV >
Come on cassiope, let's us idiots leave these rude dudes to play by themselves! ;o)
On 03/22/2011 10:46 AM, FatScouser wrote:
>> You may do better to look at this as a time domain problem: acquire an >> impulse response from your system (assuming that it's linear or close to >> it), then look for the best filter in the time domain that deconvolves >> that impulse. This also gives you a direct measure of feasibility: if >> your impulse response has significant energy beyond 75ms, then you know >> you're screwed right off, and you can put your energy into a resume >> rather than trying to make the boss happy :-). >> >> If this is going inside a control loop, then you're building a >> compensator, not a filter, and you should consider splitting it up into >> a feed-forward section and a feed-back section, with a goal of getting >> the best response you can get with some known, fixed delay (that you >> then have a chance to compensate for elsewhere in your machine). You >> can often do a much better job this way than you can either with a >> compensator in front of a loop, or with a single compensator inside a > loop. > > Hi Tim, > > Thanks a lot for the info. Interesting ideas with the time domain approach, > and also the compensator. I wasn't intending to create adaptive > filters/compensators in a control loop, however: the settings would be > fixed. > > I was hoping to come to a reasonable - albiet not perfect - solution to the > problem, and present my boss with a GEQ comprising many bands in the 0-40 > Hz range. Hmmmm... I think we need to hire the service of experts - like > yourself ;o) - if we really want this.
When I was describing that approach I wasn't thinking "adaptive"* -- if you can gather enough information for the equalizer solution to work without adaptation, you can gather enough information for a time-domain solution to work. In fact, they're really just different ways of looking at the same thing -- it's just that it this case the time-domain approach, or a more general frequency-domain approach, may work better than starting out with something that you can call a "graphics equalizer". If your boss sounds receptive, I'd be happy to work on something like this. It's a fun control problem, and I know that there are approaches that can be taken to make things like this work better -- although the first thing that I'd owe you would be a feasibility study, to see if your particular situation could be improved by using fancy techniques. * I strongly advocate for not using adaptive controllers unless you really need them, you really know what to do with them, and you're really sure you'll need them. They can do amazingly wonderful things for performance, but they can often turn around and bite your behind without any warning at all. This may sound like an overly conservative attitude, but it closely echoes the message of a chapter in the book "Adaptive Control" by Karl Astrom, who for years was the world-wide "Doctor Adaptive Control". -- Tim Wescott Wescott Design Services http://www.wescottdesign.com Do you need to implement control loops in software? "Applied Control Theory for Embedded Systems" was written for you. See details at http://www.wescottdesign.com/actfes/actfes.html