Open Source DSP XOs

Status
This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.
Ok, so the STM32F4 I2S 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.
IMO, when the three STM32F4 I2S interfaces are all in slave mode, all their I2S WS lines should converge to the unique LRCK originating from the SPDIF receiver. You as STM32F4 programmer, you only need to monitor one WS line. You shall configure all three STM32F4 I2S interfaces by carefully studying the code that's generated by the STM32CubeMX utility. I agree there is a risk of I2S desynchronization caused in case the STM32CubeMX-generated code is losing time in configuring all required I2S interfaces one by one sequentially. One should check this. Anyway, one can replace the STM32CubeMX-generated code by fine-tuned code writing all the required registers once, for quickly and simultaneously resetting and configuring all required I2S interfaces, in a proper way.

I find such clocking scheme, simple and elegant.
Will somebody try this in first place?

I'd love an experimental ST F411RE Nucleo "cape" featuring one WM8804 SPDIF as receiver/transmitter and one TDA7801 (or TDA7802) as quad digital power amp.
  • good as SPDIF stereo 2-way preamp and XO including four power amps,
  • good as SPDIF stereo preamp (TDA7801 unpopulated),
  • good as SPDIF 4-way XO including four power amps (building a SPDIF 4-way speaker)
Creating a dedicated thread?
 
Last edited:
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.

I don't disagree with that, just the approach I prefer personally is bottom-up, rather than the top-down approach you've described. I didn't set out on beginning this thread to get to a software design toolset for implementing any digitally crossed over speaker design. Rather my aim was to evolve some interesting components of the whole solution given the Cortex M0/3/4 SoCs which were then available and which looked to be coming. Not myself being a dyed-in-the-wool lover of high level languages I'm no fan of abstraction layers but each to their own - there's definitely more than one way to skin the cat.
 
I've been following this thread for a different reason. I don't need XOs, but am looking for an open source multi channel audio decoder which would use hardware very similar to what you are discussing here.

Just noticed that these guys are selling what looks like a RPi hat, which decodes hdmi audio. Have a look at it here: Video to Surround Sound Shield - Pi2 Design

Any thoughts?
 
Looks interesting but rather misleading where they're claiming a multichannel digital output over 3.5mm jack. In the rendering there is no such jack. Anyway let's hope it'll stimulate a lot of interest in DIYing HT systems.

I think they mention on the Indiegogo page that the digital SPDIF out is for passthrough. The toslink port is shown in some of the renderings. If you look at the pictures, you'll see they have four PCM5102A DACs feeding the eight analog channels.

Does someone here know anything about the ADV7623 chip? I was under the impression that you have to be an HDMI licensee in order to get these chips.
 
@Indigogo
Overall performance exceeds 116db THD + N!
What does it mean?

Datasheet: PCM5102A
112dB(SNR)/112dB(DNR)/–93 dB(THD)/–93dB(THD+N at –1 dBFS)

The chip can handle ARC, is it implemented? I think this is a real important feature if you use more than one source connected to an ARC enabled display,
or you simply like to switch between media player and TV.

In my opinion, without the capability to decode TrueHD or DTS HD or at least DD/DTS, you can not use it in a serious way.
This is also a big hurdle for every startup or small company that like to develop modern AV devices.
 
Last edited:
What does it mean?

Lol. I have no idea where they got that.

What does it mean?

Datasheet: PCM5102A
112dB(SNR)/112dB(DNR)/–93 dB(THD)/–93dB(THD+N at –1 dBFS)

The chip can handle ARC, is it implemented? I think this is a real important feature if you use more than one source connected to an ARC enabled display,
or you simply like to switch between media player and TV.

In my opinion, without the capability to decode TrueHD or DTS HD or at least DD/DTS, you can not use it in a serious way.
This is also a big hurdle for every startup or small company that like to develop modern AV devices.

FWIW, their Indiegogo page mentions that it can decode DD and DTS and AFAIK you can only send PCM/DD/DTS through the ARC. A better option would probably be add more HDMI ports which are available on the ADV7623.

I assume that you would have to pay extra to get the HBR codecs (although it would be great if you could purchase a key afterward to activate it like the MPEG 2 and VC-1 codecs on the RPi).
 
Just got a reply from one of the creators:

The questions:
+Greg Cote would you mind giving a bit of technical details on the CSB502V2S shield?

