Updated 8x8 and 16x16 audio

palmerr said:
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?
Click to expand...
That all sounds great - thanks so much for your effort on this, I hope it turns out to be worth it.

The multi-TDM code doesn’t directly support larger transfers, though as noted above it could be coerced into doing it using pairs of 16-bit signals, and the lowest-impact way of doing that would be changing the inter-library conversion objects. I may take a look soon.

I’ll take another look at your fixed HPF() later today.

Oh, I meant to say before, liking the avatar!
 
Pulled in, seems to be working fine for me.

I've done a bit of work on the F32 library and put in PR #27 which adds conversion of an F32 audio stream to / from two I16 ones containing the MS and LSwords. This can be used to get 24-bit TDM I/O - only lightly tested so far, though.
 
OK, a little less efficient than doing a full 32-bit transfer, but workable enough! Might as well set 32-bit mode and be done with it.

I'll get onto the control code over Easter. It shouldn't be too hard - just a couple of changes to the code writing registers R9 & R10.

A quick look says R9 code is OK. Revised R10 code looks like:
Code: 
// TDM slot offset
void AudioControlTLV320AIC3104::writeR10(uint8_t codec)    // p51
{
        uint8_t val = (codec * 2 * _sampleLength) + AIC_FIRST_SLOT; // TDM offset in 16 bit slots, 2 per codec
        if(_i2sMode == AICMODE_TDM)
            val += AIC_TDM_OFFSET;
        writeRegister(10, val, codec);
}

I'll do some more reflecting before posting the change formally.
 
Last edited:
Less efficient for sure, but it’s a simple non-breaking change to the F32 library, and means a separate TDM_F32 doesn’t (immediately) need to be developed and maintained. If it gets pulled in and I get some encouragement to do so then it’s fairly likely I’d do the proper code at some point.
 
I've rewritten HPF to accept any cut-off frequency up to 5kHz. 0 still sets the filter off.

Verbose( ) now controls HPF( ) diagnostic printing.

Enjoy!
 
Holy moly this 2776 is small! Just want to confirm this is the correct orientation. Thanks!

IMG_2285.JPG
 
Yes, that looks correct.

BTW, I'm working on a stackable 4 channel mic-line preamp board. Very low noise, individually switchable phantom power, individually switchable -30dB pad (for pro-line inputs) and 20dB gain to bring the level up to where the CODEC PGAs have good noise specs. It uses V+, V- and should work fine on +/-5V.

The amplified TRS output board has also been validated and uploaded.

Rev L Boards are due early this week, with the new WCLK and MCLK buffers + an extended expansion header for the additional SAI pin 32.
 
Hi All,

Two updates.
  • 2-stage DAC Biquad filters added to repo - code and arguments are based on Teensy Audio filter_biquad.h
  • More boards are available on Tindie - with the WCLK and BCLK buffers + an extended expansion header for the additional SAI pin 32.
  • Main Board files updated to Rev M.
 
Almost no difference between K and M - I simply had the wrong 1.8V regulator specified on L.

L & M have the extra buffers on MCLK and WCLK and an extra pin on the Expansion header to more easily enable 32x32 mode.

All three revisions work seamlessly together in 8x8 and 16x16 modes.

The Mic preamps are on the back burner for the moment, while I work on reducing the cost. Using THAT chips make the preamp boards more expensive than the main boards. I'm working on an OPA1632 design that is much less expensive. Just paper design at the moment. Unbuilt and untested.

It's a mic-line preamp with more headroom for line inputs U2D or R29 is omitted if that's not required.
draft mic preamp.png
 
Any USB audio functions are not related to the hardware. This hardware would be compatible with any transport protocols up to 32 x 32 channels.

I'd suggest that you ask the question under a separate topic.

Another option would be to use my Ethernet Audio library and a T4.1 It will transport more than 8 channels of audio to any computer that will run the freeware VB Audio software, which makes the channels available to DAWs, etc. Ethernet Audio Library
 
Next up is 24-bit (32-bits per TDM slot) drivers that will interface with the OpenAudio library (https://github.com/chipaudette/OpenAudio_ArduinoLibrary) providing higher-quality audio.

With 16 channels of 16-bit data mixed together, the ENOB gets down to around 12 bits, and even lower if the channels are captured with some headroom, which isn't really adequate for good audio.

It will be interesting to see what the ADC noise floor actually is, as my current tests via USB show performance to the theoretical maximum for 16-bit audio.
 
The basic 8x8 tdm drivers are now working for open audio (F32 format), with some updates to the control object to handle 32 bit word lengths correctly.

I'll post the code once it's more fully tested. After that perhaps F32 multi-tdm for 16x16, h4yn0nnym0u5e?
 
palmerr said:
After that perhaps F32 multi-tdm for 16x16, h4yn0nnym0u5e?
Click to expand...
I’ll put it on my to-do list, though the F32 to dual I16 objects that I recently contributed to the F32 library will do the job for now. Obviously the TDM fixes, either mine or yours, need to be in place…
 
Do your dual I16 objects do the right thing with I32 TDM slots -> F32 audio buffers?

Most of the conversion fun for my F32drivers was sorting that out correctly.

BTW, USB out from the PC seems OK, but I'm dropping USB data sent from the Teensy. I do have Serial open but not sending any data.
Screenshot 2025-05-29 092430.png

I have some I16 audiomem assigned.
 
palmerr said:
Do your dual I16 objects do the right thing with I32 TDM slots -> F32 audio buffers?

Most of the conversion fun for my F32drivers was sorting that out correctly.
Click to expand...
I believe so, but as ever there could be bugs in areas I didn’t test.

It works on the basis of two consecutive i16 TDM object ports being interpreted as one i32 audio word by the codec, which is true for most of them, yours being the notable exception. Just having a setting in the control object which flips the codec from expecting 16x16-bit slots to 8x32-bit should be enough.

As noted, this does also require one or other of the bug-fixed TDM drivers, yours or mine, to make sure the LSW gets sent correctly.
palmerr said:
BTW, USB out from the PC seems OK, but I'm dropping USB data sent from the Teensy. I do have Serial open but not sending any data.
Screenshot 2025-05-29 092430.png

I have some I16 audiomem assigned.
Click to expand...
Ouch, that looks nasty! USB does use AudioMemory for its buffers, so as ever do make sure you have “enough”, whatever that means…

There’s been a lot of work done on improved USB audio code, see this thread. The main thrust was getting more than 2 channels, and higher sample rates, but work was needed to get proper synchronisation to the PC to prevent clicks and glitches. It may be relevant, though what you show seems way worse than the “usual” occasional sample loss. Installation is a bit tedious at the moment, but apart from one Mac user who can’t get it to work at all, it seems to be pretty good.
 
I did some more testing and USBout_F32 is dropping exactly 4 samples in every 128. (F = 172.16 = 44100/(128*2))

Internal and PC-based sample rates seem to be synchronised - Teensy-generated and PC-generated signals stay in sync over time.

The same code with USBout_I16 and doesn't have the issue: 32-bit TDM; sine_F32 -> convert F32 to I16 -> USBout_16.

That's weird, as USBout_F32 is basically AudioConvert_F32toI16 -> USBout_I16 !

1749255299418.png
 
Last edited:
I have added the new code for OpenAudioLib 32-bit samples, with some examples, to the repo.

Included is a workaround for the USB issue above.
 
You must log in or register to reply here.
Back
Top