Teensy 4.0 support for TGA Pro

[Blackaddr]

Teensy 4.0 support is now available for the TGA Pro guitar shield! A new adapter is also available to add T4.0 support to previous Teensy 3.X boards.

A little about the Teensy 4.0 from PJRC:

• runs at 600 MHz, overclocks up to 1 GHz
• has 1 megabyte of on-chip RAM
• has L1 cache! Something missing from all previous Teensies

The TGA Pro was originally designed with the feedback from the DIY Stompboxes community in 2017. What does the TGA Pro do? It provides the *everything else* needed to make a high quality, low-noise digital guitar processor.

• high quality stereo audio CODEC
• high impedance guitar preamp with gain control
• generates proper, low-noise 9V analog supplies on board using only the +5V volts from the Teensy
• onboard MIDI circuits and optional MIDI connectors
• optional onboard Neutrik TRS jacks
• optional Expansion Control board providing pots, switches and LEDs

The Teensy 4.0 comes with it's own opensource Audio library to make it very easy to use and make effects. I also have an expansion opensource library called BALibrary to make it even easier to integrate things like physical controls, external memory and MIDI.

The schematics and mechanical dimensions are also public to make it easy to integrate the TGA Pro into your own custom projects.

[ElectricDruid]

Nice work, Blackaddr. I might have to take a serious look at this. I've been wanting to get into this sort of stuff for a while, but there's always too much else to do. Therefore anything you do that lowers the bar makes it much more likely! Thanks!

Tom

[jonny.reckless]

Excellent! I just ordered one to go with my teensy 4.0, I was quite frustrated that the teensy audio shield doesn't work with 4.0, and was about to embark on a project to design an audio / control PCB using the CS4272, when I saw this. You saved me a lot of effort 

[Blackaddr]

Thanks! Making it easier for someone to get into digital audio was definitely the goal of this whole project. It's amazing how much processing power is being packed into these Teensy boards from PJRC.

[jonny.reckless]

Yes, the teensy 4.0 in particular is really powerful, 600MHz Cortex-M7 combined with CMSIS DSP library allows for a lot of signal processing in real time!

I think I could port my virtual guitar amp from raspberry pi to teensy 4.0 and get it running with super low latency 

I imagine there is some hacking of the codec driver / DMA to do in order to get 24 bit audio into and out of the Wolfson codec? It looks like input_i2s.cpp is currently hard coded to support 16 bit moves into the DMA from the audio peripheral, and control_wm8731.cpp sets the codec up for 16 bit operations, at least on the master branch? This also appears to be the case in BAAudioControlWM8731.cpp in the BALibrary? Do you have any plans to extend the BALibrary to 24 bit audio? Those Wolfson WM8731 have decent dynamic range and distortion figures that makes 24 bit worthwhile for guitar. The CS4272 is even better. One day I'd like to build a guitar effect using that codec. Class leading SNR, dynamic range and distortion, would be great for a super high gain modeling amp. At that point, you'd have to be super careful with the analog front end to get the 114dB dynamic range of the CS4272.

I had to make quite a lot of modifications to the standard teensy 3.6 libraries to use FreeRTOS and support 32 bit floating point nodes in the audio graph. I didn't want to do the audio DSP in interrupt context (zero latency convolution reverb requires multi threaded support for example) which required a lot of fairly ugly hacks which I'm not very proud of. The trick to actually getting it to work without dropouts was sync'ing the Systick timer to the audio sample rate so the FreeRTOS context switching for audio tasks was in sync with the audio buffer switching. It's all a bit clunky, I'm hoping to clean it all up one day and then maybe get it into a state where I can send a merge request, but I am not optimistic.

The teensy libs are phenomenal and beautifully designed and written. So clean and easy to understand, it's a real pleasure to work with, compared with something like ALSA which is a dog's breakfast IMHO 

I really hope Paul gets round to supporting 24 bit audio I/O and 32 bit processing natively sometime. He'd make a much cleaner job of it than I ever could. It's really valuable with high gain modeling DSP to get the extra dynamic range especially on the A/D where low level noise floor and small signal linearity are essential for guitar, where you might have 70dB of overdrive gain for a high gain lead tone. With 12dB of input headroom and a 16 bit A/D, you run out of effective bits at the low end making it sound a bit gritty, especially when you back off the volume control on the guitar to clean it up a bit, you might be running into the A/D at -50dBFS to begin with, so every ounce of noise and distortion performance you can squeeze out of the front end is valuable.

