I'm trying to create an application to run on the Cheap Yellow Display (containing a 2.8" LCD display and a ESP32 module) for streaming MP3 music files to a Bluetooth speaker. I am using Phil Schatzmann's ESP32-A2DP, arduino-audio-tools and his arduino-libHelix libraries for this effort. I have modified his various examples with the intension of having a class I call SongManager with methods for playing an MP3 song, starting and stoping playback of songs, setting playback volume and other features. I have intentionally removed all of Schatzmann's code for automatically playing directories of MP3 songs in a continuous manner and instead have built an interface for playing single songs only as I plan on integrating this code (if I ever get it working) into an existing music player of my own design which needs this functionality.

So I have cobbled together two test programs from his example programs. They both do the same thing the difference being one uses his AudioSourceSDFAT.h source and the other uses his AudioSourceSD.h source. The test program using AudioSourceSDFAT.h works as designed. I can submit a path name to a MP3 file on the SD card and the code will play it perfectly. However when I try to do the same thing using the AudioSourceSD.h code the test program crashes. The reason I need to use the AudioSourceSD.h code is that the program I want to integrate this code into uses the Arduino SD library exstensively.

I know the SD library works on this module as I have build many apps with it. So this is not an issue with me not knowing what I am doing.

So in my SongManager class I can turn on logging at the debug level and see what each of the test programs are doing and they are remarkably similar. In the working test program there is a bunch of setup shown in the Serial Monitor including connection to my Bluetooth speaker and then a long series probably 100's of Waiting for buffer messages shown below:

[D] A2DPStream.h : 253 - Waiting for buffer: writing 1024 > available 512
[D] A2DPStream.h : 253 - Waiting for buffer: writing 1024 > available 512
[D] A2DPStream.h : 253 - Waiting for buffer: writing 1024 > available 512
[D] A2DPStream.h : 387 - a2dp_stream_source_sound_data: 512 -> 512
[D] BufferRTOS.h : 95 - int audio_tools::BufferRTOS::writeArray(const T*, int) [with T = unsigned char]: 1024
[D] A2DPStream.h : 387 - a2dp_stream_source_sound_data: 512 -> 512
[D] A2DPStream.h : 265 - write 1024 -> 1024

from this I deduce that the music data is waiting for some process to empty the buffer and when that happens, the test program proceeds to play the MP3 file perfectly.

However in the non-working test program the same connection to my Bluetooth speaker occurs and again a very large number of the Waiting for buffer messages are produced followed by an assert failute message which terminates the program and my ESP32 reboots. This is shown below:

[D] A2DPStream.h : 253 - Waiting for buffer: writing 1024 > available 512
[D] A2DPStream.h : 253 - Waiting for buffer: writing 1024 > available 512
[D] A2DPStream.h : 253 - Waiting for buffer: writing 1024 > available 512
[D] A2DPStream.h : 253 - Waiting for buffer: writing 1024 > available 512

assert failed: SbcAnalysisInit sbc_analysis.c:1093 (s32X)

It seems to me that whatever process finally empties the buffer in the working test programs is not happening in the non-working test program.

I have provided the working test program in a zip file called: SD_BT_Test.zip and the non-working program in a zip file called: SD_BT_Test2.zip. If you try and run this code you will have to change the path to some MP3 file you have on your SD card.

If anyone has any insights as to what might be the issue I would love to hear them as I have been stuck on this for a couple of weeks.

Thanks

SD_BT_Test.zip
SD_BT_Test2.zip

The issue seems to be the bad performance of the SD library!

I have used the ESP32-A2DP library before with the SD library and it worked great. The only reason I am attempting to use all of your libraries was because I wanted a more modern approach that uses much less memory than my current application uses.

Is there any timeouts that I can modify to make the SD library work?

The SD library is very slow.
You can try to increase the SPI frequency.
However I would recommend to use SDMMC instead...