Quad channel output on Teensy 3.6

[PaulStoffregen]

I got TDM output working! Here's a first commit.

https://github.com/PaulStoffregen/Audio/commit/1c9a3030223068c6dd8bfba44d6879dbbd918555

It implements 16 outputs, each 16 bits. For use with CS42448, the even numbered outputs end up as the 16 most significant bits and the odd outputs end up as the 16 least significant bits for each of its 8 channels.

Theoretically, we could have 16 separate outputs, if some combination of chips in TDM most each listed to the right 16 of the 256 bit output frame.

Here's a scope screenshot of the TDM waveforms:



In this test, I had the same signal (from the Guitar synth example) connected to outputs 2 and 6.

 

[PaulStoffregen]

As usual, this first version is running with a non-optimized memory copy.

// TODO: needs optimization...
static void memcpy_tdm(uint32_t *dest, const uint32_t *src1, const uint32_t *src2)
{
        uint32_t i, in1, in2, out1, out2;

        for (i=0; i < AUDIO_BLOCK_SAMPLES/2; i++) {
                in1 = *src1++;
                in2 = *src2++;
                out1 = (in1 << 16) | (in2 & 0xFFFF);
                out2 = (in1 & 0xFFFF0000) | (in2 >> 16);
                *dest = out1;
                *(dest + 8) = out2;
                dest += 16;
        }
}

Looks like running 8 of these memory copies is taking 77 us in the high priority DMA interrupt. Not wonderful, but ok for now. Hopefully this part will get optimized someday.

 

[PaulStoffregen]

