DEQX Premate 8 digital active crossover / DSP

[voodooless]

Instead of shooting the messenger why don't you step up to the plate and provide evidence to the contrary and prove that the SHARC chip can't do FIR or convolution in hardware when the block diagram for the chip clearly states it has dedicated hardware to do this.

Not to mention the text just above it:

 

[Tranquility Bass]

Not to mention the text just above it:

View attachment 369810

Not only that they have had dual core SHARC DSP with built in ARM core as well for quite a while https://www.analog.com/en/products/adsp-sc589.html

And now they have some new DSP's !! Look at the specs of this sucker https://www.analog.com/en/products/adsp-21837.html

Check it out. With 24 GFLOPs and 8 GMACS floating point performance That's equivalent to 41,666 taps at 192KHz or 83,333 taps at 96KHz or 166,666 taps at 48KHz. What's not to like ! That's why you use a dedicated DSP and not a phone chip !!

System Features

• SHARC-FX high performance floating-point core
• • 256-bit vector size
  • Peak performance at 1 GHz core frequency: 24 GFLOPS, 8 GMAC (32-bit float), 16 GMAC (16-bit fixed)
  • 64/512 kB L1 instruction/data RAM with ECC
  • 32/256 kB L1 instruction/data cache with ECC
• 
  
• Arm Cortex-M33 connectivity core
• • 400 MHz frequency, 64/128 kB instruction/data RAM with parity protection
• 
  
• Memory
• • Parallel operation with dedicated memory, DMA, and multichannel support
  • Up to 16 Mb (2 MB) on-chip L2 SRAM with ECC protection
  • One Level 3 (L3) 16-bit interface to DDR3L SDRAM devices
• On-board accelerators
• • Two FIR engines (up to 1 GHz, 4 taps per cycle)
  • Four IIR engines (up to 1 GHz, 6 cycles per biquad each)
• 
  
• Security
• • Cryptographic hardware accelerators
  • Fast secure boot with IP protection

Package, Key Peripherals, and Compatibility

• 17 mm × 17 mm, 400-ball BGA_ED (0.8 mm pitch), RoHS compliant
• Ethernet, HyperBus, CAN-FD, HADC, I2C, ASRC/SPORT
• ADSP-2156x and ADSP-2159x layout-compatible options

 

[voodooless]

What's not to like !

I guess the price

That's why you use a dedicated DSP and not a phone chip !!

I don’t know. Given that current phone chips are faster than laptops of about 5 years ago, I really doubt that a phone SOC would have issues doing 40k taps at 192kHz with plenty of channels The DSP chip alone is the price of a complete Pi5.

 

[Tranquility Bass]

I guess the price

I don’t know. Given that current phone chips are faster than laptops of about 5 years ago, I really doubt that a phone SOC would have issues doing 40k taps at 192kHz with plenty of channels

We'll it would kind of add credibility if we knew what this magic phone chip was

 

[voodooless]

We'll it would kind of add credibility if we knew what this magic phone chip was

Pick one… any recent midrange chip will probably have enough performance. Check out what CamilaDSP can do on an age old Pi3, it’s not even funny. Pi4:

A Raspberry Pi 4 doing FIR filtering of 8 channels, with 262k taps per channel, at 192 kHz. CPU usage about 55%.

 

[Tranquility Bass]

Pick one… any recent midrange chip will probably have enough performance. Check out what CamilaDSP can do on an age old Pi3, it’s not even funny. Pi4:

They said it's a 6 core device running at 2GHz. What would that be ??

 

[Keith_W]

Check it out. With 24 GFLOPs and 8 GMACS floating point performance That's equivalent to 41,666 taps at 192KHz or 83,333 taps at 96KHz or 166,666 taps at 48KHz. What's not to like ! That's why you use a dedicated DSP and not a phone chip !!

That's wonderful. In that case, I stand corrected. Do you know of a product that has this chip in it? And BTW, is 166,666 taps @ 48kHz per channel x 8 channels?

 

[Tranquility Bass]

