Open Source DSP XOs - Page 33 - diyAudio
Go Back   Home > Forums > Source & Line > Digital Line Level

Digital Line Level DACs, Digital Crossovers, Equalizers, etc.

Please consider donating to help us continue to serve you.

Ads on/off / Custom Title / More PMs / More album space / Advanced printing & mass image saving
Reply
 
Thread Tools Search this Thread
Old 1st July 2012, 03:16 AM   #321
diyAudio Member
 
abraxalito's Avatar
 
Join Date: Sep 2007
Location: Hangzhou - Marco Polo's 'most beautiful city'. 700yrs is a long time though...
Blog Entries: 109
Send a message via MSN to abraxalito Send a message via Yahoo to abraxalito Send a message via Skype™ to abraxalito
Default The Goodies

Consultants don't produce stuff, they just write reports.
Attached Images
File Type: jpg goodies.jpg (24.0 KB, 314 views)
__________________
There is surely nothing quite so useless as doing with great efficiency what should not be done at all - Peter Drucker
  Reply With Quote
Old 1st July 2012, 03:31 AM   #322
diyAudio Member
 
Join Date: Jun 2009
Quote:
Originally Posted by abraxalito View Post
Consultants don't produce stuff, they just write reports.
there are lots of reports on this thread. not much going on in the nuts and bolts department
  Reply With Quote
Old 1st July 2012, 11:50 AM   #323
diyAudio Member
 
abraxalito's Avatar
 
Join Date: Sep 2007
Location: Hangzhou - Marco Polo's 'most beautiful city'. 700yrs is a long time though...
Blog Entries: 109
Send a message via MSN to abraxalito Send a message via Yahoo to abraxalito Send a message via Skype™ to abraxalito
Oh I'm reporting on some of the nuts and bolts on my blog - in particular my LAID architecture which merges an FIR filter with the DAC. I hope to produce some PCB artwork for that in the next couple of months.
__________________
There is surely nothing quite so useless as doing with great efficiency what should not be done at all - Peter Drucker
  Reply With Quote
Old 4th July 2012, 06:33 PM   #324
diyAudio Member
 
Join Date: Jun 2009
Quote:
Originally Posted by steph_tsf View Post
Unfortunately, the 5.1 channel I2S proposition is unpractical. Confront it to any modern multichannel Codec. Draw the WM8581 block diagram next to it, and try connecting it. LPC43xx as I2S slave and WM8581 as I2S master. Good luck!
I haven't found any problems integrating an LPC4300 with the CS42xxx family yet. I'm not particularly familiar with Wolfson's codecs but figure 25 in 8581 datasheet shows CS42xxx equivalent IO so I'm not seeing any problems integrating a 4300 with an 8581 either. One does have to pay attention to pin assignments and bus directions when assigning external IO to I2S peripherals and SGPIO slices but it's not hard. Tedious maybe, but keeping track of that kind of stuff is what spreadsheets and schematics are for.

I haven't placed my LPC4300+CS42526 board yet but from the floorplanning it looks like all IO lines between the two parts (including I2C, interrupt flags, and reset) can be done without any vias on a two layer board. I will say I find the pin assignments for the I2S peripherals on the LQFP144 package I'm currently targeting perhaps a little quirky. But it's no big deal.
  Reply With Quote
Old 5th July 2012, 02:03 AM   #325
diyAudio Member
 
steph_tsf's Avatar
 
Join Date: Mar 2008
Quote:
Originally Posted by twest820 View Post
I haven't placed my LPC4300+CS42526 board yet but from the floorplanning it looks like all IO lines between the two parts (including I2C, interrupt flags, and reset) can be done without any vias on a two layer board. I will say I find the pin assignments for the I2S peripherals on the LQFP144 package I'm currently targeting perhaps a little quirky. But it's no big deal.
Thanks for communicating about this. It looks positive and reassuring. Since the beginning of I2S we see different ways to practically implement it.

The first I2S applications were in CD players equipped with an I2S DAC, the CD decoding chip acting as master, and providing the MCLK.

Later on we've got the record/play digital audio like the DAT, Mini Disc and Digital Compact Cassette, featuring an ADC and a DAC connected using I2S, acting as I2S slaves and receiving the MCLK from the controller chip, just as usual.

