"Glitches" I2S Teensy 4.0 > DAC (flat wave)

[domingo]

Hi All,

I've been dealing with this problem in the last 3 days. Teensy 4 connected to a DIY DAC based on TDA1387. Only BCKL, LRCLK and DOUT connected, no MCLCK is needed by it.

When listening, a very annoying "click" is heard every 10sec. aprox. out of the DAC. Sometimes it can play for a minute without problem, sometimes it "glitches" every after a few seconds, quite randomly.

I sampled the problem with a recorder and the glitches are actually very little sections that remain unsampled, showed as short flat horizontal lines within the zoomed waveform, as it can be seen in the picture.

Anyone can help me diagnose this problem? I2S cables are very short, around half cm. for LRCLK and BCKL, 1.5cm. max. for DOUT. I'm using single unshielded CAT5 cables for each connection so that might be a problem, even though they are so short. I tried using 100-330ohm resistors across each path and the problem was still there; same symptom in the breadboard with long cables as well.

Strange enough with the Teensy 3.6 this doesn't happen. If cables are the problem, which one (of the three) can most likely cause this effect? Or could it also be my USB connection? (sound source is a laptop doing USB pass-through).


Many thanks in advance.
Domingo

[MarkT]

Forum rule? This is a software problem I think, the dropout is one audio block I suspect, ie 2.9ms, although
your 'scope shots omit timebase info so that's a guess.

[PaulStoffregen]

Agreed, would be much better if those pictures included the time base.

It does look like a data underrun condition. If the source is USB, then the next major question is which operating system and software is transmitting that USB audio stream?

[domingo]

Thank you for answering MarkT!

I'm sorry for omitting the code. Here it goes, actually very simple but I also suspect a software problem.

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

// GUItool: begin automatically generated code
AudioInputUSB            usb1;           //xy=120,168
AudioMixer4              mixer2;         //xy=342,245
AudioMixer4              mixer1;         //xy=350,136
AudioOutputI2S           i2s1;           //xy=546,191
AudioConnection          patchCord1(usb1, 0, mixer1, 1);
AudioConnection          patchCord2(usb1, 1, mixer2, 2);
AudioConnection          patchCord3(mixer2, 0, i2s1, 1);
AudioConnection          patchCord4(mixer1, 0, i2s1, 0);
// GUItool: end automatically generated code

void setup() {
  AudioMemory(12);
  }

void loop() {

Here a picture with samples in the timeline. I can roughly count from sample 988815 to 988953 more or less (138 in total). Another glitch goes from sample 3036146 to 3036284, also 138 in total. The number is consistent but difficult to count exactly since a peak forms at the beginning of each glitch.

[domingo]

Hi Paul! Thanks for your interest.

Operating system is OSX (10.14). Software transmitting is OSX audio engine as well. Strange enough with T3.6 there's no problem, but I can make tests with other software engines (ie. Ardour or Audition) or simply Windows and report again.

[PaulStoffregen]

I can roughly count from sample 988815 to 988953 more or less (138 in total).

We need to know the sample rate to turn a number like 138 into actual time. But I'm going to guess 48 kHz which gives 2.9ms, which Teensy's time for 128 samples at 44.1 kHz.

Sure looks like an underrun condition because Teensy didn't get enough data from the Mac.

If you're willing to try an experiment, find and uncomment this line in usb.c

	//USB1_PORTSC1 |= USB_PORTSC1_PFSC; // force 12 Mbit/sec

The difficult part is it's buried deep within the application bundle. On Windows and Linux the Arduino software is just folders and files. On Mac, control-click Teensyduino and "Show Package Contents" to access inside it. Look for usb.c in Contents/Java/hardware/teensy/avr/cores/teensy4. Editing any files inside the application may cause MacOS to later believe the software is corrupted or a security threat (Apple started tightening security since Mountain Lion) so best to make a backup copy, or just plan on downloading a fresh copy of Teensyduino after you're done.

During audio streaming, Teensy transmits asynchronous rate feedback which is supposed to tell your Mac to adjust the output data rate slightly to match the rate Teensy is consuming the data. The asynchronous rate feedback algorithm is different at 480 vs 12 MBit speed, using 32 vs 24 bits. Would help to know if the same problem happens with both, or only at 480 Mbit speed when we're sending 32 bit rate feedback.

The problem could also be a stability problem in the process of adjusting the rate feedback. It's notoriously difficult to get right for Mac, Windows and the various audio systems Linux uses. Maybe we should someday increase the buffer on Teensy's side, which will add some latency, but also give us a lot more slack of the rate feedback to adjust before hitting an overrun or underrun.

We could also probably do better in concealing the underrun condition. Outputting a block of 128 zeros is easy, but with some effort we could probably do better at filling in the missing time with something that doesn't cause an annoying pop...

[domingo]

I tried it Paul. Lowering the USB speed to 12Mbit/s seems to help a bit, but the glitches are still there. I verified that speed is now 12Mbit/s in the Mac System Report –which only became effective after reseting the Teensy with the hold button.

They happen with any sound source I've tried in the Mac. Even with Ardour which seems to bypass completely the Mac audio core. Tested files are 44.100Hz 32bit (floating).

With Windows 7 in an old PC the problem didn't occur at all.

Any other clues for a short term solution would be great. I'm up for any tests on this side.

[domingo]

Small update:

- Glitches also occur when playing 16bit WAV files.
- I tried a Macbook Air 2012 with OSX 10.14 and now a MacBook Pro 2015 OSX 10.13. Both present the same problem. DAWs tend to be more prone to it.

How complex is it to disable the underrun condition temporarily Paul? I'm all for filling up those gaps with the corresponding samples, mostly because I consider important that the source file's length is equal to the DAC's output –I suppose that if sample sections are missing the analog output will be slightly shorter than the digital input and difficult to sync afterwards... But as a temporary solution (and test) I think it might worth a try. What do you think?