PWMAudio Crashing

[ScullyE]

Hello! Thank you for your amazing work. The entire arduino-pico project is fantastic.

I am having an issue that had me scratching my head for the past few days. I've been trying to use PWMAudio for a project very similar to the example for PWMAudio and a headerless wav. It seems to fail unexpectedly when storing that wav file with const keyword (which should put it in PROGMEM). This works sometimes, and sometimes doesn't, and I've yet to figure out why and when it doesn't work. I suspect it's related to DMA channels. When it fails, it sounds like it's reading a random memory address as audio (almost white noise like crackling), and the pico will lock up and be unreadable over USB without connecting while holding down the boot button.

The easiest way to reproduce this issue follows:

#include <PWMAudio.h>
#include "wav.h"

// The sample pointers
const int16_t *start = (const int16_t *)out_raw;
const int16_t *p = start;

// Create the PWM audio device on GPIO 1.   Hook amp/speaker between GPIO1 and convenient GND.
PWMAudio pwm(17);

unsigned int count = 0;

void cb() {
  while (pwm.availableForWrite()) {
    pwm.write(*p++);
    count += 2;
    if (count >= sizeof(out_raw)) {
      count = 0;
      p = start;
    }
  }
}

void setup() {
  Serial.begin(9600);
  Serial.println("test");
  pwm.onTransmit(cb);
  pwm.begin(44100);
}

void loop() {
  /* noop, everything is done in the CB */
}

And adding a const before the definition in wav.h

This code will work fine without the lines:

  Serial.begin(9600);
  Serial.println("test");

It will also work fine if the const keyword isn't used, but the above lines are included. This also fails when not using Serial, often when trying to play one audio file, then switching to a different audio file.

I'm not really worried about getting Serial to work, this is just the easiest way to show an issue that happens under other circumstances as well. It's fairly important that I put the audio files in flash (as they are large). Any help is appreciated, thank you!

[earlephilhower]

A quick glance makes me think you're underflowing because of the small default buffer sizes. The DMA engine misses two interrupts and gets confused. Try adding pwm.setBuffers(16, 64); before pwm.begin() and retry.

[ScullyE]

Ah, an easy solution would have been nice, but I still run into the same issue after including the above.

[earlephilhower]

Can you attach your exact wav.h file (zip it up and it should be possible) that's barfing? And please double check the sketch above is the one you've settled on that does fail. Just trying to make sure it's the same thing here and there.

The failure you're hearing is a CPU panic with the DMA engine still running w/o proper reset. If you have a Picoprobe/Debugprobe please grab a stack trace which would help pinpoint things.

The initial Serial.begin() is a no-op, it's actually started before setup() ever gets called (so the auto-reboot to upload new sketch works).

The single println() will probably result in 1 or 2 USB CDC packets and nothing ever again. There might be a race condition in the DMA startup in AudioBufferManager and possibly the USB interrupt happens at just the wrong time and boom. A quick way of eliminating that would be to add a delay(100) between the println and the pwm.begin.

[ScullyE]

I have another pico I'll try to use as a debug probe. In the meantime, the exact wav file is the one used in the example sketch for PWMAudio "PlayRaw" with the file name wav.h, though this happens with every other sample I've tried as well, regardless of the sample rate.
wav.zip

[earlephilhower]

This is an alignment issue because your array is a char and you're reading int16_t. GCC is giving your array an odd address (perfectly legal for char but illegal for int16_t). Export your WAV as 16-bits (might be a pain) or align the array to a 2-byte boundary using

const unsigned char out_raw[] __attribute__((aligned((2)))) = {

While you saw it with Serial this really could be cause by even having a single global variable anywhere in the app. The alignment primitive will take care of this.

[earlephilhower]

#2437 will adjust the example here.

[ScullyE]

Works perfectly now, thank you so much!