Enough in order to ruin stereo imaging (phase shift between first wave fronts), which also means that multi-channel applications are impossible.
The usual solution to this is a shared word clock, i.e. to 'simply' not let the clocks run completely free.
IMO, not necessarily. IMO, the WM8805 can remain the sole and only clock generator.
- WM8805 generating the WM256FS clock signal (PLL-recovered master clock)
- WM8805 configured as I2S Master
- configuring the F411RE I2S4 interface as Half-Duplex Slave (audio Rx from WM8805)
- configuring the F411RE I2S3 interface as Half-Duplex Slave (audio Tx to ES9023 #1)
- configuring the F411RE I2S2 interface as Half-Duplex Slave (audio Tx to ES9023 #2)
- routing the WM256FS clock to both ES9023
- routing the LRCK and BCLK coming from the WM8805, to the F411RE I2S3 and I2S2
- routing the LRCK and BCLK coming from the WM8805, to both ES9023
One can configure the BCLK polarity of the F411RE I2S3 and I2S2, for optimizing the ES9023 timings.
Worst case would be that some ES9023 I2S signals need to be delayed/reclocked. This can happen using plain simple D-type flip-flops.
Agree?
Last edited:
Only one of these statements is true. If you go to any computer motherboard manufacturer, you will find that most of the higher-end products have an SPDIF output. The RS232 port disappeared a long time ago, but SPDIF is still supported by TV's, CD players, computers, etc.
An easier solution is to use the User Data bits in the SPDIF data stream. Each frame has a bit for left and right channels, and 192 frames are grouped into blocks. By using an SPDIF chip like the SRC4382, you can easily use the User Data to send volume and filter parameters to the DSP in each loudspeaker over the SPDIF cable or fiber. It's a relatively slow data rate and it is unidirectional, but that is adequate for sending volume control and DSP specifications to the active speakers. No additional signaling is required, and you get the benefit of SPDIF real-time audio data without buffer delays.
Quite amazing is that recent "consumer" SPDIF chips like the WM8804 still don't enable this.
Compared to the WM8804 chip, the SCR4382 chip looks old (2006), heavy (it is a 48-pin chip), and hungry (256 mW at 48 kHz).
The SRC4382 shall encode the "U" bit at Fs / 192 which is the AES/EBU block frequency. The BLS pin (35) will thus toggle at 250 Hz when Fs equals 48 kHz.
Interrupted at 250 Hz by the SRC4382 BLS (output) pin, the STM32 F411RE shall write a bit somewhere in the SRC4382 memory map (using SPI or I2C), interpreted by the SRC4382 as the "U" bit to be encoded and sent over SPDIF AES/EBU.
For passing the Left and Right volumes, one need to setup a serial messaging service.
At least three bytes need to be sent (opcode, left volume, right volume). This is 24 bit. Knowing that the bitrate is 250 Hz, encoding the volume may take something like 100 ms.
The same principle must be applied at the receiving end. Another 100 ms delay will be added.
This means that the volume setting control will be slow, exhibiting a latency in the order of 250 ms. This may discomfort some users.
A more robust messaging system relying on ASCII will be slower.
Say the "V" ASCII code as opcode, two bytes ("0" "0" to "F" "F") for the Left volume, two bytes ("0" "0" to "F" "F") for the Right volume, and the CR ASCII character as delimiter. This is already 6 bytes (48 bits). Knowing that the bitrate is 250 Hz, encoding the volume this way will take 192 ms.
The same principle must be applied at the receiving end. Another 192 ms delay will be added.
This means that the volume setting control will be slow, in the order of 500 ms. Won't such 500 ms volume control latency discomfort most users ?
Please note, at this stage, reading the SRC4382 datasheet, I don't see clearly :
- where in the memory map of the SRC4382, the STM 32F411RE SPI (or I2C) must write the "U" bit (this is concerning the preamp software)
- where in the memory map of the SRC4382, the STM 32F411RE SPI (or I2C) can read the "U" bit (this is concerning the speaker software)
When relying on a single (but complicated and hungry) SCR4382, the job of injecting the AES/EBU Pro "U" bit as volume control :
- only requires a microcontroller equipped with SPI (or I2C),
- causes a 250 ms to 500 ms latency on the volume control
- requires a microcontroller equipped with three half-duplex I2S (not an issue thanks to the STM32 F411RE)
- requires a WM8804 as SPDIF receiver
- requires two WM8804 as SPDIF transmitters (one for the Left speaker, and one for the Right Speaker)
- requires attention what's regarding the MCLK and I2S clocking scheme
- causes no volume control latency as now, the control data is 24-bit at 48 kHz
Another possibility is to rely on a Wireless (Bluetooth or Zigbee) volume control opertating at something like 100 kbit/s. However doing so, how to hook two speakers (Left and Right) on a same SPDIF connector ? You need a SPDIF splitter, and that's a hassle. Back in 1994, Philips had the idea of chaining the DSS speakers. The Philips DSS940 and DSS930 speakers had one SPDIF input, and one SPDIF output. Which means that every DSS speaker was embedding a SPDIF splitter. Such idea of chaining the DSS speakers got inherited from the Philips MFB speakers connecting scheme dating back from 1974.
Today, audiophile people don't appreciate the SPDIF signal needing to pass through the Left speaker, before reaching the Right speaker.
Today, audiophile people want to connect their speakers, directly to the source. The Left speaker, to the left source. The Right speaker, to the right source.
Last edited:
The "sacrificed audio channel" volume control method looks particularly tempting using some AKM chipset.
AK4116VN 20-pin SPDIF receiver here
AK4104ET 16-pin SPDIF transmitter here
A STM Nucleo R411RE "cape" embedding one AK4116VN and two AK4104ET would be very welcome (watch out the clocking scheme).
This is your long-awaited "Open Source SPDIF DSP Preamp".
A STM Nucleo R411RE "cape" embedding one AK4116VN and two ES9023 would be very welcome (watch out the clocking scheme).
This is your long-awaited "Open Source SPDIF DSP XO".
Provided those little AKM chips can be purchased, I think we should try such "sacrificed audio channel" volume control method in first place. Oh, and I was forgetting : there is only one input, and this is a plain dirty SPDIF full of jitter. And I bet that such little system will deliver a quite interesting quality, objectively and subjectively. Not to mention the possibility to compensate loudspeakers in gain and phase, with the full latitude permitted by IIR and FIR filters.
AK4116VN 20-pin SPDIF receiver here
AK4104ET 16-pin SPDIF transmitter here
A STM Nucleo R411RE "cape" embedding one AK4116VN and two AK4104ET would be very welcome (watch out the clocking scheme).
This is your long-awaited "Open Source SPDIF DSP Preamp".
A STM Nucleo R411RE "cape" embedding one AK4116VN and two ES9023 would be very welcome (watch out the clocking scheme).
This is your long-awaited "Open Source SPDIF DSP XO".
Provided those little AKM chips can be purchased, I think we should try such "sacrificed audio channel" volume control method in first place. Oh, and I was forgetting : there is only one input, and this is a plain dirty SPDIF full of jitter. And I bet that such little system will deliver a quite interesting quality, objectively and subjectively. Not to mention the possibility to compensate loudspeakers in gain and phase, with the full latitude permitted by IIR and FIR filters.
The CS8427 also has block buffers to send and receive the User Data. But a more recent consumer "SPDIF chip" that provides User Data buffers is the ADAU145X series of DSP chips.
Actually, sending the data is easy: just write to the user buffer and then set the register bit to send out the entire frame. Reading the data must be synchronized to the BLS signal, but this is not a problem. I'm using a 40MHz 68S08, and the CPU utilization for the ISR is less than 25%.
This analysis is incorrect. The block rate is 250Hz, but each block includes 192*2 user bits, which is 48 bytes (24 left and 24 right). Since the data is reliably aligned in buffers in the chip, this can be binary data. An update rate of 250Hz results in a delay that is less than what is commonly used to debounce a rotary encoder, so this delay will not be perceivable.
The DIR buffers are on Register Page 1 and the DIT buffers are on Page 2. Because you have to switch register pages to read the data, it is best to read the entire buffer during the ISR. The challenge, though, is reading all of that data using the relatively slow I2C bus. But it can be done with a carefully written ISR.
A simple Y-connector at the SPDIF source works just fine. It's not a "proper" solution, but it works fine. Or just provide two connectors and an extra driver at the source.
To each their own. But I like using the SPDIF User Data, as it is a very simple solution for active speakers. And once you figure out the SRC4382, you'll like it. On the transmit side, the SRC4382 chip makes a great selector switch for an audio preamp and the SRC capabilities are useful for the different data rates from CD data, USB audio, A/D, etc. On the receive side, the SRC4382 feeds an ADAU1701 for the DSP, and all of the other features except the DIR are powered down. So what goes in the speaker is a simple 3-chip solution (CPU, SRC and DSP) plus the amps. I'm not locked into using the ADAU1701 as the DSP, but once you figure it out, it is a nice chip for making crossovers for active speakers. I've also got code for the STA309/STA32X/STA350 embedded DSP and I'm working on other DSP's as well.
Of course, this solution isn't "open source" unless the code in the micro and the DSP is made available. But a lot of people are already working on open source software for the ADAU1701, so that problem will probably get solved. I just purchased a $20 Sparkfun Redboard and I started laying out a shield with the SRC4382 and ADAU1701. I may or may not go through with that design, but if I do, it might become open source. But this project is not something I really need, so a lot comes down to whether someone helps out...
Last edited:
I'm very impressed by the ADAU1452 introduced by ADI in January 2014.
By providing the same 32-bit resolution as the ARM Cortex-M4, ADI made a decisive move extending the marketing life of the SigmaDSP product line.
Regarding such 32-bit iteration of the SigmaDSP core, is it plain fixed-point 32-bit, without tricks and small prints ?
Wondering if there are enough MIPS in the ADAU1452 for implementing a 4-way SPDIF loudspeaker featuring a volume control over the SPDIF "U" bits.
One must rely on a "U" bit signalling scheme avoiding the ADAU1452 wasting a lot of CPU cycles herein. The ADAU1452 must :
What about using one ADAU1452 ASRC as SPDIF jitter buster ?
For materializing a SPDIF speaker, you can hook two stereo DACs like ES9023 or PCM5102A. It would be nice to also hook a stereo ADC, possibly low latency, providing one or two measurement mike inputs.
However the ADAU1452 appears be a fantastic chip to me, at the moment it is only supported by the SigmaStudio programming environment. And, bad news for us here, from what I can understand from ADI website, the SigmaStudio programming environment is not available for hobbyists and small projects.
Can somebody explain ADI's expectations and business model ?
As soon as it becomes possible to develop open software (third-party compiler ?) for the ADAU1452, we'll get a kind of gold standard. Must say this is VERY appealing.
Before I attempt designing a PCB for the ADAU1452, I will of course try the EVALuation board that's available from ADI. I guess it is coming with some SigmaStudio programming licence.
Can somebody tell me the practicalities, after unboxing the EVAL-ADAU1452 ?
Is there already a third-party tool allowing to program the EVAL-ADAU1452, in total freedom ?
By total freedom I mean being able to rely on my own audio DSP operating system, create my own audio DSP modules, and not to forget, also program some efficient "U" bit extraction and message decoding within the ADAU1452.
For sure my own audio DSP operating system and modules won't be as elaborated and structured as the ones possibly developed by Paul Beckmann (DSP Concept). I'm saying this because I guess that SigmaStudio was written by Paul Beckmann. Clearly, people wanting to program their own audio DSP operating system and modules on the ADAU1452 need to be considered as wanting to reinvent the wheel, which means that some of them will end up with square wheels, conceptual issues, and so on.
One should ask ADI. Could ADI tolerate this, provided people attempting relying on their own audio DSP operating system and modules :
In case the "U" bit extraction routine is a hassle for the ADAU1452, one can rely on a Cortex-M0 doing so using SPI. The ADAU1452 would deliver the raw "U" bit over SPI at something like 100 kbit/s, having short pauses between blocks. The Cortex-M0 would do the decoding. The Cortex-M0 would send HEX-encoded messages to the ADAU1452 over SPI like "V" "L" "4" "2" "R" "9" "A" (CR). The meaning of this is : "Volumes should be 42 for Left and 9A for Right. Please note, the Cortex-M0 sofware remains the same for all speakers. The ADAU1452 receiving such message over SPI decodes it. It reads a hardware GPIO for knowing what channel he is. In case the ADAU1452 is serving the Right channel, it will indeed set the volume to "9A", scaling the audio in digital.
By providing the same 32-bit resolution as the ARM Cortex-M4, ADI made a decisive move extending the marketing life of the SigmaDSP product line.
Regarding such 32-bit iteration of the SigmaDSP core, is it plain fixed-point 32-bit, without tricks and small prints ?
Wondering if there are enough MIPS in the ADAU1452 for implementing a 4-way SPDIF loudspeaker featuring a volume control over the SPDIF "U" bits.
One must rely on a "U" bit signalling scheme avoiding the ADAU1452 wasting a lot of CPU cycles herein. The ADAU1452 must :
- extract the "U" bits
- decode the volume info carried by the "U" bits
- split the audio over 4 channels (XO function)
- scale the audio according to the volume info (this is a digital volume done by data scaling, relying on some 110 dB DACs DNR)
What about using one ADAU1452 ASRC as SPDIF jitter buster ?
For materializing a SPDIF speaker, you can hook two stereo DACs like ES9023 or PCM5102A. It would be nice to also hook a stereo ADC, possibly low latency, providing one or two measurement mike inputs.
However the ADAU1452 appears be a fantastic chip to me, at the moment it is only supported by the SigmaStudio programming environment. And, bad news for us here, from what I can understand from ADI website, the SigmaStudio programming environment is not available for hobbyists and small projects.
Can somebody explain ADI's expectations and business model ?
As soon as it becomes possible to develop open software (third-party compiler ?) for the ADAU1452, we'll get a kind of gold standard. Must say this is VERY appealing.
Before I attempt designing a PCB for the ADAU1452, I will of course try the EVALuation board that's available from ADI. I guess it is coming with some SigmaStudio programming licence.
Can somebody tell me the practicalities, after unboxing the EVAL-ADAU1452 ?
Is there already a third-party tool allowing to program the EVAL-ADAU1452, in total freedom ?
By total freedom I mean being able to rely on my own audio DSP operating system, create my own audio DSP modules, and not to forget, also program some efficient "U" bit extraction and message decoding within the ADAU1452.
For sure my own audio DSP operating system and modules won't be as elaborated and structured as the ones possibly developed by Paul Beckmann (DSP Concept). I'm saying this because I guess that SigmaStudio was written by Paul Beckmann. Clearly, people wanting to program their own audio DSP operating system and modules on the ADAU1452 need to be considered as wanting to reinvent the wheel, which means that some of them will end up with square wheels, conceptual issues, and so on.
One should ask ADI. Could ADI tolerate this, provided people attempting relying on their own audio DSP operating system and modules :
- don't pollute the ADI support
- don't publish ADAU1452 source code that's actually code generated by SigmaStudio
In case the "U" bit extraction routine is a hassle for the ADAU1452, one can rely on a Cortex-M0 doing so using SPI. The ADAU1452 would deliver the raw "U" bit over SPI at something like 100 kbit/s, having short pauses between blocks. The Cortex-M0 would do the decoding. The Cortex-M0 would send HEX-encoded messages to the ADAU1452 over SPI like "V" "L" "4" "2" "R" "9" "A" (CR). The meaning of this is : "Volumes should be 42 for Left and 9A for Right. Please note, the Cortex-M0 sofware remains the same for all speakers. The ADAU1452 receiving such message over SPI decodes it. It reads a hardware GPIO for knowing what channel he is. In case the ADAU1452 is serving the Right channel, it will indeed set the volume to "9A", scaling the audio in digital.
Last edited:
ADAU1452 has registers for reading and writing the user data bits.
Anyway, how about using BLE for volume control, how much would it cost to add something like BLE chip with uC+PGA to each speaker? Guess there are some boards like MSP430 (or Arduino) based ones available off-the-shelf. You could then use any BLE/Bluetooth Smart enabled smart phone as a remote controller.
Anyway, how about using BLE for volume control, how much would it cost to add something like BLE chip with uC+PGA to each speaker? Guess there are some boards like MSP430 (or Arduino) based ones available off-the-shelf. You could then use any BLE/Bluetooth Smart enabled smart phone as a remote controller.
I guess you mean Sparkfun BLE Mate 2 or MikroE BLE2 click. For people wanting a dedicated remote control (thus, not relying on a smartphone) there is the possibility of relying on a IR to BLE bridge. Say you rely on the Sparkfun Infrared Remote Control. At the receiving end you could have a Sparkfun RedBoard and one of the above BLE module plus a IR receiver. Such little box would thus transform the IR remote control function into a BLE remote control function.
No I mean cheap Bluetooth boards like this HC-05 module:
Wireless Serial 6 Pin Bluetooth Transceiver Module HC-05 RS232 Master Slave AI1G | eBay
IR-BT is easy with the module and MSP430 Launchpad (+IR led). Controlling the pairing may be the most difficult task.
E: Above is not BLE, but this one is:
http://www.ebay.co.uk/itm/Pro-HM-10...107?pt=LH_DefaultDomain_3&hash=item2ed83d71d3
It's based to TI's CC2540 chip, and contains 8051 CPU core (guess it can be programmed using some SDK, see http://www.ti.com/product/CC2540/toolssoftware#devtools).
USB BLE dongle can be get for under a pound, like BT 3.0 "selfie remote":
http://www.ebay.co.uk/itm/Bluetooth...Domain_3&var=630554551210&hash=item5418d60242
Wireless Serial 6 Pin Bluetooth Transceiver Module HC-05 RS232 Master Slave AI1G | eBay
IR-BT is easy with the module and MSP430 Launchpad (+IR led). Controlling the pairing may be the most difficult task.
E: Above is not BLE, but this one is:
http://www.ebay.co.uk/itm/Pro-HM-10...107?pt=LH_DefaultDomain_3&hash=item2ed83d71d3
It's based to TI's CC2540 chip, and contains 8051 CPU core (guess it can be programmed using some SDK, see http://www.ti.com/product/CC2540/toolssoftware#devtools).
USB BLE dongle can be get for under a pound, like BT 3.0 "selfie remote":
http://www.ebay.co.uk/itm/Bluetooth...Domain_3&var=630554551210&hash=item5418d60242
Last edited:
Well it seems the SDK (the BT stack for CC2540) is tied to IAR compiler which works only for 30 days (and costs a lot of money), so forget it.
You need to read the FAQ for SigmaStudio:
FAQ: Can we bundle SigmaStudio with our product design?
A: No, the SigmaStudio software is licensed for use as a design tool and is not intended for use as a mass-market tuning/programming tool. If your product design requires a software interface for tuning audio parameters, then you should develop one that fits your product's need. SigmaStudio includes too many features that are more than what a consumer will need to interface to the audio processor - there's too much of a chance for them to do something they they (and you!) don't want them to do.
A: No, the SigmaStudio software is licensed for use as a design tool and is not intended for use as a mass-market tuning/programming tool. If your product design requires a software interface for tuning audio parameters, then you should develop one that fits your product's need. SigmaStudio includes too many features that are more than what a consumer will need to interface to the audio processor - there's too much of a chance for them to do something they they (and you!) don't want them to do.
Sigma Studio is intended to define the DSP architecture by allowing the designer to string together processing cells in a sequence. Once the processing is defined, you can only interact with the device by changing parameter data. So, for example, SigmaStudio will allow you to define a bank of biquads, delays, volume controls, etc, and then once this architecture is defined, your software interface will allow the user to change the biquad parameters, or the length of the delays, or the volume. One way to look at SigmaStudio is that it is a tool for making a programmable network of processing cells into a fixed-architecture chip.
This is an overstatement and an overly restrictive use of the term "open-source". The STA350 is a fixed-architecture chip with a hard-wired sequence of processing cells that are commonly needed for building active speakers. Sure, you can't rearrange the processing sequence or reconfigure the processing cells, as you can with a SigmaDSP chip, but you can develop open source software that allows the user to manipulate the DSP parameters to accomplish useful goals--like build active speakers.
Obviously, both the STA350 and the SigmaDSP chips require a micro on the board to provide a higher-level interface than I2C transfers, but that doesn't make the design closed, either. I believe the best way to partition the system design is to keep all of the DSP parameter calculations in the host processor. The host code is where the biquads get defined and where the coefficient data is calculated, and there is no complex processing in the micro--it is simply a USB string to I2C converter, to pass those parameters to the DSP chip. So by defining and standardizing on a simple command protocol to the micro, the bulk of the software can be "open source".
Obviously, some of the posts in this thread are suggesting to implement the DSP code in a fast micro rather than a dedicated DSP chip, but I don't understand why anyone would want to do this. The ADAU1701, which is no where near as fast as the ADAU1451, can calculate over 200 biquads each sample point, and it has plenty of delay memory and other resources--including a fairly good A/D and D/A. It's got enough channels to be a complete loudspeaker crossover/EQ solution, and it's only $7!.
Good point. The present thread started in September 2011 when some ARM Cortex-M0 micro featuring buffered SPI went available, able to emulate 16-bit I2S at 44.1 kHz or 48 kHz thanks to some careful handling of the SPI routine and LRCK pin. The grand idea was to materialize fixed-point 32-bit audio DSP costing a fraction of dollar. Considering such low price, eight ARM Cortex-M0 micros could have been used for building a stereo 4-way system. One inexpensive 32-bit DSP chip per speaker driver.
The idea of being open-source came in order to audit the DSP code, in a quest for the cleanest implementation.
Now in March 2015,
- the WM8804 used as "Consumer" SPDIF to I2S converter is widely available and inexpensive,
- the ADAU1451 32-bit audio DSP featuring a "Pro" SPDIF receiver and a "Pro" SPDIF transmitter enabling some "U" bit extraction and manipulation is widely available and inexpensive,
- the STA350BW I2S-input Biquad filtered power amp is widely available and inexpensive,
- the STM32 F411RE Cortex-M4 micro featuring one I2S input, two I2S outputs, one I2C and one SPI at the same time, is widely available and inexpensive, and on top of this there is the ST Nucleo F411 prototyping board costing less than 10 dollars,
- the TDA7801 (or TDA7802) dual I2S-in 4-channel power amp is widely available and inexpensive.
If you don't reject the idea of configuring one DSP trench for each speaker driver, you can try the STA350BW in Mono BTL. Albeit having no second sources, the STA350BW can operate through open-source PCBs and open-source configuration data. And this is a power amplifier.
If you prefer centralizing the DSP of a multiway speaker, you better try the ADAU1451, outputting two I2S to a TDA7801 4-channel power amplifier. I still don't know if after purchasing a ADAU1451 evaluation board, I will be able to program more ADAU1451 chips purchased from Mouser, and for how long. Can somebody please tell me ?
Viewed this way, the STM 32F411RE Cortex-M4 micro featuring one I2S input, two I2S outputs, one I2C and one SPI at the same time, doesn't appeal anymore. It has no SPDIF input, no ASRC, and no SPDIF output. On the other hand, it has USB. Which means that after developing some PC software, you could hook it on a PC for configuring it. It gets particularly interesting when you add measurement mike inputs to the STM32 F411RE, letting the PC run as a realtime audio analyzer. That's something not to be undervalued.
Today in March 2015, wanting to connect a multiway system straight on the SPDIF output of a CD/DVD/Blu-ray, the real hassle is the volume control.
There is a volume control box required, to be hooked on the SPDIF output of a CD/DVD/Blu-ray.
Is this always 16-bit audio ?
Is this sometimes 24-bit audio ?
Please tell me.
Anyway, such volume control box could consist on :
- a SPDIF-in socket,
- a WM8804,
- a STM 32F411RE,
- two SPDIF-out sockets in parallel.
The F411RE reads one or two rotary encoders (volume, balance).
The F411RE scales down the audio according to the volumes.
The F411RE sends scaled audio to the WM8804 SPDIF transmitter section.
Thanks to the two SPDIF TOSLINK operating in parallel, one can connect the Left speaker and the Right speaker to the volume control box.
This is only working nice, provided the volume scaled audio is 24-bit.
At a -20 dB volume, the audio resolution will still exceed 16-bit.
For having the same BCLK at the input and at the output, the digital audio entering the WM8804 SPDIF receiver must be 24-bit.
Will it be the case when playing an audio CD, a DVD, a Blu-ray ?
Will it be the case when exploiting the SPDIF output of a PC motherboard ?
A poor man's stereo 4-way system could consist on :
- one SPDIF volume control box only accepting 24-bit audio
- two SPDIF cables,
- two 4-way plates.
- a single SPDIF-in socket,
- a single STM32 F411RE (one 24-bit I2S-in and two 24-bit I2S-out),
- a single TDA7801 (two 24-bit I2S-in) acting as 4-channel power amp.
One can however trade the least significant bit of audio against a general purpose serial data, to be physically output and to be physically returned to a 4800 bit UART. This way one can implement a general-purpose message passing in Hex, with special characters as delimiters.
While doing all this, the poor man would only need to read two datasheets : the WM8804 and the STM32 F411RE.
While doing all this, the poor man would only need to learn three software development bricks : STM32CubeMX, STM32CubeF4, and KEIL MDK ARM 5.14 (demo mode having 32k limit and no code disassembly).
This way, all the software remains C code and assembly code.
As consequence, all popular tools and methods promoting the open-source code development can apply.
Last edited:
In terms of the title of the thread, I take the phrase 'open source' in a pragmatic, rather than ideological way. Its an attempt to head off losing valuable engineering development time and experience when a manufacturer declares a part EOL (as happened to Bruno Putzeys with his TI silicon).
As such, discussion of DSP parts (not peripheral interface parts) with a single source are OT for this particular thread.
Last edited:
Regarding STM32 I2S in slave mode there is a bug on chip when the slave mode is started. Because of that the I2S WS has to be pulled high by the master before the I2S on STM is started:
https://my.st.com/public/STe2ecommu...14902C3CDE46A77F0FFD06506F5B¤tviews=262
Well, maybe the WS line can be OR'ed with a GPIO status bit (might cause some delay / jitter though), but that should be something that the designer of the I2S block should have already taken into account.
https://my.st.com/public/STe2ecommu...14902C3CDE46A77F0FFD06506F5B¤tviews=262
Well, maybe the WS line can be OR'ed with a GPIO status bit (might cause some delay / jitter though), but that should be something that the designer of the I2S block should have already taken into account.
Last edited:
Thanks you so much for pointing this. Sharing such knowledge will save projects. Kind of open-source already.
The errata sheet is DM00037591. You can find it here.
This is section 2.5 entitled "I2S peripheral limitation".
Actually there are two bugs on the STM32F4 I2S interface.
Subsection 2.5.1 says "In I2S slave mode, WS level must be set by the external master when enabling the I2S." IMO, such wording is unclear and misleading. The workaround proposed by STM helps understanding the actual bug. To me, it seems that STM designed the slave WS sense logic basing on levels, while they should have designed it basing on transitions. From what I understand from their prose, as workaround, you as STM32F4 programmer, you need to monitor the WS signal delivered by the Master (the I2S chip you are talking with), before enabling the STM32F4 I2S Slave peripheral. If you selected the I2S protocol, you need to wait the Master to set the WS line at High level. If you selected the LSB or MSB-justified mode, you need to wait the Master to set the WS line at Low level. IMO, monitoring the STM32 WS pin as GPIO for waiting the required transition, after which you immediately enable the I2S interface, won't cause jitter. I say this basing on the assumption that the "GPIO monitoring to I2S WS use" reconfiguration blindness that's happening when you activate the I2S interface will be very short, never more than half a Fs period. On the other hand, in case such blindness is longer than half a Fs period, the WS line will undergo one or more transitions during the blindness, and this will ruin the proposed workaround.
Subsection 2.5.2 says "I2S2 in full-duplex mode may not work properly when SCK and WS signals are mapped on PI1 and PI0 respectively". The proposed workaround is to select PB10 pin or PB13 pin for I2S2 CK, and select PB12 pin or PB9 pin for I2S2 WS.
Last edited:
I jumped in because thought the title implied crossover *design* as well as implementation of the filters. In a full-featured crossover design tool, there is an application for specifying the filters based on the driver measurements. And maybe the capability to address the effect of baffle diffraction, box parameters, and room effects. The filter implementation in the active speaker is just one aspect of crossover design.
In a well designed crossover development tool, the actual hardware implementation of the DSP should be insulated from the user by an abstraction layer. I think that is a much more pragmatic approach to obsolescence than insisting that the DSP be implemented in a multi-sourced processor. But the ideal solution would be a combination of both strategies -- a standard DSP architecture, plus an abstraction layer to support inevitable variations and peripherals.
An example of an abstraction layer is in this crippled preview of Active Speaker Designer (ASD). You can safely download and install the code in the link--it is all managed code running in .NET. On the main screen, select "ASD Object Model" from the Help Menu. The abstraction to insulate the application from the hardware implementation is the Amp object, which consists of channels and each channel has biquad banks and filters and delays. The DSP module interacts with the Amp object as it calculates the biquad coefficient data, delays, volume levels, etc. When you select a hardware platform using the Amps Module, it selects the coefficient data format and the right translation logic to task the DSP using its "native" command format. So the main part of this active crossover program doesn't care what type of hardware is used to implement the filter--all that matters is the tasking interface and data formats for the parameters.
I had to implement the abstraction layer because of the same problem you pointed out: the original chip I was using (TAS3004) went NLA. But as you can see by browsing the selections in the Amps module, I'm trying to support a wide range of boards with different DSP chips and variants of boards--including boxes like the DCX2496. If you make a Cortex-MX board, that would be great--I could just add a new Cortex-specific Control Module, make adjustments to the DSP module to depict an abstraction of its capabilities, and then add that board to the list of Amps. This doesn't require extensive redesign--new chips or boards can be accommodated fairly easily.
Again, I don't disagree that it is desirable to have an multi-vendor CPU solution for the filter implementation. But if you are really interested in having an open-source solution for designing speakers like the Orion, I think you need to look beyond just the filter implementation.
A streamlined abstraction layer becomes possible when you embed measurement mikes for real-time calculating and graphing a Bode plot using a pink noise. Looks complicated ? All you need is to select between Linkwitz-Riley 4th-order and Linkwitz-Riley 6th-order. You then display the target Bode plot against the measured Bode plot in realtime, while the user is fiddling with eight "generalized BiQuads" in series. A "generalized Biquad" is a "l" lowpass + "b" bandpass + "h" highpass with l, b and h numbers in the -1, +1 range for a given Fc and Q. Add a small delay line, and you are done.
I would avoid having a same application taking care of the DSP and the box volume determination. I would avoid reinventing the wheel what's regarding box volumes determination and vents, knowing that beyond trivial boxless, closed box and bass reflex box, you may opt for additional internal boxes and vents acting as resonators/dampers. Try to figure out the 3-box 8th-order Bose subwoofer. Try to figure out 2-box 4th-order Sony and Yamaha subwoofers featuring negative impedance amplifiers. You better stay away from this, what's regarding DSP.
How to do, then ?
You simply take a box, just as it is, and you DSP-equalize it in gain and in phase.
BiQuads are especially useful when relying on active subwoofers. You take a stock Sony or Yamaha subwoofer, and you IIR-equalize it using BiQuads for conforming it to a 4th-order or 6th-order Linkwtz-Riley lowpass. When this is done, all you need to do is to IIR-filter using BiQuads the corresponding bass/medium/high unit, conforming it to a 4th-order or 6th-order Linkwtz-Riley highpass.
In case you intend having a tweeter starting at 3 kHz or 4 kHz, you'll be better with a short FIR-based crossover (say 30 samples) exhibiting no relative phase shifts and preserving the global phase, like Philips did with the DSS930 and DSS940 speakers 20 years ago. For shortening the required FIR impulse response you may damp the medium driver response using BiQuads (IIR filters), especially if the medium driver is exhibiting cone breakup. Short FIR-based crossovers are an interesting matter. You need to rely on the DFT for determining the target lowpass and complementary highpass. You may help the PC, relying on the FFT instead of the DFT. Your FIR-filter shall thus be 32-samples, 64-samples or 128-samples. That you may truncate a little bit if the target DSP is on the slow side. Using FIR filters, there are many degrees of freedom. The degree of freedom reduces to zero when you opt for linear phase ratiometric symmetric crossovers (highpass having the same slope as lowpass), exhibiting a given pseudo-order. By pseudo order, I mean getting a pseudo 3th-order (18 dB/octave) or a pseudo 2.5th-order (15 dB/octave) in case you hate preshoot and ringing.
The cherry of the pie is to rely on a true 32-bit DSP precision for equalizing the deep bass using BiQuads (IIR filters), between 15 Hz and 100 Hz. This is why you may opt for the 32-bit ARM Cortex-M4, 32-bit ARM Cortex-M7, or 32-bit ADAU1541, all featuring I2S and possibly TDM also.
At the end of the day, provided you always rely on realtime measurements, you'll realize that the FRD bells and whistles are not required anymore.
What's regarding IIR filters, a normal user equipped with a normal brain will feel happy, fiddling in a realtime graphical interactive way, for determining the l, b, h, Fc and Q values of the eight BiQuads in series, and determining some short delay, for attaining a target Bode plot (gain and phase).
What's regarding FIR filters, by relying on the FFT and inverse FFT, any decent Gigahertz PC can automatically determine the FIR coefficients needed for attaining a given target Bode plot. The user only needs 1) to specify the parameters of the linear phase ratiometric symmetric crossover (highpass/lowpass, Fc, pseudo-order) and 2) to carefully adjust the distance between the mike and the speaker. While doing so, the user will have the satisfaction to see a clean and short impulse response emerging. As said above, nothing prevents the user pre-equalizing the speaker driver using a few IIR filters (BiQuads) for helping the FIR filter doing his job.
In a nutshell, go to the roots, perform realtime measurements, apply textbook theory and algorithms, and you'll realize how all this is trivial, from a physical perspective. Don't hesitate involving the user in the physical realities.
I'm telling you all this because I see that provided you continue working out your excellent idea of creating abstraction layers for various DSP-capable hardwares, the high-level functional blocks (abstractions) that you really need are very few, and conceptually simple, however sometimes very demanding what's regarding the realtime numbers crunching requirements (FFT and inverse FFT). You will thus produce an intuitive, easy to use software, helping the user to navigate through the underlying physics of loudspeaker drivers and crossovers, in a very rewarding manner.
Last edited:
Ok, so the WS line should be first configured as a GPIO input pin and monitored. First you wait for a high level, then a low level, and finally when a transition from low to high level is monitored again the I2S configuration can start. This way you assure that you get the maximum time for the I2S initialization. Things get complicated when you have three I2S blocks and you need to do the same for each.
It would be so much easier to use the master mode in controller (codecs as slaves). Regarding S/PDIF that would require the use of ASRC chip. In master mode the problem is in starting the separate I2S blocks at the same time to avoid the phase difference between 0 to 1/Fs seconds. No so much problem if you have just 2-way speakers + possible subwoofer(s) if you dedicate one I2S to each speaker (left/righ/sub).
I think the peripheral interfaces implementations are a much bigger problem than expected. If you want still use SMT parts or kits there is also the 32F429IDISCOVERY kit (32F429IDISCOVERY Discovery kit for STM32 F429/439 lines - with STM32F429ZI MCU - STMicroelectronics) which contains the STM32F429 chip with SAI interface (in addition to I2S) supporting multichannel TDM format. However, even in that kit it seems to be problematic to assign the I2S pins because the board is stuffed with so many functions (at least you will loose the touch panel to get the I2S3 to work, and only the A channel of SAI is usable, the B channel pins are connected to LCD).
Last edited:
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.