Variable delay triggering T3.2 audio output by T3.6 controller

[randomrichard]

I am using a Teensy 3.6 to control a Teensy 3.2 which outputs a WAV file periodically. The picture shows the trigger pulse 0.5msec wide sent by the T3.6, and the beginning of the WAV file output from the T3.2. I am surprised that there is a 5msec delay, and a variation of about 1.5msec on that delay. Both T's operate at 48MHz optimised. The software is that on the T3.2. Is there any way to reduce the delay, and its variation?
View attachment TCT.ino

 

[manitou]

others have observed the 6ms delay https://forum.pjrc.com/threads/4218...Through-Signal?p=137941&viewfull=1#post137941
I measured 6 ms delay with the following simple sketch

// measure codec delay
//  PWM on pin 21 to line-in
//  analyzer to pin 21, line-out and trigger on pin 1
#include <Audio.h>

// Audio Objects
AudioControlSGTL5000     audioShield;
AudioInputI2S            i2s1;
AudioOutputI2S           i2s2;
AudioConnection          Connect1(i2s1, 0, i2s2, 0);
AudioConnection          Connect2(i2s1, 1, i2s2, 1);

void setup()
{
  analogWriteFrequency(21, 1024);
  analogWrite(21, 128);
  pinMode(1, OUTPUT);
  AudioMemory(25);          // Way below this

  delay(100);
  AudioNoInterrupts();      // Use to synchronize all audio
  // Enable the SGTL5000 audio CODEC
  audioShield.enable();
  audioShield.lineInLevel(0);     // was 2 2.2 V p-p max
  audioShield.lineOutLevel(13);      // was 19 2.2 V p-p FS
  AudioInterrupts();
}

void loop()
{
  digitalWriteFast(1, HIGH);  // trigger duty cycle change
  analogWrite(21, 192);
  delay(100);
  digitalWriteFast(1, LOW);
  analogWrite(21, 64);
  delay(100);

}

first line is pin 1 trigger when duty is changed
2nd line is pin 21 PWM output
3rd line is line-out

 

[FRS]

Tips for improved latency... Try lowering the BLOCKSIZE from 128 to something more like 16 (that seems to be the best value that still allows things to work properly.

If you are using the playflashraw library, think about editing that software to read out the start and length of each sample, hard code those values in code/lookup table. Having to access the EEPROM chip serially to find this information by search for sample name, then transmitting it back to code takes entirely too long as it is.

I was able to make edits to code as described and got latency down to about 1mS.