I want to know:
a) if ARC is implemented on the ADV7623?
b) if anything other than I2C is used on the GPIO pins of the RPi?
c) what the I2C is used for (does it control the ADV7623, the DACs or both)?
-d) can the shield may be used standalone or does it have to be used with a RPi?

Your feedback will be appreciated.

The Answers:

Not a problem:
a.) It is connected, but we have not tested it.
b.) i have a pin list with the CSB502V2S that i can email to you
c.) Only ADV7623, The DAC's are PCM5102 and use HW control
d.) It requires the Pi or other SBC compatible with it, such as Odroid C1/C2 or UP-Board

and here is an image of the pinout:
An externally hosted image should be here but it was not working when we last tested it.
 
FWIW, their Indiegogo page mentions that it can decode DD and DTS and AFAIK you can only send PCM/DD/DTS through the ARC. A better option would probably be add more HDMI ports which are available on the ADV7623.

No, they say it can passthrough DD/DTS (5.1). You can't use the analog output for DD/DTS playback, you will have to use a software decoder.

And sorry, they offer it and did not test this basic feature?!
 
Hey so I haven't been looking in this thread for a couple of years but I just noticed that the STM32F746 nucleo boards are getting cheap, like $50. Bare chips are $18-$25.

If I read the spec right, they have an SPDIF decoder with 4 inputs, three half-duplex I2S ports, a two-port Serial Audio Interface and HDMI-CEC. Should be enough IO to build a stereo 4-way crossover at least, plus the Nucleo-DISCO board has loads of accessories like touchscreen. Downside to the Nucleo is that it has a a few of the audio ports hardwired to cheap codecs.

Has anyone looked into using one of these? I realise there are probably cheaper and more-powerful/more-IOful DSPs available, but these have a very good free (libre and gratis) toolchain that is guaranteed to be available in the long term.
 
Last edited:
I've not been following what's happening at levels higher than the M4 as so far I've only coded for the M0 and M3. This summer I do plan to start writing for the M4 and would like to kick off with the STM32F401. I also dearly want to get my hands on the latest NXP M4 which is the LPC5411x as this has the lowest power draw of any M4 I've so far seen, around 9mA @ 100MHz. There's even an M0+ core on some parts in the range which is more frugal and compared to the previous generation LPC54 devices this time around they've not skimped on the M0's hardware multiplier. Meaning the M0 can be used for DSP work too.

Had a look on Taobao and the M7 Nucleos are going for under 200rmb which is pretty good value (about $30).
 
I think there is no way to synchronize M7 SAI or I2S outputs to S/PDIF inputs, or at least I didn't found a way. Software ASRC maybe but heavy for the CPU and would increase latency. There is a signal "spdifrx_frame_sync" in the SPDIFRX block but it can be connected only to the timer block to count frequency drift. You will need at least an external PLL feeding SAI/I2S clock blocks controlled by software (DMA interrupt or the timer maybe) to synchronize the SPDIFRX and SAI blocks for an example, and you will need largish buffer.
 
That would appear to be true, but wouldn't be a problem if you used an I2S input. Maybe a WM8804 (or whatever the cool kids are using now) if you really needed the SPDIF-in and couldn't figure out how to get the recovered clock from SPDIFRX.

I would expect it to be easier than that though - why even have the SPDIFRX block if it can't be used to drive an I2S output? There doesn't seem to be an appnote for it, but I didn't look real hard.
 
That would appear to be true, but wouldn't be a problem if you used an I2S input. Maybe a WM8804 (or whatever the cool kids are using now) if you really needed the SPDIF-in and couldn't figure out how to get the recovered clock from SPDIFRX.

I would expect it to be easier than that though - why even have the SPDIFRX block if it can't be used to drive an I2S output? There doesn't seem to be an appnote for it, but I didn't look real hard.

I think it wouldn't be too hard to use something like TentLabs VCXO together with STM32 code to implement the PLL. Just keep count of the DMA interrupts for the SPDIFRX and SAI blocks and generate a relative output voltage using DAC to control the VCXO. That way also the jitter is eliminated. Only problem is that a single VCXO is locked to single Fs "series", like 44.1 KHz x N. For 48 kHz based sample rates you will need an additional VCXO. The VCXO output (11.2896MHz for 44.1k series for an example) is used as SAI_CLK for STM32.

See VCXO
 
Status
This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.