Open Source DSP XOs

Status
This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.
Some interest was expressed on the nCore thread about implementing a digital version of the Orion ASP. Since its no longer relevant to that thread, here's a new one to see if there's any interest in a team effort to implement open source DSP crossovers. Not specifically restricted to SL's ASP but that might be a great starting point if the analog version's details were available with SL's permission.

My initial (crazy?) idea is to get models of various XO components working in LTSpice using Kendall Castor-Perry's delay line implementation here:

Which filters are noisier – analog or digital? part 2
 
I'd be interested. As in the general idea of open-source DSP, and the Orion would be a great initial case.

So. Team-building: We need engineers with DSP experience, or equivalent :) I'm not one, but I am a computer scientist so I can help with programming stuff. Can't commit lots of time as I'm knee deep in paid work, but I'll advise as best I can!
 
OPen source audio dsp for filters sounds wonderful. are you thinking diy all the way like using fpga or some already available dsp core? If fpga is way to go skip spice go for math software.
More or less i thing first to do is implement general signal path so we can use multiple filters without caring what inter connect we are using is benefiting most and hopefully people can easily try ne w filters.

REALLY WHAT KIND OF PLATFORM?

most of times when i am talking digital technology i get flamed, IT IS NOT MY FOUL THAT THEY DON*T UNDERSTAND WHAT I AM SAYING. I am not american and my english is poor. if that isn't enought to confuse you I AM DRUNK.
 
OPen source audio dsp for filters sounds wonderful. are you thinking diy all the way like using fpga or some already available dsp core? If fpga is way to go skip spice go for math software.

I was thinking to keep it relatively platform independent by doing the design more conceptually using LTSpice. But it can't be entirely platform independent so ARM was what I had in mind - at the least that's vendor independent. ARM means 32bit fixed point processing (with the option for 64bit math if/when called for).

FPGA is a bit daunting for any DIYer who's not got experience with it (which is probably most). However there's a growing number of free or low cost tools when it comes to ARM and its a micro which happens to run fast enough to handle DSP.
 
I was thinking to keep it relatively platform inspice dependent by doing the design more conceptually using LTSpice.

When LTSpice is good tool i think since we are doing actual coding it is better to do with math. Math is cross platform:). when using math soft we can test actual code more effectively. When it comes to resolution my experience we need minimum 56 bit in fixed point.

Have you looked Home :: OpenCores they have openrisc that sounds promising. when you said open source have you looked GNU arm tools?
 
Interesting idea. Source code availability aside, what processing capabilities are needed which aren't already available from existing solutions (MiniDSP, SigmaDSP, VSTs such as Frequency Allocator or ReaEQ, rackmount platforms like the ones from Ashley and Behringher, or even Hypex's DLCP if they ever get around to shipping it)? Replicating the ASP in any of these tools is just a matter of a couple minutes' data entry from Linkwitz's block diagram.
 
When LTSpice is good tool i think since we are doing actual coding it is better to do with math.

Do you mean Mathcad? Or Matlab? How to implement math?

Math is cross platform:). when using math soft we can test actual code more effectively.

Mathsoft? Is that a free package?

When it comes to resolution my experience we need minimum 56 bit in fixed point.

Doesn't that depend on what filter is being run though? For example the link I gave shows that for LF filters, more resolution is needed than with HF, given the same amount of noise.

Have you looked Home :: OpenCores they have openrisc that sounds promising. when you said open source have you looked GNU arm tools?

I looked but its relevance here escaped me. Care to elucidate? I have looked at GNU ARM tools, haven't played.
 
Interesting idea. Source code availability aside, what processing capabilities are needed which aren't already available from existing solutions (MiniDSP, SigmaDSP, VSTs such as Frequency Allocator or ReaEQ, rackmount platforms like the ones from Ashley and Behringher, or even Hypex's DLCP if they ever get around to shipping it)?

I had a brief look at SigmaDSP a while back but didn't invest time or effort because of not wishing to be locked into just one vendor (ADI in this case). Processing capability is a bit restricted going that route - its run at a fixed sample rate. The others I have no direct experience of. I don't doubt PC-based solutions have the necessary grunt in processing terms but I'm not a believer in the longer term ubiquity of the PC platform.
 
So you want something that can be easily compiled for a conventional instruction set as opposed to processor/family-specific DSC SIMD extensions or DSP instruction sets? Vinnie Falco's bits are worth a look. I'd describe the code as overly layered but it's faster to strip layers and port to C than to recode.

Personally when I looked at this space I concluded a SigmaDSP was the easiest way to meet my needs. The ARM Cortex parts and big AVRs have the MIPS to run a reasonable number of biquads (particularly if used as DSCs, though that violates the single vendor constraint) but the limited number of I2S peripherals makes them unfriendly to crossover operation. It's a bit more expensive to set up an Intel Atom fanless PC or a quiet laptop with an audio interface and run an ASIO based PC crossover but I found the time saving from not having to write a RTOS kind of core to move the data streams compelling in comparison---particularly as I already had the audio interface, VST host, VSTs, and old laptop to do the processing. Much easier than working with the xmon USB audio interface parts directly or paying the $$$ for a TC Dice license too. However, I'd ultimately like something more turnkey than a PC and the ADAU144x parts are quite attractive as they're cheap, available in DIY friendly packages, and have lots of I2S peripherals as well as onboard SPDIF and ASRC blocks. I figure that saves enough time I can probably migrate to another platform once SigmaDSP becomes obsolete and still come out ahead on the deal.

