Updated 8x8 and 16x16 audio

The RevA board is working nicely, however there is an input spike at ~21kHz, the magnitude of which is directly proportional to the signal level (at least for inputs from 0.9 FSD to 0.05 FSD). There is no frequency spike on a sine wave output.

The code was compiled at 600Mhz for the T4.0 using the latest teensyduino.

The spur frequency seems to be a sideband of 1/2Fs as its frequency is 21.025kHz with a primary signal of 1kHz and 21.85kHz with a 200Hz primary. The magnitude of the spike increases with frequency, being 50dB below the fundamental at 200Hz, and 5dB greater than the fundamental at 8kHz, where the spur frequency has moved down to 14.05kHz.

Adding and removing the LRCLK series resistor doesn't change the magnitude, and the frequency isn't exactly half the sample rate, so I doubt if it's crosstalk from LRCLK.

I tried some input filtering (150 ohms/2700pF), but that didn't make any difference to the magnitude of the spur.

The artefact is there and the same magnitude with both single-ended and differential inputs.

There's no active logic else on the PCB, other than the T4.0, the TLV320AIC3104s and a single inverter for BCLK.

Any clues?
@palmerr
Looking forward to see your continued progress on this project.

Question: In the schematic you posted (Rev C (A Prod)), There are two sheets. There is an IC1 and IC2, but I do not see IC3, IC4 from the JPG image of the PCB. Am I missing something? Or does this schematic not match the JPG image of the PCB for some reason?

Rich
 
Rich,

Thanks for your interest.

Simple, there's a third sheet to the schematic!

The circuits for IC3&4 are identical to 1&2, so I didn't include page 3 for the purposes of the discussion needed at that point. It turned out that it was a code issue in the audio library - see PR 480 if you are interested.

When the project is complete, I'll open source the audio library driver code for the AIC3104 and the PCB design files (KiCAD) and gerbers on my github.

At this stage, I'm still testing a few things to make sure the boards will work reliably in 16x16 mode. Sometimes the signals on the MCLK and BCLK lines can get messy at > 10MHz and a few strategically placed resistors are likely to be necessary to stop impedance mismatches and signal reflections. Paul made a comment about this in one of his posts on the original SGTL5000 audio board.

You will note on the schematics posted that there are resistors for each IC on these two lines, as well as a common one near the Teensy. Currently the ones at each chip are shorted out and things work fine in 8x8 mode, but it remains to be seen how things will go with stacked boards.
 
Rich,

Thanks for your interest.

Simple, there's a third sheet to the schematic!

The circuits for IC3&4 are identical to 1&2, so I didn't include page 3 for the purposes of the discussion needed at that point. It turned out that it was a code issue in the audio library - see PR 480 if you are interested.

When the project is complete, I'll open source the audio library driver code for the AIC3104 and the PCB design files (KiCAD) and gerbers on my github.

At this stage, I'm still testing a few things to make sure the boards will work reliably in 16x16 mode. Sometimes the signals on the MCLK and BCLK lines can get messy at > 10MHz and a few strategically placed resistors are likely to be necessary to stop impedance mismatches and signal reflections. Paul made a comment about this in one of his posts on the original SGTL5000 audio board.

You will note on the schematics posted that there are resistors for each IC on these two lines, as well as a common one near the Teensy. Currently the ones at each chip are shorted out and things work fine in 8x8 mode, but it remains to be seen how things will go with stacked boards.
@palmerr

I understand that you are still testing a few things for 16x16 mode. But it sounds like things are stable in 8x8 mode. I was wondering if, for those of us interested in 8x8 mode, if you would consider releasing PCB design files, gerbers and source code? I for one would like to get a PCB made and assembled and do some testing.

Rich
 
Rich,

I'm between a messy board and the final prototype(s) PCBs at the moment. The main PCB is 3" x 5.25" (75 x 130mm). The big red X marks on the schematics are to tell the PCBA folks not to mount these components.

I've created some IO 'wing' boards with XLR and TRS options.

The main PCB differences are:
  • changing the way the I2C bus is multiplexed - h4yn0nnym0u5e suggested using a PCA9546 to save some Teensy pins.
  • moving the input and output capacitors to the IO 'wing' boards to make the main PCB as small as possible.
I will release all the files when things are stable. At the moment, I'm working on updating my Teensy ethernet audio library extensions to use T4.1 native ethernet, so it might be a few weeks before I get back to hardware.

I'm also thinking of ordering some PCBA boards, as the IAC3104 are VQFN-32 footprints and not really suitable for home assembly. I'll either do a Kickstarter to gauge interest or simply sell them on Tindie. Any thoughts?

tlv320aic3104 audio rev H - prod.png

Wing Board 4 XLR MK II.png

Wing Board 4 Mk II.png
 

Attachments

  • RevB 8x8 Teensy Audio.pdf
    98.3 KB · Views: 21
