Jump to content


Photo

Time and/or phase-aligning multiple subs - all-pass filters?


  • Please log in to reply
22 replies to this topic

#1 andy497

andy497

    Member

  • Members
  • PipPip
  • 21 posts

Posted 18 October 2016 - 06:17 PM

I'm experimenting with not just matching/optimizing via a fixed distance delay, but using IIR all-pass filters to mate the group delay of different driver alignments.  

 

For reference, I have four sealed subs (4 cubic footish) and two ported (12 cubic footish, ~16 hz tune) in the theater and thought this might be interesting.  I started in winisd and played with all-pass parameters on the sealed sim until the system group delay matched with the ported sim.  It's possible to get very close with just guess/checking (though it would be nice to write an algorithm to solve for this, particularly for active crossover design of multi-way speakers).  I then put those biquad coefficients into a minidsp and ran before/after REW sweeps of the subs separately and together in-room.  

 

Theory matched practice pretty closely.  The trouble is that, while the phase plots in REW when measured at the seat look fairly close (and much tighter than without the all-pass), when I turn on all subs and run a sweep, the frequency response is markedly worse (bumpy with deep funky null).  I'm wondering if part of the problem is much of the phase shaping happens say <30 hz, and there it's more about room modes than first-arrival.  Alternately, I've got one sealed sub near-field right up against the seat with the rest dispersed around the room at roughly 10-15 feet distance, and that might be further confusing things.  As it is, everything sums ok, but I've always thought it could be better.

 


  • WelisdeyMAIB likes this

#2 SME

SME

    Super Bass Overlord

  • Members
  • PipPipPipPipPipPipPipPip
  • 1,002 posts

Posted 18 October 2016 - 08:53 PM

The situation does complicate a lot once you put the subs into a room, especially in a configuration like you are using.  Have you tried re-adjusting the delays again to see if you can get better overlap with the all-pass IIRs in place?

 

Otherwise if you want to improve on this, I think you will need in-room measurements of each sub independently, either performed using either a loopback or an acoustic timing reference so that the measurements are accurately time-aligned with one another.  From there, you may be able to use REW's EQ simulation capability in conjunction with its ability to add responses to simulate what the summed response will look like in-room at the location(s) that you actually measured.  Note that this exercise is useless unless you have the timing information.  It is critical.

 

I don't really know of anyone who has done this sort of thing, other than myself.  I wrote custom software to facilitate this, not just for a single measurement location but for several so that I can optimize the independent responses of multiple subs over a wider listening area.  That software is not suitable for public release at this point, but maybe some day it will be ...



#3 3ll3d00d

3ll3d00d

    Ultra Member

  • Members
  • PipPipPipPipPipPip
  • 425 posts

Posted 18 October 2016 - 08:57 PM

this works well -> http://andyc.diy-aud...g.org/mso/html/

 

v nice piece of software


  • SME likes this

#4 SME

SME

    Super Bass Overlord

  • Members
  • PipPipPipPipPipPipPipPip
  • 1,002 posts

Posted 18 October 2016 - 09:02 PM

this works well -> http://andyc.diy-aud...g.org/mso/html/

 

v nice piece of software

 

That should help a lot.  And indeed, it supports plenty of standard filter types including all-passes as well.



#5 andy497

andy497

    Member

  • Members
  • PipPip
  • 21 posts

Posted 19 October 2016 - 05:27 PM

I can't believe I've never run across that software before or seen the thread on AVS.  Very exciting!

 

Getting a proper timing reference in REW has been a major pain in the past, but I'll keep at it.  I was very excited about that recent feature since I do hdmi out with a usb mic.  However, I've had nothing but problems with the asio half on the two laptops I have.  Both are modern windows 10 machines but share the same behavior: I can get 3 or 4 measurements tops, at which point the next sweep has an awful crackling sound.  I haven't been able to fix that with adjustments to the latency/buffer settings; the only way to correct it seems to be to reboot, and then I have to do another dance to get the hdmi device and minidsp usb mic detected correctly.  I'll typically get no sound from the mic, or it will appear to work normally but the signal recorded by REW will sometimes be 18 db too high.  :huh:  



