Click, the right click (open in new tab) to see it full size to be able to read it.
It's theoretical for the most part, currently. But I've wasted far too many bytes explaining it and failing. A picture says....
Clocks are a concern, with so many "off the shelf" modules either forcing they be clock source, or in the cases of BT modules and the PCM5102, just not caring about master clock at all. I can do clock routing, I can do frame stuff/drop.
I'm not aiming for HiFi SOTA in the first pass. Those STM32F411 mux front ends are pretty maxed out routing 2 I2S and 2 SPI. At first I may just limit the internal buses to 48K,16bit. Most of the hardware is capable up to 192K,32 and the Atmel USB bridges go WAY, WAY higher.
Should be noted. It is possible, though impractical that all inputs can be routed to all outputs at the same time. In the real world however its more likely that one bus will be music with heavy EQ going to the headphone output and the other bus being everything else at low gain/low eq and appearing everywhere. Even to the point that a notification on my phone will come out the speakers and headphone or whatever I choose independent of other sources.
as an aside, my choice of music has been poor while testing. An anomaly which sounds exactly like a buffer overrun ... is actually a synth with a stupidly heavy decimation filter on the original recording. That had me diagnosing for at least 5 minutes. I want to resist going to a signal gen, source and oscilliscope, for testing but I suppose I should. I prefer to play music through it and grimace at the buffer over-runs and screw ups "for real".
I do plan and create timing signal outputs and I have 4 channel OSC to see how different buffers are migrating with the clock "shenanigans". The standard double buffering creates a nice square wave on a scope. Running 4 different buffers on 4 channels should allow me to watch buffer slew in real time and verify correction techniques work.
I do plan and create timing signal outputs and I have 4 channel OSC to see how different buffers are migrating with the clock "shenanigans". The standard double buffering creates a nice square wave on a scope. Running 4 different buffers on 4 channels should allow me to watch buffer slew in real time and verify correction techniques work.
Yes. The OP is, of course, free to adopt whatever approach the OP wants but this has got to be one of the most backasswards approaches to a routing matrix ever.
Why? All inputs are simultaneous. There is not concept of "Source select". All of them are active. Or can be.
However I do see where you might have a point. I felt that a single STM32F411 per input was excessive, so I paired them up with a primary source and a secondary source. If both inputs are selected to the same bus it will just mix them. This presents a limitation on them both going to the same output of course. With single paths to the SPI bus all channels can remain individual and only do mix down in the bus processors.
So really the only routing is which processor it goes by. The inputs and outputs are not mutually exclusive, but N to N.
However I do see where you might have a point. I felt that a single STM32F411 per input was excessive, so I paired them up with a primary source and a secondary source. If both inputs are selected to the same bus it will just mix them. This presents a limitation on them both going to the same output of course. With single paths to the SPI bus all channels can remain individual and only do mix down in the bus processors.
So really the only routing is which processor it goes by. The inputs and outputs are not mutually exclusive, but N to N.
Likely a lack of imagination on my part but I would stick to the tried and tested. I'd start with a crosspoint switch and build out from there. Might even consider Dante if I could get the parts.
Interesting. I wasn't aware of these. Very low level. I worry about the learning curve some. Similarly to DSPs.
It only really solves a small part of the architecture, might be more useful routing primary source clocks to the outputs more than routing I2s.
I'm approaching this from a software engineering perspective, so I'm isolating, encapsulating and presenting interfaces between components. I don't have the MCU capacity to receive 6 channels of I2S and have anything left to do anything with it. So I need a reduction from N down to 2. Using SPI as a much higher bitrate (aka trunking/TDM/Multiplexing).
A lot of the hardware is choosen because there are bare metal minimal modules purchasable. A lot of the Anamero stack for example. Or at least knock offs.
Hardware strategy is to start with modules on breadboards, 60% of the arch is tested already in small prototypes. I need to expand the protoypes to include one and then both full signal paths. From there I will go hybrid. Using a custom PCB and JSTs to interconnect modules. Revision and refinement, if it occurs could result in moving from the hybrid PCB to the bare metal PCB. I doubt this project will be near that stage for a few years.
It only really solves a small part of the architecture, might be more useful routing primary source clocks to the outputs more than routing I2s.
I'm approaching this from a software engineering perspective, so I'm isolating, encapsulating and presenting interfaces between components. I don't have the MCU capacity to receive 6 channels of I2S and have anything left to do anything with it. So I need a reduction from N down to 2. Using SPI as a much higher bitrate (aka trunking/TDM/Multiplexing).
A lot of the hardware is choosen because there are bare metal minimal modules purchasable. A lot of the Anamero stack for example. Or at least knock offs.
Hardware strategy is to start with modules on breadboards, 60% of the arch is tested already in small prototypes. I need to expand the protoypes to include one and then both full signal paths. From there I will go hybrid. Using a custom PCB and JSTs to interconnect modules. Revision and refinement, if it occurs could result in moving from the hybrid PCB to the bare metal PCB. I doubt this project will be near that stage for a few years.
Look I get it. If you went full out on this you'd probably just have one of those cross switches and a baller DSP. The rest would just be input/output DAC/ADC/BT/USB.
I'm avoiding that approach because I spend a few evenings browsing through DSP reference manuals and noting they are over 1000 pages most of which is I2S or SPI configuration registers. A lot even have their own despoke C libraries and flash. It's a career. I'm not going there, this time.
Also, I'm working with Must, Should, Could, Won't strategy. So initially I'm limiting a lot of things to keep it simple. There are many things that are in the Could and probably wont (this time!).
I'm avoiding that approach because I spend a few evenings browsing through DSP reference manuals and noting they are over 1000 pages most of which is I2S or SPI configuration registers. A lot even have their own despoke C libraries and flash. It's a career. I'm not going there, this time.
Also, I'm working with Must, Should, Could, Won't strategy. So initially I'm limiting a lot of things to keep it simple. There are many things that are in the Could and probably wont (this time!).
I spent a few hours looking at DSPs. ADAU1701/1452 etc. The first thing to get me excited was the Analog Devices Sigma GUI driven development environment. That's a bit of a game changer over trawling datasheets and I2C register values 'manually'.
However, trying to apply something like the ADAU1701 to my requirements, even with a basic surface scan of the docs, doesn't really solve half of them.
2 main issues with these particular DSPs are:
The 1452 for example lists 32 channels digital audio internally as a feature. However, most of those are taken up by 3 or 4 channels or ADCs, dedicated spdif channels and of course the output DAC/spdif channels, and I see it claiming 4 serial IOs which I'm assuming would include I2S. How many serial IO channels per I2S. Is it enough? If I use it's SPDIF for the optical ins, use it's internal ADCs for analogue ins, there HAS to be enough channels for additional I2S from the USB interfaces. Probably.
I haven't delved deeper yet and I'm still ploughing on ahead doing it low level in software with MCUs for now.
As to how these DSPs will take to downmixing petty much all inputs at once and sending them to potentially all outputs at once, while providing 2 channels of 5 band parametric EQ... I haven't delved far enough to find out. I expect for that the easier/smaller/consumer DSPs will not work.
Input select -> Single channel EQ -> Output Select. I have absolutely no doubt they would be perfect.
However, trying to apply something like the ADAU1701 to my requirements, even with a basic surface scan of the docs, doesn't really solve half of them.
2 main issues with these particular DSPs are:
- source select matrixes seem the default.
- the seem concentrated on the AD/DA aspects far more than the digital in, digital out aspects.
- to some people DSP means adding some crappy reverb or spatial expander rubbish to your in car audio!
- A lot are basically designed for being the AD heart of a car HiFi, providing Radio/CD/BT/USB/Aux inputs and 4/6 + sub outputs for the amp, allowing controls for F/R L/R speaker balance etc.
The 1452 for example lists 32 channels digital audio internally as a feature. However, most of those are taken up by 3 or 4 channels or ADCs, dedicated spdif channels and of course the output DAC/spdif channels, and I see it claiming 4 serial IOs which I'm assuming would include I2S. How many serial IO channels per I2S. Is it enough? If I use it's SPDIF for the optical ins, use it's internal ADCs for analogue ins, there HAS to be enough channels for additional I2S from the USB interfaces. Probably.
I haven't delved deeper yet and I'm still ploughing on ahead doing it low level in software with MCUs for now.
As to how these DSPs will take to downmixing petty much all inputs at once and sending them to potentially all outputs at once, while providing 2 channels of 5 band parametric EQ... I haven't delved far enough to find out. I expect for that the easier/smaller/consumer DSPs will not work.
Input select -> Single channel EQ -> Output Select. I have absolutely no doubt they would be perfect.