Playback stops with [E] SDDirect.h : 81

[BorpaBoatski]

Using:
Arduino UNO R4 Wifi
VS1053 MP3 Shield
Sandisk microSD

I'm aiming to make a media player that is suppose to run almost the whole day. However, I found that after my player does several loops, it would stop and give this message [E] SDDirect.h : 81. Searching online and it seems to be running out of RAM. I added this block to print the SRAM of my process:

int FreeMemory()
{
  char top;
  return &top - reinterpret_cast<char*>(sbrk(0));
}

The results are summed as follows:

Memory 19207
... <- Repeated value
...
Now Playing 2
Memory 18719
...
...
Now Playing 0
Memory 18315
...
...

So it seems to be losing memory every time the track changes. How do I free up the memory that was used by previous track? I have attached my code in the .zip file.

LosingMemoryExample.zip

[pschatzmann]

Hmm, this will be difficult to find!

• I suggest to start with the simplest sketch possible: just remove all your logic to exclude that that the issue has been caused by your code. e.g. the PrintFiles never closes root.
• Then there are 3 potential sources of the problem that we can try to exlude separatly: AudioSourceSD, VS1053Stream and
  AudioPlayer.
  • step 1: replace VS1053Stream with a NullStream and check if the memory leak remains
  • step 2: replace AudioSourceSD with a AudioSourceCallback class: this might be a better aproach for your case anyhow: just provide a callback via setCallbackNextStream that provides the next file to play.
  • step 3: replace the AudioPlayer and just copy the whole file to the VS1053Stream

I think VS1053Stream is rarely used: so it might come from there ?

ps. This assumes that the memory leak is not in the SD library, so this might need to be tested separatly. You can try to replace it with SDFAT.

[pschatzmann]

I committed a correction to the VS1053Stream in the AudioTools. There was a potential memory leak when calling end() and begin().
If the issue remains, I will need to look into the VS1053 library.

[BorpaBoatski]

I replaced my VS1053Stream with the corrected version. Unfortunately, I am still seeing the same memory loss.

[pschatzmann]

Unfortunatly I don't have the hardware setup to test this properly. So I created the following test sketch that just opens, writes data and closes the VS1053Stream:

#include "AudioTools.h"
#include "AudioTools/AudioLibs/VS1053Stream.h"
#include <unistd.h>

VS1053Stream vs1053;  // final output

int freeMemory() {
  char top;
  return &top - reinterpret_cast<char*>(sbrk(0));
}


void setup() {
  Serial.begin(115200);
  while (!Serial)
    ;
  AudioToolsLogger.begin(Serial, AudioToolsLogLevel::Warning);

  // setup output
  auto cfg = vs1053.defaultConfig();
  cfg.is_encoded_data = true;  // vs1053 is accepting encoded data
  vs1053.begin(cfg);
}

void loop() {
  vs1053.end();
  Serial.print("rc = ");
  Serial.print(vs1053.begin());
  for (int i = 0; i < 1000; i++) vs1053.writeSilence(1000);
  Serial.print(" / free ram: ");
  Serial.println(freeMemory());
}

I could not reproduce any memory leak:

rc = 1/ free ram: 25675
rc = 1/ free ram: 25675
rc = 1/ free ram: 25675
rc = 1/ free ram: 25675
rc = 1/ free ram: 25675
rc = 1/ free ram: 25675
rc = 1/ free ram: 25675
rc = 1/ free ram: 25675
rc = 1/ free ram: 25675
rc = 1/ free ram: 25675
rc = 1/ free ram: 25675
rc = 1/ free ram: 25675

[pschatzmann]

The same with the following player test sketch that just generates 0 values during 5 seconds:

#include "AudioTools.h"
#include "AudioTools/AudioLibs/VS1053Stream.h"
#include "AudioTools/AudioCodecs/CodecCopy.h"
#include <unistd.h>

const char* startFilePath = "/";
const char* ext = "mp3";
Stream* nextStreamCallback(int offset);
AudioSourceCallback source(nextStreamCallback);
VS1053Stream vs1053;  // final output
AudioPlayer player(source, vs1053, *new CopyDecoder());
NullStream zeros;
TimedStream timed;

// provide the next "file"
Stream* nextStreamCallback(int offset) {
  timed.begin();
  return &timed;
}

// report the free RAM
int freeMemory() {
  char top;
  return &top - reinterpret_cast<char*>(sbrk(0));
}

void setup() {
  Serial.begin(115200);
  AudioToolsLogger.begin(Serial, AudioToolsLogLevel::Warning);

  timed.setStream(zeros);
  timed.setEndSec(5);

  // setup output
  auto cfg = vs1053.defaultConfig();
  cfg.is_encoded_data = true;  // vs1053 is accepting encoded data
  vs1053.begin(cfg);
  vs1053.setVolume(1.0);  // full volume

  // setup player
  player.begin();
}

void loop() {
  if (!player.copy()) {
    Serial.print("free ram: ");
    Serial.println(freeMemory());
  }
}

Which gives the following log:

ree ram: 20691
free ram: 20691
free ram: 20691
free ram: 20691
free ram: 20691
free ram: 20691
free ram: 20691
free ram: 20691
free ram: 20691
free ram: 20691
free ram: 20691
free ram: 20691

I was testing with the 1.5.1 core version!

[BorpaBoatski]

I tested with the sketch you just posted and I am getting the same result where the memory is constant. I downloaded the latest release which was 1.2.1. Where do I find 1.5.1?

I think the issue could be coming from the stream. I added the AudioSourceSD into your sketch as the source for the player and now I'm getting the losing memory issue again. You recommended changing the AudioSourceSD class to AudioSourceCallback. How do I provide the file for it to play?

[pschatzmann]

This is what I get:

I found the problem: for the AudioSourceSD, the last file was not closed: I committed a correction to align the logic whith what has been implemnted for SDFAT.

If you want to use the callback, you would do something like this:

// provide the next "file"
File actual_file;
Stream* nextStreamCallback(int offset) {
  actual_file.close();
  actual_file = SD.open(your next file name)
  return &actual_file;
}

[BorpaBoatski]

Oh the board package. Yes, mine is at 1.5.1.

I tried with the corrected AudioSourceSD but still not improvement there.

HOWEVER. Your idea of using the nextStreamCallback is working! There's no memory loss being shown.

[BorpaBoatski]

Just to update. Right now I have it playing the playlist constantly and on shuffle as well with no loss in memory. However, once I attempt to fading the volume of the vs1053 or running begin() or end() to start/stop playback. The memory takes a hit again. Interestingly, even if the memory value drops really low, the playback is still working fine compared to last time where it would cease completely. I think this is just a limitation of the memory printing(?) Any ideas?