#6 andyc56

andyc56

    Newbie

  • Members
  • Pip
  • 9 posts

Posted 20 October 2016 - 07:21 PM

Getting a proper timing reference in REW has been a major pain in the past, but I'll keep at it.  I was very excited about that recent feature since I do hdmi out with a usb mic.  However, I've had nothing but problems with the asio half on the two laptops I have.  Both are modern windows 10 machines but share the same behavior: I can get 3 or 4 measurements tops, at which point the next sweep has an awful crackling sound.  I haven't been able to fix that with adjustments to the latency/buffer settings; the only way to correct it seems to be to reboot, and then I have to do another dance to get the hdmi device and minidsp usb mic detected correctly.  I'll typically get no sound from the mic, or it will appear to work normally but the signal recorded by REW will sometimes be 18 db too high.  :huh:  

 

Hi,

 

I've had some strange problems when trying to do a loopback measurement of the frequency response of my UMC-200 pre-pro at line level with ASIO4ALL on a Windows 7 machine with AMD processor using HDMI.  I was able to get a good sweep again (but only temporarily) by changing the REW output channel to a different one, then changing back to the desired channel again.  I don't know if this is the same problem you were having, and I don't know what the sweep would have sounded like, since it was a line-level measurement without a mic.  All I know is that it gave me a really crazy looking frequency response when it happened, which for a line-level device is clearly wrong.

 

I'm the MSO author, so feel free to ask about it here or in the main MSO thread at AVS.


  • lilmike likes this

#7 lilmike

lilmike

    Super Power Member

  • Members
  • PipPipPipPipPip
  • 157 posts
  • LocationPNW USA

Posted 20 October 2016 - 10:47 PM

Hi,

 

I've had some strange problems when trying to do a loopback measurement of the frequency response of my UMC-200 pre-pro at line level with ASIO4ALL on a Windows 7 machine with AMD processor using HDMI.  I was able to get a good sweep again (but only temporarily) by changing the REW output channel to a different one, then changing back to the desired channel again.  I don't know if this is the same problem you were having, and I don't know what the sweep would have sounded like, since it was a line-level measurement without a mic.  All I know is that it gave me a really crazy looking frequency response when it happened, which for a line-level device is clearly wrong.

 

I'm the MSO author, so feel free to ask about it here or in the main MSO thread at AVS.

 

Hi Andy, thanks for stopping by. 

 

Huge thanks for your efforts with MSO. I have a bit more theater to build before I can put it to work, but I am a lot closer than I was.


  • andyc56 likes this

#8 andyc56

andyc56

    Newbie

  • Members
  • Pip
  • 9 posts

Posted 20 October 2016 - 11:04 PM

Hi Andy, thanks for stopping by. 

 

Huge thanks for your efforts with MSO. I have a bit more theater to build before I can put it to work, but I am a lot closer than I was.

 

You're welcome!

 

A while back, you were talking about raising the max allowable center freq of PEQ filters for horn sub EQ.  I can look at how to do that while discouraging the high max center frequency usage for more typical applications.  Maybe have a special PEQ type that allows it.


  • lilmike likes this

#9 lilmike

lilmike

    Super Power Member

  • Members
  • PipPipPipPipPip
  • 157 posts
  • LocationPNW USA

Posted 21 October 2016 - 12:07 AM

You're welcome!

 

A while back, you were talking about raising the max allowable center freq of PEQ filters for horn sub EQ.  I can look at how to do that while discouraging the high max center frequency usage for more typical applications.  Maybe have a special PEQ type that allows it.

I can also apply some pre-EQ to kill the out of band stuff without too much trouble. I am still working on figuring out how to smooth the response as much as possible through cabinet design, anything I can do to minimize the amount of EQ that I need to apply is a good thing. 

 

