Thanks a lot for that in-depth explanation!
It depend on what kind of filtering you are doing in FIR: I think Bruno pointed out automated FIR generation (inverse response and the like) and steep slopes (with their off axis problems...).
In FIR you can actually replicate anything that can be done with IIR filters, and even keep the whole think minimal phase if you want to avoid any delay.
As you have pointed out doing filtering with only one convolution (and a direct one with the current openDRC implementation) will lead to less rounding errors than the equivalent biquad filters.
I have done a small software called rePhase that you can use to generate FIR to do all sort of filtering (linear phase Linkwitz Riley slopes of arbitrary order, among others) and manual EQ (both amplitude and phase can be EQed separately):
http://www.diyaudio.com/forums/mult...hase-linearization-eq-fir-filtering-tool.html
It is optimized to make the best use of a given number of taps, using auto centering of the impulse based on energy, and iterative optimizations to minimize deviations from target.
I which Hypex would let the user add a short FIR filter in front of the IIR filters to invert phase shifts (as per the Grimm Audio white paper, which was an inspiration for rePhase), but it looks like they decided to ditch that functionality
Last edited:
That's why it is a pity they didn't add a I2S header so you can add your own USB interface with or without I2S isolation.And you have to intergrate it on the pcb, means more space> more costs.
I think Hypex made a valid decision not to implement a state of the art USB audio streaming option. A lot of people are moaning about the price already!
BTW, with a Minidsp product you have to buy a seperate USB streaming board!
Who is talking about Minidsp here?
(at least Minidsp has I2S in and out headers)
That's why it is a pity they didn't add a I2S header so you can add your own USB interface with or without I2S isolation.
Who is talking about Minidsp here?
But the Minidsp has a cheapo dsp chip!
But the Minidsp has a cheapo dsp chip!
when you say cheapo dsp chip what do you mean ?
As I see it both the AD sigma dsp and TI TAS chips compete with each other in the market place and don't win any scores when it comes to the mips department. Also the TAS part is not recommended for new designs so that doesn't say much for its popularity.
Thanks a lot for that in-depth explanation!
It depend on what kind of filtering you are doing in FIR: I think Bruno pointed out automated FIR generation (inverse response and the like) and steep slopes (with their off axis problems...).
In FIR you can actually replicate anything that can be done with IIR filters, and even keep the whole think minimal phase if you want to avoid any delay.
As you have pointed out doing filtering with only one convolution (and a direct one with the current openDRC implementation) will lead to less rounding errors than the equivalent biquad filters.
I have done a small software called rePhase that you can use to generate FIR to do all sort of filtering (linear phase Linkwitz Riley slopes of arbitrary order, among others) and manual EQ (both amplitude and phase can be EQed separately):
http://www.diyaudio.com/forums/mult...hase-linearization-eq-fir-filtering-tool.html
It is optimized to make the best use of a given number of taps, using auto centering of the impulse based on energy, and iterative optimizations to minimize deviations from target.
I which Hypex would let the user add a short FIR filter in front of the IIR filters to invert phase shifts (as per the Grimm Audio white paper, which was an inspiration for rePhase), but it looks like they decided to ditch that functionality
I think you'll find the TAS doesn't have any serious horsepower to implement decent size FIR filters at least not for six channels !!
Nice! I considered writing something similar based on talking with Bruno here on DIYA about the same short FIR phase linearization mentioned in the Grimm whitepaper but was estimating a computationally prohibitive number of taps to do what I needed. So I ended up writing Cross Time DSP instead. I plugged my woofer/subwoofer channel with 7 biquads and one first order filter into rePhase and came up with 3000 to 6000 taps for redbook depending on the desired goodness of fit (maximum optimization, best of various windows). Call it 10,000 taps at the DLCP's sampling rate, stereo execution of which would maybe fit into two top end SHARCs running flat out. In comparison, the five forward time biquads I use require about 75 MACs if they're implemented with 64 bit coefficients and feedback on a 32 bit DSC like the Cortex M4. To execute that in stereo at 93.75kHz a single M4 might have to be clocked at oh, gee, perhaps 20MHz.
It's this explosion of taps at low normalized frequency that I had in mind when remarking FIR is inelegant. I quite agree the ability to run a few hundred stereo taps to phase linearize a two way XO or the mid-tweeter XO in a three or four way in forward time is useful. However, to my knowledge, it was never a goal to support such phase linearization in the DLCP.
Post 336 By Twest:
". Loosely speaking, the order from worst to best is SHARC floating point, SigmaDSP, SHARC fixed point, TAS3108."
Post 336 By Twest:
". Loosely speaking, the order from worst to best is SHARC floating point, SigmaDSP, SHARC fixed point, TAS3108."
how did you come to that conclusion ??
I did not, Twest did!
As I see it the TAS stores coefficient with only 23 bit resolution whereas a 32 bit fixed point processor has 31 bits of resolution. I'm sure the SHARC is going to perform transparently with 24 bit ADC's and DAC's. Even with 32 bit floating point it has a 23 bit mantissa and 40 bit floating point accumulator with 80 bits of multiply precision.
I shall test the hypex dsp agains my other active filters.
I use them for my special speaker project, a emarald physics CS1 clone.
Speakers designed to use with a dsp.
i already have,
- Behringer DCX2496 with analoge volumecontrol.
- Behringer CX3400 analoge active filter( moddified).
- Nanodigi with pcm4222 ADC and PCM1798 DAC.
So there will be enough to compare.
I use them for my special speaker project, a emarald physics CS1 clone.
Speakers designed to use with a dsp.
i already have,
- Behringer DCX2496 with analoge volumecontrol.
- Behringer CX3400 analoge active filter( moddified).
- Nanodigi with pcm4222 ADC and PCM1798 DAC.
So there will be enough to compare.
Nice! I considered writing something similar based on talking with Bruno here on DIYA about the same short FIR phase linearization mentioned in the Grimm whitepaper but was estimating a computationally prohibitive number of taps to do what I needed. So I ended up writing Cross Time DSP instead. I plugged my woofer/subwoofer channel with 7 biquads and one first order filter into rePhase and came up with 3000 to 6000 taps for redbook depending on the desired goodness of fit (maximum optimization, best of various windows). Call it 10,000 taps at the DLCP's sampling rate, stereo execution of which would maybe fit into two top end SHARCs running flat out. In comparison, the five forward time biquads I use require about 75 MACs if they're implemented with 64 bit coefficients and feedback on a 32 bit DSC like the Cortex M4. To execute that in stereo at 93.75kHz a single M4 might have to be clocked at oh, gee, perhaps 20MHz.
It's this explosion of taps at low normalized frequency that I had in mind when remarking FIR is inelegant. I quite agree the ability to run a few hundred stereo taps to phase linearize a two way XO or the mid-tweeter XO in a three or four way in forward time is useful. However, to my knowledge, it was never a goal to support such phase linearization in the DLCP.
Interesting software! Have you implemented a real-time version?
It would be similar to Phase arbitrator in its implementation I think (inverted overlapped buffers).
Concerning rePhase, if you stay at 48khz and use a rectangular window (best window if you only want to do phase correction and moderate amplitude corrections) 1024 taps should be enough to correct even a LR 48khz at 100Hz with only minor phase deviation down low (and of course any other additional filter at higher frequencies).
Current openDRC convolution implementation is direct, which limits it to something like 12000 taps at 48khz (depending on the additional power you want to keep for biquads sections), but fft convolution lead to much more taps available, still with less rounding errors than biquads.
I hope they will stay with a direct convolution, and let the user distribute taps between channels and downsample the frequency of the low channels to make the best use of the available taps (as per Four Audio's technique).
Anyway, this is a bit OT, but I think (direct) convolution is the most elegant (and mathematically optimal) way to do filtering (linear phase or minimum phase, or a mix of the two with a given target delay...) and will probably become more and more affordable in the future. Most of the price of these crossovers is already in the converter and analog path...
I think FIR has a bad reputation because it is always associated with semi-automated correction tools (which are sometimes really good, but require far more knowledge than it seams to operate correctly and not introduce more problems than solutions), steep filters (brickwall...), and delay.
Fact is anything that can be done in IIR can be done in FIR (with no additional delay), with less potential errors and sound degradation. And of course much more can also be done (phase correction being just one of these), with arbitrary amplitude and phase responses...
The principle -described in Bruno's white paper for Grimm Audio LS1- is not to do a FIR filter on each channel, but a stereo FIR in front of the IIR crossover to recover the phase shifts they will introduce.
The LS1 uses a derivate of the DLCP in a 4-way configuration, and has enough power to operate a short convolution to correct the LR24 @ 1.5khz.
That type of filter does not require a lot of taps, but more taps would be required to correct a filter lower in frequency (but with more audible gain probably)
Last edited:
Thanks! As time reversed IIR and FIR are both out of scope to the DLCP I agree we're getting a bit off topic for this thread. I'll reply in the rePhase thread in a bit. (Though the TAS3108's 135MMACs is enough to do about 200 taps per channel on the DLCP; maybe a future update will have support...)
Can you share the analysis on which this assertion is based? IIRs operating at low normalized frequency for subwoofers or room correction require about 16 guard bits, sometimes 20 depending on center frequency and sampling rate. That's another way of saying fixed point with 32 bit coefficients and feedback and 64 bit MAC will result in a DAC with 19 bit DNR---such as the AKM on the DLCP---outputting incorrect signal in the 19 - 32 + (16 to 20) = 3 to 7 least significant bits due to the DSP's numerical limitations resulting in it being told to do the wrong thing. From an objective standpoint this does not qualify as transparent as 19 + 16 to 20 = 35 to 42 bits of precision are needed to hold the numerical noise below the DAC's own noise floor. Floating point will be a few bits less accurate due to the larger rounding errors and an additional bit is needed in the DSP for every additional bit of the DNR in the DAC. So, to satisfy a basic definition of objective transparency with a 23 bit DNR DAC like the ES9012, about 43 fixed point bits are desirable. Might as well call it 48 bits and use something like the TAS3108 on the DLCP.
The TAS3108 uses 28 bit coefficients, not 23; please refer to TI's documentation for the part. You're correct accuracy relative to a biquad fully implemented with higher precision diminishes as coefficients are truncated but, as a basic approximation, there's no difference between a truncated coefficient and a higher precision coefficient whose least significant bits happen to be zero. Coefficients are about how accurately the requested filter is implemented and, at 28+ bits, the results are generally pretty decent. Numerical limitations in an IIR's feedback path want more caution as they result in limit cycles and other forms of non-periodic steady state noise. The TAS3108's 48 bit data path provides 48 bit feedback so calling it a 28 (or 23 bit) part neglects that it's numerically better conditioned than the more common implementations with 28 bit coefficients and feedback and 56 bit MAC or 32 bit coefficients and feedback with 64 bit MAC.
Also I think maybe you misread the SHARC documentation. The floating point multiplies yield 40 bit results, not 80. The fixed point multiplies are 64 bit and the accumulator's 80 bit. This allows slightly less conservative fixed point scaling than in DSPs without a 64 bit saturating MAC, potentially moving the numerical noise floor down by one or two bits if the implementer decided the extra shift instructions required to realign the data were worth it. Almost nobody does this so it's probably more realistic to view the SHARC's extended accumulator as a feature for avoiding FIR overflow that doesn't really apply to IIR biquads. A biquad chain can be made somewhat FIR like to reduce the scaling overhead and take better advantage of extended accumulators---search for merged biquads---but, again, it's unlikely most implementations will code this. So, in the majority of cases, the extra 16 bits in the SHARC's accumulator probably don't make a difference with respect to IIR accuracy.
However, as I mentioned a few posts back, I'm not aware of results as to whether allowing the numerical noise floor to rise above the DAC's noise floor is subjectively audible. Hence my interest in your analysis. Don't get me wrong here; I'm not saying the miniSHARC is going to be bad, just that a look at the DSP suggests the DLCP has a reasonable chance of being subjectively preferable even in cases where the DAC isn't being pushed hard (as an aside, I looked into DIYing my own SHARC based DSP platform a while back but couldn't justify the cost of the compiler).
The performance of the filter depends on its implementation. Rounding Errors can be minimized if the correct filter implementation is chosen for the bandwidth of interest. I have successfully implemented low noise filters on a SHARC using floating point that work well at low frequencies.
There is a good article about the sharc here Extended Precision Floating vs Fixed Point - Sharc | Comp.DSP | DSPRelated.com
yes it's 28 bits in a 5.23 fixed point format and that means only 23 fractional bits. Not much better than 32 bit floating point coefficients.
Sorry I should have said the SHARC has 80 bit accumulators in fixed point mode and 40 bit accumulators in floating point mode.
what is a minisharc ? I don't see it on their website.