Open Source DSP XOs

[abraxalito]

Originally Posted by steph_tsf

Do you really mean an analog delay line of 22 µs ?

Yes, 22.675uS to a first approximation I found it surprising on first encountering the notion too.

Will the results (amplitude, phase, time domain response) be the same as the real-world digital IIR or FIR ? Can you provide an example ? Looks very promising ...

On the filter I have attached in schematic form to the post directly above yours, it does indeed agree with MATLAB. I will do more comprehensive checking (against MATLAB and reality) in due course as I explore more possibilities with this approach.

I guess you need somebody exploiting the LTspiceIV netlist in text format, then converting it into DSP code. Looks also very promising ...

Did you know that LTSpice accepts .wav files as input? So in theory its possible to take your favourite track and then process it through a filter designed in schematic form to see how it would sound (in theory). In the analog filter world of course, theory doesn't always tie up with practice. I have higher hopes for digital filters...

Which audio DSP platform are you targeting ? DSP56K maybe ? The Elektor DSP56374 board ?

Nope, a much cheaper one. See attached pictures - cute eh? Thanks for the links btw

[steph_tsf]

Originally Posted by abraxalito

DSP56K ? Nope, a much cheaper one. See attached pictures - cute eh? Thanks for the links btw

Hey, it reads Cortex-M0 on the PCB. Are you using the ARM Cortex-M0 as DSP engine ? Does it imply that you are using a 32x32 bit multiplication with a 64 bit accumulation ? Looks impressive. But wait a minute, how do you attach a I2S audio DAC on such CPU ? Are you using the built-in serial ports, or a FPGA maybe, so in a nutshell, how do you manage the frame sync and how do you guarantee it remains jitter-free ?

[abraxalito]

Originally Posted by steph_tsf

Hey, it reads Cortex-M0 on the PCB. Are you using the ARM Cortex-M0 as DSP engine ?

Bingo Well spotted.

Does it imply that you are using a 32x32 bit multiplication with a 64 bit accumulation ?

No - the multiply on the M0 is a lot more rudimentary. Perhaps you've been indulging in too much of the M4 user manual - I must confess to salivating on reading all about its DSP extensions M0 can do 32*32 in one cycle (20nS for the incarnation you're looking at there) but there's no way to handle any overflow so its best to keep the input values to 16 bits or less. Accumulation can be any number of bits (up to the limitation of 14 user registers) so long as the individual products don't overflow 32bits. This means long FIRs are not a problem but coefficients can't easily exceed 16bits.

Looks impressive. But wait a minute, how do you attach a I2S audio DAC on such CPU ? Are you using the built-in serial ports

Yes - at the moment one built-in serial port is generating the BCLK and DATA signals, I use a timer output to create WS. That makes up a single stereo I2S channel. The built in FIFO means this is good for up to 4X oversampling. There's a second serial port available for more fancy effects or doing a two way XO potentially (which is in the pipe of course, no timescales yet...).

, or a FPGA maybe, so in a nutshell, how do you manage the frame sync and how do you guarantee it remains jitter-free ?

Frame sync is admittedly a bit of a hack being generated by a timer. Have to set that up empirically which is a bit of a hassle. Its not jitter free yet - I have noticed jitter sidebands on the output of test tones, but they're fairly low in level (below -110dB from memory) so not overly concerned about them just now. A solution is available - use the SSP in slave mode with an external clock - for those who are jitter averse.

[steph_tsf]

Originally Posted by abraxalito

ARM as DSP, bingo Well spotted.

Would be fantastic if you manage to hook a S/PDIF receiver and two stereo DACs, for implementing a two-way digital crossover plus a Linkwitz Transform for flattening the deep bass. Clocking the whole stuff from the S/PDIF signal, using a quality S/PDIF receiver as master, is a way to avoid jitter. A digital Linkwitz Transform operating at 96 kHz without decimation requires 32 x 32 bit arithmetics, with 64-bit intermediate results. Have you considered the new Freescale ARM Cortex-M4 processors like the Kinetis K60 maybe ? They may support such 32x32=64 arithmetic, maybe not single cycle. For three-way crossovers, one may cascade two such lovely boards in digital domain using the remaining serial port.

[abraxalito]

Originally Posted by steph_tsf

Would be fantastic if you manage to hook a S/PDIF receiver and two stereo DACs, for implementing a two-way digital crossover plus a Linkwitz Transform for flattening the deep bass.

I'll have to look into the Linkwitz Transform as I'm not familiar with it. Thanks for the heads up. I think to do the full two-way XO we'd need to go for two M0's (not a big deal as the chips are about 1euro a piece). At present my setup has data coming in off a QA550 wav player through some HC595s. If I want to use the second serial port for output it shares pins I'm already using for that 8 bit parallel input, making things a tad awkward. So I figured perhaps with a two M0 setup we'd not only have more CPU cycles to play around with but also more buffer RAM to handle de-jittering. We might also be able to dispense with a dedicated SPDIF receiver chip (which is already more expensive than the CPU).

Have you considered the new Freescale ARM Cortex-M4 processors like the Kinetis K60 maybe ? They may support such 32x32=64 arithmetic, maybe not single cycle.

I have looked, but to be honest I'm rather lazy about learning new peripherals. I'll muck about with these until NXP's M4s come along. In the meantime there's always the M3s if I run out of CPU grunt.

For three-way crossovers, one may cascade two such lovely boards in digital domain using the remaining serial port.

Actually I was thinking of cascading using the on-board UART as its nicely buffered, then a 3 M0 solution could handle a 4-way XO. Haven't gone anywhere near the UART yet so that's looking a few months ahead.

[steph_tsf]

Would be nice to have such tiny lovely PCB replacing one or more AK4383 DACs. Hacking an audio-video receiver this way, you can be multichannel and multiway, all in digital domain. Imagine a USB port for configuring it in a flexible way, basing on a LTspiceIV netlist. See attached picture.

[Boden]

@ Abraxalito,

Hardware discussions aside, have you been looking into the level of performance of LspCAD 6.**PRO, Ultimate Equalizer/Sound Easy ord DEQX?

For Hi tec loudspeaker design, anything less ambitious than these packages in terms of filter SPL plus phase optimization and linearization capabilities should not be taken seriously. Now that is quite a task...

I will stay tuned!

Kind Regards,

Eelco

[abraxalito]

Originally Posted by Boden

Hardware discussions aside, have you been looking into the level of performance of LspCAD 6.**PRO, Ultimate Equalizer/Sound Easy ord DEQX?

Nope, are any of them open source? Or are they hardware boxes?

For Hi tec loudspeaker design, anything less ambitious than these packages in terms of filter SPL plus phase optimization and linearization capabilities should not be taken seriously.

Ah that's OK then - I'm not so interested in hi-tech, rather appropriate tech for the task at hand. Which, relative to what goes on in commercial DSP these days (see software radio or 4G phone basestations) needn't be very high tech at all. Which is just great because being well off the 'bleeding edge' means we get what we need very cheap

I will stay tuned!

You're welcome - but I will warn you now that if hi-tech solutions are your aim, this will never fit the bill

[Boden]

What are the current aims of your DSP?

Eelco

[Boden]

Sorry forgot to answer post 28. The mentioned programs are rather sophisticated software packages containing loudspeaker filter(x/o) simulators and, more important optimizers.

To my best of knowledge at least LSPcad Pro 6.** and Soundeasy can be used to program e.g. the Behringer 2496. Native software of the Behringer is a bit too simple for more sophisticated filter design, thus leaving the capabilities of the hardware largely unused. I am told these filter packages use Spice engines, but that might be wrong.

Eelco