A third generation came when S/PDIF needed to be used as audio input. This time the controller chip (or DSP chip) could not always act as clock generator as when the audio input was S/PDIF, the S/PDIF recovered clock needs to serve as master clock. On the other hand, when the audio input is analog, a local crystal oscillator is used as clock generator. Such evolution reinforced the idea that a proper I2S implementation needs to keep the DSP away from the MCLK generation. Therefore, the industry produced more and more advanced Audio Codecs featuring a S/PDIF input, acting as highly integrated modules, isolating the DSP from the MCLK generation in any circumstance.

Modern Audio Codecs featuring an S/PDIF input like Wolfson WM8580 (year 2009 maybe) and Cirrus CS42526 (year 2005 maybe) exactly do this, with excellence.

The WM8580 features a quartz oscillator (XTI, XTO) followed by a programmable PLL able to generate all basic MCLK frequencies, both the 44.1 series and the 48.0 series, using a single 27.0 MHz quartz.

The CS42526 is slightly inferior, or perhaps more audiophile oriented, having no internal PLL associated to the basic MCLK, which means that you need two quartz oscillators (and select the right one) if you want to cover both the 44.1 series and the 48.0 series. I say "more audiophile oriented" because Cirrus may have felt that by relying on a PLL even for the basic MCLK generation, they would get critics from Audio enthusiasts.

Both the WM8580 and CS42526 feature a S/PDIF clock recovery circuit basing on a dedicated, separated PLL, acting as alternate MCLK generator. The general feeling is that the Wolfson S/PDIF clock recovery scheme is better than the Cirrus one. Don't know how those two particular chips compare, actually.

You may then ask why the WM8580 features a MCLK pin configurable as input or output. I would say that WM8580 pin 24 should remain unconnected in a plain normal application. I consider WM8580 pin 24 to be helpful as output, when debugging, for analyzing MCLK as generated by the internal PLL. I also consider WM8580 pin 24 to to be helpful as input, again when debugging, for comparing the resulting audio signal/noise figure, between using the internal PLL for generating MCLK, and using an external clock. I would never use WM8580 pin 24 in the definitive application, never route it on the board, and never make it touching the DSP chip.

Now practically, what to do with the CS42526? It needs some external frequency management if wanting to cover the 44.1 and 48.0 series. We have RMCK (pin 55 as input), receiving the 11.2896 MHz (44.1 series) or the 12.288 MHz (48.0 series). From an audiophile perspective, you need to rely on two different oscillators, that the LPC4330 commutes using a GPIO line. This way people are not going to raise questions about the MCLK clock quality, especially when you show them that each oscillator is made of unobtainium, maintained at a precise xx temperature, same for the VCC supplies. Kind of joke. From a practical perspective, a possibility is to have MCLK coming from a LPC4330 PLL. Doing so you will cause some audio quality dilution as the CS42526 will be responsible for 80% of the audio quality, and the LPC4330 the remaining 20%. That's a simple way to see it. You better ensure that the MCLK copper track going from the LPC4330 to the CS42526 doesn't radiate, and doesn't capacitively couple to other tracks.

I just went looking to two potential LPC4330 contenders.

I got impressed by the STM32F37x announced as featuring three I2S, even in the 48-pin package. Warned by abraxalito, I checked the I2S implementation and discovered that STM multiplexed the four pins of a plain normal SPI (SDO, SDI, CLK, CS) with the (SD, CK, WS and MCK) of a so-called I2S. Which means that each I2S is unidirectional, and capable of delivering the MCLK. Such "thing" should not be called I2S. On top of this, on the STM32F37x 48-pin package, if you need USB, it clashes with I2S1 and I2S2. For avoiding this, you need the STM32F37x 64-pin package. This means that you need a 64-pin STM32F37x for doing a stereo 2-way crossover (one I2S as input, two I2S as output), something you should be able to do using a 28-pin Microchip PIC32MX2 featuring two bidirectional I2S (or supposed to be so).