@Frank - Another CS42448 board is scheduled to be built tomorrow by Erin (aka The Soldering Goddess, who soldered the one you see in msg #25). If all goes well, Robin will send that CS42448 board and your other stuff later this week. We were talking about trying DHL this time....

 

[PaulStoffregen]

I've added code for TDM input.

https://github.com/PaulStoffregen/Audio/commit/7673a0dbdf99429cd4c8e129f1d6d9840480f36e

The AudioInputTDM brings in 16 channels, so all 256 bits of the TDM frame are available. For use with CS42448, the useful data appears as inputs 0, 2, 4, 6, 8 & 10.

I also looked briefly at a datasheet for one of the TI chips which supports TDM. Looks like they expect the frame sync pulse during the first MSB, rather than the cycle before. If anyone ever bothers to build up a board with more than 2 stereo TI chips, maybe the TDM code will need an option to generate the FS pulse 1 cycle later?

 

[Frank B]

@Frank - Another CS42448 board is scheduled to be built tomorrow by Erin (aka The Soldering Goddess, who soldered the one you see in msg #25). If all goes well, Robin will send that CS42448 board and your other stuff later this week. We were talking about trying DHL this time....

Thank you, no hurry.
I'll look if I can optimize the memcpy... everything else is already done
Great work.

 

[PaulStoffregen]

I've published the PCB on OSH Park.

https://oshpark.com/shared_projects/2Yj6rFaW

Edit: and also pretty much all the same material on hackday.io

https://hackaday.io/project/2984-te...g/57537-tdm-support-for-many-channel-audio-io

 

[alonper]

Hi, I have a question regarding the sparkfun guide for the quad channel (input in my case) with Teensy3.2
https://www.sparkfun.com/news/2055
what is the meaning of "cut apart"?

The pairs of pads near pins 13 and 22 need to be cut apart. The trace between the center and left pads of the I2C address selector also need to be cut.

I've done all written in this guide (except cutting apart - I haven't seen this while reading in the first time) and then the Teensy was got into short and got hot, the PC didn't recognized it, so I removed the audio boards and now the teensy is ok - while connecting 1 audio adapter (the main one - only with 0.1u cap removed) the teensy react but the audio board is not working...
I have just read the article again and found the "cutting apart" thing. I am afraid that I blow the 2 audio adapters..
So what the meaning of "cut apart"? how should I do that?

Thanks in advance

 

[Frank B]

As the heading says, there is a small trace between the big pads - remove it with a knife

 

[alonper]

As the heading says, there is a small trace between the big pads - remove it with a knife

OK thanks.
Does it make sense that the audio adapters were blown because not cut those traces?

 

[PaulStoffregen]

Does it make sense that the audio adapters were blown because not cut those traces?

It's possible. Both may have tried to transmit on pin 13.

But I'd suspect some other unknown error was made. While shorting those signals together isn't good, it usually doesn't destroy the chip.

 

[alonper]

It's possible. Both may have tried to transmit on pin 13.

But I'd suspect some other unknown error was made. While shorting those signals together isn't good, it usually doesn't destroy the chip.

I removed all the new wiring. The Teensy 3.2 is now connected to the "Main" audio board, (the one that got 0.1u cap removing. near leg 15)
I have tried to upload a few examples to test the board.
USBpassThrough -> while streaming audio to the teensy audio device no output from the 3.5mm jack.
I tried also this code :

#include <Audio.h>
#include <Wire.h>
#include <SPI.h>
#include <SD.h>
#include <SerialFlash.h>

AudioInputUSB            usb1;           //xy=200,69  (must set Tools > USB Type to Audio)
AudioOutputUSB           usb2;           //xy=365,94
AudioConnection          patchCord1(usb1, 0, usb2, 0);
AudioConnection          patchCord2(usb1, 1, usb2, 1);
AudioControlSGTL5000     sgtl5000_1;     //xy=302,184

void setup() {                
  AudioMemory(12);
  sgtl5000_1.enable();
  sgtl5000_1.volume(0.8);
}

void loop() {
}

Audio streamed to the Teensy Audio Playback device --> no audio coming back from the Teensy Audio Recording device.
It worked before the twicking..
I Just ordered a new audio cards.. hope to find out that the problem is not the Teensy3.2..

Thanks

 

[PaulStoffregen]

I tried also this code :

That program can not work. It doesn't have any normal input or output objects with "update responsibility". Add at least 1 instance of any other input or output.

This quirk of the USB input & output is documented in the design tool.

https://www.pjrc.com/teensy/gui/?info=AudioInputUSB
https://www.pjrc.com/teensy/gui/?info=AudioOutputUSB

Look at the "Notes" section of the right-panel documentation.

 

[alonper]

That program can not work. It doesn't have any normal input or output objects with "update responsibility". Add at least 1 instance of any other input or output.

This quirk of the USB input & output is documented in the design tool.

https://www.pjrc.com/teensy/gui/?info=AudioInputUSB
https://www.pjrc.com/teensy/gui/?info=AudioOutputUSB

Look at the "Notes" section of the right-panel documentation.

Ohh I will look.
Thanks!

by the way the USBpassThrough also didnt worked..

 

[PaulStoffregen]

To test your hardware, the synthesis examples like Guitar are best. They just send output to the headphone, regardless of settings on your PC. Those examples don't depend on a properly formatted & readable SD card. They don't rely on drivers or audio config settings on your computer, as the USB stuff does.

Check your hardware first using the simple examples that don't depend on your computer to participate in creating the sound.

USBpassThrough may be failing because your hardware is destroyed, or it might be simply a sound setting on your computer preventing audio from being sent to Teensy.

 

[Frank B]

@Paul, I got the CS42448 board, thank you. Wow, the Soldering-Godess did a good job! I'd like to adopt her
All these in- and outputs look pretty amazing.
Are there any things left to do (besides the memcpy) ?
Tomorrow, I do some testing..

 

[PaulStoffregen]

Tomorrow, I do some testing..

Yes! I should admit, I spent very little time testing, especially the inputs.

 

[dreggory]

Paul, is there any chance that the TDM input code you wrote would work for the ics-52000 microphones from invensense? see my post at https://forum.pjrc.com/threads/4289...-using-mics-from-invensense?highlight=i2s+tdm

 

[macaba]

Hi Paul,

This is fantastic work.
I'd like to design an application-specific audio mixer (for use in flight simulators, using an ethernet port for control), this looks to be exactly what I need.
I've ordered your shared PCB from OSH Park (thank you) to experiment with, hopefully it won't be too difficult to solder up.

Just a few questions:

1. I'm wanting to minimize the input to output latency. If I edit the block size to less than 128, will AudioInputTDM & AudioOutputTDM continue to work?
(Less than 3ms is desirable mainly because it'll be a vocal usage situation - people wearing headsets listening to their own & other voices.)
(I personally won't be able to tell the difference but other people are more sensitive to latency!)

2. In your notes, you state: "AudioMemory should be at least 16" - does this mean the default setup has a 46.4ms latency? (2.9ms * 16)

3. Most of my audio objects will be mixers - does running mixer objects on Teensy 3.6 automatically make use of the hardware floating point for lower CPU usage?

-Mark

 

[PaulStoffregen]

1. ... If I edit the block size to less than 128, will AudioInputTDM & AudioOutputTDM continue to work?

They haven't been tested at any other block size, but it should work.

If you find a case that doesn't work, please remember to post complete code to reproduce the problem (aka "Forum Rule").

2. In your notes, you state: "AudioMemory should be at least 16" - does this mean the default setup has a 46.4ms latency? (2.9ms * 16)

No, not at all related to latency. It means the input won't function unless there's at least 16 blocks free. It receives 16 channels in parallel, you know.

3. Most of my audio objects will be mixers - does running mixer objects on Teensy 3.6 automatically make use of the hardware floating point for lower CPU usage?

No. The faster Cortex M4 DSP extensions are always used. The FPU makes 32 bit float almost as fast as regular integers. But the DSP extensions speed up a very limited class of integer operations. The audio lib uses integers, which are still slightly faster, and are significantly faster than floats in those special cases.

 

[macaba]

please remember to post complete code to reproduce the problem (aka "Forum Rule").

Of course.

It receives 16 channels in parallel, you know.

This now seems entirely obvious. Consider me ashamed!

But the DSP extensions speed up a very limited class of integer operations.

Interesting, I'll have to read the documentation on that out of curiosity.

I'm just designing my signal chain in the Audio System Design Tool. (There are going to be 144 mixer objects!) There's this snippet from the 'Notes' for the Mixer object:

"level" may be any floating point number from 0 to 32767. 1.0 passes the signal through directly. Level of 0 shuts the channel off completely. Between 0 to 1.0 attenuates the signal, and above 1.0 amplifies it.

Is '32767' an error here, or can I really do a digital gain of 32767? (Not that I'd want to do such a high digital gain for fidelity reasons of course)

 

[PaulStoffregen]

can I really do a digital gain of 32767? (Not that I'd want to do such a high digital gain for fidelity reasons of course)

Numerically speaking, yes you can. Of course that's pretty useless since any signal more than 0 goes right to the clipping limit.

Likewise, there are many floating point numbers you could use very close to zero which actually round down to zero due to numerical precision of the 32 bit integers used within the mixer object.

 

[macaba]

Is there any audio library developer documentation out there?
I'm making a 'AudioMixerCrosspoint16' object that will mix 16 input signals to 16 output buses. I've used AudioMixer4 as my template but that only deals with 1 output stream so I'm unsure how to add more output streams.

Edit:
My first pass is here:
https://github.com/macaba/Audio/blob/master/mixer_crosspoint_16.h
https://github.com/macaba/Audio/blob/master/mixer_crosspoint_16.cpp

 

[PaulStoffregen]

This:

https://www.pjrc.com/teensy/td_libs_AudioNewObjects.html

 

[macaba]

Thank you Paul, I got it working and added it to the Audio System Design Tool too (on my fork).

Brief testing shows it works, I'll be able to do further testing once I've got a TDM board.

It means I was able to simplify a design with 80(!) 4-channel mixer objects to this:


Edit: Spoke too soon. More testing required here.

 

[PaulStoffregen]

If you're just adding signals with sketch-controlled gain levels, there's probably little to be improved beyond simply using lots of 4 channel mixers. Well, other than the aesthetics of your source code and the fun & challenge of digging into the internals of the library.