I think this is normal to take quite some time if you have the system search the whole file system recursively for mp3 files!
In the start path, use a subdirectory that contains the relevant mp3 files

Please open issues only for bugs and not for questions...

ps. If you really need to search the whole file system, use the indexed implementations instead.

@pschatzmann Thank you for your response, but the main issue I described in the first point wasn't addressed at all. Could you also provide an answer to that, or did I perhaps explain the problem poorly?

@pschatzmann
I used an MP3 file that plays flawlessly on a "Lilypad MP3 Board". During the silent pauses, no "PUP" noises can be heard. This sound typically occurs at the beginning and end of a pause or moment of silence within the MP3.

For testing purposes, I created a spoken text using Google Sound of Text: https://soundoftext.com/

Hello world2.mp3

Using mp3DirectCut, I extended the pauses in the file slightly.
image
Using mp3DirectCut, I don’t see any unusual peaks.

Now, when this file is played, the "PUP" noises appear at the start and end of each pause in the MP3.

I’ve attached the MP3 file — maybe you can test it that way.

The ESP32 Audio Kit is connected via USB to a PC. I also tested it with a lithium battery, and the same issue occurred. Both power sources should be clean and stable, especially the battery.

At the audio output, I connected a VISATON FRS 7W (Art. No. 2017) 8-ohm speaker.

I haven’t tested it with the MedianFilter yet, because the setup seems a bit tricky to me and I need to take a closer look. However, I can imagine that in general, MP3 files containing such silent gaps might lead to these kinds of issues.

@pschatzmann
I’ve now tested it with headphones as well, and the same issue occurs — I can hear these noises.

The problem only happens with spoken MP3 files that don’t have any background music and contain truly silent pauses between speech. When I play an audio drama that includes background music, these noises don’t occur.

By the way, the ESP32 Audio Kit supports 4–8 ohm speakers.

I have the impression that the hardware decoder might be shutting down during silent passages and reactivating once the silence ends. This switching on and off could be causing the noise. It’s actually the same sound I hear whenever any MP3 file starts playing — I get that noise then too. At the beginning of playback, I can work around it by activating the speaker amplifier slightly later. But during playback, that’s not possible.

Is there a way to fill the silent passages with a very low, inaudible signal so that the hardware decoder doesn’t shut down in the first place?

It would also be interesting to know whether this issue has been observed with the ESP32 Audio Kit board, or if I’m the only one experiencing it. Because if this is a general issue with this board series, I might need to consider switching to a different one.

@pschatzmann
I listened to the MP3 file using headphones, and the issue also occurs when using headphones.

I rewrote the code to use the WAVDecoder and converted my MP3 file to WAV format.
This is the file I used: Hello_world2.wav

– The issue also occurs when playing the WAV file, even with headphones.

For completeness, here is the code I used to play the WAV file.

/**
 * @file player-sd-audiokit.ino
 * @brief see https://github.com/pschatzmann/arduino-audio-tools/blob/main/examples/examples-audiokit/player-sdfat-audiokit/README.md
 * Make sure that the pins are set to off, on, on, off, off
 * @author Phil Schatzmann
 * @copyright GPLv3
 */