Have you had any experience applying the MSO solutions to a FreeDSP? I've just started messing with SigmaStudio, but haven't found a way to directly enter biquads yet.

 

Looks like I found it! Nevermind! There is a 2nd order IIR Coefficient filter buried in the menus of the General 2nd order filter.


  • andyc56 likes this

#10 andyc56

andyc56

    Newbie

  • Members
  • Pip
  • 9 posts

Posted 21 October 2016 - 12:29 AM

I can also apply some pre-EQ to kill the out of band stuff without too much trouble. I am still working on figuring out how to smooth the response as much as possible through cabinet design, anything I can do to minimize the amount of EQ that I need to apply is a good thing. 

 

Have you had any experience applying the MSO solutions to a FreeDSP? I've just started messing with SigmaStudio, but haven't found a way to directly enter biquads yet.

 

Looks like I found it! Nevermind! There is a 2nd order IIR Coefficient filter buried in the menus of the General 2nd order filter.

 

This is the first I've heard of FreeDSP, so I'll have to spend some time going through the web site.  I can export biquad coefficients in the same format that REW does for miniDSP.  These have the miniDSP oddity that the a1 and a2 coefficients in the file are actually the negatives of the coefficients in the transfer function.  I haven't used SigmaStudio, so i don't know if it expects the inverted a1 and a2 the way the miniDSP software does.


  • lilmike likes this

#11 andy497

andy497

    Member

  • Members
  • PipPip
  • 21 posts

Posted 21 October 2016 - 02:01 PM

Thanks for all your effort andyc56! I've got about 16 hrs into MSO now and am having a bunch of fun. I'm out of town now, but I have three different i7 machines at home which will be cranking on solutions all weekend.

Quick q if you have a sec:
Is there a way to define global eq constraints? e.g. min/max cummulative boost. I'm limiting individual peqs, but it keeps stacking things and occasionally wants to push one channel up 25 db. For the same config I've gotten nearly as flat with no channel pushed more than 6 db, but i don't have a way to make it prefer smaller effective boosts/cuts.

#12 andyc56

andyc56

    Newbie

  • Members
  • Pip
  • 9 posts

Posted 21 October 2016 - 04:14 PM

Is there a way to define global eq constraints? e.g. min/max cummulative boost. I'm limiting individual peqs, but it keeps stacking things and occasionally wants to push one channel up 25 db. For the same config I've gotten nearly as flat with no channel pushed more than 6 db, but i don't have a way to make it prefer smaller effective boosts/cuts.

 

At the moment, there's no way to constrain the maximum allowable total PEQ boost in a given channel, just individual boost.  I've always used MSO with all PEQs set to a maximum individual boost of 0 dB per the default.  In this way, if there are any notches in a combined response, it must try to fill them in by minimizing cancellation.  I'd suggest giving that a try.  You can often fill in response notches by a surprising amount without any boost in any PEQ at all.



#13 lilmike

lilmike

    Super Power Member

  • Members
  • PipPipPipPipPip
  • 157 posts
  • LocationPNW USA

Posted 21 October 2016 - 05:15 PM

This is the first I've heard of FreeDSP, so I'll have to spend some time going through the web site.  I can export biquad coefficients in the same format that REW does for miniDSP.  These have the miniDSP oddity that the a1 and a2 coefficients in the file are actually the negatives of the coefficients in the transfer function.  I haven't used SigmaStudio, so i don't know if it expects the inverted a1 and a2 the way the miniDSP software does.

The FreeDSP seemed like it was worth a try. I haven't put mine together yet (just like everything else that's theater-related), but have been playing with the software as I have some free time. I also have a MiniDSP that I can compare with. Was thinking I would just feed the same biquads into each and measure the outputs. Don't hold your breath waiting though.



#14 andy497

andy497

    Member

  • Members
  • PipPip
  • 21 posts

