Not as much as it might seem at first glance; Blackfins are a 16 bit architecture with 32 bit extensions and it happens they lack a 32 bit MAC (that's presumably why there are no 32 bit functions in the DSP library). So if one wants 32 bit for accuracy the 2000MMACs on the ADSP-BF609 are comparable to perhaps 200MMACs on a SHARC (I'd have to check the instruction set in detail). In comparison, higher end Cortex M4s also hit 200MMACs and boards+programmer/debuggers start around a quarter of an entry level Blackfin eval setup. I'm being somehwat loose here; Cortex M4 MACs are 32 bit multiply, 64 bit accumulate which is a bit less powerful than the SHARC's 32 bit multiply, 80 bit accumulate. But the Blackfin number I mentioned is more of a 32 bit accumulate. There are also some tradeoffs among architectures in IIR versus FIR performance and interesting things one can do with putting Cortex M4s in parallel.
That said, SHARC eval boards may be the best option depending on what one's looking for; the ones for entry level 800+MMAC parts are ~25% more than the ADSP-BF609 EZ-Board. And both Blackfin and SHARC eval boards are cost effective ways to get an entry level VisualDSP++ license and make interesting miniSHARC alternatives.
Last edited:
Do the math. 
32k taps * 48kHz * 8 / (12228 taps per 400MHz SHARC * 48kHz) = 21 400MHz SHARCs. You could maybe pull off the necessary 12.3GMACs with an 8 core desktop processor but looking into more efficient filtering approaches seems wise. I mentioned some IIR options in post 26 of this thread and there's a rich literature on computationally efficient FIR implementations that you can read up on. Another option would be to look at implementing convolution on GPUs. It doesn't massively parallelize all that well but with a couple hundred double precision TMACs available that doesn't really matter; various implementations are available.
This is all somewhat orthgonal to rePhase, though...
32k taps * 48kHz * 8 / (12228 taps per 400MHz SHARC * 48kHz) = 21 400MHz SHARCs. You could maybe pull off the necessary 12.3GMACs with an 8 core desktop processor but looking into more efficient filtering approaches seems wise. I mentioned some IIR options in post 26 of this thread and there's a rich literature on computationally efficient FIR implementations that you can read up on. Another option would be to look at implementing convolution on GPUs. It doesn't massively parallelize all that well but with a couple hundred double precision TMACs available that doesn't really matter; various implementations are available.This is all somewhat orthgonal to rePhase, though...
If i do it again from scratch i go for exaSound Audio Design > e18 DAC > Overview + PC as DSP.
I know this is DIY site. But any reasonable converters with DSP with volume controls will cost you ca. same with questionable outcome + still somewhat limited DSP power.
It is very difficult to make "ultimate" digital XO. You find yourself bettween a lot problem. Most difficult proper asynchrous USB input and proper clock distribution between dacs DSP and input. Unless you make your own DPS for everything you will have to deal with SMD rework and it always is mess
I know this is DIY site. But any reasonable converters with DSP with volume controls will cost you ca. same with questionable outcome + still somewhat limited DSP power.
It is very difficult to make "ultimate" digital XO. You find yourself bettween a lot problem. Most difficult proper asynchrous USB input and proper clock distribution between dacs DSP and input. Unless you make your own DPS for everything you will have to deal with SMD rework and it always is mess
Then the SHARC 21469 EZ-KIT LITE FOR THE ADSP-2146X SHARC FAMILY is a better choise. It has an ADSP-21469. The VisualDSP++ 5.0 Run-Time Library Manual for SHARC® Processors has a convolve function.
Unfortunately there is no uCLinux for the SHARC. I really don´t want to recompile just to change the impulse
more10, why not use the miniSHARC plateform?
For the price of a single evaluation board (with software?) you could buy 3 of those miniSHARC.
The forthcoming plugin will probably be limited in power, but there is room for improvement (taps distribution accross channels, downsampling of some channels, FFT convolution, etc.)
For the price of a single evaluation board (with software?) you could buy 3 of those miniSHARC.
The forthcoming plugin will probably be limited in power, but there is room for improvement (taps distribution accross channels, downsampling of some channels, FFT convolution, etc.)
Chapter 28: Digital Signal Processors How Fast are DSPs?
Could someone experienced in DSP figure out how long taps can be executed on a SHARC using FFT convolution?
Could someone experienced in DSP figure out how long taps can be executed on a SHARC using FFT convolution?
That will be the first plugin.
Last news they wanted to stick to 96khz, which with some power kept for IIR biquads will leave only 512 taps per channel (which is really not much at that sampling freq!).
After some discussions on their forum the plugin seems to be delayed (was supposed to be before christmas), so I hope they will go down to 48khz as the main sampling freq (1024 taps at 48khz is already quite a bit better) and allow for taps distribution among channels for the first version of the plugin (not need for 1024 taps for a non-brickwall crossover above a few hundreds of Hz...).
Further versions could implement downsampling of some channels and/or FFT convolution, time will tell...
Last news they wanted to stick to 96khz, which with some power kept for IIR biquads will leave only 512 taps per channel (which is really not much at that sampling freq!).
After some discussions on their forum the plugin seems to be delayed (was supposed to be before christmas), so I hope they will go down to 48khz as the main sampling freq (1024 taps at 48khz is already quite a bit better) and allow for taps distribution among channels for the first version of the plugin (not need for 1024 taps for a non-brickwall crossover above a few hundreds of Hz...).
Further versions could implement downsampling of some channels and/or FFT convolution, time will tell...
Last edited:
Coding is fun?
For a 4 way stereo filter that means 1500 taps. Is 1500 taps enough?
Simple answer, No. No way if you are doing anything below 500 Hz (guesstimate on the lower frequency limit) .
Let's just say the software sitting atop the miniSHARC seems primitive and the pace of development slow---I would tend to bet on Hypex porting Grimm's computationally efficient FIR phase correction to the DLCP first though the pace there is slow as well (but the coding's better). One reason why DIY with an M4 or SHARC eval board could be attractive if one doesn't want a PC in the loop (though doing one time EQ and phase correction offline and just playing back the equalized track with IIR XO can avoid quite a lot of fuss about real time processing power---perhaps I should do a Cross Time DSP DCR to support rePhase impulse files ).
).Brute force with PC CPU is quite doable, but don't sell DSP chips short. DCX2496 may not do lots of taps, but good sample rate conversion management covers a lot of ground.
Example:
Loopback of DCX channel with soundcard is used to capture IR of PEQ set to 47Hz, gain 9.5dB and Q=10.0. Capture done at fs 48kHz results in IR with >24k effective sample length, thus >48k samples active in DCX 96kHz sample rate output.
Future is bright with continuing development.
Chapter 28: Digital Signal Processors How Fast are DSPs?:
Chapter 18: FFT Convolution:
120 cycles per sample for a 16 k point filter.
A 300 MHz Sharc performs 1500 cycles per 192 kHz sample. It should be possible to filter 12 channels (ignoring memory bottlenecks).
Chapter 18: FFT Convolution:
120 cycles per sample for a 16 k point filter.
A 300 MHz Sharc performs 1500 cycles per 192 kHz sample. It should be possible to filter 12 channels (ignoring memory bottlenecks).
Last edited:
Why use a specialised DSP board when a near-silent PC can be had for a couple of quid?
And then you can develop on the target machine using free software. 32 bit floating point is very quick and it's powerful enough to use 64 bit if you so desire (even on a 32 bit machine). Plus you lock everything to the same sample clock (sound card is the destination for the audio stream, source for your crossover app, and destination for your crossover's output).
All this talk of SHARCs etc. makes me think I'm missing something, and also makes me head spin at the learning curve involved.
And then you can develop on the target machine using free software. 32 bit floating point is very quick and it's powerful enough to use 64 bit if you so desire (even on a 32 bit machine). Plus you lock everything to the same sample clock (sound card is the destination for the audio stream, source for your crossover app, and destination for your crossover's output).
All this talk of SHARCs etc. makes me think I'm missing something, and also makes me head spin at the learning curve involved.
I posted some simulations on the miniDSP forum, in the hope they change their mind: Forum | miniDSP
(pic uploaded below for full resolution)
So you want 8 channels of fullrange correction
That is a lot to ask to a $175 kit!
Another solution to spare some of these taps (in the active crossover scenario) is to do the filtering with the biquads and use the FIR only for phase linearization.
In that case you know you will always get the precision you want for the magnitude (and no ripples), and as the impulse is not symmetrical you will make a better use of the available taps with energy centering...
Attachments
What's the difference between writing DSP on a PC and a dedicated DSP? I ask in all sincerity, because I have been busily writing my crossover software in 'C' for the last few months, and I thought I was doing DSP! Will you be writing in another language?