Updated 8x8 and 16x16 audio

I’ll get to the full 80o32i :cool:, just need to figure out the geometry to keep the wiring as short as possible. Plus, recover a bit from that build, it was pretty fiddly.

Yes, I’m pleased the multi-TDM works as well as it does. I’d done some testing with dual CS42448 boards but this is pretty much the acid test. I should really look at inputs at some point, of course, just to check they’re OK.

I didn’t try without the buffer, I decided that rebuilding if it didn’t work (a distinct possibility) would be tedious, with a good chance of breaking something in the process.

All the TDM/SAI1 data pins are used: OUT1A, B, C and D, and IN1, so pins 7, 32, 9 and 6, and pin 8. To get the last 16o16i will need the TDM2/SAI2 pins.

I used 8 buffers for clocks: 3 each for MCLK and BCLK, and the last 2 for LRCLK. One could always get another buffered LRCLK with a 74LVC1G125 or similar. I didn’t buffer data, as those signals are “only” fanning out to 8 chips, not 32, which you’d shown to work. So for SAI1 your audio expansion connector would need to carry 9 buffered clocks and 5 data pins: on the back of the PCB you’d have jumpers to select which are use, bearing in mind 32, 9 and 6 can be outputs or inputs.

For full flexibility you’d add SAI2 (5 pins) and another I²C (because the muxes are maxed out…).

I‘d imagine good practice dictates a few ground pins near the clocks, too. Maybe a 3.3V regulator to take the load off the Teensy’s one - not sure what current’s used off that.

Looks like a minimal expansion for SAI1 only is 14 clock/data pins plus grounds. Add another 7 for SAI2+I2C2. Add another 4 so you don’t have to wire 3.3V, reset and I²C separately? So, 25 pins for the maximal option, say a 2x16 header to give you plenty of ground pins.

Jumper array has to route 3 clock, 2 data and 2 I²C pins, from 4 clock sources each (1 local+3 buffered), 7 data sources (2 output only, 2 input only, though), 4 I²C sources.
 
Thanks.

All looks doable on the main board - at least up to 32x32. 64 and beyond will need a T4.1. I might widen the new board by a few mm so that the T4.1 pin is over the PCB. Realistically, beyond 32x32 is just for fun... I can't very many people wanting to do that, particularly with only 16 bit sampling. The noise contribution off that number of channels starts to become a problem (64 channels ~ 5 bits of ENOB lost).

With the buffer, no problem with the 3.3V rail, the only extra stuff on the Teensy supply is the I2C bus mux, consuming a milliamp or so. The octal buffer will consume a similar amount. Plenty Teensy of 3.3V still in reserve.
 
You’re very likely right about use cases above 32x32 - it’s just daft poms that try that sort of thing! And maybe artists who aren’t unduly concerned with sound quality, as long as they can fill a darkened space with 80 independent sound channels…

If you route everything so much the better, as long as it doesn’t compromise the majority of use cases. If not, the truly motivated will find a way :D

Yes, pin 32 is a bit of a pain, isn’t it? Paul must have had his reasons, I guess. If you do extend the board, I’d say not beyond the end of the Teensy, because of being able to put the SD socket up to the enclosure wall.

Good news on the 3.3V.
 
Sadly the 12 pin input and output IDC cables are going to interfere with getting the SD card to the edge of the PCB. Those committed to (or for?) big numbers of channels could always put some kind of a cutaway at the top corner of the case to make SD card access easier.

I'll look at accommodating 32x32 with optional on-board components and make sure configs beyond that can be patched in by the truly obsessed without murdering the PCB too badly.
 
I've had a quick look at it. I've added buffers to MCLK and LRCLK on each board. That reduces the fan-out to acceptable levels. With the existing jumpers for DI and DO that should support the 32x32 case with pins 6, 7, 8, 9 for DI/DO patching as before. I'll have a look at what I can do to better accommodate 64x64 without adding more gates.

I haven't stretched the board at this stage so the extreme T4.1 pins will still need fly leads at this stage.

When you've had a look at multiple inputs, I'd be keen to know the optimum DI/DO pins for 32x32 mode - I'll make sure that's easy to implement.
 