That's wonderful. In that case, I stand corrected. Do you know of a product that has this chip in it? And BTW, is 166,666 taps @ 48kHz per channel x 8 channels?

Divide by 8 for 8 channel count but no doubt you would need less taps for the higher frequencies. It's a new chip in pre-release status but there is an upgrade path for existing 21565 and 569 designs using the same foot print

 

[voodooless]

They said it's a 6 core device running at 2GHz. What would that be ??

I’m not sure what your question is? This midrange SOC for instance has quite a bit more cores:

Exynos 1380 5G Mobile Processor | Samsung Semiconductor USA

Meet the new Exynos 1380 processor for power like a pro. With octa-core CPU, powerful GPU, 200MP camera, 5G modem and on-device AI, upgrade your mobile experience to pro-grade.

semiconductor.samsung.com

Cortex®-A78x4 2.4GHz

Cortex®-A55x4 2.0GHz

The Pi4 is 4xA72 at 1.8 GHz , Pi5 is 4xA78 at 2.4 GHz, more equivalent to the above. All of them will easily do the number of FIR taps the dedicated DSP chip can.

 

[mdsimon2]

Linkwitz does not mention that it is possible to digitally delay drivers so that they can become coincident again.

The point of the Linkwitz quote is that for non-coincident drivers, digital delay is only valid at one point (on-axis) and cannot be valid at other locations. Therefore, with linear phase filters you will get ringing off-axis unless you are using coincident (i.e. coaxial) drivers. Now, there is certainly an argument that on-axis is more important, but it is important to understand what he was saying.

To add to the discussion, my first use of FIR was with an ADSP-21369 (third generation SHARC) running at 333 MHz, this provided 9600 taps at 48 kHz and was more than capable of delivering the following linear phase XO:

-LR4 at 80 Hz
-LR8 at 1 kHz
-LR8 at 3 kHz

The comparisons in this thread between SHARC and ARM are also a little bit odd as they aren't using the same technique and likely have significant latency differences.

Shamelessly stealing a quote from @HenrikEnquist from this post -> https://www.audiosciencereview.com/...nts-and-rising-noise-floor.42383/post-1501159 in response to the question:

Thank you for sharing this. I must say I'm both surprised and not at the same time. I work in software as a performance automation engineer and that's how I would look for a solution. What I don't get is: if a rpi can provide the processing power, why not use it in a minidsp device or use the same kind of parts? It doesn't make sense to me for hardware to be the limitation.

The hardware is only one part. CamillaDSP (and other software DSPs) rely on FFT to do fast convolution. This has a few disadvantages that you probably don't want in a hardware dsp. The first is that it needs a lot more ram and storage to store and run the algorithms. The second is that it requires the sound to be processed in chunks of preferably a few thousand samples. This again needs more ram, and also adds quite a bit of delay. Hardware DSPs that support FIR normally perform the convolution directly with a hardware MAC engine (multiply-accumulate). This gives less delay (basically only the inherent delay of the IR) but needs a lot more calculations than FFT convolution. The IR length gets limited by the speed of the MAC engine. They can usually do a couple of hundred million MACs per second, which is divided by the samplerate and the number of channels to see how many are available per sample. That's the maximum usable number of taps. It usually ends up at no more than a few thousand, and often less.

Michael

 

[voodooless]

The comparisons in this thread between SHARC and ARM are also a little bit odd as they aren't using the same technique and likely have significant latency differences.

Oh sure, fully agree. But the argument was raw FIR performance, not latency.

For anything other than video (playback) or audio production, latency is largely not an issue. And if the ARM device also does the video, it’s not even an issue because you can just compensate for it.

 

[Tranquility Bass]

I’m not sure what your question is? This midrange SOC for instance has quite a bit more cores:

Exynos 1380 5G Mobile Processor | Samsung Semiconductor USA

Meet the new Exynos 1380 processor for power like a pro. With octa-core CPU, powerful GPU, 200MP camera, 5G modem and on-device AI, upgrade your mobile experience to pro-grade.