Last edited:
Personally, I'd have a preference for a PCBA with just the surface-mount components fitted. That gives a bit of freedom with the connectors, though in all honesty it'd be most likely to get tested and then put in the toy box for "future evaluation". I'm more likely to hook it to a 'scope than a PA. Depending on cost I'd maybe buy 3 units, unless a compelling project came up (unlikely).

Just my 2 cents...
 
@palmerr

Depending on price I would buy a few units on Tindie.

Also, I am interested in learning more about your "Teensy ethernet audio library extensions". Please share info and/or links about it.
 
RTMS,

The old github repository at ether_audio and id discussed in forum.

The discussion on the revised version is at forum. I'll be posting on the latter thread with updates.

I haven't priced the completed boards, but will post here when I have details.
 
I'm really interested in this as well. This, combined with a jumperless matrix would be very interesting for synthesizer and effect setups, especially a portable setup.

Would the teensy be able to handle audio processing duties along-side doing midi as well?
 
Also, is there any real possibility of using this and the ethernet board to create a digital snake? The network audio options for the teensy seem limited at the moment and overall network audio that is ready to use and not locked to proprietary/expensive hardware just doesn't seem to exist.
 
Yes, that's two possible uses.

Beware, however that network audio from multiple sources without PTP suffers from variable latency - I'm experiencing up to 2.9mS between sources on my test hookup (which is on a private network, so probably better than shared). As well, there are 3-6 buffer (10-20mS) delays depending on network quality, to ensure continuous audio.

Another us is to update my existing 8x8 foldback (matrix) mixer design (see the PJRC blog) - which already has remote control stations to enable them to also provide audio - like an Aviom monitoring setup.

I'm sure there are many more - which is why I'm revisiting the two porjects together.
 
Do you need PTP or full TSN support? I've been dancing around trying AVB, now that the pi 5 has a ptp eth phy, but the switch requires additional 802.* implementation beyond that. I found a PTP switch for ~$160, but getting full TSN support jumps up to $400+.

My ultimate goal is to have a single connection to a synthesizer with POE to power it and carry audio and midi (possibly even USB over ethernet). This is all theoretical but the midi 2 people have mentioned how they would like to see this kind of combo. For now I'm just going to make copper cat5 snakes to consolidate cables and try using the jumperless matrix switch to handle all of my inputs and outputs. The DC power can go over a second cat 5 and I'll have 5 cables down to 1 or 2.

This audio project could be interesting to have a self-contained mixer (and audio interface?) and midi router connected to a matrix switch.
 
I don't think PTP will help improve sound much and its a lot of extra coding to realign packets from all streams.

I've found, so far, that a 100Mb ethernet switch not carrying much other traffic and especially ***NOT*** wireless traffic (mandatory forward error correction, even on UDP) works just fine for at least 8 streams of 8 channels - at least at the network and Teensy / QNEthernet level.

I haven't started thinking about MIDI yet, even though it's well-supported by VBAN. I'll keep progress posted in the other thread
 
Note that with QNEthernet, you can call Ethernet.loop() more often than relying on yield() (which is called after every execution of the main loop) or delay() (which calls yield()) by themselves, to move the stack forward more often, should you find that it’s needed. It’s not necessarily a magic fix, however, and one should verify any improvement.
 
Thanks Shawn,

I'm still keen to remove the need for a main loop call, and also to 'defeat' delay().

I'm playing with attaching to the eventResponder at the moment, but have hit a roadblock as the object owning the callback (and its variables) isn't static. I might need to redesign the code to enable this. At the moment, the ethernetControl object is explicitly constructed in the main program, as this is the standard way to do it in Teensy Audio.
 
I dealt with this by setting the object’s EventResponder context to this during construction. The static callback then retrieves the context, casts it to a pointer to the object’s type, and calls the actual class method via that. The status and data set at trigger time can also be useful.

I’ve learned the hard way that yield() is called from way more places than @shawn mentioned, including deep within the bowels of SdFat. It caused me problems for some reasonably common use cases of file streaming, requiring a significant re-write of parts of the code.
 
This is actually a really exciting project. Some of the guitar pedals that people have built are AMAZING, and fun to play around with, but you can now buy a guitar modeler for very cheap, that even has mobile app control. But digital mixers are still pretty expensive. Someone much smarter than me could hook this up to a esp32 tft, like what Pio has done with his hexe project. This could potentially be very useful to a lot of people.
 
I have already done that https://www.pjrc.com/audiotoy-8x8-channel-audio-mixer/

There's an EPS32 in the top RH corner which commands the Teensy via a serial connection, and communicates with another ESP32 TFT touchscreen remote controller.

The controller's input screen is pictured below, and there are 8 output mix screens. Coloured dots indicate channel enable and Mic/line level input selection. (Yellow button sets the Line-level pad for Inputs and Solo for outputs). Pressing the encoder knob changes screens. It's been in production for more than a year and hasn't missed a beat (yet!).

When I'm done with the updated audio card and the ethernet transport layer, I'll probably update the controller to a Pico W (cheaper and easier to program!). If I do, I'll publish the entire project.

controller.png
 
Back
Top