All the recent high performing teensy boards have hardware floating point support, and writing audio DSP is so much easier in floating point. I know you lose the "two for one" benefit you get with CMSIS DSP in 16 bit fixed point, but at 600MHz you don't need to worry about doing 2 MACs in parallel per clock cycle (or two) anyway.

[Blackaddr]

1) First off, let's talk about bits:

24-bit (or greater) is only needed for "processing" audio (i.e. doing math on it) not for "transporting" audio or listening to it. This is because humans ability to distinguish sounds falls off rapidly below -80 dB. 16-bit audio provides a dynamic range of about 96 dB.

For example, even when using the CMSIS IIR filtering functions for audio, the function inputs and outputs are 16-bit, but the internal resolution can be selected as 32-bit or even 64-bit due to the resolution required in the coefficients. But the input and output only need to be 16-bit.

So, humans can't really hear beyond 16-bits, so keeping extra bits at the very end of the chain doesn't help because the listener can't hear them. BUT...not having enough resolution while doing math on the audio will accumulator rounding error that builds up after each calculation resulting in errors the listen CAN hear.

This is why 24-bit integers or floating point are very beneficial for doing calculations. But once you're done, you can go back to 16-bits.

Since the Teensy Audio library is a chain of audio blocks connected by AudioConnections (just like a pedal chain with patch cables), there is not a lot of benefit from keeping 24-bits between the "pedals" but using extra bits inside the pedals is often very beneficial. How many bits you use internally is up to you, the Audio Library doesn't prohibit this. It only forces the audio in and out of a given audio block to be 16-bit. For example, in my analog delay effect, the input/output is 16-bit but I use 32-bit CMSIS IIR functions to achieve the necessary precision in the filter coefficients.

So, the question is do you really need 24-bits all the way through your audio effect chain or can you convert back to 16-bit at the input and output of each Audio Processor block in your Teensy project?

2) Let's talk about SNR.

SNR is very similar to our discussion about bits. Every component you pass through adds some analog noise. These all add up together all the way down the chain, and what you hear is the sum off all those noise levels. Generally speaking, one component's noise in your chain is usually much louder than the rest, so its' the one that matters. Improving the SNR of the other components doesn't really yield any audible improvements.

The WM8731 has an SNR of 90 dB for it's ADC. That's already quieter than you can problem hear. But it's only one component in your entire system. The largest source of noise in a guitar system is the pickups themselves. Pickups are designed to pickup magnetic signals, and all the noise  and interference generated by your pickup far exceeds that of any ADC.

Most people experiencing noise in a guitar system that is louder than the guitar interference itself is because the circuit is improperly designed and noise from digital circuits is coupling into the analog signals. In other words having a codec with SNR of > 100  dB is pointless if you can't design your circuit/board to have less than -100 dB of interference between the digital and analog paths.

The reason the TGA Pro is so quiet is because I've worked very hard to make the digital system noise stay out of the analog paths. The CODEC SNR of 90dB is never going to be the worst offender in a guitar based system.

So, in summary, IMHO, there is no need for 24-bit CODECs with SNR > 100 dB in a guitar system since the entire system never gets anywhere near this. That said, guitarists fixate on things like mojo and specs and believe they hear differences when they really can't. I acknowledge this is only my opinion and this topic is as controversial as whether vinyl sounds better than good quality digital.

[jonny.reckless]

All this is true, and I agree with your points in general, except guitar amp modeling is something of a special case regarding analog front end and A/D conversion requirements. I don't want to get into a bun fight but I do have different experience. I've confirmed experimentally by quantizing the input signal of my virtual guitar amp (using a UA Apollo twin for an audio interface) from 24 bits to 20, 18, 16 and 14 bits before the signal processing chain (applying 0.5LSB or sometimes 0.3LSB of triangular dither in each case) and you can clearly hear and feel when playing a difference below 20 bits. I do appreciate that guitarists sometimes fixate on things like mojo, but some of that mojo is backed by solid science and signal processing theory.

This is a somewhat pathological case, but I like many other guitarists usually play with a high gain sound and use the volume control on the guitar to clean the tone up. An analog circuit is at its most linear with the smallest perturbations of signal about its operating point. This is the point where a digital system is at its most non linear. When you back the volume off on a guitar with a high gain signal, you're typically driving the A/D at -50dBFS, and then applying something like 70dB of gain for a high gain lead tone. With a decent 16 bit A/D your noise and distortion figure at the front end of the signal chain is about -30dB. This compares with about -50dB for a well designed valve input stage, assuming a signal level of about -60dBV, and a source impedance of 10k ohms using ECC82 as your first gain stage. That 20dB makes a difference.