That said, I do have a C# project aimed at integrating DSP operations into rip+burn workflows which I plan to open source once I have enough coded for a meaningful release. It's been moving slowly since it's summer and my day job's been busy of late. The code's quite a bit simpler than Vinnie's and I've no objection to folks picking it up and porting it to C if they want. Just don't hold your breath. :p
 
So you want something that can be easily compiled for a conventional instruction set as opposed to processor/family-specific DSC SIMD extensions or DSP instruction sets?

No, I was barely thinking about instruction sets at all. Certainly wasn't thinking in terms of C. It would have most use ISTM if its just at the level of the conceptual block diagram of the filters - Direct Form I for example - with coefficients calculated for various cut off frequencies. LTSpice doesn't support anything close to C code. I'm a hardware guy and to me the best approach is to consider digital filters in the same way as analog ones - produce a schematic design and let individuals be concerned with the instantiation details.

Personally when I looked at this space I concluded a SigmaDSP was the easiest way to meet my needs. The ARM Cortex parts and big AVRs have the MIPS to run a reasonable number of biquads (particularly if used as DSCs, though that violates the single vendor constraint)...

I can see how in the case of AVR because that's solely Atmel, but how does an ARM DSC violate the constraint? At the present time the M4 is quite probably only available from Freescale (if they are indeed shipping real hardware?) but it won't be long before NXP's M4 comes along. Others are bound to follow.

... but the limited number of I2S peripherals makes them unfriendly to crossover operation.

Its been something of a limitation but less so with the introduction of NXP's M4 part where there are configurable sync serial ports.
 
Seems the Bristow-Johnson cookbook is likely sufficient, then. FIR synthesis is less turnkey but there's not exactly a shortage of textbooks describing windowing, Remez exchange, and so on.

If a single vendor's IP licensed to multiple implementors is considered a multiple vendor solution well, then, that's obviously OK. I also find the NXP M4s attractive but, well, they're still in development and I don't have a solution for routing and soldering BGAs that fits in what I'd consider to be a DIY budget. Digikey has the Freescale M4s in stock.
 
IIR are the way to closely follow a analog continuous filter prototype - their "irregular" structure compared to FIR make most "DSP" instructions less useful

there is a requirement for extended word length intermediates/storage - particualrly as BiQuad corner frequency ratio to sampling rate becomes large - 32 bits aren't enough to avoid truncation/quantization effects at the 16 bit output level with subwoofer frequencies and hi res sample rates
 
Last edited:
I have looked into options for developing DSP crossovers. As far as hardware solutions are concerned I think miniDSP and Behringer DCX2498 are hard to beat. Any alternative solution would not be much cheaper and will take an enormous amount of development.

The most appealing goal of such endeavor as I see it will be a computer based solution that can improve ease of use and be offered at no cost. VST plugins are not flexible enough and the good ones aren't free. My vision is a Universal Audio Driver that utilizes the CPU or the GPU to process the signal before routing it to the sound card. The interface should allow the user to build configurations on the fly by connecting processing blocks similar to Console or Kx-Project. IIR and FIR implementations should be possible. The disadvantages are centered around possible platform dependance and having to use a computer but the driver itself should be flexible enough to accommodate a variety of sound cards and DACs.
 
I'm not sure how powerful it effectively is for DSP use, but the latest core module used by the midibox.org project may be useful, especially because the firmware's already open source:

MBHP_CORE_LPC17 Module

That said I think it would be easier to work with miniDSP. I briefly spoke to them a while ago, and with the correct community based approach they MAY be open to allowing a custom programming interface to their boards. Something along the lines of sharing the communication protocol for their MCU, thereby allowing people to upload firmwares created with SigmaStudio.
 
Not exactly an XO...

Seeing as KC-P's LTSpice simulation idea is a little unconventional (discrete time filter being simulated in continuous time) I wanted to try out a fairly simple filter in it and see what the results looked like.

Here's the schematic for the first one I've tried. Its an FIR for sinc compensation, to use with a non-oversampled DAC in correcting the sinx/x roll-off inherent in such designs.

I originally used Audacity (its EQ function which allows a filter to be created from drawing lines on a frequency response graph) to create this but then when plugging it into MATLAB the results didn't agree with those in Audacity. So I figure Audacity may have some inaccuracies since when I put the same filter into LTSpice it more or less agrees with MATLAB. In due course I'll implement this in real hardware and the measurements will be the final arbiter. Until then if anyone wants to play with a simple (11 tap) FIR filter, here's my rather scrappy looking schematic. The scrappiness arises from it originally being a 21 tap filter which Audacity gave me which I found I could optimize down to 11 taps using LTSpice as the simulator - so the concept most certainly does work. :)


@twest820 - BGA is not the only available package for those NXPs - TQFP144 is shown too, a tad more DIY friendly. I see Freescale has just announced some 99c Kinetis K10/K20 M4s in small packages which they say will ship next year.
 

Attachments

  • KCPfir.zip
    1.2 KB · Views: 119
Last edited:
My initial (crazy?) idea is to get models of various XO components working in LTSpice using a delay line.
Do you really mean an analog delay line of 22 µs ?
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 ...
I guess you need somebody exploiting the LTspiceIV netlist in text format, then converting it into DSP code. Looks also very promising ...
Which audio DSP platform are you targeting ? DSP56K maybe ? The Elektor DSP56374 board ?
See it here http://www.elektor.com/magazines/2011/june/audio-dsp-course-(2).1810926.lynkx
IIR coefficients up to the 8th-order may be calculated using http://www.diyaudio.com/forums/digi...ir_lab-design-help-digital-audio-filters.html - see post #12
 
Last edited:
Status
This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.