This thread started as a study for Open Source DSP XO software (simulated using LTSpice), see the first posts. Some kind of platform or at least vendor independent hardware implementation was targetted, that's why ARM was mentioned. ARM doesn't have a standard peripheral for I2S in Cortex-M specs, so vendors have a little bit different implementation. Regarding XO's a multi-channel I2S or TDM would be needed, multiple stereo I2S interfaces / ports are not exactly the same, there can for an example be a small phase difference involved (if the individual ports are enable at different time).
So this thread is not about implementing the crossover on a specific platform.
Please read the MikroE Audio Codec Proto Manual, figure 2. This is the schematic of the MikroE board. Obviously, MikroE has renamed all WM8731 digital audio interface pins. This is indeed I2S, thus not SPI, provided the ADC and the DAC are operating at the same rate.
Let's see what's happening when we define the STM32 F411RE I2S as Full-Duplex Master. Doing so, the I2Sx_WS pin of the STM32 F411RE chip is an output. Consequently, if there is a lot of jitter on the I2Sx_WS pin of the STM32 F411RE chip, the audio quality may degrade. For maximizing the audio quality, you will hook a high quality 12.288 MHz oscillator feeding the STM32 F411RE I2S_CKIN (input). The STM32 I2Sx_WS (output) pin needs to be connected, both to the ADCLRC (input) pin and DACLRC (input) pin of the WM8731. The STM32 F411RE I2Sx_CK (output) pin needs to be connected to the WM8731 BCLK (input) pin. Now comes the question of the WM8731 MCLK. You could hook a quartz on the WM8731 XTO and XTI pins. A more effective way is to have the high quality 12.288 MHz oscillator, also feeding the WM8731 MCLK (input) pin. This way you can safely connect more than one MikroE Audio Codec Proto board on a STM32 F411RE chip, using a single high quality 12.288 MHz oscillator.
What if the STM32 F411RE chip is grabbing 48 kHz digital audio from a WM8804 used as S/PDIF to I2S converter ? In such case the WM8804 needs to act as digital audio reference clock, following the incoming sample rate. Can a WM8804 deliver a high quality MCLK, to be used as MCLK for the STM32 F411RE chip (I2S_CKIN input pin) and to be used as MCLK for all WM8731 chips (MCLK input pins) ? Yes, and this is the WM8804 MCLK pin 16, outputting the PLL-recovered audio master clock at 256 x Fs. This is 12.288 MHz for Fs = 48 kHz. This is 11.289 MHz for Fs = 44.1 kHz. The STM32 F411RE chip and all WM8731 chips will inherently follow the incoming sample rate.
I guess such scheme is the most simple, effective, and affordable open-source DSP XO. Especially when using off-the-shelf boards like the ST Nucleo 411RE, MikroE Audio Codec Proto, and eBay sure-hifi WM8804 S/PDIF TOSLINK to IIS Converter. Especially when using STMCube32MX as the STM 32F411RE chip configurator.
At the end of the day, after succeeding in connecting a ST Nucleo 411RE on :
- one eBay sure-hifi WM8804 S/PDIF TOSLINK to IIS Converter
- two or three three MikroE Audio Codec Proto boards,
you'll realize that hooking a WM8580 chip on a STM32 F411RE chip can do the exact same.
You can see the WM8580 chip as embedding one WM8804 chip and three WM8731 chips. The problem is, most people don't understand the WM8580 clocking schemes. Now that we explained the required clocking scheme using one WM8804 chip and several WM8731 chips, we are able to organize the clocks of the WM8580.
If we accept the idea that an open-source DSP XO consists of fiddling with jumpwires, connecting ready-made boards, guess what will happen if there is a Nucleo "SPDIF xo" available through eBay, embedding a WM8580 ...
Your Nucleo "SPDIF xo" sales will vastly increase, as soon as there is a Nucleo "SPDIF pre" taking one SPDIF stream (seamlessly 44.1 kHz or 48 kHz), reading the balance and volume (two pots on the 12-bit ADC), and delivering two SPDIF signals each embedding the volume info, one for the left speaker, and the other for the right speaker.
Convey each SPDIF signal over a 110 ohm balanced digital cable, XLR-like.
In 2 years, 20% of newly developed DIY-speakers will be 110 ohm digital, embedding your digital "SPDIF xo", obeying the volume control info elaborated by your "SPDIF pre".
Later on, you shall design an all in one "SPDIF xo" board embedding the STM32 F411RE chip and the WM8580 chip, featuring a USB host/device connector, enabling end-users to load various application softwares.
Having all the bits and pieces readily available, it's time to go "Through the Looking-Glass", don't you think ?
Steve Job did it, when he merged a PDA, a MP3 player, a web browser and a mobile in one device, called the iPhone.
- one eBay sure-hifi WM8804 S/PDIF TOSLINK to IIS Converter
- two or three three MikroE Audio Codec Proto boards,
you'll realize that hooking a WM8580 chip on a STM32 F411RE chip can do the exact same.
You can see the WM8580 chip as embedding one WM8804 chip and three WM8731 chips. The problem is, most people don't understand the WM8580 clocking schemes. Now that we explained the required clocking scheme using one WM8804 chip and several WM8731 chips, we are able to organize the clocks of the WM8580.
If we accept the idea that an open-source DSP XO consists of fiddling with jumpwires, connecting ready-made boards, guess what will happen if there is a Nucleo "SPDIF xo" available through eBay, embedding a WM8580 ...
Your Nucleo "SPDIF xo" sales will vastly increase, as soon as there is a Nucleo "SPDIF pre" taking one SPDIF stream (seamlessly 44.1 kHz or 48 kHz), reading the balance and volume (two pots on the 12-bit ADC), and delivering two SPDIF signals each embedding the volume info, one for the left speaker, and the other for the right speaker.
Convey each SPDIF signal over a 110 ohm balanced digital cable, XLR-like.
In 2 years, 20% of newly developed DIY-speakers will be 110 ohm digital, embedding your digital "SPDIF xo", obeying the volume control info elaborated by your "SPDIF pre".
Later on, you shall design an all in one "SPDIF xo" board embedding the STM32 F411RE chip and the WM8580 chip, featuring a USB host/device connector, enabling end-users to load various application softwares.
Having all the bits and pieces readily available, it's time to go "Through the Looking-Glass", don't you think ?
Steve Job did it, when he merged a PDA, a MP3 player, a web browser and a mobile in one device, called the iPhone.
In 2 or 3 years, most "digital" speakers (both DIY and commercial) will be using IP (either over ethernet or wirelessly).
You know this can't be true. Different systems will remain in coexistence.
In 2 years, newly developed DIY and commercial speakers will remain 50% legacy passive, 20% analog active, 20% XLR-like SPDIF, 10% IP using Ethernet or Wireless.
In 5 years, newly developed DIY and commercial speakers will be 15% legacy passive, 25% analog active, 30% XLR-like SPDIF, 30% IP using Ethernet or Wireless.
Do not underestimate the importance of :
- audiophiles only tolerating "bit exact" approaches exempt from sample rate conversions
- musicians and singers not tolerating latencies
Therefore, in 10 years, newly developed DIY and commercial speakers will be 10% legacy passive, 10% analog active, 50% XLR-like SPDIF, 30% IP using Ethernet or Wireless.
Why 50% XLR-like SPDIF ? Because those ones will come equipped with Wireless management modules. This way you can update their parameters and software, as connected objects, possibly worldwide. They may embed measurement mikes. They may enter "sound check" modes. This is the future.
I stand by my statement, but let me clarify that by stating that I am talking about new designs/products - of course the installed base will remain in use.
What do you base those numbers on? "XLR-like SPDIF" is pretty much 0% now, and I don't see any future for it, while everybody is developing IP-based technologies.
Again, what do you base your numbers on?
My guess would be 30% legacy passive, 20% analog active, and 50% IP, with SPDIF being 0%.
IP is (or can be) just as bit exact as any other digital format.
Have you looked at what studios are installing these days? Hint: AES67, RAVENNA.
I agree with those features being the future, but there is no need for SPDIF to accomplish that. The connection to the speaker will be IP, and it will allow you control (and update) of all parameters (and integration) over web/apps.
Hi steph_tsf,
I only see SPI and I2C like the project page says.. no I2S. The top 5 pin functions I recognize as SPI and the bottom 2 are I2C.
Attachments
Clearly, you don't care the WM8731 datasheet. You should pay some time, reading it thoroughly. It is available here, now that Cirrus Logic finalized the acquisition of Wolfson in August 2014.
MikroE renamed the WM8731 I2S audio interface pins following the SPI standard.
Pretty bad move, IMO. This caused a generation of people confusing the I2S interface with SPI, not to mention those confusing the I2S interface with I2C. This caused a generation of people saying the MikroE Audio Codec Proto board doesn't work.
One need to remember that MikroE released the Audio Codec Proto board in August 2010, quite a long time ago, when the only affordable microcontroller featuring a I2S interface was the NXP LPC1768 (ARM Cortex-M3). Unfortunately, back in August 2010, MikroE had no development board featuring a NXP LPC1768 microcontroller. Unfortunately, back in August 2010, the only affordable development board featuring a LPC1768 microcontroller was the very first mbed board, the LPC1768 mbed board, released in September 2009, without any software support (no drivers) for the LPC1768 I2S interface.
Unfortunately back in August 2010, MikroE was still heavily promoting the Microchip PIC32 microcontroller.
It took nearly two years for MikroE (April 2012) to publish their WM8731 exemple software for their Audio Codec Proto board. You can find such WM8731 exemple software here.
And now, guess what...
Still today, March 2014, it is still written for old-generation PIC32 chips, only featuring SPI instead of the required I2S interface.
Today, March 2014, Microchip has the PIC32MX2 and the PIC32MZ, all equipped with a I2S interface.
Nowadays very few people (including MikroE people) are willing to develop hardware and software for those MIPS-based microcontrollers (non ARM-based, thus).
This explains why mikroE is not rushing in publishing WM8731 drivers for the Microchip PIC32MX2 and the Microchip PIC32MZ.
Interestingly, MikroE has the MINI-M4 for STM32 board (STM32 F415RG chip), available here.
It is hard for me to find why MikroE is not rushing in publishing WM8731 drivers for the STM32 F415RG chip.
A possible reason is that the WM8731 has distinct ADCLRCK and DACLRCK, enabling the ADC to operate at a different sample rate from the DAC sample rate. One can thus say that the WM8731 features a non-standard I2S interface. Actually it is a I2S interface superset.
Most Audio Codecs (ADC and DAC on a same chip) have a single LRCK, forcing the ADC and the DAC to operate at the same sample rate.
MikroE possibly doesn't want to invest time and money on a chip like the WM8731, appearing as non-standard what's regarding the I2S interface.
For properly learning how to operate the WM8731 using a STM 32F405RG chip equipped with I2S, you need to dig into the f4_codec_v2_demo.zip code from Eric Brombaugh that's available here. This should be your Bible.
Once you'll feel comfortable with Eric Brombaugh STM 32F405RG and WM8731 software combination, you'll be able to amend it for running it on a ST Nucleo F411RE board for driving the WM8731 that's inside the MikroE Audio Codec Proto board.
At this stage, you may think that you could recycle your software as a WM8731 driver for mbed.
Unfortunately, some mbed boards are basing on STM Cortex-M4 chips, while some other mbed boards are basing on NXP Cortex-M4 chips.
Unfortunately, the I2S interfaces of those microcontrollers are not the same.
One cannot thus issue a "mbed WM8731 driver".
One could eventually issue a "mbed STM 32F4 I2S WM8731 driver".
Please note, as you can see when running the STM32CubeMX utility, not all STM 32F4 chips are equal.
The STM32 F401RE chip features two Full-Duplex I2S interfaces.
The STM32 F411RE chip features two Full-Duplex I2S interfaces plus two half-Duplex I2S interfaces.
You can setup each STM 32F4 I2S interface as Master or as Slave.
You can ask a Full-Duplex capable I2S interface to generate a MCLK when operating in Master.
Any "mbed STM 32F4 I2S WM8731 driver" needs to configure the I2S interfaces in a sensible way, that's useful from a practical point of view, that most people can understand.
Not an trivial task.
Starting from there, you could develop a ST Nucleo "cape" hosting a WM8580. Possibly, you could publish software a "mbed STM 32F4 I2S WM8731 driver".
Not a trivial task, considering the WM8580 block-diagram.
You'll need to make some drastic choices, about how to use the WM8580.
While dealing with mbed, expect to face people like you, completely lost what's regarding SPI, I2C, and I2S, vaguely understanding the difference between Master and Slave, not fully understanding the audio quality issues that may arise when improperly organizing the clocking scheme. This is why on mbed, you should only deal with audio coming from S/PDIF, always considering the PLL-recovered MCLK coming from S/PDIF-in, as the main, high quality audio clock for the rest of the system.
As soon as you target other applications like sampling analog audio (Analog Line-In), the clocking scheme needs to be different. Such problematic is going to fly above the average mbed man's head, not to say it will highly complicate the software driver, especially if you want your system to switch on-the-fly between S/PDIF-in, and Analog Line-In.
Clearly, 20 years ago Philips failed in marketing their DSC950 preamplifier, DSS940 speaker, and DSS930 speaker. This doesn't imply that SPDIF speakers have no future. Philips failed for a couple of obvious reasons.
The DSC preamp and DSS speakers were not providing galvanic isolation.
The DSC preamp and DSS speakers were crazy expensive.
The digital link was not a genuine SPDIF. The DSC-to-DSS link added some low frequency modulation superimposed on the SPDIF signal, for transmitting the volume control over a "phantom" UART.
The connector was a Cinch, unable to feature a mechanical locking mechanism
The DSC preamp and DSS speakers were crazy expensive.
The digital link was not a genuine SPDIF. The DSC-to-DSS link added some low frequency modulation superimposed on the SPDIF signal, for transmitting the volume control over a "phantom" UART.
The connector was a Cinch, unable to feature a mechanical locking mechanism
The revised SPDIF speakers embedding an open-source DSP XO that I'm proposing here don't exhibit such drawbacks.
They do provide galvanic isolation.
They are affordable and DIY-friendly, the first iterations basing on the affordable mbed ST Nucleo F411RE board and some affordable WM8580-based Nucleo "cape".
The digital link is now a genuine SPDIF. The trick is that one audio channel gets sacrificed for conveying the volume info. For making a stereo system, you thus need a "SPDIF pre" taking one SPDIF as input, and delivering two SPDIF as outputs (one is left audio + left volume, the other is right audio + right volume).
Bidirectional status and command remain possible using inexpensive Wireless boards (IrDAIRDA, Bluetooth, Bee, WiFi) from MikroE or Sparkfun.
The connector is a 110-Ohm XLR, featuring a mechanical locking mechanism.
They are affordable and DIY-friendly, the first iterations basing on the affordable mbed ST Nucleo F411RE board and some affordable WM8580-based Nucleo "cape".
The digital link is now a genuine SPDIF. The trick is that one audio channel gets sacrificed for conveying the volume info. For making a stereo system, you thus need a "SPDIF pre" taking one SPDIF as input, and delivering two SPDIF as outputs (one is left audio + left volume, the other is right audio + right volume).
Bidirectional status and command remain possible using inexpensive Wireless boards (IrDAIRDA, Bluetooth, Bee, WiFi) from MikroE or Sparkfun.
The connector is a 110-Ohm XLR, featuring a mechanical locking mechanism.
I'm pretty sure that we'll see many SPDIF speakers, made this way.
Last edited:
Actually, today March 2014, all PIC32MX1, all PIC32MX2, some PIC32MX4, some PIC32MX5, and all PIC32MZ come equipped with new SPI that are I2S-capable thanks to some "audio mode" control bit in some setup register.
MikroE has the nice little MINI-32 board embedding a PIC32MX5 here.
Unfortunately, it embeds a PIC32MX534F064H, one of the few PIC32MX5 not equipped with the new I2S-capable SPI.
I have some lying around. I never wasted time studying the MikroE Audio Codec Proto board demo software for figuring out how to configure the PIC32MX5 buffered SPI for hooking up to three MikroE Audio Codec Proto boards, for managing 6 audio channels.
There appears to be at least three different kinds of SPI in the PIC32 family.
- The plain simple SPI, not buffered.
- The buffered SPI. This is the one Microchip and MikroE experimented with the WM8731-based Audio Codec Proto board. They configure the PIC32 buffered SPI as Slave. Probably their buffered SPI routine does not support 24-bit audio data. Probably their buffered SPI routine relies on a time-critical trick for dealing with the LRCK signal.
- The new I2S-capable SPI (audio mode).
The reason why I'm currently dealing with the ST Nucleo F401RE and F411RE boards, is the existence of the STM32CubeMX utility, enabling to evaluate and configure the chip peripherals, clocks and pinout.
If Microchip had the same configuration utility, I'll try de-soldering the 64-pin PIC32MX534F064H from the MikroE MINI-32 board, for replacing it by a 64-pin PIC32MX530F128H or PIC32MX550F256H or PIC32MX570F512H or PIC32MX575F512L featuring three I2S-capable SPI. Actually, I'm not sure that the MikroE mikroBasic PRO compiler is supporting those chips.
Today, the idea of programming Microchip PIC32 chips in Basic looks like a dead end as currently there is no Basic compiler for the newest PIC32MZ chips running at 200 MHz, possibly featuring four I2S-capable SPI.
Last edited:
20 years ago I would have agreed with you. Today SPDIF is legacy standard, pretty much like RS-232 - still used in some cases, but mostly through a USB converter, and only for things that don't have ethernet or wifi.
Today Vivaldi, Bach, Brahms, Beethoven and Mozart music is Legacy.
Today the power grid is Legacy.
Today petrol stations are Legacy.
Today RS232 is Legacy.
Today SPDIF is Legacy.
It doesn't imply all this is useless.
Truly Legacy stuff is of great use, indeed.
SPDIF preamps and speakers, better designed than Philips did 20 years ago, are of great use.
This is true, especially when Bluetooth or WiFi (bidirectional control and status, possibly worldwide) is complementing SPDIF (one unidirectional digital audio channel + volume control).
This way, SPDIF speakers can act as (internet) connected objects, indeed.
There will remain many situations where you don't need and want (cost, complexity, reliance) the audio to be transported over an Internet Protocol.
But what benefit does SPDIF bring? Why not connect the speakers directly to IP?
The cost and complexity are rapidly becoming non-issues. They have already become non-issues in the pro and studio world.
Agree. Unfortunately, diyAudio is about do-it-yourself. I think that cost and complexity can be issues in diyAudio, unless somebody (like you?) is coming with some ready-to-use hardware and software, that one can order.
As preamp, one could opt for a Raspberry-based or BeagleBone-based preamp equipped with USB (as audio input) and Ethernet (as audio link to speakers). No specific hardware required, thus. That's a good point.
What about exploiting a SPDIF connector, like the one you can find on a CD/DVD/Bluray player ?
Inside the speakers you need one Ethernet port and at least two I2S interfaces. Can you do this basing on a ST Nucleo F411RE board ? What would you suggest ?
How about something like Olimex ENC28J60-H. It has SPI, not I2S, so it restricts your choice in DSP processors.
This is an interesting suggestion.
48 kHz stereo high-quality audio = 48 kHz x 32-bits resolution x 2 audio channels = 3072 kbit/s
Ethernet bitrate = 3072 kbit/s * 1.5 overheads = 4608 kbit/s
This should be okay for 10-BaseT, indeed.
USB Audio to Ethernet Speaker (using a ready-made module)
***********************
Raspberry PI having one USB2 port (used for high quality audio), and one Ethernet port.
Rotary encoder (volume control)
Rotary encoder (balance control)
Ethernet switch 4 ports (this is a stock Ethernet switch)
*****************
Port 1 connecting to Preamp
Port 2 connecting to Left Speaker
Port 3 connecting to Right Speaker
Ethernet Speaker (4-way digital xo inside) (using ready-made modules and jumpwires)
*******************************
Olimex ENC28J60-H
ST Nucleo F411RE having one SPI for the Olimex ENC28J60-H and two I2S interfaces for two WM8731 MikroE Audio Codec Proto boards
One strap on a GPIO input line for selecting the Left or Right audio channel
Two such Ethernet Speakers required for a stereo system.
The first advantage of Ethernet Audio is that the endpoints (the WM8731 DACs) can operate as audio clock masters, explicitly requesting audio packets when they are needed. This is asynchronous audio. This is the only perfect solution for avoiding audio clock mismatches, buffer overflows, and buffer underruns.
The second advantage of Ethernet Audio is the possibility to send audio backwards, while the speakers are playing, possibly when reducing the audio resolution from 32-bit to 16-bit. This can be useful during the setup and during the selftest of the speakers, with a PC receiving the audio frames coming from mikes embedded into the speaker. If the transmission delay over Ethernet (possibly Internet) is stable and correctly compensated, the PC will be able to measure the Bode plot (gain and phase) of the speaker.
Very important is that the audio packets requests (possibly bidirectional), control data and status data don't eat the 10-BaseT bandwidth.
Can somebody confirm, that this is feasible in a diy-context?
No point in 32 bit (32 bit float has the same resolution as 24 bit fixed point), and 50% overhead is probably conservative if using reasonable packet size.
Indeed.
Only the first one will be equipped with the crystal. The second one will be slaved to the first using a wire.
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.