How should I debug audio exceptions

[ggyshay]

Hello! I've been working on a teensy drum machine (including samples), the code is now huge so I don't think it makes sense to put it here. Sometimes after playing the same sample from flash memory many times the serialFlash cant open the file again, (it gets a strange signature from flash memory apparently). I have tried to isolate the issue on a separate file but then it disappears, so I'm wondering, how could I debug exceptions related to interrupts? I would like to see when each interrupt is called and debug it.

Thank you very much!!

[defragster]

Can you get a smaller repro with a two SerialFlash samples running over and over? Alternating between two samples? Two samples would allow the open close behavior.

If that won't repro when emulating it would seems to be related to memory corruption perhaps in the handling of the other numerous samples.

What Teensy is in use? What is showing for 'Sketch uses' … program and variables?

Adding the info from example/audio/ MemoryAndCpuUsage would show something of the state of the audio system.

[ggyshay]

Currently I have just one sample playing, the other things are synthesis (thats the reason for 80% cpu max)
I'm using teensy 3.6,

```Sketch uses 225740 bytes (21%) of program storage space. Maximum is 1048576 bytes.
Global variables use 36264 bytes (13%) of dynamic memory, leaving 225880 bytes for local variables. Maximum is 262144 bytes.```

This are some serial.prints that i've put in the file. When it manages to open the sample it reads the serialFlash signature as "sig: FA96554C 18F60258"

but when the opening fails this is what it outputs:
```KICK1.RAW
sig: 2E7D2DC6 2FF02F3B
unable to open file
played 971 times CPU: 69.17,80.07 Memory: 47,50
CPU: 69.17,80.07 Memory: 47,50```

The played n times part means that the error occurred after playing the sample 971 times, the cpu usage was about 80% for about the last 700 sample plays , I have allocated 60 memory blocks.
When this issue occurs the audio stops playing, the logs on serial monitor still come in for a while

[defragster]

Good info, none of that looks scary close to exhausting or over using anything obvious.

Creating/Posting a simple sketch that emulates the core of the KICK1.RAW and a simple synthesis would show it to work or fail. If it works for 1,000 iterations or more it might point out the problem difference from the larger code. If it fails it would be much easier for somebody to work with.

[ggyshay]

I've figured out how to isolate the issue, at this point I believe that the issue come from some priority issue related to the IntervalTimer as implied from https://forum.pjrc.com/threads/26686...t-based-timing. Here is the main code.

#include "audioInfra.h"
#include "Audio.h"

IntervalTimer myTimer;

class Kick
{
public:
  Kick()
  {
    patch9 = new AudioConnection(wav, 0, s_out, 0);
    s_out.gain(1.0);
  }

  void noteOn(byte velocity)
  {
    if (wav.play("KICK1.RAW"))
    {
      count++;
    }
    Serial.printf("played %d times", count);
  }

  int count = 0;
  AudioAmplifier s_out;

private:
  AudioPlaySerialflashRaw wav;
  AudioConnection *patch9;
};

Kick *k;
AudioConnection *patchCord1;

void setup()
{
  Serial.begin(112500);
  while (!Serial)
    ;
  Serial.println("serial is up");
  audioInfra->setup();

  Serial.println("audio infra setup done");
  k = new Kick();

  patchCord1 = new AudioConnection(k->s_out, 0, audioInfra->output1, 0);

  Serial.println("objects allocated");

  int sixteenth = (int)(1000.0 * 15000.0 / 240.0);
  myTimer.begin(sendMidiClock, sixteenth);
  Serial.println("general setup finished");
}

void loop()
{
}

void sendMidiClock()
{
  k->noteOn(127);
}

And here is the AudioInfra.h file

#include <Audio.h>
#include <i2c_t3.h>
#include <SD_t3.h>
#include <functional>
#include <EEPROM.h>
#include <SerialFlash.h>

#ifndef _AUDIO_INFRA_H_
#define _AUDIO_INFRA_H_
#define SDCARD_CS_PIN 10
#define SDCARD_MOSI_PIN 7
#define SDCARD_SCK_PIN 14
#define SFLASH_PIN 6

class AudioInfra
{
public:
  void setup()
  {
    AudioMemory(60);
    sgtl5000_1.enable();
    sgtl5000_1.volume(0.8);

    audioInfraPatch1 = new AudioConnection(output1, 0, internalMixer, 0);
    audioInfraPatch2 = new AudioConnection(output2, 0, internalMixer, 1);
    audioInfraPatch3 = new AudioConnection(internalMixer, 0, audioOutput, 0);
    audioInfraPatch4 = new AudioConnection(internalMixer, 0, audioOutput, 1);

    SPI.setMOSI(SDCARD_MOSI_PIN);
    SPI.setSCK(SDCARD_SCK_PIN);
    SerialFlash.begin(SFLASH_PIN);
    delay(100);
    Serial.println("serial flash begun");
  }

  AudioMixer4 output1;
  AudioMixer4 output2;
  AudioAmplifier _input;

private:
  AudioOutputI2S audioOutput;
  AudioConnection *audioInfraPatch1;
  AudioConnection *audioInfraPatch2;
  AudioConnection *audioInfraPatch3;
  AudioConnection *audioInfraPatch4;
  AudioMixer4 internalMixer;
  AudioControlSGTL5000 sgtl5000_1;
};

AudioInfra *audioInfra = new AudioInfra();

#endif

[ggyshay]

I've solved the issue. I was playing the sample inside the interrupt of IntervalTimer, I don't completely understand why but that was the problem, I know it is a bad idea to put long stuff in interrupts though. So the solution is to set a flag "sampleShouldPlay" to true and play the sample in the loop if that flag is set.

[defragster]

I've solved the issue. I was playing the sample inside the interrupt of IntervalTimer, I don't completely understand why but that was the problem, I know it is a bad idea to put long stuff in interrupts though. So the solution is to set a flag "sampleShouldPlay" to true and play the sample in the loop if that flag is set.

Good you resolved it. I was going to add a note about being wary of debug in _isr() code - wasn't clear what was in use and if that was being done.