Open Source DSP XOs

[rsdio]

Originally Posted by steph_tsf

I own a Microchip ICD3 debugger.
Can I program and debug all three chips individually, from a single debug connector ?
Is there something like the ARM "SWD multidrop" debug protocol, in the Microchip world ?

I do not believe so. Other debugging standards like JTAG involve a daisy-chained serial loop, such that multiple chips can be debugged with one connection. However, my understanding is that the Microchip debugger connects directly to a pair of serial lines on a single chip, with no provision for extending the lines to more than one chip.

You can also ask this question on the Microchip forum.

[steph_tsf]

Seems that a chip like PIC32MX534F064H (5.06 eur from Mouser, 64-pin) also benefits from the SPI upgrade supporting I2S. There are three SPI. They could interface a WM8580A Codec for implementing a stereo 3-way crossover with SPDIF-in, Analog-in, and volume control. As all three SPI are taken by the audio lanes, one extra SPI needs to be implemented using bit-banging for controlling the volumes.

Seems that the PIC32MX534F064L (5.67 eur from Mouser, 100-pin) has four upgraded SPI. This way the fourth SPI can be used for controling the volumes, so no bit-banging anymore for controlling the volumes.

I'm tempted by a MikroElektronika MINI-32 board (25.00 usd), featuring a PIC32MX534F064H inside. Designing a MINI-32 "shield" hosting a WM8580A Codec (5.91 eur from Mouser) would lead to a stereo 3-way crossover with SPDIF-in, Analog-in, and volume control. Don't know if the built-in USB can be used as audio input.

Quite interesting is the MikroElektronika AUDIO CODEC PROTO. This is a tiny board hosting a WM8731 Codec. During months, MikroE remained evasive about how to connect it on a PIC32 SPI. Now with the PIC32 SPI upgrade supporting SPI, it should be a piece of cake. I guess MikroE is now working on sample code for their MINI-32 board when hooking their AUDIO CODEC PROTO.

[rsdio]

Originally Posted by steph_tsf

PIC32MX534F064H There are three SPI.

PIC32MX534F064L (5.67 eur from Mouser, 100-pin) has four upgraded SPI.

I'm tempted by a MikroElektronika MINI-32 board (25.00 usd), featuring a PIC32MX534F064H inside. Don't know if the built-in USB can be used as audio input.

The PIC32MX534F064H should be able to handle USB Audio Class 1 at Full Speed, but you probably have to write your own firmware.

The 64-pin 'H parts have 3 I2S SPI, the 100-pin 'L parts have 4 I2S SPI.

[abraxalito]

PIC32 would get more interesting for me if there were any other silicon vendors adopting MIPS cores. Anyone know of any? - in the uC market I mean, not stuff like Alchemy Semi.

[s3tup]

Originally Posted by steph_tsf

Wonderful ! Would be nice to have a crossover signal flow like the one I've attached. Is it feasible ?

I have no "linked frequency point" filters - it's a bit more complicated and isnt useful in the real world (imho) - acoustical slopes/response/phase rules the resulting system response, and the filters should flex the acoustical output to specific slopes/Q/freq points...

I don't have multiple-out filters, as everything is based on single pieces of transfer functions which have single input-single output...

Otherwise, it's up to you how would you like to chain the transfer function blocks - "tree", "paralel".

I haven't yet implemented the mixing/substracting of signals - where several outputs are connected to single input... I'll implement it.
You can't make loops of filters...


I'm pretty far from hardware export of filters - i can do biquad coefficients, but signal routing and coefficiencts insertion into DSP source code is out of my reach right now.
Could you please share your DSP sourcecode for the ARM you have?
Probably i'll generate a source for fuctions of DSP blocks in text:

PHP Code:

float DSP_LP2_x1234(float inSignal, int pos)
{
float a0=0.000001;
float a1=0.000001;
float a2=0.000001;
float b0=0.000001;
float b1=0.000001;
float b2=0.000001;

return (inSignal[pos]*a0 + inSignal[pos-1]*a1 + inSignal[pos-2]*a2)/(inSignal[pos]*b0 + inSignal[pos-1]*b1 + inSignal[pos-2]*b2);
} 


with a chaining in the main():

PHP Code:

