Can we get a comprehensive summary of the overall goals here?
I made a quick review of the dozen pages of this thread, and although I did not read every word I see lots of discussion of processors, but very little about external I/O. Certainly a lot of mention of I2S, which can be external - but only with some difficulty. There was at least one reference to a desire for the DSP XO to run untethered from a computer. There was also mention that this thread is "about" an ARM-based DSP XO. I was still left with what seem to be some huge questions.
Will analog input be required? optional?
Will digital input be pushing the sample clock (SPDIF, HDMI) or pulling the clock (USB, FW, EN, ?I2S)? ... or will there be options for both kinds?
Is the primary design expected to have analog outputs? This would more easily allow the ideal low-jitter clock near the DAC chip or chips.
Will digital outputs be a necessary option? I suppose this is a less critical question, since any design allowing on-board DAC circuits would also allow digital-only conversion to standard digital audio outputs.
Related to the last two questions: Is the primary output expected to be mainly digital or mainly analog?
Basically, I would enjoy seeing a design document of some kind, or a FAQ, or at least a review. Does abraxalito basically own this thread, and therefore the final determination of the design goals?
For me, the critical question with digital audio is always clocking, and thus working without a computer (untethered) means that the clocking will suffer (unless perhaps the DSP XO uses USB Audio Class to talk to media sources without a computer).
I suppose it's also possible for FireWire Audio Devices to talk peer-to-peer without a computer acting as a host, but I have not purchased the FireWire specifications to see whether peer-to-peer audio can be implemented. On this last note, there are standalone DSP solutions such as the Universal Audio UAD-2 Satellite (DUO and QUAD) FireWire DSP Accelerators, but they probably do not count as open source in the slightest. But their form factor is certainly attractive if all of the protocols can do what they need.
Anyway, I'll stop here and give folks a chance to respond to my basic questions.
EDIT: I suppose Word Clock would be a way to allow digital inputs that are technically "push clock" to be slaves, provided that the media source is capable of slaving to Word Clock input.
I made a quick review of the dozen pages of this thread, and although I did not read every word I see lots of discussion of processors, but very little about external I/O. Certainly a lot of mention of I2S, which can be external - but only with some difficulty. There was at least one reference to a desire for the DSP XO to run untethered from a computer. There was also mention that this thread is "about" an ARM-based DSP XO. I was still left with what seem to be some huge questions.
Will analog input be required? optional?
Will digital input be pushing the sample clock (SPDIF, HDMI) or pulling the clock (USB, FW, EN, ?I2S)? ... or will there be options for both kinds?
Is the primary design expected to have analog outputs? This would more easily allow the ideal low-jitter clock near the DAC chip or chips.
Will digital outputs be a necessary option? I suppose this is a less critical question, since any design allowing on-board DAC circuits would also allow digital-only conversion to standard digital audio outputs.
Related to the last two questions: Is the primary output expected to be mainly digital or mainly analog?
Basically, I would enjoy seeing a design document of some kind, or a FAQ, or at least a review. Does abraxalito basically own this thread, and therefore the final determination of the design goals?
For me, the critical question with digital audio is always clocking, and thus working without a computer (untethered) means that the clocking will suffer (unless perhaps the DSP XO uses USB Audio Class to talk to media sources without a computer).
I suppose it's also possible for FireWire Audio Devices to talk peer-to-peer without a computer acting as a host, but I have not purchased the FireWire specifications to see whether peer-to-peer audio can be implemented. On this last note, there are standalone DSP solutions such as the Universal Audio UAD-2 Satellite (DUO and QUAD) FireWire DSP Accelerators, but they probably do not count as open source in the slightest. But their form factor is certainly attractive if all of the protocols can do what they need.
Anyway, I'll stop here and give folks a chance to respond to my basic questions.
EDIT: I suppose Word Clock would be a way to allow digital inputs that are technically "push clock" to be slaves, provided that the media source is capable of slaving to Word Clock input.
Last edited:
See the first post in the thread. I see the thread as a gathering place for interested people to share tips, experiences, code and schematics of using ARM Cortex (M0,3 & 4) SoCs to implement high-end digital crossovers. The initial idea was to use LTSpice as a way of modelling filter designs but so far there's been not a lot of interest there.
I can't see why this wouldn't be just a matter for the individual designer?
Seems you're labouring under the assumption that there's a specific project behind this thread - at present there is not. But I am working on a sub-module design for a DAC using an ARM Cortex processor. At present I'm uncertain whether to share that design on this thread or on another. Feedback anyone?
There is no such 'primary design'.
I don't know what 'own the thread' would mean here. I'm just the initiator of the thread.
In my experience the critical question with digital audio is noise control. Discussion of PCs is tangential to the thread.
How about implementing a motherboard with DSPs on board + additional analog/digital cards which could be put into the motherboard at 90 angle? Just like PC, but with DAC cards.
You can use WM8804/5 transmitters instead of DACs if you want.
You can use different type DACs for different outputs - NOS TDA1543s, DS PCM1798/4, and many others. You can simply swap them given you have 256fs masterclock and proper i2s format configured for all dacs.
You can easily fall-back to simple SPDIF dacs by making additional SPDIF receiver board pin-compartable with DAC boards, and sticking SPDIF+DAC together.
Ah, and in case your DSP motherboard gets upgraded to FIR-capable CPU, or downgraded to the tiny TAS3108 - you have all your DACs salvaged and reused.
You can use WM8804/5 transmitters instead of DACs if you want.
You can use different type DACs for different outputs - NOS TDA1543s, DS PCM1798/4, and many others. You can simply swap them given you have 256fs masterclock and proper i2s format configured for all dacs.
You can easily fall-back to simple SPDIF dacs by making additional SPDIF receiver board pin-compartable with DAC boards, and sticking SPDIF+DAC together.
Ah, and in case your DSP motherboard gets upgraded to FIR-capable CPU, or downgraded to the tiny TAS3108 - you have all your DACs salvaged and reused.
Last edited:
All suggestions warmly welcomed 
I have considered this one and wondered why there's a need for the motherboard - I rather like the idea of brotherboards, without the need for a mother to plug them into. The disadvantage of the motherboard approach is knowing in advance what the maximum number of output channels is to be.
Suppose someone wants to build the ultimate digitally crossed over 7.1 system. Its entirely possible they might want in excess of 20 channels, necessitating at least 10 stereo slots being made available, This would be a bit of a bummer for those with more modest requirements. So why not just stack boards?
My initial design idea for a DAC is to have an SPDIF input, two NXP Cortex M0 or M3 CPUs and a stereo DAC (optional headphone amp, not yet decided) with on-board analog volume. This could be a fairly modest sized board - say no more than double credit-card sized. It might be possible to partition the DAC design to give two or four output channels (not yet decided). The idea is to have the board drive whatever poweramp you have (balanced input of course) without the need for any pre.
The aim for all this is high end sound, which to me means low power (for low noise). For my money S-D type DACs don't give high-end sound for all their impressive datasheet figures. So initially I'll likely begin with relatively cheap multibit (16bits) DACs.
I have considered this one and wondered why there's a need for the motherboard - I rather like the idea of brotherboards, without the need for a mother to plug them into. The disadvantage of the motherboard approach is knowing in advance what the maximum number of output channels is to be.Suppose someone wants to build the ultimate digitally crossed over 7.1 system. Its entirely possible they might want in excess of 20 channels, necessitating at least 10 stereo slots being made available, This would be a bit of a bummer for those with more modest requirements. So why not just stack boards?
My initial design idea for a DAC is to have an SPDIF input, two NXP Cortex M0 or M3 CPUs and a stereo DAC (optional headphone amp, not yet decided) with on-board analog volume. This could be a fairly modest sized board - say no more than double credit-card sized. It might be possible to partition the DAC design to give two or four output channels (not yet decided). The idea is to have the board drive whatever poweramp you have (balanced input of course) without the need for any pre.
The aim for all this is high end sound, which to me means low power (for low noise). For my money S-D type DACs don't give high-end sound for all their impressive datasheet figures. So initially I'll likely begin with relatively cheap multibit (16bits) DACs.
Brotherboards imply height-limit if stacked in arduino-style... All these fancy caps won't fit, as well as TO220 regs and transistors
Could you please list some of them? All i know are TDA1541, some big AD and PCM58/63s, which ain't that cheap nor easily obtainable, nor take a little of board space (with their DFs). They are fine for standalone hifi DACs, but a bit pricey and bulky for multiway solutions.
In addition, someone from russian board have run comparision of ultimate classic passive filter + class A amplification (Zen9 or Power Follower) + a good DAC against a ESI 1010 card with FIR crossovers, and FIR solution have easily outperformed the classical approach. He used a Troels Cyclop drivers set with their crossovers.
FIRs are far better than regular biquad solutions, but they require lots of horsepower from CPUs.
For the volume control - i'd suggest going with ladder-type relay attenuators. They are "digital" in volume settings and "analog" in attenuation. These should be put in the amplifiers to eliminate additional buffer stage required on their outputs.
Could you please list some of them? All i know are TDA1541, some big AD and PCM58/63s, which ain't that cheap nor easily obtainable, nor take a little of board space (with their DFs). They are fine for standalone hifi DACs, but a bit pricey and bulky for multiway solutions.
In addition, someone from russian board have run comparision of ultimate classic passive filter + class A amplification (Zen9 or Power Follower) + a good DAC against a ESI 1010 card with FIR crossovers, and FIR solution have easily outperformed the classical approach. He used a Troels Cyclop drivers set with their crossovers.
FIRs are far better than regular biquad solutions, but they require lots of horsepower from CPUs.
For the volume control - i'd suggest going with ladder-type relay attenuators. They are "digital" in volume settings and "analog" in attenuation. These should be put in the amplifiers to eliminate additional buffer stage required on their outputs.
Good points - I'm not using any coupling capacitors and there's nothing particularly power-hungry on the board so the regs are very unlikely to get hot. It would be kinda nice if my DAC board could find application in portable too
Glad to help out with more details - the DACs I have in my prototype designs are TDA1387 and TDA1545A. These I've chosen because they offer a really good bang for the buck. They're SO8 packages so not exactly real estate hogs. They have no DF on-board - that function is handled by the M0/M3 if required, according to the DIYer's wish.
I've implemented a clone of the SAA7220 on one Cortex M0, it runs at something like 5% of the power budget of that older chip.
I've been playng with AD605 for this function - whilst it doesn't have ultra-low THD it sounds fine to my ears.
From Analog Devices, there is the ADAU1702 (48 pin, 25 MHz, built-in Stereo ADC and 4-channel DAC) at 3.57 dollar. There are digital pins for connecting more DACs and/or a SPDIF input. You would always use the ADAU1702 as digital crossover engine, if there was not an issue regarding the development tool and licencing cost. Look miniDSP, the way they lock the software, preventing you from letting you run your own software.
From Freescale, one should not forget the Elektor DSP56374 board featuring all the necessary I2S lanes on the expansion header. However, the DSP56374 is phased out, and is not recommended for new designs. Elektor provides a valuable advice about a few possible development tools, requiring no licensing.
Within Freescale, there is also the DSP56725 (80 pin, 250 MHz, dualcore) at 6.05 dollar. I don't know if the DSP56374 development tools can accept a DSP56725 as target, dualcore.
This being said, a few recently introduced Flash 32-bit µCs costing 5 dollars, operating around 100 MHz, come now equipped with one or more I2S lanes for interfacing audio ADCs, DACs, CODECs and ASRCs. They are low power, minimizing EMI issues.
On one hand you have the recently introduced PIC32MX1 and PIC32MX2, featuring the MIPS M4K core running at 40 MHz and up to two I2S lanes. The BDTi report says "the multiplier can complete one 32×16-bit multiply or MAC operation in a single cycle. A 32×32-bit multiply or MAC completes in two cycles". There are other reports from other people saying the PIC32 needs more than two cycles for completing a 32x32 MAC. A possible issue is the C language interface, making me think that trivial audio DSP filters like IIRs and FIRs need to be programmed bare metal, in assembly language.
The recently introduced Microchip PIC32 MX1/ MX2 Starter kit (DM320013) hosts a PIC32MX220F032 with 32KB of Flash, 8KB RAM and a WM8731 24-bit Audio Codec. Actually, you may consider the DM320013 as the very first "open source DSP XO". Input your audio on pin 19 or pin 20 of the WM8731, split it in lowpass/highpass using your own software, and output the two resulting channels in analog on pin 12 and pin 13 of the WM8731. A piece of cake, a ready-to-run solution ? Now look the DM320013 schematic : Line_in and Line_out of the WM8731 are not exploited by the DM320013 PCB. And look the audio playback sample code provided by Microchip : instead of providing source code in assembly, they have followed the "C", "Driver", and "Modular" approach. And their bit-banging SPI implementation is using NOP loops. If you get tempted testing the PIC32, be warned you need to blast everything down to a simple and healthy bare metal assembly code, then grow from it, adding bells and whistles. You may get some help from Lucio Di Jasio Book "Exploring the PIC32" written in 2008 (quite old now). Also, there are a few interesting posts, about the PIC32 assembly code, on Microchip's website.
This being said, nothing prevents you from creating a PCB hosting a Wolfson WM8580 Codec or a Wolfson WM8581 Codec (always as master with its own quartz), providing a SPDIF_in, a stereo Line_in, and up to eight Line_out. For making a stereo 3-way or 4-way crossover. You would connect such PCB, acting as master, on any µC featuring up to four I2S lanes and one SPI lane. The local MCLK doesn't need to reach the µC. Such sub-assembly is definitely required, seeing how Microchip wasted the WM8731 resources in their PIC32 MX1/ MX2 Starter kit (DM320013).
Imagine you have such WM8580 or WM8581 sub-assembly lying around.
For a stereo 2-way crossover, you could use the Microchip Microstick II (DM330013-2) small development kit, hosting a PIC32MX220F032B chip. Such chip outputs two I2S lanes, and you can implement a SPI using bit-banging operating at Fs within the audio DSP interrupt service, without NOP loops.
On the other hand you have the ARM Cortex-M4 core implemented by vendors like Freescale (K10 K20 ... : one I2S lane), STM (STM32 F4 : two I2S lanes), Infineon (XMC4000 : six I2S lanes).
T.I. also has Cortex-M4 µCs, with their LM4F family, but currently they only feature SPI, and no I2S lanes. I guess T.I. is now evaluating the option consisting on providing McASP (coming from the C6000 world) on top of SPI for promoting their own Multichannel Audio Codecs using TDM or TDMCA.
Currently I am not listing the NXP LPC4300 (also basing on a Cortex-M4 core) because it is not a Flash µC, and because the I2S lanes need to be done using the M0 coprocessor tightly coupled to few SGPIO sequencers. This looks overcomplicated now that the Infineon XMC4000 family is in the pipeline.
The Microchip PIC32 MX1/ MX2 Starter kit (DM320013) looks ideal because of delivering one I2S lane, and incorporating a WM8731 Codec.
The first thing to do is to verify that the I2S lane can operate at the required bitrates and word lenghts for audiophile use.
For such purpose, one could create and share a bare metal assembly application, a "PIC32 Audio DSP engine" from where many motivated people could learn and grow.
If the "PIC32 Audio DSP engine" works well, a small PCB equipped with a WM8580 or WM8581 Codec need to be created, that would be reused on different µC platforms, especially the Infineon XMC4000.
Then, when the XMC4000 becomes available, no doubt there will be a low cost development kit available from Infineon. If Microchip doesn't feature I2S on their PIC32MX5 and PIC32MX6 families, it will be time to switch on the ARM Cortex-M4 platform, and connect the WM8580 or WM8581 board on it.
So, in summary :
1 - Buy a Microchip PIC32 MX1/ MX2 Starter kit (DM320013)
2 - Write a trivial PIC32 Audio DSP application in assembly using the onboard WM8731
3 - Develop a proper WM8580 or WM8581 Board, four I2S lanes and one SPI
4 - Buy a Microchip Microstick II (DM330013-2) small development kit, program it for outputting two I2S lanes, write a stereo 2-way crossover application, connect the WM8580 or WM8581 Board, and you are done !
5 - Switch to the Infineon XMC4000 as soon as it comes available
6 - Or stay with Microchip if they manage to upgrade their bigger PIC32 chips, providing up to four I2S lanes
7 - Re-use the WM8580 or WM8581 Board and you get a stereo 3-way or 4-way crossover
8 - Add bells and whistles like a DIR9001 ASRC and a high quality analog output volume controller
Budget : approx. 100 dollars.
Last edited:
I would tend to favor the WM8850 for Wolfson, though Cirrus's CS425xx parts are probably a stronger choice. In addition to a few dB better performance figures given a choice between sample rate conversion (WM8850) or PLL clock recovery (CS425xx) I tend to favor PLLs. The time blurring from SRC interpolation filters is in band while the PFD spurs from a PLL are usually well out of band and hence not too hard to attenuate in the PLL loop filter. That's not to say the PLL in the CS425xx is anything exceptional---performance-wise it's nothing special---but it is certainly cost effective and simple.
The MiniDSP 2x4 is based on an ADAU1701 and the 2x8 is probably using a CS42428. To my knowledge MiniDSP hasn't confirmed the latter but if it's not that part it's probably something functionally equivalent. So if one wants easy DSP XO one can probably just by a MiniDSP kit and be happy. DIYing an equivalent offers more control, much more time consumed (some of us would call it entertainment), and the ability to trade off lower cost versus higher performance. But let us be realistic; the cost savings or subjective improvements DIY offers are modest compared to an off the shelf solution. So the reason to DIY an XO is mostly because one wants to, not because one needs to.
I certainly agree a CS425xx---CS42516 or CS42526 in my case---is an easier and lower cost solution than routing MCLK around. However, I happen to want to fool around with DAC antialias filtering in ways which CS425xx parts do not exactly support. Do I want to do that tinkering enough to incur the additional complexity? Not sure yet.
An LPC4300 talking with a CS42516 would be a pretty nice little system.Even pretty good drivers distort more than the AD605's -65dB. I generally try for more like a total of -80dB max through all the electronics so that playback fidelity's limited only on the drivers. But that's more because it's easy to do than because it's required. A typical -50 or -55dB driver is likely to thoroughly mask the AD605's spectra.
Last edited:
Indeed the CS42516 or CS42526 are 64-pin Codecs, currently Mouser has them in stock for 5.19 eur, and they feature differential audio ports. They need external audio opamps.
The Wolfson WM8580 or WM8581 are 48-pin Codecs, currently the Mouser stock is zero, price is 5.91 eur, and they only feature single-ended audio ports. They don't need external audio opamps if the power amplifier is nearby.
Attach a 12.288 quartz (or oscillator), and the job is done. The Codecs will use the 12.288 quartz clock when the input is the ADC, and the Codecs will lock on and regenerate the SPDIF clock when the input is SPDIF.
What would be the cost for a credit-card sized board hosting the CS42526 and all audio opamps, featuring four "user" connectors :
- analog audio inputs and outputs (single-ended)
- SPDIF inputs (with power for provision for Optical receivers)
- µC interface (5V power supply, I2S lanes, SPI or I2C control bus)
- ASRC daughterboard connector
The Wolfson WM8580 or WM8581 are 48-pin Codecs, currently the Mouser stock is zero, price is 5.91 eur, and they only feature single-ended audio ports. They don't need external audio opamps if the power amplifier is nearby.
Attach a 12.288 quartz (or oscillator), and the job is done. The Codecs will use the 12.288 quartz clock when the input is the ADC, and the Codecs will lock on and regenerate the SPDIF clock when the input is SPDIF.
What would be the cost for a credit-card sized board hosting the CS42526 and all audio opamps, featuring four "user" connectors :
- analog audio inputs and outputs (single-ended)
- SPDIF inputs (with power for provision for Optical receivers)
- µC interface (5V power supply, I2S lanes, SPI or I2C control bus)
- ASRC daughterboard connector
WM858X are LQFPs. not that diy-frienly. Diyers tend to like soic/ssop things with less pins per device... Is there any codecs with ssop/soic package? These uC are at least LQFPs too, not to mention BGAs et cetera.
Here is my estimate costs per single DAC board, 2 channels:
PCM1794 - $46
PCM1798 - $29
WM8740 - $26
PCM1798 cheapified - $22
WM8804/5 - $9.5
Cheapified PCM1798 looks competitive, with NE5532 opamps per datasheet scheme. And it is full-blown DS DAC, with external I/V stage with all it's benefits.
But with additional several $$ you get propertly designed PCM1798 with THS differential opamp and NE5534 summing circuit.
Here is my estimate costs per single DAC board, 2 channels:
PCM1794 - $46
PCM1798 - $29
WM8740 - $26
PCM1798 cheapified - $22
WM8804/5 - $9.5
Cheapified PCM1798 looks competitive, with NE5532 opamps per datasheet scheme. And it is full-blown DS DAC, with external I/V stage with all it's benefits.
But with additional several $$ you get propertly designed PCM1798 with THS differential opamp and NE5534 summing circuit.
That's my idea of DSP platform in single picture
Call it MRD /market requirements document/.
Next stage would be SRS /system requirements specification/ and then HDS /hardware design specification/.
After the HDS - right into boards layout.
Clocking and PSU schemes should be drawn, as i want to try both slave and master for the modules.
Also, as i look at it... There is not enough space for everything, if i go with my standart "5x5cm" board sizes for modules + 10x10cm for mobo.
In addition, some modules should have ability for daisy-chaining - waste of board space and major ground cutouts. They should carry i2s lines too...
Some of them should be able to inject into i2s bus (ASRC for example)...
Moreover, 5x5cm board is fine for my tas3108, but could be too small for other DSPs.
PSU board is just 5x5cm, therefore no largish caps is possible = external PSU with rectifiers and large caps should be used. PSU board will contain just the regs + surrounding circuit. Maybe sticking to fixed regs will save some space, and won't affect much the performance, as every board should take care of it's own supply filtering.
Some MCU would help too, for the configuration over i2c, although i don't want to add another degree of complexity.
Looks overkill... 9 daughter boards to start from
Call it MRD /market requirements document/.
Next stage would be SRS /system requirements specification/ and then HDS /hardware design specification/.
After the HDS - right into boards layout.
Clocking and PSU schemes should be drawn, as i want to try both slave and master for the modules.
Also, as i look at it... There is not enough space for everything, if i go with my standart "5x5cm" board sizes for modules + 10x10cm for mobo.
In addition, some modules should have ability for daisy-chaining - waste of board space and major ground cutouts. They should carry i2s lines too...
Some of them should be able to inject into i2s bus (ASRC for example)...
Moreover, 5x5cm board is fine for my tas3108, but could be too small for other DSPs.
PSU board is just 5x5cm, therefore no largish caps is possible = external PSU with rectifiers and large caps should be used. PSU board will contain just the regs + surrounding circuit. Maybe sticking to fixed regs will save some space, and won't affect much the performance, as every board should take care of it's own supply filtering.
Some MCU would help too, for the configuration over i2c, although i don't want to add another degree of complexity.
Looks overkill... 9 daughter boards to start from
Attachments
Hi s3tup!
Could you throw a bit of text to explain your graph?
Looks good but i can't interpret the various columns.
Best
Nick
Could you throw a bit of text to explain your graph?
Looks good but i can't interpret the various columns.
Best
Nick
That's my idea of DSP platform in single picture
Call it MRD /market requirements document/.
Next stage would be SRS /system requirements specification/ and then HDS /hardware design specification/.
After the HDS - right into boards layout.
Clocking and PSU schemes should be drawn, as i want to try both slave and master for the modules.
Also, as i look at it... There is not enough space for everything, if i go with my standart "5x5cm" board sizes for modules + 10x10cm for mobo.
In addition, some modules should have ability for daisy-chaining - waste of board space and major ground cutouts. They should carry i2s lines too...
Some of them should be able to inject into i2s bus (ASRC for example)...
Moreover, 5x5cm board is fine for my tas3108, but could be too small for other DSPs.
PSU board is just 5x5cm, therefore no largish caps is possible = external PSU with rectifiers and large caps should be used. PSU board will contain just the regs + surrounding circuit. Maybe sticking to fixed regs will save some space, and won't affect much the performance, as every board should take care of it's own supply filtering.
Some MCU would help too, for the configuration over i2c, although i don't want to add another degree of complexity.
Looks overkill... 9 daughter boards to start from
Each block color represent's it's pin compatability group.
"DSP motherboard" and "Stand-alone DACs" represent physical layouts of blocks in the devices.
"Stand-alone DACs" have 2 columns - with and without ASRC module.
"Input module options" lists possible input modules, which will be interexchangeable (pin compatable).
The last column - is optional 8-ch RS485 receiver board for replacing the DSP board with PC-sourced i2s bus taken from Envy24 cards. This board should be pin-compatable with DSP board, because it should give 4 i2s lines on it's output.
"DSP motherboard" and "Stand-alone DACs" represent physical layouts of blocks in the devices.
"Stand-alone DACs" have 2 columns - with and without ASRC module.
"Input module options" lists possible input modules, which will be interexchangeable (pin compatable).
The last column - is optional 8-ch RS485 receiver board for replacing the DSP board with PC-sourced i2s bus taken from Envy24 cards. This board should be pin-compatable with DSP board, because it should give 4 i2s lines on it's output.
Freescale Kinetis K10
Potentially the lowest cost M4's to date, but only 50MHz :
http://cache.freescale.com/files/32bit/doc/ref_manual/K10P48M50SF0RM.pdf?fpsp=1&WT_TYPE=Reference%20Manuals&WT_VENDOR=FREESCALE&WT_FILE_FORMAT=pdf&WT_ASSET=Documentation
Potentially the lowest cost M4's to date, but only 50MHz :
http://cache.freescale.com/files/32bit/doc/ref_manual/K10P48M50SF0RM.pdf?fpsp=1&WT_TYPE=Reference%20Manuals&WT_VENDOR=FREESCALE&WT_FILE_FORMAT=pdf&WT_ASSET=Documentation
Unfortunately those 48-pin Freescale K10 chips only provide one I2S. You thus need at least two K10 chips for a 2-way crossover. On top of this, as developer, you need the JTAG/SWD Segger J-Link Debug Probe at 300 dollars or the JTAG/SWD Red Probe+ at 150 dollars talking to a solid Integrated Development Environment having a correct Freescale K10 installed base and support.
On the other hand the Microchip 28-pin PIC32MX1 or PIC32MX2 provides two I2S enabling a one-chip 2-way crossover. As developer, you need the Microchip ICD3 Debug Probe at 200 dollars and the Microchip MPLABX Integrated Development Environment.
Today, what's still missing in the ARM Cortex-M4 armada, is a two or three dollar chip featuring four I2S ports. Would be nice, isn't ? Today, a chip like the STM32 F4 costing 10 dollars in small quantities, only provides two I2S. It remains to be proven that the JTAG/SWD Red Probe+ can hook on it.
But wait a minute, there will be the T.I. AM3358 (an ARM Cortex-A8) costing 10 dollars in small quantities, equipped with eight I2S pins, enabling a one-chip 4-way crossover. Total cost is actually more, as you need external Flash and RAM. A credit-card sized 4-way xover is possible using four chips : the AM3358 µC, the Flash, the RAM, and a 7.1 Audio Codec like a WM8581 or CS42526.
Nearly available today is the 89 dollars "BeagleBone", a credit-card sized board hosting the AM3358 µC, the Flash and the RAM.
The Open Source DSP XO could thus materialize into a "Digital Audio Cape" for BeagleBoard, hosting a WM8581 or CS42526 Audio Codec, plus maybe a DIR9001 chip (ASRC), target price 50 dollars or so.
Another good news is the existence of Tin Can Tools Flyswatter USB to JTAG in-circuit debugger and programmer designed for ARM Cortex-A8 cores, at 50 dollars. The corresponding Integrated Development Environment is OpenOCD.
Within OpenOCD, as this is an open system, one can introduce high level Digital Audio features easing the do-it-yourself approach.
On the other hand the Microchip 28-pin PIC32MX1 or PIC32MX2 provides two I2S enabling a one-chip 2-way crossover. As developer, you need the Microchip ICD3 Debug Probe at 200 dollars and the Microchip MPLABX Integrated Development Environment.
Today, what's still missing in the ARM Cortex-M4 armada, is a two or three dollar chip featuring four I2S ports. Would be nice, isn't ? Today, a chip like the STM32 F4 costing 10 dollars in small quantities, only provides two I2S. It remains to be proven that the JTAG/SWD Red Probe+ can hook on it.
But wait a minute, there will be the T.I. AM3358 (an ARM Cortex-A8) costing 10 dollars in small quantities, equipped with eight I2S pins, enabling a one-chip 4-way crossover. Total cost is actually more, as you need external Flash and RAM. A credit-card sized 4-way xover is possible using four chips : the AM3358 µC, the Flash, the RAM, and a 7.1 Audio Codec like a WM8581 or CS42526.
Nearly available today is the 89 dollars "BeagleBone", a credit-card sized board hosting the AM3358 µC, the Flash and the RAM.
The Open Source DSP XO could thus materialize into a "Digital Audio Cape" for BeagleBoard, hosting a WM8581 or CS42526 Audio Codec, plus maybe a DIR9001 chip (ASRC), target price 50 dollars or so.
Another good news is the existence of Tin Can Tools Flyswatter USB to JTAG in-circuit debugger and programmer designed for ARM Cortex-A8 cores, at 50 dollars. The corresponding Integrated Development Environment is OpenOCD.
Within OpenOCD, as this is an open system, one can introduce high level Digital Audio features easing the do-it-yourself approach.
Yes, that's true - though as the 10k+ price shown by Freescale is under $2, its hardly going to break the bank is it? At 50MHz they'll do 62.5MIPs tops, so a single one is probably a bit underpowered anyway.
No need to spend so much - check out the link I've given above to an eBay option.
The downside of that is that its an investment in Microchip - whereas buying an ARM debugger/IDE gives the choice of multiple silicon vendors. Microchip being a single company can't compete with the choice of clock speeds, peripheral variety, RAM/ROM options, pin-outs and packages that comes from having an ecosystem at one's disposal.
We can but dream eh? But I think paralleling chips is a fine solution at the current cost (and power requirements) of these parts. Its also a much more expandable route to dedicate a CPU to each driver (or perhaps each stereo pair). Then if you want to add in a sub at a later date, just get another CPU+DAC combination.
Nice modularity and expandability, indeed. So if you put a room equalizer as front-end, a N-way stereo crossover would require N+1 Freescale K10 chips. As developer, how would you program and debug this ? SWD multidrop instead of JTAG ? Is it available now ?
I'm not sure that DSP for loudspeaker is such a complicated thing that you need debugging access across the whole system.
You can debug 1 chip, then you expect the other ones to be nearly identical.
If you want to make it the hard way, you can unit test each routine, then system test the whole thing with real life inputs.
But yeah - the effort/cost is probably not worth given that you have single chips around that will do the same job as 10 cascaded 50MHz chips...
You can debug 1 chip, then you expect the other ones to be nearly identical.
If you want to make it the hard way, you can unit test each routine, then system test the whole thing with real life inputs.
But yeah - the effort/cost is probably not worth given that you have single chips around that will do the same job as 10 cascaded 50MHz chips...
As far as I'm aware, yes. When I fire up my J-Link it tells me its using SWD (if my memory serves). But I haven't tried this with multiple CPUs on the same wire. So that's an experiment for the future.
I wouldn't debug this with all chips running myself though, I'd do this in two stages. Debug the code in just one CPU and get that working first. Then hopefully the only differences between different CPUs would be coefficients, not code.
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.