Open Source DSP XOs

[abraxalito]

I doubt very much they're unable - more unwilling to. I guess they see peripherals as the way that customers differentiate their ARM offerings. Yet I think it would be a good thing if ARM was more proactive in peripheral design - at least for the more 'core' stuff like serial, because then we might see more innovation in other areas - like NXP's SPIFI and SGPIO for instance. NXP's SSP is ARM's design but few other vendors use that (TI does I think, STM doesn't). An ARM designed I2S would be a boon.

[twest820]

Minor update: the LPC4310, 4320, 4330, and 4350 parts' status has transitioned to production and the datasheet was revised 10/11. Nothing really of note unless one happens to be targeting the 180 BGA where some of pins moved but there's a bit more detail on power consumption that's interesting for regulator sizing and such (the SGPIO peripheral's draw is still <tbd> but it's probably a few hundred microamps). Looks like I can run my XO+EQ with about 20mA. Versus 17mA for the SPDIF receiver and 16mA for the DAC's digital side. And 120mA typ for DAC analog and the output buffers. Darn op amps.

LPCXpresso 4.3.0 is out too. But I've been busy with layout verification and have to get code for Q31 filter bank synthesis together so haven't updated---there'll probably be another update by the time I get back to firmware.

[Trevor White]

Originally Posted by twest820

Minor update: the LPC4310, 4320, 4330, and 4350 parts' status has transitioned to production and the datasheet was revised 10/11. Nothing really of note unless one happens to be targeting the 180 BGA where some of pins moved but there's a bit more detail on power consumption that's interesting for regulator sizing and such (the SGPIO peripheral's draw is still <tbd> but it's probably a few hundred microamps). Looks like I can run my XO+EQ with about 20mA. Versus 17mA for the SPDIF receiver and 16mA for the DAC's digital side. And 120mA typ for DAC analog and the output buffers. Darn op amps.

LPCXpresso 4.3.0 is out too. But I've been busy with layout verification and have to get code for Q31 filter bank synthesis together so haven't updated---there'll probably be another update by the time I get back to firmware.

what are you making ?

[twest820]

An embedded replacement for my PC XO and EQ. At the moment it's a WM8805+LPC4300 in LQFP144 (the 4310, 4320, or 4330 are all available in this package and are pin compatible)+CS4565 SPDIF->DSP->DAC board. The BOM's been through several iterations and might change again but it looks fairly well converged at this point.

[twest820]

Thought I’d mention I’ve implemented equivalents of arm_biquad_cascade_df1_q31 (32 bit fixed point samples with 64 bit accumulate), arm_biquad_cas_df1_32x64_q31 (32 bit fixed point samples with 64 bit accumulate and feedback), and a higher precision version that would be probably be called arm_biquad_cas_df1_64x64_q31 (32 bit fixed point samples with 64 bit accumulate, coefficients, and feedback). I’ve been using the code on a PC to do some of the numerical characterization Abraxalito, Steph, and I were discussing over on the IIR Lab thread and have found that, chosen appropriately, the filters hit the quantization noise floor of 24 bit audio. This is comfortably below the noise floor of an ES9012 DAC in mono.

As a rule of thumb, for redbook audio Q31 is sufficient for filters centered at 1kHz and above, Q31_32x64 is sufficient to around 200Hz, and Q31_64x64 is a good choice below that. Back of the envelope I’m estimating my relatively complex 38 biquad three way XO+EQ would require a Cortex M4 core running at 60MHz. Scale accordingly for higher sample rates.

If you want to do your own investigations grab the latest Cross Time DSP commit and have look at the unit tests to get started.

[mhelin]

Originally Posted by twest820

An embedded replacement for my PC XO and EQ. At the moment it's a WM8805+LPC4300 in LQFP144 (the 4310, 4320, or 4330 are all available in this package and are pin compatible)+CS4565 SPDIF->DSP->DAC board. The BOM's been through several iterations and might change again but it looks fairly well converged at this point.

You mean CS4365 DAC? Do you have all of them (SPDIF,DSP and DAC) on the same board or separate ones? I think modular design would suite best for people who like to use different components (SPDIF receiver, ASRC, clock, DAC's etc). How are you clocking the DAC? Is it interface using SGIOP? I'd like to use the Crystal DAC as well but also with XMOS and it's I2S lib need you have an external clock (24.576 MHZ for an example) feeding XMOS which is the master and generates other clocks. With XMOS it's also easy to use ADAT interface as output.

[twest820]

Yes, 4365; 4565 is a typo. SPDIF, DSP, and DAC are all on the same board with one of the WM8805's clock outputs going to the CS4365 and the other to the LPC4300. I'm using a mix of the 4300's I2S and SGPIO peripherals and the preliminary schematic includes an expansion header with duplex clocking, I2S receive, and the seven SGPIO lines that aren't used for driving the 4365.

So it's not modular per se, but if one wants to patch in an ADC, different multichannel DAC, alternate clock, or pretty much any arbitrary I2S source or sink it's not particularly difficult.

[mhelin]

Originally Posted by twest820

So it's not modular per se, but if one wants to patch in an ADC, different multichannel DAC, alternate clock, or pretty much any arbitrary I2S source or sink it's not particularly difficult.

So you haven't been considering adding a sample rate converter? Anyway, the LPC4300 looks interesting because of the SGPIO, using multiple I2S ports feels complicated because separate clocks are needed for both interfaces.

Btw. is the 4300 pinout compatible with 2294 for an example, there are these modular (empty) boards I'd like to use:

Empty ARM MCU Cards for NXP LPC devices - mikroElektronika

E: To answer myself they aren't compatible.

[mhelin]

Looked at the LPC4330-Xplorer schematics. The board has onboard UDA1380 codec /A/D SNR 97 dB, DAC 100 dB) using I2S0 but the I2S1 pins are used by the flash. The SGPIO pins are supposed to be exported to the headers. So it can be used for developing the software and DAC at least.

[twest820]

Originally Posted by mhelin

So you haven't been considering adding a sample rate converter?

Considered and rejected based on ABX results (and some maths). The time domain degradation from resampling is inversely proportional to the change in sample rate and proportional to the steepness of the antializasing filter. I found 4x resampling with a slow rolloff was OK, but preserving the original bit rate was subjectively preferable. It can also be computationally preferable; for biquads CPU scales rather like O(N log N) with sample rate due to the increased precision needed when the filters are operated at low normalzied frequency.