Posted 27 October 2016 - 09:07 PM

One week update:

 

Well, I thought things would get easier after my initial 35 sweeps, but the work was just beginning.  I have been having a terrible time getting the expected results on a given channel before/after eq.  I thought this might be related to my reliance on the acoustic timing feature in REW, but that's working swimmingly.  I can run individual sweeps of four subs, then sweep the combined subs, and the computed sum sweep in both REW and MSO precisely matches the actual.  In contrast, when I sweep an individual channel, apply a simple eq and sweep again, the results are close but not quite right.  Lots of eq points and lots of channels compounds the errors significantly.  Obviously you can't do things like boost away a null, but I'm not trying to do that.  I would expect simple eqs of a single channel in "minimum phase" regions to behave predictably, just as changing the master volume on the avr produces a nearly identical sweep at a different level.  Which leads to...

 

Finding no. 1:

I discovered last night that THX "Boundary Gain Compensation" was enabled on my receiver.  It's hidden in its own menu folder far away from things like audyssey and bass management.  Grr.  I thought this was a simple shelving filter, but before and after sweeps reveal some really strange effects on different sub channels.  I turned that off and took yet more before sweeps, so I'm hopeful I'll see improvements when I'm able to next take some measurements.  This means I'll probably want to remeasure and adjust the whole signal chain again as well.

 

Finding no. 2:

I'm growing skeptical of the "import REW biquads" function in my minidsp with 2x4 advanced plugin.  First, it will accept 6 biquads for both the input and output channels, but there are only 5 peq slots.  I'm guessing the 5th is dropped, but it's very hard to tell from the interface.  I've been using five per bank just to eliminate that as a variable.  Secondly, while biquad computations seem to match fairly well from the minidsp display graph to the MSO software, they aren't fully one to one.  The frequencies of adjustments seem to line up, but the magnitude may be slightly different, especially on large adjustments, e.g. a deep cut that equates to -15 dB in MSO might register as roughly -12 dB in the minidsp graph.  I'm thinking the minidsp plugin graph is pretty small and might have some display/rounding issues, but it has me wondering.

 

Besides the disappointing and confusing results so far with before/after sweeps, I think the software is fantastic.  If I give it a few peqs and shelf/LT/all-pass filters to work with, it's amazing what it can do.  With a first-order all-pass to play with on each sub channel, it's able to align them such that the low-end extends down to a 8-9 hz -3dB point with almost no boost on any channel, and there is more headroom across the entire bandwidth.  Setting things the old-fashioned way, my -3 point has been in the tweens with a 12 dB LT.



#15 andyc56

andyc56

    Newbie

  • Members
  • Pip
  • 9 posts

Posted 28 October 2016 - 12:07 AM

I'm having trouble splitting up quotes, so I'll just paste them into regular quote blocks.

 

In contrast, when I sweep an individual channel, apply a simple eq and sweep again, the results are close but not quite right.  Lots of eq points and lots of channels compounds the errors significantly.  Obviously you can't do things like boost away a null, but I'm not trying to do that.  I would expect simple eqs of a single channel in "minimum phase" regions to behave predictably, just as changing the master volume on the avr produces a nearly identical sweep at a different level.

 

That's really weird.  So just applying a single EQ to a single channel doesn't give the expected measured response?  I don't know what could be causing that.

 

Edit: Can you try this with just a PEQ and no all-pass filter in the path?  I'll go back and re-check the biquad coefficients for the all-pass filters using Matlab.

 

Internally, MSO computes the filter responses as analog filters.  When it computes the biquad coefficients, it uses the bilinear transformation to get the z-domain transfer function.  There is a nonlinear scale factor that "predistorts" e.g. the center frequency of the PEQ such that after the bilinear transformation the z-domain transfer function has the exact same center frequency as the analog one.  There is some "bandwidth warping" going on due to the nonlinearity of the frequency transformation, but when the critical frequencies of the filter are so much less than the Nyquist frequency of the DSP, there is negligible error, on the order of a couple hundredths of a dB.  In order to ensure the integrity of the calculated biquad coefficients, I compared my results with the spreadsheet by Charlie Laub at the miniDSP site.

 