semiconductor.samsung.com

The Pi4 is 4xA72 at 1.8 GHz , Pi5 is 4xA78 at 2.4 GHz, more equivalent to the above. All of them will easily do the number of FIR taps the dedicated DSP chip can.

What is the sample rate of this tap specification ? Usually the rpi defaults to 48K. Ironically the SHARC only runs at 1GHz which is half that of this ARM device.

 

[voodooless]

What is the sample rate of this tap specification ?

DEQX Premate 8 digital active crossover / DSP

Instead of shooting the messenger why don't you step up to the plate and provide evidence to the contrary and prove that the SHARC chip can't do FIR or convolution in hardware when the block diagram for the chip clearly states it has dedicated hardware to do this. Not to mention the text just...

www.audiosciencereview.com

Usually the rpi defaults to 48K. Ironically the SHARC only runs at 1GHz which is half that of this ARM device.

That’s not an easy comparison, as @mdsimon2 mentioned, the calculations involved are vastly different, plus that the DSP uses dedicated hardware, while the SOC has to rely on general computing cores (and some SIMD). I’m sure that the performance per watt of the DSP is better.

 

[Ibanez]

The new DSP Nexus uses the ADSP-21569 chip, and it can not do FIR filters. If you are aware of any FIR capable hardware convolver that uses the ADSP-21569 I would be quite interested. I have been looking for a FIR hardware convolver for quite some time.

I knew that you would pull out that Putzeys paper, it seems to be a favourite of yours. Ringing is risk that you run with FIR filters, you can certainly produce filters that don't ring, or ringing that is so low that it is inaudible. Compare this to min phase which rotates phase. It effectively takes your signal and smears it across time.

You seem to have truncated the Linkwitz quote. For the benefit of everyone reading, this is the full quote:



Linkwitz does not mention that it is possible to digitally delay drivers so that they can become coincident again. And, as Putzeys points out, the ringing is not audible.

And BTW, you seem to have quite an irrational hatred of DEQX (and also a few other things, e.g. Elektra). I wonder what they ever did to you.

But as I understand from an actual user of DspNexus, it can do FIR filters, read this link , read earik 's post with actual screenshot fro.m the unit. https://www.audiosciencereview.com/...sor-danville-signal-shipping-now.48922/page-2

And i aleady have an Antelope Orion SC, 16ch out balanced over dsub+ 2 monitor outs, unbalanced, 12 mic inputs.
And DSUB doesn't cost a fortune, not even prebuilt, if you buy 1 meter or shorter, the breakout doesn't need to be that long. And you can also DIY those at a fairly cheap price. What do your xlr cables cost vs breakout DSUB?
I mean Dsub and connect those to your regular XLR cables. I already got eight XLR, from my Okto that i had a little bad luck with, so my DSub didn't need to be that long. And Okto is not bad / price, it has AES/EBU also, but as you said, no mic input which is sad. But there you choose tonusr either UMIK or an ceap 2i2o interface, and connect that via AES to sych when measure.

Is merging using some other pinout DSUB standard than Tascam or Yamaha if they are so expensive to buy? I just need to ask.

 

[HenrikEnquist]

What is the sample rate of this tap specification ? Usually the rpi defaults to 48K. Ironically the SHARC only runs at 1GHz which is half that of this ARM device.

IMO it's not really meaningful to compare fir performance of dedicated dsp chips and general purpose cpus. A dsp chip can do much shorter and perfectly predictable latency, while the cpu can use much more efficient FFT convolution to do vastly more taps. Which one is better? Depends!

 

[ernestcarl]

What do you think of some of those "cheap" Chinese loudspeaker FIR DSP units found in AliExpress and Alibaba... ? "Brand naming" is different for very similar or exactly the same unit designs (judging from images/description only) e.g. Paulkitson, ShennDare, Nuoxun -- I'm sure there are a few loudspeaker management system units that carry other names as well.