void main()
{

float in_0=0;
float in_1=0;

float out_00=in_0;
float out_01=in_1;
float out_10=in_0;
float out_11=in_1;
float out_20=in_0;
float out_21=in_1;

while (1==1)
{
out_00=DSP_LP2_x1534(out_00,x);
out_00=DSP_HP2_x1434(out_00,x);
out_00=DSP_Notch_x1334(out_00,x);
out_00=DSP_Whatever_x1232(out_00,x);

out_01=DSP_LP2_x1534(out_01,x);
out_01=DSP_HP2_x1434(out_01,x);
out_01=DSP_Notch_x1334(out_01,x);
out_01=DSP_Whatever_x1232(out_01,x);

out_10=DSP_HP2_x1555(out_10,x);
out_10=DSP_HP2_x1555(out_10,x);

out_11=DSP_HP2_x1555(out_11,x);
out_11=DSP_HP2_x1555(out_11,x);

x++;
}
} 


The sourcecode itself is quite mechanical, and could be generated based on text templates:

PHP Code:

float $function$ (float inSignal, int pos)
{
float a0=$a0$;
float a1=$a1$;
float a2=$a2$;
float b0=$b0$;
float b1=$b1$;
float b2=$b2$;

return (inSignal[pos]*a0 + inSignal[pos-1]*a1 + inSignal[pos-2]*a2)/(inSignal[pos]*b0 + inSignal[pos-1]*b1 + inSignal[pos-2]*b2);
}
} 


[steph_tsf]

At this stage, I think that the idea of an open-source DSP Xover would benefit from a fully documented application implementing a stereo 3-way crossover having a fixed structure like the one shown above, only using IIRs, substractors and delays.

There would be a front-end written in Visual Basic, using USB and a Windows PC for modifying values like IIR coefficients and delays.
For calculating the IIR coefficients, we already have IIR_Lab, a design help for digital audio filters. It may suffice in the early days. IIR_Lab : a design help for digital audio filters

No doubt there can be more elaborate front-ends running on Windows, providing graphics, relying on Visual Basic or anything else. At the moment, I guess that most developers will want to keep their front-ends proprietary, and I fully respect such approach.

As shown above, if the PIC32 redesigned SPI can synchronize three SPI in audio (aka I2S) mode, a proof of concept can be designed right now using one MikroE MINI-32 and one MikroE AUDIO CODEC PROTO (Codec in Master Mode). The oscilloscope can easy tell if all three SPI outputs remain in sync. If all three SPI outputs remain in sync, it will be time for designing a "shield" for the MikroE MINI-32, hosting a WM8580 Audio Codec.

As soon as there is an Embedded Artists LPC43xx LPCXpresso board, more computing power will be possible.

[chaparK]

Interesting topic, thanks for sharing your ideas. I looked at the STM32F4 and i must say i'm impressed.

Originally Posted by s3tup

[...] I'm pretty far from hardware export of filters - i can do biquad coefficients, but signal routing and coefficiencts insertion into DSP source code is out of my reach right now.
Could you please share your DSP sourcecode for the ARM you have?
Probably i'll generate a source for fuctions of DSP blocks in text:

PHP Code:

float DSP_LP2_x1234(float inSignal, int pos)
{
float a0=0.000001;
float a1=0.000001;
float a2=0.000001;
float b0=0.000001;
float b1=0.000001;
float b2=0.000001;
 
return (inSignal[pos]*a0 + inSignal[pos-1]*a1 + inSignal[pos-2]*a2)/(inSignal[pos]*b0 + inSignal[pos-1]*b1 + inSignal[pos-2]*b2);
} 


s3tup, if your code is implementing a biquad, then it's not OK. You need a buffer for the output signal, and forget about dividing terms. Division is nearly heresy in DSP

[s3tup]

chaparK,
That sourcecode is just example... Actual code will have all the in/out buffers, and proper biquad implementations...

As i think of it, it's enough to write a piece of efficient code in ASM, and then integrate it to the code-generator routine... in the other hand, these compilers tend to optimize the code pretty good...

[dudaindc]

Originally Posted by steph_tsf

Wonderful ! Would be nice to have a crossover signal flow like the one I've attached. Is it feasible ?

Nice GUI... is the your code too?

[steph_tsf]

Originally Posted by dudaindc

Nice GUI... is the your code too?

Xover is a visual basic application used as front-end, designed for sending parameters to any DSP, provided it is running open source code. As I would like to generate some revenue from it, I don't intend distributing Xover as is, but instead, I intend transforming it into a web based application, asking 0.99 $ each time the DSP gets flashed. No money asked when you change parameters. Money only asked when you want the changes to become permanent. At the moment I have no idea what kind of web-based framework I may use.