Just wanted to say that this is a super cool project, thanks so much for documenting it. Found this thread while trying to troubleshoot my own 6-input, 4-output PCB comprising 3 x SGTL5000s (which seems very basic after reading this!). I'm currently building a guitar with six individual string pickups and onboard effects, so if I can't get my own board working then this looks like a great alternative. Also, for what it's worth, I can imagine a (niche) use case for 32x32: a few years ago, I built a polyphonic modular synthesizer (link) where all the patching took place place inside the Teensy audio system (basically a Teensy soft synth with a physical patch bay that sent digital signals). The synth has 4-note polyphony, which means four signals flow through each virtual patch cable. If there was a 32x32 audio board, you could have many analogue effects circuits seamlessly integrated into the synth, e.g. you could send four channels into a four analogue filters and then get the audio back into the system again digitally as a polyphonic signal. Sorry, am rambling at this point, didn't want to derail the thread, just wanted to say that this is really cool!
 
Not derailing at all - the whole reason we build the hardware and software is for people to use it in interesting ways. Good to see that there's a use case for 32x32.

BTW Polymod looks cool - right out of the 70's or 80's!

As you can see above, h4yn0nnym0u5e has proven even 64x64 works with a a little extra hardware. The next revision of the 8x8 boards will have MCLK and LRCLK buffers on each board, making 32x32 a matter of just patching DI and DO across to alternate pins on boards 3 & 4.

I did look at several alternate CODECs for this iteration, but the TLV320AIC3104 stood out for its ability to shift its active slot to anywhere in the 256 clock TDM cycle, having PGAs on the inputs that could do a fair job with mic inputs and excellent line-level specs, plus outputs that could drive headphones and professional balanced lines as well as high-impedance lines.

Making the SGTLs input and output in a different TDM slot seemed like a too-difficult problem to solve, considering Paul got stumped trying to do the same thing with the CS42448.

There's an amplified TRS output board that will drive balanced lines to +16dBm being tested at the moment, as my AudioToy matrix mixer project (link) uses CAT5 cable to drive transformer balanced foldback amps at +4dBm. Hopefully they will be available in the repo (link) and on Tindie (link) shortly.

I also have a preamp board in the pipeline that has much better noise specs for mics, has electronically switchable mic/line gain and electronically switchable phantom power. It will be a little further down the track - perhaps a month or so.

Both the amplified boards will probably be PCBA (finished boards but without the TRS jacks) as they have a bunch of tiny components.

Why no jacks? They add to the build cost significantly as they have to be hand soldered and add to the postage weight of the boards.

Anyway, thanks for joining the conversation. Keep us in touch with any thoughts of how you might use multi channel Teensy audio.
 
Congratulations to both of you—this is seriously impressive and definitely deserves a write-up in a well-known publication.

I’ve spent a lot of time thinking about what kind of channel counts actually make sense for projects like this. I usually look to how professional live audio systems are built—stage boxes, distributed routing, and networked infrastructure. The same applies to large-scale installs in airports, conference centers, and similar environments. These systems are never built around a single all-in-one box, and they’re rarely distributed in analog. Naturally, they’re not running at 16-bit either. From what I know, most professional converters run at 24-bit resolution.

So I think you're right—32x32, or maybe 64x64 if the converters and bitrate can handle it. Realistically, 32 is probably plenty for one box. Anything beyond that could be handled by an additional unit over Dante or something similar. In most cases, not all channels would be active at once—it becomes more of a muxing scenario.

One use case I’d love to see is an interactive installation with mics and speakers placed throughout a space, doing something immersive and unexpected. A system like this opens the door to a lot of creative possibilities.

Does the updated audio library support multichannel at 24-bit or 32-bit? That would make a big difference in keeping noise low while supporting higher channel counts.
 
24 bit is not formally supported, but there are a number of forks for higher bit count.

Of course you reduce the number of supported channels that will fit into a 256bit slot when you increase the bit depth!

For live sound, 16 bits isn't much of an issue, as Paul has pointed out many times. It's only when you get to multi-channel recording with post-processing that the extra bit depth really comes into its own.

And yes, almost all pro interfaces default to 24 bit. 24 bits = 150 dB dynamic range - which is substantially larger than the difference between jumbo jet exhaust and crickets! A really good audio interface may deliver 120 dB S/N - so there's already 4 bits of 'noise' in a 24 bit sample.

32 bit is like monster cable: 'special' ears may be able to discern a difference, but there is no measurable improvement on 24 bits .
 
@mattybrad that’s an awesome project! A hardware version of my soft-patchable synth, but based on Teensy 3.6. I guess the Teensy 4.x one stalled for some reason? Maybe this new board can resurrect the idea…