When I was checking out the biquad coefficient code, the results agreed with Charlie's spreadsheet down to 14 digits for all filter types except the PEQ.  To chase the difference down further, I wrote a Matlab script and a set of functions to compute the response of the analog PEQ, the coefficients of the digital PEQ, and the response of the digital PEQ.  Center frequency and boost/cut at the center frequency were dead on, as expected by the "pre-distortion" of the analog filter center frequency.  Maximum error between the analog filter response and the computed digital filter response was a couple hundredths of a dB over the frequency band to 200 Hz.  (Edit: I just went back and reinstalled Matlab and ran that script again. Maximum error between analog and digital filter is 1.4 * 10^(-4) dB.)

 

I'm not saying Charlie's spreadsheet for the PEQ is wrong though.  There is potential ambiguity in the definition of "Q" for the analog PEQ.  I use the one that Bruno Putzeys uses in his Hypex sub amps.  For those, the "Q" is assigned to the analog filter "pole Q" when there is a boost, and to the analog filter "zero Q" when there is a cut.  This gives the result that two PEQs with the same Q and center frequency, one with a boost of X dB and the other with a cut of X dB will exactly cancel each other out when combined.  My guess, although I have not proven it, is that the discrepancy between my results and Charlie's for the PEQ may be due to a possibly different definition of "Q" being used for the analog PEQ filter.  At any rate, I got excellent agreement between the analog and digital filter responses, so I am satisfied the calculations are good for the PEQ.

 

Finding no. 1:

I discovered last night that THX "Boundary Gain Compensation" was enabled on my receiver.  It's hidden in its own menu folder far away from things like audyssey and bass management.  Grr.  I thought this was a simple shelving filter, but before and after sweeps reveal some really strange effects on different sub channels.  I turned that off and took yet more before sweeps, so I'm hopeful I'll see improvements when I'm able to next take some measurements.  This means I'll probably want to remeasure and adjust the whole signal chain again as well.

 

Let's hope that was the cause of the problem.  Is there any dynamic EQ sneaking into the AVR?

 

I'm growing skeptical of the "import REW biquads" function in my minidsp with 2x4 advanced plugin.  First, it will accept 6 biquads for both the input and output channels, but there are only 5 peq slots.  I'm guessing the 5th is dropped, but it's very hard to tell from the interface.

 

That should give an error message.  I think the 4-way advanced plugin can have 6 PEQs, but the 2x4 advanced is limited to 5.  When you tell MSO how many biquads your DSP has per channel, and you use more than that, it will still give you all the coefficients in order to not lose information.  I believe it prints out a warning in the filter report when that happens.  I'll check that, and if it doesn't, I'll fix it so it does.  I should probably display a warning message when this happens when exporting biquad text as a file too.  The purpose of specifying the maximum number of biquads is that if you use less, it will pad them with "through connection" biquads up to the maximum number in the exported text and the filter report.

 

Secondly, while biquad computations seem to match fairly well from the minidsp display graph to the MSO software, they aren't fully one to one.  The frequencies of adjustments seem to line up, but the magnitude may be slightly different, especially on large adjustments, e.g. a deep cut that equates to -15 dB in MSO might register as roughly -12 dB in the minidsp graph.  I'm thinking the minidsp plugin graph is pretty small and might have some display/rounding issues, but it has me wondering.

 

It could be that they're using a small number of frequencies and lots of smoothing so that the peak or dip is missed and smoothed over.  That's just a guess on my part.  With regard to MSO PEQ biquad computations, the center frequency and gain/attenuation of a single PEQ digital filter at the center frequency ought to be dead nuts on.

 

