Hypex DSP module(s) - Page 36 - diyAudio
Go Back   Home > Forums > Source & Line > Digital Line Level

Digital Line Level DACs, Digital Crossovers, Equalizers, etc.

Please consider donating to help us continue to serve you.

Ads on/off / Custom Title / More PMs / More album space / Advanced printing & mass image saving
Reply
 
Thread Tools Search this Thread
Old 23rd December 2012, 10:00 AM   #351
diyAudio Member
 
Join Date: Jun 2009
Quote:
Originally Posted by ds23man View Post
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 ??
  Reply With Quote
Old 23rd December 2012, 10:04 AM   #352
ds23man is offline ds23man  Netherlands
diyAudio Member
 
Join Date: Oct 2006
Quote:
Originally Posted by Trevor White View Post
how did you come to that conclusion ??
I did not, Twest did!

  Reply With Quote
Old 23rd December 2012, 10:29 AM   #353
diyAudio Member
 
Join Date: Jun 2009
Quote:
Originally Posted by ds23man View Post
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.
  Reply With Quote
Old 23rd December 2012, 10:32 AM   #354
Koifarm is offline Koifarm  Netherlands
diyAudio Member
 
Koifarm's Avatar
 
Join Date: Aug 2005
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.
  Reply With Quote
Old 23rd December 2012, 02:48 PM   #355
pos is offline pos  Europe
diyAudio Member
 
pos's Avatar
 
Join Date: Feb 2008
Location: Paris
Quote:
Originally Posted by twest820 View Post
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...
  Reply With Quote
Old 23rd December 2012, 02:53 PM   #356
pos is offline pos  Europe
diyAudio Member
 
pos's Avatar
 
Join Date: Feb 2008
Location: Paris
Quote:
Originally Posted by Trevor White View Post
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)

Last edited by pos; 23rd December 2012 at 03:19 PM.
  Reply With Quote
Old 23rd December 2012, 03:08 PM   #357
ds23man is offline ds23man  Netherlands
diyAudio Member
 
Join Date: Oct 2006
Quote:
Originally Posted by pos View Post
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!
  Reply With Quote
Old 23rd December 2012, 05:38 PM   #358
diyAudio Member
 
Join Date: Jun 2009
Quote:
Originally Posted by pos View Post
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...)

Quote:
Originally Posted by Trevor White View Post
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).
  Reply With Quote
Old 23rd December 2012, 10:35 PM   #359
diyAudio Member
 
Join Date: Jun 2009
Quote:
Originally Posted by twest820 View Post
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

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

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

Quote:
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.
  Reply With Quote
Old 23rd December 2012, 11:08 PM   #360
diyAudio Member
 
Join Date: Jun 2009
So no particular analysis, got it, thanks.

Quote:
Originally Posted by Trevor White View Post
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.

Last edited by twest820; 23rd December 2012 at 11:11 PM.
  Reply With Quote

Reply


Hide this!Advertise here!
Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are Off
Pingbacks are Off
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Low-cost active crossover module for Hypex UcD amps Al Garay Class D 1 12th December 2010 02:26 AM
Low cost dsp based crossover module Crossoverman Multi-Way 38 20th February 2010 11:25 AM
Wanted Hypex Power Module rhcclark Swap Meet 2 18th July 2008 02:32 AM
DSP module with AD-DA Snickers-is Parts 4 20th August 2007 05:00 PM
Hypex UcD 400 AD amplifier module for sale mp006ltk Swap Meet 9 15th November 2006 02:56 PM


New To Site? Need Help?

All times are GMT. The time now is 11:43 PM.


vBulletin Optimisation provided by vB Optimise (Pro) - vBulletin Mods & Addons Copyright © 2014 DragonByte Technologies Ltd.
Copyright 1999-2014 diyAudio

Content Relevant URLs by vBSEO 3.3.2