#include <AudioTools.h>
#include <AudioTools/AudioLibs/AudioBoardStream.h>
#include <AudioTools/AudioCodecs/CodecMP3Helix.h>
#include <AudioTools/AudioCodecs/CodecWAV.h>
#include <AudioTools/Disk/AudioSourceSD.h>
const char *startFilePath="/test";
const char* ext="wav";
//SdSpiConfig sdcfg(PIN_AUDIO_KIT_SD_CARD_CS, DEDICATED_SPI, SD_SCK_MHZ(10) , &SPI);
AudioSourceSD source(startFilePath, ext, PIN_AUDIO_KIT_SD_CARD_CS);
AudioBoardStream kit(AudioKitEs8388V1);
//MP3DecoderHelix decoder; // or change to MP3DecoderMAD
WAVDecoder decoder;
AudioPlayer player(source, kit, decoder);
void setup() {
 Serial.begin(115200);
 AudioToolsLogger.begin(Serial, AudioToolsLogLevel::Info);
 // SD-Card
 SPI.begin(PIN_AUDIO_KIT_SD_CARD_CLK, PIN_AUDIO_KIT_SD_CARD_MISO, PIN_AUDIO_KIT_SD_CARD_MOSI, PIN_AUDIO_KIT_SD_CARD_CS); // SCK, MISO, MOSI, CS
 SD.begin(PIN_AUDIO_KIT_SD_CARD_CS, SPI, 25000000); // 25 MHz instead of standard
 if (!SD.begin(PIN_AUDIO_KIT_SD_CARD_CS, SPI)) {
 return;
 }
 // setup output
 auto cfg = kit.defaultConfig(TX_MODE);
 cfg.auto_clear = false;
 kit.begin(cfg);
 kit.setTimeout(0);
 // setup player
 player.setVolume(0.01);
 player.setSilenceOnInactive(false);
 //player.begin(); //Causes large MP3 files (approx. 100 MB) to take several seconds to start playing.
 //player.play();
 player.setPath("/test/Hello_world2.wav");
}
void loop() {
 player.copy();
}

I assumed that you already tested with a proper log level because this is described all over the place when having quality issues.
Please confirm that AudioToolsLogger.begin(Serial, AudioToolsLogLevel::Warning); does not make a difference...

@pschatzmann
Yes, I’ve now also tested it with the following code. It actually makes NO difference at all.
AudioToolsLogger.begin(Serial, AudioToolsLogLevel::Warning);

@pschatzmann

Could this phenomenon be a bug?

I previously developed an MP3 player based on the VS1053 chip. Since the VS1053 is a hardware decoder, I used the same MP3 files that worked well on that setup as a reference for this project. That’s how I noticed these issues — which did not occur with the VS1053.

What’s your take on it?

Personally, I would consider this a bug and would like to officially report it so it can be reviewed and not overlooked. I’ve already attached the MP3 and WAV files that reproduce the issue.

Thanks for testing it. I also continued reducing the code in parallel, and after that, I was no longer able to reproduce the issue. I honestly don’t understand what caused it earlier. I removed the AudioPlayer class from the code, which was using AudioSourceSD as its source. That might have been the reason — as you also suggested. Instead, I switched to using the standard SD.h, and it seems that was indeed the key. It’s a bit of a pitfall, since older code examples still rely on AudioSourceSD.

Thanks again for your quick response to my issue. Attached is my current code, which no longer shows the problem. I hope it helps someone else down the line.

/**
 * @file player-sd-audiokit.ino
 * @brief see https://github.com/pschatzmann/arduino-audio-tools/blob/main/examples/examples-audiokit/player-sdfat-audiokit/README.md
 * Make sure that the pins are set to off, on, on, off, off
 * @author Phil Schatzmann
 * @copyright GPLv3
 */
#include <SPI.h>
#include <SD.h>
#include "AudioTools.h"
#include "AudioTools/AudioLibs/AudioBoardStream.h"
#include "AudioTools/AudioCodecs/CodecMP3Helix.h"
#include <AudioTools/AudioCodecs/CodecWAV.h>
const int chipSelect=PIN_AUDIO_KIT_SD_CARD_CS;
AudioBoardStream kit(AudioKitEs8388V1); // final output of decoded stream
EncodedAudioStream decoder(&kit, new WAVDecoder()); // Decoding stream
StreamCopy copier; 
File audioFile;
void setup() {
 Serial.begin(115200);
 
 AudioToolsLogger.begin(Serial, AudioToolsLogLevel::Error);
 // setup audiokit before SD!
 auto config = kit.defaultConfig(TX_MODE);
 config.sd_active = true;
 
 kit.begin(config);
 kit.setVolume(0.01);
 // setup file
 SD.begin(chipSelect);
 audioFile = SD.open("/test/Hello_world2.wav");
 // setup I2S based on sampling rate provided by decoder
 decoder.begin();
 // begin copy
 copier.begin(decoder, audioFile);
}
void loop() {
 
 if (!copier.copy()) {
 stop();
 }
}