Hypex DSP module(s)

[Trevor White]

Originally Posted by ds23man

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

[ds23man]

Originally Posted by Trevor White

how did you come to that conclusion ??

I did not, Twest did!

[Trevor White]

Originally Posted by ds23man

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.

[Koifarm]

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.

[pos]

Originally Posted by twest820

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

[pos]

Originally Posted by Trevor White

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

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)

[ds23man]

Originally Posted by pos

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 far taps would be required to correct a filter lower in frequency (but with more audible gain probably)

There is a empty spot on the DLCP, and if I look right it can be used for a second TAS3108!

[twest820]

Originally Posted by pos

Interesting software!

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

Originally Posted by Trevor White

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.

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

[Trevor White]

Originally Posted by twest820

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

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.

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.

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.

Sorry I should have said the SHARC has 80 bit accumulators in fixed point mode and 40 bit accumulators in floating point mode.

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

what is a minisharc ? I don't see it on their website.

[twest820]

So no particular analysis, got it, thanks.

Originally Posted by Trevor White

What is a miniSHARC? I don't see it on their website.

The product announcement's in the December 2012 newsletter. Nothing not already available in the OpenDRC. really.