At -50dBFS and 16 bit your input signal is quantized to effectively 7 bits of resolution. A properly dithered signal will be OK with respect to distortion at this level, at least for low frequencies, but the noise floor required to eliminate quantization distortion raises the level of hiss in the signal considerably, even with some form of noise shaping or oversampling. To get rid of the hiss requires you to under dither, and this in turn creates a gritty sound due to the presence of quantization distortion which smears low level detail and sounds harsh, at least to my ears. There's a reason Kemper, Fractal and Helix use 24 bit conversion at the front end. This is not a subjective "snake oil" thing, you can measure it on a bench with an AP.

Manufacturers make 24 bit converters for audio because 16 bit is insufficient for many professional audio applications, especially when you need lots of working headroom. In practice you can't really get better than about 20 bits of actual dynamic range at room temperature with typical signal level and impedance, but this is a lot better than 16 bits. Treat the least significant 4 bits of a 24 bit sample as a fruit machine - built in dither.

I agree that 16 bit is fine for playback, transport, the majority of effects processing inputs and outputs, and D/A conversion at the end of the signal chain. 16 bit is also OK for light non-linear applications such as compression with modest gain reduction provided you are careful with internal dynamic range. I also agree you need longer word lengths for coefficients of digital filters with poles (or zeros) close to the unit circle, even when factoring high order polynomials into second order sections to reduce numerical sensitivity.

For certain applications 24 bit input is really valuable. Like I said I don't want to get into a flame war.  The teensy audio library runs at 16 bit because for the purpose it was designed 16 bit is sufficient, and Paul used a cheap 16 bit audio codec, which again is fine for the purpose it was intended. It is however not ideal for high gain non-linear applications, and those are the bread and butter of guitar effects.

I run my audio graph using 32 bit floating point. It makes the DSP a lot easier and provides great internal dynamic range. It also avoids the overhead of converting to and from 16 bits (and correctly dithering) at every node, which adds up to a lot of CPU overhead and added noise. One conversion from 24 bit to float at the beginning of the pipeline, and one conversion from float to 16 bit (with dither) at the end of the pipeline. Dither is surprisingly important even with 16 bit audio paths. You shouldn't really care about quantization distortion that is at -90dB, but in real life, with headroom and multiple cascaded processing blocks, distortion can become a problem if you don't care about dithering at appropriate stages in the signal path. A lot of early commercial products ignored dither and gained a reputation for sounding somewhat harsh, gritty or cold as a result. Quantization distortion is not as objectionable as aliasing, but it never sounds "sweet" like valve overdrive. Some people love that low-fi bit-crushed effect. I'm not one of them.

The reason the TGA Pro is so quiet is because I've worked very hard to make the digital system noise stay out of the analog paths. The CODEC SNR of 90dB is never going to be the worst offender in a guitar based system.

I'm curious what the loopback THD+N performance of the TGA Pro is? D -> A -> D say at -1dBFS 1kHz and -40dBFS 1kHz. Looking at the schematic I do have some simple suggestions on how we might improve the analog front end performance, I'd be happy to collaborate with you on this if you're interested.

[Blackaddr]

Totally respect your perspective Jonny, so let's see what we can do to get you what you want. 

1) the WM8731 codec on the TGA Pro does support up to 96 KHz with true 24 bit samples. So the hardware can do what you need. It's trivial to modify BAAudioControlWM8731.cpp to set the I2S interface on the codec to use this mode.

2) The Teensy Audio library is built for 16-bit only. BUT....Chip Audette already ported the Teensy Audio Library to use floating 32-bit as the interface for the T3.6 a couple years ago as he also found 16-bit not good enough for his application. You can find his work here.

So while the AudioConnection and AudioStream classes are redesigned for f32, if you look at Chip's new version of output_i2s and input_i2s, he has re-written them to use 32-bit integers as the CODEC interface instead of 16. The WM8731 also supports 32-bit integer word size that contains 24 true bits of audio with the last 8 bits zero'd so this should work on the TGA Pro codec as well.

Hopefully Chip's work will get you a huge jumpstart on your 24-bit processing.

[jonny.reckless]

Thanks very much, that's great. It looks like Chip has also saved me quite a bit of work.
Jonny

[jonny.reckless]

Got my TGA board, looks great, I've got audio loopback working so hardware is good, thanks!

[Blackaddr]

Awesome! Once you get making progress on your project consider starting a thread to show it off.  Pictures, video/audio or other ear/eye candy would be great.