Another LPC4330 contender is the Infineon XMC4000 - XMC4500. They announce it as having six flexible serial interfaces, each capable of I2S. Don't know if the I2S are bidirectional. Worst case scenario would be they are unidirectional, in which case you would consume four I2S for a stereo 3-way crossover (one as input, three as outputs), plus one as I2C (for the Codec control), and you still have a spare serial interface, perhaps a SPI for controlling some external, high quality volume control chips. Looks straightforward.

After all those years chasing for a Cortex-M4 featuring a decent amount of I2S, I mean plain normal bidirectional I2S, I have the impression that ARM doesn't want to market this. One reason may be ARM and Freescale slooowly teaming up for organizing the final and definitive DSP56K obsolescence (one of the first integrated DSP architecture) and the definitive ColdFire obsolescence (the very old 68K architecture after some instruction set simplification). New 65 nanometer Cortex-M4 chips, single core and dual core, clocked at 320 MHz, badged Freescale, could materialize a new generation replacing the entire DSP56K + ColdFire range. A 65 nanometer Cortex-M4 running at 400 MHz would nearly provide the MAC/s performance of a DSP56K clocked at 250 MHz. It can't provide 400 Mega MAC/s because if lacks the zero loop overhead (critical in FIRs), the bit reversal addressing mode (critical in FFT), and the fast short interrupt (possibly replaced by powerful DMA schemes). Later on, and still on a 65 nm design rule, speed-optimized Cortex-M4 cores could run at 800 MHz, delivering more MAC/s than any existing DSP56K or ColdFire. The only big issue with such concept, even clocked at 800 MHz, is the lack of bit reversal addressing in the Cortex-M4, critical for computing FFTs. How many years shall we wait ?

Since 2007, since the Microchip PIC32 basing on the MIPS M4K architecture, we get significant PIC32 silicon upgrades every two years. In 2009 the PIC32 gained buffered SPI. In 2011 the PIC32 gained SPI with "Audio Mode" aka I2S.

Keeping such pace, as soon as 2013 we could get PIC32 chips with the 65nm design rule (320 MHz?), some MIPS DSP extensions, and the TDM interfaces (multichannel audio).

A few month ago, Microchip signed the MIPS 14K licence. Microchip may also have signed the MIPS microAptiv licence. MIPS microAptiv core (unveiled May 10th 2012) is based on the prior-generation M14K/c cores, with the addition of microMIPS code compression support and the DSP ASE function block. It comes in both cache-less (microcontroller) and cache-inclusive (microprocessor) variants.
More info here: MIPS' Aptiv: DSP Capabilities Become Pervasive | www.bdti.com
Do we get the the bit reversed addressing on MIPS DSP ASE, for optimizing the FFT computation? Anyway, with MIPS teaming up with Microchip, there should be less slooow politics than in the ARM-Freescale play field, meaning that if Microchip wants to design a chip aiming at terminating both the DSP56K and the ColdFire, they can do it overnight - should I say if the MIPS DSP ASE feature the bit reverse addressing, and if they add TDM interfaces on top of SPI/I2S.

A Microchip microAptiv chip featuring on-chip Flash memory, only featuring 28 pins and a pin multiplex scheme like on the PIC32MX1/2, equipped with TDM for talking with a WM8580 or WM8581, can also feature USB 2.0 host/device/otg, a few extra SPI, and I2C. Take the 44-pin Microchip microAptiv chip and you also get Ethernet. Add an external, optional MHL/HDMI receiver and your application could grab audio from any source. There can be one hundred millions chips like this sold each year in audio docking stations, USB speakers, TV sound bars, and active speakers.

Now, grab the MIPS proAptiv range (MMU, external SDRAM, third-party graphics coprocessor), and you get a chip directly competing with the ARM Cortex-A9 MP and Cortex-A15 MP, able run Android phones, tablets and TV boxes. As Ingenic Semicoinductor already got support for compiling Android 4 on MIPS, one can infer that the MIPS Android compiler will get an upgrade for supporting the newest MIPS proAptiv chips. If on top of this, Google buys some MIPS assets, you'll see interesting things coming, like billions of chips like this, sold each year.

Quite strange is that Intel is nowhere into this. That's weird, especially now that Steven Sinofsky from Microsoft, announced WOA (Windows on ARM) on February 9th, 2012. Shall we really believe that Intel is busy, on an industrial scale, porting Android on x86?