Besides the disappointing and confusing results so far with before/after sweeps, I think the software is fantastic.  If I give it a few peqs and shelf/LT/all-pass filters to work with, it's amazing what it can do.  With a first-order all-pass to play with on each sub channel, it's able to align them such that the low-end extends down to a 8-9 hz -3dB point with almost no boost on any channel, and there is more headroom across the entire bandwidth.  Setting things the old-fashioned way, my -3 point has been in the tweens with a 12 dB LT.

 

I'm glad to hear that at least, but sorry to hear that you're having these other problems.


  • SME likes this

#16 SME

SME

    Super Bass Overlord

  • Members
  • PipPipPipPipPipPipPipPip
  • 1,002 posts

Posted 28 October 2016 - 08:11 AM

Wow!  You sure did your homework on the biquad calculations.  I just skipped all the messy math and went straight to the answers published in one of the cookbooks online.  I confirmed that they matched what my MiniDSP 2x4 did.  The match was close enough for me not to notice, except for error that could be attributed to the 56-bit fixed point arithmetic on the 2x4 vs. 32-bit floating point in my simulations.  Differences became apparent below 30 Hz and worsened substantially below 20 Hz.  Anything below there was basically a crap shoot on the 2x4.  These same filters were fine on the OpenDRC-AN, which uses 32-bit float.

 

Now you make me want to check to see if PEQs with opposite gains that are otherwise identical cancel each other in my implementation.


  • andyc56 likes this

#17 andy497

andy497

    Member

  • Members
  • PipPip
  • 21 posts

Posted 28 October 2016 - 03:35 PM

Lots of excellent insights andyc56 and SME.

 

I think I found my culprit.  I pulled into REW two different "before" sweeps of the same sub, one a day apart of the other but with otherwise identical settings, to see if I could make one look like the other.  A simple low shelf (what the internet speculates the THX BGC does) won't do it.  At some point, I tried the REW merge A to B function, and it became obvious.  When REW realigns the timing of one sweep, it becomes a mirror match of the other.

 

i-r9dmx6R.png

 

That leads me to believe that BGC perhaps wasn't on and I just had a hiccup with the acoustic timing reference.  My avr tries to be smart and retain all of the audyssey/speaker config/etc settings per input, but that can drive you nuts when you're testing and frequently changing inputs.

 

I'm surprised that a timing shift like that would so dramatically change the computed frequency response.  Further, my intuition would be that higher frequencies would be corrupted while the longer wavelengths would barely change at all, but it almost looks like the opposite - at least in the < 200 hz range.

 

 

@SME:  I've heard that minidsp had trouble with the low frequency filters, but I wasn't sure why.  56 bit fixed seemed like plenty.  In fact, it's been a long time since my last comp. sci. class, but I thought 56-bit fixed offered better precision over a small range like -1 to 1 than float.  Or is the quantization error happening somewhere in the multiply steps?  Again, my understanding was as long as you have enough bits for the accumulator, fixed bit multiplies will have less error that float, especially if you're multiplying small and big numbers together.  I suppose the devil is in the details.

 

 

Upshot:  I had time last night to take a new set of sweeps for just one position and let MSO do it's magic.  The result of a few minutes of computation was pretty darn good.  I plugged in the coefficients and measured +/- 2 dB or so over 10 to 90 hz where the subs drop off (I wasn't integrating with mains), and less than +/- 2 from predicted to actual (majority of difference 10 to 20 hz).  I'm encouraged.  Now I just need to ensure that I don't have timing problems when I take new baseline measurements.  Once I move the mic to a new position, there's really no way to repeat a previous measurement to know for sure that it wasn't faulty.

 

 

p.s. I looked at predicted/measured phase response for a sub with an all-pass, an LT, and a bunch of peqs applied, and it's really beautiful.  Very good phase agreement from 10 to 100 hz.


  • andyc56 likes this

#18 SME

SME

    Super Bass Overlord

  • Members
  • PipPipPipPipPipPipPipPip
  • 1,002 posts

