What is the current state of Audio Library support for the Teensy 4.0?

[chipaudette]

The reference manual for the processor is not helpful...because the missing piece of information is which Teensy pins (which I2S lines) are used by the I2S_quad class. That's the part I can't figure out. That's a question that is entirely within the Teensy universe.

It is *so* awesome that someone (Paul?) Did all the hard and thankless labor to get it to work! Bit which I2S pins did they end up using?

Thanks!

Chip

[KurtE]

Sorry, I am not much of an Audio guy.

But a couple of quick searches in source files may give you your answers.
Example I did a global search in sublime text for i2s_quad

And with that found the file input_i2s_quad.cpp

void AudioInputI2SQuad::begin(void)
{
	...
#elif defined(__IMXRT1062__)
	const int pinoffset = 0; // TODO: make this configurable...
	AudioOutputI2S::config_i2s();
	I2S1_RCR3 = I2S_RCR3_RCE_2CH << pinoffset;
	switch (pinoffset) {
	  case 0:
		CORE_PIN8_CONFIG = 3;
		CORE_PIN6_CONFIG = 3;
		IOMUXC_SAI1_RX_DATA0_SELECT_INPUT = 2; // GPIO_B1_00_ALT3, pg 873
		IOMUXC_SAI1_RX_DATA1_SELECT_INPUT = 1; // GPIO_B0_10_ALT3, pg 873
		break;
	  case 1:
...

So looks like pins 6 and 8 are of interest.

And in the output_i2s_quad.cpp I see

void AudioOutputI2SQuad::begin(void)
{
...
#elif defined(__IMXRT1062__)
	const int pinoffset = 0; // TODO: make this configurable...
	memset(i2s_tx_buffer, 0, sizeof(i2s_tx_buffer));
	AudioOutputI2S::config_i2s();
	I2S1_TCR3 = I2S_TCR3_TCE_2CH << pinoffset;
	switch (pinoffset) {
	  case 0:
		CORE_PIN7_CONFIG  = 3;
		CORE_PIN32_CONFIG = 3;
		break;
	  case 1:
...

Looks like pins 7 and 32 might be of interest...

But again I am only guessing.

[Rick Muething]

Paul,
Having an issue with a fairly large project (HF/VHF Ionospheric Simulator ~ 2300 lines on a Teensy 4.0) Am using 32 Audio "components" including in and out ports but if I try to add an audio component (I need a couple more) the following happens:
1) Compiles OK and attempts load.
2) My startup splash screen activates but then hangs...no other functions work. If I remove the added "component" all is OK.
3) Not running low on Memory about 7 % program storage and 36 % dynamic memory. Have 100 audio blocks allocated max is something like 30.
The good news is almost everything is working and the audio components have worked well and the simulator is useful and performs well...its just a couple of "bells and whistles" I wanted to add.
Any help or pointers would be appreciated. Tom Lafleur is helping me on this project....he did all the PCB layouts etc.
Thanks....keep up the great work...I just ordered a Teensy 4.1!
Rick Muething rmuething@cfl.rr.com

[colinza]

Does anyone know what the status is for dual audio shields with the Teensy 4.0, has anyone tried it yet? Wanted to make a carrier board to connect a teensy and two audio shields without stacking. The audio app seems to suggest the 4.0 supports dual audio shields but the wiring instructions linked to Sparkfun are still for the 3.2.

[PaulStoffregen]

has anyone tried it yet?

Yes, it's works. Here you can see a test I ran shortly after it was first supported. I created 4 waveforms using PWM and resistor-capacitor filters. The 4 waveforms go into the inputs of both shields, and a program routes the digital data to the 4 outputs (crossing from 1 board to the other), and I checked all 4 shield outputs have the signals the PWM created.

Plenty of photos, so you can see for sure it works and exactly how it was wired.

https://forum.pjrc.com/threads/61123...l=1#post242054

PaulS also checked in on that thread using just digital signal loopback.

You can see a followup in msg #22 on that thread, where the problem initially reported turned out to be a wiring error. That's a 3rd confirmation it definitely is working!

The data pins from the 2nd audio shield need to connect to pins 6 and 32. If you're using Teensy 4.0 that means running a wire to one of the surface mount pads on the bottom side, since that's the only way to access pin 32 on the smaller Teensy 4.0 board.

[colinza]

Fantastic, thanks so much Paul!

[colinza]

If you're using Teensy 4.0 that means running a wire to one of the surface mount pads on the bottom side, since that's the only way to access pin 32 on the smaller Teensy 4.0 board.

Time to order some pogo pins!

[J_Sanders]

I noticed that slave mode on I2S2 is commented out in output_I2S2.cpp:
// void AudioOutputI2S2slave::begin(void)

Is there a known reason why it won't be able to work in a future update? Or is it possibly working and not fully tested?

Thanks!
-J

[PaulStoffregen]

Is there a known reason why it won't be able to work in a future update?

I2S slave mode causes the entire audio library to run at the sample rate dictated by the incoming LRCLK signal. Hopefully the fundamental reason why 2 ports running in slave mode can't work is apparent.

Someday (maybe when we get a chip with the ASRC peripheral) I hope to add I2S slave mode which resamples to Teensy's internal audio clock. But so many other things in the audio library and non-audio software in general are much higher priority, so that's unlikely to be implemented anytime soon.

[MarkT]

Surely you can have a setup with one ADC or DAC as master, and everything else as slave, including Teensy? The clocks are
routed from the master to everything, which should mean the Teensy can run as slave for input and output?

[J_Sanders]

Thanks Paul!

I had in mind to use I2S2 by itself, to get around this issue - but I ran an SD test this morning using I2S2 (with some comical prototyping wire remapping) and got the same result.

[MarkT]

The reference manual for the processor is not helpful...because the missing piece of information is which Teensy pins (which I2S lines) are used by the I2S_quad class. That's the part I can't figure out. That's a question that is entirely within the Teensy universe.

It is *so* awesome that someone (Paul?) Did all the hard and thankless labor to get it to work! Bit which I2S pins did they end up using?

Thanks!

Chip

Fig 37.2 in the processor manual shows that the way I2S data inputs and outputs are multiplexed in SAI1
is:

function      T4 name  T4 pin no
      RX0     IN1      8
TX3 / RX1     OUT1D    6
TX2 / RX2     OUT1C    9  
TX1 / RX3     OUT1B    32
TX0           OUT1A    7

[ other alternate actual pins can be assigned to these functions, but most of the others aren't pinned out in
the T4, so these are basically fixed allocations ]

The SAI1 unit can be configured to read from consecutive inputs only, thus for two
input pins (= 2 x stereo = quad), the choices are 8/6, 6/9, 9/32.
The Teensy names for the pins only reflects the output function except for IN1

This matches the code in the audio library.

You should be able to guess that the corresponding pins possibilities for quad output
are 7/32, 32/9 and 9/6, which indeed they are.

[ reading chapters 37--40 three times in a row will answer most questions about the details of audio
units, the first pass as a skim-read to familiarize, the second to assimilate the main functions and the third to
reinforce - that's how I get familiar with a complex datasheet in practice I find ]

[PaulStoffregen]

Which Teensy pins each configuration of input & output uses are also documented in the design tool right-side panel.

[alex6679]

Someday (maybe when we get a chip with the ASRC peripheral) I hope to add I2S slave mode which resamples to Teensy's internal audio clock. But so many other things in the audio library and non-audio software in general are much higher priority, so that's unlikely to be implemented anytime soon.

I implemented an I2S slave input class that works very similar to the AsyncAudioInputSPDIF3. It's more or less a copy of AsyncAudioInputSPDIF3 input at which all spdif specific code (setting the registers and the setup of the dma trasnfer) is replaced with the i2s configuration and the input frequency is not read from SPDIF_SRFM but computed from the duration between i2s irs calls. I think it would not be a nice solution to make a separat asychnron input variant of all i2s inputs. But it's probably possible to implement a single async input block, that resamples the data of an arbitrary i2s input. I could implement a suggestion for an interface, if you think it makes sense to implement such a class for the audio library.