Last edited by steph_tsf; 5th July 2012 at 02:33 AM.
  Reply With Quote
Old 5th July 2012, 07:42 AM   #326
diyAudio Member
 
Join Date: Jun 2009
Quote:
Originally Posted by steph_tsf View Post
Don't know how those two particular chips compare, actually.
Over here. Keep in mind baseband jitter is attenuated by about 50dB in SPDIF period jitter measurements so Wolfson's 50ps headline spec is essentially irrelevant.
  Reply With Quote
Old 11th August 2012, 11:10 AM   #327
diyAudio Member
 
Join Date: Nov 2011
Hi, people.
Now I am experimenting with LPC4330.
At this moment it sends 96kHz*24bit stream from USB to 4 I2S stereo pairs...
  Reply With Quote
Old 17th August 2012, 04:28 AM   #328
diyAudio Member
 
steph_tsf's Avatar
 
Join Date: Mar 2008
A few homebrew DSP tools including FIR-based XOs. Attached .zip.
Attached Files
File Type: zip tools part 1.zip (869.9 KB, 27 views)
File Type: zip tools part 2.zip (655.6 KB, 16 views)
File Type: zip tools part 3.zip (452.4 KB, 18 views)
  Reply With Quote
Old 17th August 2012, 04:35 AM   #329
diyAudio Member
 
steph_tsf's Avatar
 
Join Date: Mar 2008
Quote:
Originally Posted by a5856 View Post
Hi, people. Now I am experimenting with LPC4330.
At this moment it sends 96kHz*24bit stream from USB to 4 I2S stereo pairs...
This is exactly what we have waited for so long. Will you help us getting this running on NGX LPC4330 Xplorer? Using KEIL MDK ARM with ULINK2/ME or using LPC-Xpresso with NXP LPC-Link?

Last edited by steph_tsf; 17th August 2012 at 04:49 AM.
  Reply With Quote
Old 17th August 2012, 06:35 AM   #330
diyAudio Member
 
Join Date: Jun 2009
Quote:
Originally Posted by a5856 View Post
At this moment it sends 96kHz*24bit stream from USB to 4 I2S stereo pairs...
Very cool. +1 on Steph's questions about the toolchain you're using.

Quote:
Originally Posted by steph_tsf View Post
A few homebrew DSP tools including FIR-based XOs.
In case one's wondering what's in the .zips, they contain eight apps. Most don't play nicely on my Win7 SP1 x64 box with UAC enabled.

- DFT iDFT - install fails on permission to c:\DFT_iDFT_A.txt denied
- FIR LAB - install fails on permission to c:\FIR_Lab.txt denied
- iDFT XO - install fails on permission to c:\iDFT_XO.txt denied
- iDFT XO CG - install fails on permission to c:\iDFT_XO_CG.txt denied
- iDFT XO CSRn - install fails on permission to c:\iDFT_XO_CSRn.txt denied
- iDFT XO CSTBSi - install fails on permission to c:\iDFT_XO_CSTBSi.txt denied
- IIR Lab 1.03 - analyzes IIR biquads at various numerical precisions
- IIR Lab Mini 1.03 - simplified version of the above

I know version 1.00 of IIR Lab can be found in other threads. Steph, I'll dig our previous discussion of the tool up and reply on the appropriate thread when I get the time.
  Reply With Quote

Reply


Hide this!Advertise here!
Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are Off
Pingbacks are Off
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Volume / Source selector - open source project ? AuroraB Analog Line Level 22 22nd September 2012 03:21 PM
Violet DSP Evolution - an Open Baffle Project cuibono Multi-Way 211 18th May 2010 03:26 AM
Open call for suggestions on Open Source DIY Audio Design gfergy Everything Else 1 15th April 2007 08:33 AM
Open Source, Open Architecture! zenmasterbrian Digital Source 185 23rd February 2007 11:35 PM


New To Site? Need Help?

All times are GMT. The time now is 07:01 AM.


vBulletin Optimisation provided by vB Optimise (Pro) - vBulletin Mods & Addons Copyright © 2014 DragonByte Technologies Ltd.
Copyright 1999-2014 diyAudio

Content Relevant URLs by vBSEO 3.3.2