My updated multi-TDM doesn’t support 24- or 32-bit I/O, but it probably could with minimal tweaks. As just noted, you might have to reduce the channel count, I’m not sure if either the Teensy or TLV can cope with double the bit rate and 512-bit frames. It’s vaguely on my radar to look at @chipaudette’s F32 Audio library fork properly at some point, it’s probably the best-maintained entry point to higher-resolution audio on the Teensy. I could do it sooner if anyone expresses an interest!
 
Hmmm. I’ve just taken a look at the F32 library, and it appears that minor tweaks to AudioConvert_I16toF32 and AudioConvert_F32toI16, and another to the TLV control object, would allow 24-bit I/O.

The converters need two inputs for I16toF32, and two outputs the other way. These second ports carry the 8 LSBs of the 24-bit sample, shifted up. They could have all 16 LSBs of a 32-bit sample, but they’ll be lost on conversion to F32. These second ports’ update() code then needs suitable changes to do the conversion.

The TLV control code needs to be able to select 8x32-bit slots rather than 16x16-bit. The data will be on two TDM ports, as it already is (hence only using even-numbered ports for a CS42448, for example), and can be connected to the updated F32 I/O objects with a couple of AudioConnections.

The AudioSynthWaveformSineHires already uses this split bus technique, presumably for when Paul was initially testing TDM.
 
palmerr, as I work through my own project goals, I’m definitely learning a lot from your work—thank you for sharing it. I wanted to ask if you’ve decided on a license for the board. I’ve been wrestling with this myself; as you know, projects like this take a lot of time and effort. It’s hard to fully commit to something like MIT, but I’m on the fence about releasing my latest Gerbers to help get the project out there and keep the momentum going.

h4yn0nnym0u5e, big +1 from me on 24-bit support. My use case includes recording, and once I get the basic functionality settled, I plan to lean on the F32 library for that.

One thing I’ve been thinking about: is there anything about the Teensy’s internal clock that doesn’t align with pro audio standards? When I compared it to the TI EVM, I noticed the clocks run at different speeds. I know the codecs use ratios to derive their timing, so that could be part of it.

I also remember an old post where someone couldn’t get the Teensy to sync to an external studio clock, and that’s what ultimately led them to abandon the idea. I’m curious what it would take—hardware and software-wise—to support proper clock sync, with the Teensy as an I2S clock slave. And how would that affect the code if we were to change the master clock speed? Is this possibly why I can’t get the TAC5212 module to sync? I do know the ratio is supported, but it's close to the upper limit according to the clock configuration tables. What speed is the ultimate speed and how does it compare to what the Teensy is putting out?

All of these questions feel pretty important for getting the Teensy into more serious recording environments. I’d love to help move that forward by building and distributing modules and turn-key solutions aimed at the prosumer and pro audio space. One of my goals is to help produce a system that’s reliable enough to be used on stages and in studios around the world.
 
I'm thinking I could address >16-bit sampling in my playback and recording updates, but have been holding off until I have some idea whether there's any chance of the existing code being pulled into the official Teensyduino distro (1.60 beta has been stalled for months now - guess we know one reason, but it does get a bit frustrating).

I²S slave is already supported (though I've not tried it myself), and at one point I nearly managed to get clock recovery from S/PDIF to drive the audio system, including I²S, though I was left with a mysterious ticking sound which suggested I didn't have it quite right. I seem to recall it wasn't possible to recover a clock fast enough to drive TDM, but of course that's not quite the same as implementing TDM slave mode. As a home tinkerer I'm not familiar with the requirements of clock-synced studio gear.
 
Input testing:
IMG_2185.JPG

Yellow and green traces are generated on board 0 and board 5, received on inputs on board 0 and board 2, and output on board 0. Far from rigorous, but I'm happy the multi-TDM code is working!

Although there are 8 boards connected, 6 and 7 are non-functional in this instance, and boards 5 and 6 are output-only, so it's a 48o32i configuration.
 
@JayShoe Basically, whatever Paul's licence on his Teensy products is, that's what mine will be.

Syncing with an external clock isn't on the cards for Teensy, AFAIK. It's a whole other level of complexity, probably better to use the Teensy to generate the World Clock.

@Jonathan - well done with 48x32 and nice to see some inputs in the mix!

I'm unsurprised that 32 bit slots are needed for 24 bit operation. The TLVs can handle that quite nicely. I've added an issue to the repo to remind me to look at the code required.
 
I also remember an old post where someone couldn’t get the Teensy to sync to an external studio clock, and that’s what ultimately led them to abandon the idea. I’m curious what it would take—hardware and software-wise—to support proper clock sync, with the Teensy as an I2S clock slave.
For info, here is the “world clock” thread. I think there’s two separate issues here:
  • can TDM be made to work using an external source of MCLK/BCLK/LRCLK, and
  • can the above clocks be regenerated from a studio’s world clock
I have no answer for either of these questions at this time, and anyway they probably need their own threads if anyone works on them :)
 
