Several Teensy 4.0 on TDM bus

Status
Not open for further replies.
6

6Resh6

Member
Hello everyone!

I'm building prototype of extendable sound system with one TDM Master Teensy 4.0 reading files from SD card and routing them to different Slave nodes (in the future it will be the ADAU1701, but now I have only several Teensy 4.0 and want to start testing)

I've looked through several topics here about Teensy TDM slave mode but still have no solution...
I also found this doc https://www.creative-technologies.de/wp-content/uploads/2018/01/Open-Source-Audio-Platform-for-Embedded-Systems.pdf
but it's for teensy 3.x...
May be someone can help me to transform it for teensy 4.0?
 
6Resh6 said:
May be someone can help me to transform it for teensy 4.0?
Click to expand...

If nobody does this for you, you might need to dive into the code and do it yourself.

Fortunately, the SAI hardware is nearly identical between Teensy 3 & 4. The main difference is the clock source. But in slave mode you only need the clock from inside the chip to be high enough so the SAI hardware is able to recognize the external clock. I don't recall the specific minimum ratio (it's in the ref manual) but it's something like the peripheral clock need to be at least 4X or 6X the external bit clock, since it samples that incoming clock. The very nature of slave mode is the external system controls the audio clock, so you don't have to get the internal clock perfect, only fast enough.

Probably the best way to start would be reading the TDM master mode code from Teensy 3 and 4 side-by-side. Maybe open 2 copies of the file and delete all the Teensy 3 stuff from one file and all the Teensy 4 stuff from the other.
 
Paul thanks a lot for your advice, I'll try it later. For now simply got i2s and i2s slave modes files of Audio library side-by-side, compared them and compared also i2s to TDM files, so found out that the main differences are the config functions of all 3 modes. I'll also compare those files with documentation that I've mentioned before, so hope to get some results by blind tests... :D

My new problem is that even if I'll make work TDM connection between to Teensy, I have no chance to play it out by i2s2 or any DAC, am I right? :confused: :(
 
Slave mode means the external device is in control of the audio sample rate.

Today we have only 1 slave mode input which resamples data to Teensy's clock, for SPDIF. In some distant but glorious future (where there are way more programming hours in every day) I hope to have all slave mode interfaces offered in the normal way and in a resampling version. Future chips will have dedicated resampling hardware....

Without resampling, if you try to use slave mode together with master mode, or 2 slave mode interfaces, you'll get dropouts or glitches because each tries to use a slightly different sample rate. Maybe that's ok if you only want it for testing?

If you've been reading the code, you've probably seen the update responsibility stuff. Only 1 hardware input or output gets update responsibility. It is the one which causes the entire library to run. All others only just happen to work smoothly because they use a sample rate which is perfectly in sync with the one that has update responsibility.
 
> dropouts or glitches because each tries to use a slightly different sample rate

I have had good results with matching the teensy audio clock to an external clock source. That source can be audio input.
 
PaulStoffregen said:
Without resampling, if you try to use slave mode together with master mode, or 2 slave mode interfaces, you'll get dropouts or glitches because each tries to use a slightly different sample rate. Maybe that's ok if you only want it for testing?
Click to expand...

I hope it will be more than enough for testing before I'll get the ADAUs, I Only need to check if it's possible to send 32 channels from two of Teensy Master TDMs simultaneously to Teensy Slave that using only one TDM slave mode (I will change connection of slave between Masters TDM1 and TDM2 physically, in the future it will be solved by multiplexer/demultiplexer connected to ADAUs TDM)
 
jonr said:
> dropouts or glitches because each tries to use a slightly different sample rate

I have had good results with matching the teensy audio clock to an external clock source. That source can be audio input.
Click to expand...

Could you please share you solution?
 
Status
Not open for further replies.
Back
Top