Besides some bad English translations in their GUI programming -- https://www.diyaudio.com/community/threads/chinese-crossover-ningke-filters.402792/#post-7648483 -- do you think they're still "functionally acceptable" and not pure utter junk to avoid at all cost?

I'm already aware of the very limited taps per channel, but maybe 256 at 48k or 512 at 96k is already quite enough for me -- the rest of the EQ programming can be easily finished with IIR entries.

 

[Tranquility Bass]

IMO it's not really meaningful to compare fir performance of dedicated dsp chips and general purpose cpus. A dsp chip can do much shorter and perfectly predictable latency, while the cpu can use much more efficient FFT convolution to do vastly more taps. Which one is better? Depends!

And is also doable in the SHARC DSP which also has a dedicated FFT accelerator

 

[earik]

But as I understand from an actual user of DspNexus, it can do FIR filters, read this link , read earik 's post with actual screenshot fro.m the unit. https://www.audiosciencereview.com/...sor-danville-signal-shipping-now.48922/page-2

Yeah, I can attest that the dspNexus can do FIR. I'm running an 8-channel IIR+FIR hybrid system using it and am *mostly* happy. There's a really big "but" though...

The big issue with it right now is that for some reason, Danville put a 4th gen Sharc chip in there instead of a 5th gen one, which means that it's pretty easy to max out the CPU/memory if you use all the channels. For example, an 8-channel crossover with 48db/octave IIR slopes plus some driver eq ends up almost maxing out the cpu, so there's no room left to do a whole lot else (like adding FIR). In my design, I've got an 8-driver setup with individual driver EQ, then 4th order IIR crossovers, and then one FIR filter on top of each side for phase corrections and fine-tuning. I pushed it to like 95% cpu usage, but only managed to get like 1700 taps per side before I hit the limits of the chip. It sounds great, but you can't do a lot with only 1700 taps per side, so have to put most of the heavy lifting in on the IIR filters instead.

To be fair, Danville is working on what they say will be a free 5th gen dsp chip upgrade which will enable much longer filters, but they're over 6 months late on it at this point, and aside from "we're working on it" replies when I bug them, I have no idea if this will actually ever happen. This is a great unit for IIR (results-wise), but I wouldn't attempt to use it for FIR on anything more than a 2-driver crossover. It's just not powerful enough for that.

 

[HenrikEnquist]

And is also doable in the SHARC DSP which also has a dedicated FFT accelerator

Then it could make sense to compare a cpu with a dsp using the FFT accelerator to do overlap-add or overlap-save. I haven't seen any device using this though, it leads to high latency so might not be that attractive in practice.

 

[mdsimon2]

Yeah, I can attest that the dspNexus can do FIR. I'm running an 8-channel IIR+FIR hybrid system using it and am *mostly* happy. There's a really big "but" though...

The big issue with it right now is that for some reason, Danville put a 4th gen Sharc chip in there instead of a 5th gen one, which means that it's pretty easy to max out the CPU/memory if you use all the channels. For example, an 8-channel crossover with 48db/octave IIR slopes plus some driver eq ends up almost maxing out the cpu, so there's no room left to do a whole lot else (like adding FIR). In my design, I've got an 8-driver setup with individual driver EQ, then 4th order IIR crossovers, and then one FIR filter on top of each side for phase corrections and fine-tuning. I pushed it to like 95% cpu usage, but only managed to get like 1700 taps per side before I hit the limits of the chip. It sounds great, but you can't do a lot with only 1700 taps per side, so have to put most of the heavy lifting in on the IIR filters instead.

To be fair, Danville is working on what they say will be a free 5th gen dsp chip upgrade which will enable much longer filters, but they're over 6 months late on it at this point, and aside from "we're working on it" replies when I bug them, I have no idea if this will actually ever happen. This is a great unit for IIR (results-wise), but I wouldn't attempt to use it for FIR on anything more than a 2-driver crossover. It's just not powerful enough for that.

Thanks for the info. When you say 1700 taps per side, I take that as input channels? What sample rate are you using?

Michael