I'd agree, clock sync is a whole other issue. I've subscribed to the thread you referenced, if the discussion ever picks up again.

Phase-locked loops could regenerate BCLK and MCLK from LRCLK, though getting the phase shift small enough could be an issue for MCLK.
 
Jonathan, I'm updating the commissioning notes for 32x32 mode for the next gen board with MCLK and LRCLK buffers on board:

Screenshot 2025-04-14 113008.png

Is this the correct text for 32x32 mode? I'm still not quite clear on the correct SAI1 mappings.

32x32 mode (Rev L or later ONLY)​

The DI and DO jumpers on the rear of the board should be cut on the third and fourth boards in the stack and connected: DI to Teensy GPIO6 and DO to Teensy GPIO9.

Johnathan Oakley’s Multi-TDM driver is required if more than two boards are stacked. https://github.com/h4yn0nnym0u5e/Audio/tree/feature/multi-TDM
 
I've updated the hardware repo with the full Rev K schematics. The only difference is the added BCLK/LRCLK buffers and removal of the series resistors for DI/DO (as above).

I will add the PCBA files after the initial run of boards has been tested.
 
Not quite right, though my brain is also struggling a bit because one chip’s output is another’s input … and you’ve labelled your signals from the codecs’ POV, whereas I seem to think from Teensy’s!

So, Teensy outs need to be 7+32, and ins are 8+6 … so your DI and DO need that too, and as-built you already have 7 and 8, so … DI to 32, and DO to 6. Oh, and you spelt my name wrong in the notes, too: only one ‘h’ needed :)

The pin assignments are documented in the Design Tool for the multi-I2S objects, if that helps.
 
Jonathan,

I have uploaded new code for the HPF which has corner frequencies of 0Hz (off), 10, 20 & 50Hz. It uses the programmable coefficients on Reg Page 1 instead of the default set,

The new function is
Code:
HPF(freq, chan, codec)

Thanks for the 32 x 32 pin hints - I'll go check. 8+6 are straightforward, but I'm trying to avoid T4.1 only pins. Can I use 9 (OUT1C) instead of 32 (OUT1B)? https://forum.pjrc.com/index.php?threads/how-to-change-audio-library-pins.76602/

I've fixed the name issue in both doco files. A mistype, then cut and paste!
 
I'll give HPF() a go at some point - thanks.

I don't think there's a way to avoid using 32 (which is available on a back pad of Teensy 4.0). According to the Reference Manual there's only 2 ball-out options, only one of which is brought out on T4.x:
1744616401053.png


The user could of course place an unused AudioOutputTDMB and an AudioOutputTDMC, then wire OUT1C (pin 9) to the DI pad. I think that would work, though it would waste pin 32 and maybe a bit of memory.

There's actually nothing in the Reference Manual to say SAI channels have to be enabled sequentially - it's the TCE bits in TCR4, and FCOMB bits in TCR5, plus the various pin configuration registers. But I'm a little reluctant to tinker further with the multi-TDM code, it feels like a bit of a house of cards which might come crashing down if I mess with the foundations! Getting audio streams to emerge on the correct channels reliably (I think) was not trivial.

Of course, if you want to place pads now which make it possible to use OUT1A and OUT1C, then some future and braver me might see if the software can be made to cooperate.
 
Another option is to add a pin to the Expansion header. It can be fly-leaded to 32 on the main PCB and patched where needed on slaves. It's the only extra signal now that each board has BCLK/LRCLK buffers.

The OUT1A / OUT1C patch is already available for later (and neater) use.

I can note the differences between T4.0 and T4.1 patching in the doco.

I've also decided to make 24bit/32 bit a second priority until I can find an Audio Library that can fully test it. Chipaudette's fork seems to be the one that has the highest profile, but doesn't seem to have any TDM drivers. Conversely, having the function may prompt someone to do a 32-bit INT upgrade to Paul's code.

Does multi-TDM support 24 or 32 bit transfers?
 
Back
Top