Posted 28 October 2016 - 05:01 PM

@SME:  I've heard that minidsp had trouble with the low frequency filters, but I wasn't sure why.  56 bit fixed seemed like plenty.  In fact, it's been a long time since my last comp. sci. class, but I thought 56-bit fixed offered better precision over a small range like -1 to 1 than float.  Or is the quantization error happening somewhere in the multiply steps?  Again, my understanding was as long as you have enough bits for the accumulator, fixed bit multiplies will have less error that float, especially if you're multiplying small and big numbers together.  I suppose the devil is in the details.

 

The 56-bit fixed point vs. 32-bit floating point will have superior precision in different places.  The 32-bit floating point calculations will be far more accurate for very small numbers, much closer to zero than to +/- 1.  The problem isn't really with the multiplies but with accumulation as is usually the case with these things.  You may have not covered this subject in CS.  You're more likely to have covered it if you took a numerical computing course.  The amounts being accumulated for each sample are very small for low frequency filters, and the floating point computation handles this much more accurately.

 

Edit: Here's a Wikipedia article on the subject.


Edited by SME, 28 October 2016 - 05:02 PM.

  • dgage and andyc56 like this

#19 andyc56

andyc56

    Newbie

  • Members
  • Pip
  • 9 posts

Posted 28 October 2016 - 05:17 PM

Wow!  You sure did your homework on the biquad calculations.  I just skipped all the messy math and went straight to the answers published in one of the cookbooks online.  I confirmed that they matched what my MiniDSP 2x4 did.  The match was close enough for me not to notice, except for error that could be attributed to the 56-bit fixed point arithmetic on the 2x4 vs. 32-bit floating point in my simulations.  Differences became apparent below 30 Hz and worsened substantially below 20 Hz.  Anything below there was basically a crap shoot on the 2x4.  These same filters were fine on the OpenDRC-AN, which uses 32-bit float.

 

I haven't tried to do any simulation of finite word length effects on the coefficients.  If they were 32-bit floating-point, I guess I could use Matlab's single-precision floating-point arithmetic to get an idea of the error.  But with oddball-sized integer coefficients, it seems that would be a PITA to figure out.  I'm not a digital filters guy anyway, so I had to read a book on them by Antoniou (the op-amp gyrator guy) to understand what was going on.  I had to shake out some mental cobwebs going back to the 1970s. :)

 

I seem to recall that someone on AVS, it might have been notnyt, had some problems at low frequencies due to word length effects with one of the 8-channel miniDSP boxes when he used a 96 kHz plugin.  I believe it was for a high-pass filter for a vented-box sub with a pretty low tune.  He had to go with a 48 kHz plugin, which improved things, but the errors were still pretty easy to see as I recall.  It would be nice to find that thread again.

 

Bristow-Johnson has some amazingly compact formulas for the conversion of the analog filters to z-domain form for different filter types, but it is a different set of formulas for each filter type.  I wanted to have as much code shared between the filter types as possible for debugging reasons, so I ended up with formulas that are a lot messier than Bristow-Johnson's, but it's the same formula each time.  Only the center frequency pre-distortion technique varies from filter to filter.  I've attached the derivation below.

Attached Thumbnails

  • biquad_bilinear_trans.jpg

  • dgage likes this

#20 SME

SME

    Super Bass Overlord

  • Members
  • PipPipPipPipPipPipPipPip
  • 1,002 posts

Posted 28 October 2016 - 06:10 PM

Yep.  Precision problems will increase with higher sampling rate.  This is due to the increase in the number of computational operations and also the fact that the biquad coefficients often have the sampling rate in the denominator, so higher sampling rate makes their values even smaller.  I considered emulating the 56-bit fixed point arithmetic in my own simulations, but it would be a bit of a pain to implement support for multiple formats even in a language like C.  I imagine doing it in MatLab would be a nightmare.


  • dgage and andyc56 like this




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users