Low audio output on BT speaker receiving A2DP transmission from ESP32

[104TMR]

Hi All,
I've created a project that transmits Talkie TTS to a BT speaker, using A2DP from an ESP32 running AudioTools (many thanks for such powerful library).
However, I've found that the BT speaker output volume is quite low, even with its volume set to max, and a2dp_source.set_volume set to max (127).
Talkie outputs on pin 25 (DAC0) and this pin is connected to pin 32, which is set as PIN_ADC1 (in AudioConfig.h), so the Talkie output feeds into ADC1 to be transmitted by A2DP to the BT speaker.
I thought that maybe the Talkie output was low, so I amplified it before feeding into pin 32 (ADC1), but it seemed to make little difference to the BT speaker output volume.
So I made a simplified test to compare what volume was possible with the BT speaker I am using, and then compare with the volume I was getting from the ESP32/A2DP transmission.
Firstly, I used an iPhone app ("Tone Gen") to generate a 1 kHz sine wave and connected it (via BT) to the BT speaker at maximum volume.
It was very loud, and I set up a microphone to measure the strength of the sound signal coming out of the BT speaker.
The photo below (Pic1) shows the microphone output (green trace, ignore the yellow trace for now) for this 1kHz signal coming out of the BT speaker, indicating a 2Vpp output.

Pic1. Green trace shows microphone output for BT speaker with sinewave input via bluetooth from iPhone app "Tone Gen" at maximum volume.

I then used DacESP32 to generate a 1kHz sinewave on pin 25 (the same pin used for Talkie output), and connected to pin 32 for input into A2DP and transmission to the BT speaker.
The following sketch shows how this was run, essentially based on the basic_adc_a2dp example:

//DacESP32 outputs a continuous 1kHz, 3Vpp sinewave on pin 25 and this is input to ADC1 on AudioTools on pin 32.

#include "AudioTools.h"
#include "BluetoothA2DPSource.h"
#include "DacESP32.h"

DacESP32 dac1(GPIO_NUM_25);

AnalogAudioStream adc;
BluetoothA2DPSource a2dp_source;
ConverterFillLeftAndRight<int32_t> bothChannels;

// callback used by A2DP to provide the sound data
int32_t get_sound_data(Frame* frames, int32_t frameCount) {
uint8_t data = (uint8_t)frames;
int frameSize = 4;
size_t resultBytes = adc.readBytes(data, frameCount*frameSize);
return resultBytes/frameSize;
}

// Arduino Setup
void setup(void) {
Serial.begin(115200);

// start i2s input with default configuration
Serial.println("starting I2S-ADC...");
adc.begin(adc.defaultConfig(RX_MODE));

// start the bluetooth
Serial.println("starting A2DP...");
a2dp_source.set_auto_reconnect(false);
//a2dp_source.start("MyMusic", get_sound_data);
// a2dp_source.start("Soundcore Space A40", get_sound_data);
a2dp_source.start("LEATHER DRUM2+", get_sound_data);
a2dp_source.set_volume(127); //0-127
Serial.println("A2DP started now...");
dac1.outputCW(1000);
dac1.setCwScale(DAC_CW_SCALE_1); //DAC_CW_SCALE_1 is max amplitude, while DAC_CW_SCALE_8 is min amplitude.
}

// Arduino loop - repeated processing
void loop() {
}

The ESP32 is a WROOM version, with 8MB (only 4MB available) PSRAM, running a HUGE App partition scheme.

This produces a 1kHz sine wave, 3Vpp input (close to the theoretical maximum of 3.3V) into A2DP. Connecting this to the BT speaker, and measuring the sound level output with the microphone produced the following measurement (Pic2):

Pic2. Green trace shows microphone output for BT speaker with sinewave input via bluetooth from A2DP transmission from ESP32 running DacESP32 and BluetoothA2DPSource (AudioTools).

The green trace shows the microphone output, while the yellow trace shows the DacESP32 output being fed into A2DP.
Key information from these traces are that
(i) the sound level recorded by the microphone is 1Vpp (1/2 that of the output achieved by Tone Gen on the iPhone)
(ii) the generated sound waveform (BT speaker) is significantly distorted compared to both the input signal (DacESP32, yellow trace), which shows a good sinewave, and the apparently clean sinewave sound output achieved from ToneGen on the iPhone (ie. green trace in Pic 1).
I've also found a further problem, in that the BT speaker output stops for about 1 second every 31 seconds when running the DacESP32/A2DP sketch (above).
So, I would ask if anyone might have any ideas on:

• Why the A2DP transmission produces a maximum sound level output on the BT speaker that is 1/2 of what the speaker is capable of (even when the input sinewave is near to its maximum possible level, and a2dp_source.set_volume is set to its maximum of 127)?
• Why the sound wave form transmitted by A2DP seems to be significantly distorted (compared to the sinewave that is apparently generated by the Tone Gen iPhone app)?
• Why does the A2DP output regularly stop for 1 second every 31 seconds?
  Any thoughts/advice greatly appreciated!

[pschatzmann]

• For your volume issue: have you tested with the sine wave test sketch. Just remove the aplitude to get the maximum volume. In my tests this was unbearable loud!
• I think you should reconsider your current inefficient approach, which is the source of most of your issues. Try to to use a TTS which directly generates PCM data. This will avoid the issues with the amplitude, the underruns and quality...

Here is some more info about TTS...

[104TMR]

Well, thanks very much for such prompt and helpful suggestions, Phil.
You are absolutely correct: the sine wave test sketch performs 'a million times better' than a sinewave generated by DacESP32 fed into an ADC input!
The sound is powerful and clear from the BT speaker - exactly what I had been hoping for.
I've also experimented with your SimpleTTS library, and it also is miles better than Talkie.
I had become wedded to Talkie through both past experience and also because it has a relatively small memory footprint.
This project is a thermocouple (TC) data logger and graphical plotter (on a 4" TFT screen, with real time plotting of up to 6 TC temperatures), which uses Bodmer's wonderful TFT_eSPI library for the graphics.
TC values need to be available audibly at a position somewhat remote from the point of measurement (~10m), hence the interest in a TTS capability.
All up, the project is using ~1.1MB (TC reading, TFT graphics, SD logging, RTC (DS3231) timestamping), and incorporating SimpleTTS using A2DP looks like adding another ~1.75MB. So all up looks like ~2.9MB, which is still well within the 4MB.
However, I've added a PSRAM64H chip to the ESP32, primarily for high speed backing data (needs ~1MB) for TFT plot refreshing, but Bodmer's eSPI libraries will also automatically make use of this, if it is present, for running sprite objects (of which there are several running on the TFT display).
I think I remember reading somewhere in your (extensive!) help files that AudioTools will also make some use of PSRAM if it is present, and it has me wondering whether this might start using up excessive PSRAM?
If it is the case (that AudioTools and/or associated libraries automatically take up some PSRAM), is there a setting somewhere I should be aware of that controls/limits how much PSRAM AudioTools uses?
Finally, I have come across one apparent problem with the SimpleTTS-A2DP example, and that is the voice is only saying the last half of a speech segment. The first half seems to be missed, somehow.
The attached video captures this output.

SimpleTTSExample-MissingSpeech.MOV

I've had a scan of the discussion group for something about this, but can't seem to find a similar issue.
Could I ask your advice as to what may be causing this, and what could correct it?
Many thanks...

[pschatzmann]

I think Talkie is a cool functionality: so I was putting together some new project which uses Talkie to generate PCM data. I suggest that you have a look at this.

Don't worry about PSRAM: if PSRAM has been activated, then all arrays that would be allocated in RAM will go to PSRAM instead. This is actually good since the RAM is quite limited, compared to the PSRAM.

Not sure what's causing the issue with the lost start of the audio: I will need to look into this....

[pschatzmann]

For simple-tts you can generate your own custom dictionality, if you think that something is missing.

Let me know if talkie has the same issues with A2DP: this will help me to identify if the issue is on the A2DP side...

[pschatzmann]

Oh my god: I just relized that I was doing numbers wrong my whole life and nobody ever corrected me!
So for number it seems to be point: 1.2 (one point two) and not one dot two as I was doing for my whole life...

[104TMR]

Ah, well, Phil, better late than never, I guess...and at least now you get the point...;-)
I'll look into experimenting with TalkiePCM later this evening...

[104TMR]

I've tried modifying the AudioKit example file supplied with TalkePCM, but TBH, I'm not sure if I've got it completely correct.
Your review of the following appreciated:

#include "AudioTools.h"
#include "AudioCodecs/CodecMP3Helix.h"
#include "AudioLibs/A2DPStream.h"
#include "TalkiePCM.h"
#include "Vocab_US_Large.h"

AudioInfo from(8000, 2, 16);  // TalkiePCM                                         
AudioInfo to(44100, 2, 16);   // A2DP                                        
A2DPStream a2dp; 
FormatConverterStream out(a2dp);
TalkiePCM voice(out, from.channels);
const char* name = "LEATHER DRUM2+";                         // Replace with your device name

void setup() {
  Serial.begin(115200);
  AudioLogger::instance().begin(Serial, AudioLogger::Info);

  Serial.println("Starting...");

  // setup conversion to provide stereo at 44100hz
  out.begin(from, to);

  // setup a2dp
  auto cfg = a2dp.defaultConfig(TX_MODE); 
  cfg.name = name;
  cfg.silence_on_nodata = true; // allow delays with silence
  a2dp.begin(cfg);
  a2dp.setVolume(0.3);

  Serial.println("A2DP Started");
  
  Serial.println("Talking...");
}

void loop() {
  voice.say(sp2_DANGER);
  voice.say(sp2_DANGER);
  voice.say(sp2_RED);
  voice.say(sp2_ALERT);
  voice.say(sp2_MOTOR);
  voice.say(sp2_IS);
  voice.say(sp2_ON);
  voice.say(sp2_FIRE);
  voice.silence(1000);
  delay(2000);
}

This compiles and connects with the BT speaker, and noises come through, but the sound quality is almost non-existent. Audio file recording follows:

TalkiePCM_A2DP_BTSpeaker_SoundFile.mp4

The last parts of some of the words are barely distinguishable, and it seems like a more extreme example of the SimpleTTS output: severely truncated words.

Any thoughts about what might be going wrong here appreciated.

[pschatzmann]

I will have a look today: I cleaned up your code a bit by removing all the unnecesary lines. Please use the proper code quoting rules

So the issue seems to be on the A2DP side...

[pschatzmann]

First I fixed the problem with the dot/point in the simple-tts and made sure that the library is updated to the latest convention of the Audio Tools.

Then I tested with the example sketch using simple-tts with a2dp and did not notice any issues. Try to update all libraries and mybe test with another bluetooth speaker. Is the example sketch for you breaking up as well ?

I also added an talkie to a2dp example that was not working because talkie is just writing too many individual samples instead of a buffer of samples: I added a BufferedStream into the chain and then it was working perfectly as well.

[104TMR]

I downloaded and updated both AudioTools and SimpleTTS with your new libraries (many thanks!).
TalkiePCM now works perfectly, on both the BT speaker and on a pair of BT earbuds.
SimpleTTS still has problems, however, whether its the speaker or the BT earbuds.
I notice that the very first speech transmission is perfect.
All subsequent transmissions lose the first part of the speech.
This also happens when I upload the example SimpleTTS sketch (which just counts up incrementing integers). Eg. "23" becomes "...3", etc.
Not sure where to go from here to fix this.
Maybe I'll just work with TalkiePCM from here...

[pschatzmann]

Some more thoughts: try to make sure that you also have the latest libhelix version or try with libmad

[104TMR]

I have downloaded and reinstalled the latest version of AudioTools (which I understand incorporates the libhelix libraries).
Running the SimpleTTS example still produces the same result (truncated opening speech, or what I'm calling 'droput effect').

However, along another line, I did notice in the AudioTools Wiki, that you say that AudioLogging should be turned off in order to "...avoid any negative impact on the audio quality."
So, I commented out the AudioLogger line in the SimpleTTS-A2DP example, and found that the 'drop-out effect' is much reduced.
It is still there, but the improvement is noticeable.
Not sure if this indicates any particular place to look in the code for a possible solution(?).

I also downloaded and installed libmad, and looked at the example ("mp3_write") for that library and tried updating the Simple TTS example file with the libmad library in a similar way, as follows:

#include "AudioTools.h"
//#include "AudioTools/AudioCodecs/CodecMP3Helix.h"
#include <MP3DecoderMAD.h>
#include <mad_log.h>

using namespace libmad;

#include "AudioTools/AudioLibs/A2DPStream.h"
#include "SimpleTTS.h"

const char* name = "Soundcore Space A40"; 

AudioInfo from(24000, 1, 16);  // TTS                                         
AudioInfo to(44100, 2, 16);   // A2DP                                        

NumberToText ntt;
A2DPStream a2dp; 
FormatConverterStream out(a2dp);
// MP3DecoderHelix mp3;
MP3DecoderMAD mp3();
AudioDictionary dictionary(ExampleAudioDictionaryValues);
TextToSpeech tts(ntt, out, mp3, dictionary);

int64_t number = 1;

void setup(){
    Serial.begin(115200);
    AudioLogger::instance().begin(Serial, AudioLogger::Info);
    Serial.println("Starting...");
    mp3.begin();

    // setup conversion to provide stereo at 44100hz
    out.begin(from, to);

    // setup a2dp
    auto cfg = a2dp.defaultConfig(TX_MODE); 
    cfg.name = name;
    cfg.silence_on_nodata = true; // allow delays with silence
    a2dp.begin(cfg);
    a2dp.setVolume(0.3);

    Serial.println("A2DP Started");
}

void loop() {
    // speach output
    Serial.print("Providing data: ");
    Serial.println(number);

    ntt.say(number);

    number +=1;
    delay(1000);
}

However, this returns a number of compiler errors, the first of which is:

error: no matching function for call to 'simple_tts::TextToSpeech::TextToSpeech(simple_tts::NumberToText&, audio_tools::FormatConverterStream&, libmad::MP3DecoderMAD (&)(), simple_tts::AudioDictionary&)'

Clearly, I'm not using the libraries correctly, but I have to admit I'm at a loss to know where to start to get the functions properly referenced, etc.
How should the libmad library be used in the context transmitting SimpleTTS to A2DP?

[pschatzmann]

Nop, libhelix is a separate project that needs to be installed like any other codec.

The speach is stored as mp3 in PROGMEM, so the tts needs a codec to decode it to PCM.
In all the examples I used libhelix.

Example with Helix:

#include "AudioTools.h"
#include "AudioTools/AudioCodecs/CodecMP3Helix.h"
#include "SimpleTTS.h"

I2SStream out;
VolumeStream volume(out);
MP3DecoderHelix mp3;
AudioDictionary dictionary(ExampleAudioDictionaryValues);
NumberUnitToText utt;
TextToSpeech tts(utt, volume, mp3, dictionary);

You can look up the corresponding values in the table of this wiki and just replace them:

Example with Libmad:

#include "AudioTools.h"
#include "AudioTools/AudioCodecs/CodecMP3MAD.h	"
#include "SimpleTTS.h"

I2SStream out;
VolumeStream volume(out);
MP3DecoderMAD mp3;
AudioDictionary dictionary(ExampleAudioDictionaryValues);
NumberUnitToText utt;
TextToSpeech tts(utt, volume, mp3, dictionary);

Of cause you need to have this decoder library installed as well..

[104TMR]

So, I've had a go at incorporating libmad into the SimpleTTX example sketch, as follows:

#include "AudioTools.h"
#include "AudioTools/AudioCodecs/CodecMP3MAD.h"
#include "AudioTools/AudioLibs/A2DPStream.h" //Old
#include "SimpleTTS.h"
//I2SStream out;  /Remove from new (A2DP used instead of I2S)
A2DPStream a2dp; //Old
FormatConverterStream out(a2dp); //Old
VolumeStream volume(out);
MP3DecoderMAD mp3;
AudioDictionary dictionary(ExampleAudioDictionaryValues);
NumberUnitToText utt;
TextToSpeech tts(utt, volume, mp3, dictionary);

AudioInfo from(24000, 1, 16);  // TTS                                         
AudioInfo to(44100, 2, 16);   // A2DP  

//const char* name = "Soundcore Space A40";                         // Replace with your device name
const char* name = "LEATHER DRUM2+";                         // Replace with your device name

int64_t number = 1;

void setup(){
    Serial.begin(115200);
    AudioLogger::instance().begin(Serial, AudioLogger::Info);
    Serial.println("Starting...");
    mp3.begin();

    // setup conversion to provide stereo at 44100hz
    out.begin(from, to);

    // setup a2dp
    auto cfg = a2dp.defaultConfig(TX_MODE); 
    cfg.name = name;
    cfg.silence_on_nodata = true; // allow delays with silence
    a2dp.begin(cfg);
    a2dp.setVolume(0.3);

    Serial.println("A2DP Started");
}

void loop() {
    // speach output
    Serial.print("Providing data: ");
    Serial.println(number);
    utt.say(number);
    number +=1;
    delay(1000);
}

Unfortunately it bombs out with a runtime exception (Guru Mediatation error):

A2DP Started
Providing data: 1
[I] NumberToText.h : 35 - say(number='1', decimal='')
[I] TextToSpeech.h : 57 - say: ONE
[I] StreamCopy.h : 50 - buffer_size=1024
[I] AudioEncoded.h : 75 - virtual void audio_tools::EncodedAudioOutput::addNotifyAudioChange(audio_tools::AudioInfoSupport&)
[I] ResampleStream.h : 145 - setStepSize: 0.544218
[I] ResampleStream.h : 129 - -> ResampleStream:
[I] AudioTypes.h : 128 - in: sample_rate: 24000 / channels: 1 / bits_per_sample: 16
[I] AudioTypes.h : 128 - out: sample_rate: 44100 / channels: 1 / bits_per_sample: 16
[I] AudioStreamsConverter.h : 454 - -> NumberFormatConverterStream:
[I] AudioTypes.h : 128 - out: sample_rate: 24000 / channels: 1 / bits_per_sample: 16
[I] AudioStreamsConverter.h : 133 - --> ChannelFormatConverterStream
[I] AudioTypes.h : 128 - out: sample_rate: 24000 / channels: 2 / bits_per_sample: 16
[I] AudioTypes.h : 128 - in: sample_rate: 24000 / channels: 1 / bits_per_sample: 16
[I] AudioTypes.h : 128 - out: sample_rate: 24000 / channels: 2 / bits_per_sample: 16
[I] AudioTypes.h : 128 - out: sample_rate: 44100 / channels: 2 / bits_per_sample: 16
[I] VolumeStream.h : 199 - setVolume: 1.000000 at 0
[I] StreamCopy.h : 163 - StreamCopy::copy  1024 -> 1024 -> 1024 bytes - in 1 hops
[I] StreamCopy.h : 163 - StreamCopy::copy  1024 -> 1024 -> 1024 bytes - in 1 hops
[I] StreamCopy.h : 163 - StreamCopy::copy  1024 -> 1024 -> 1024 bytes - in 1 hops
[I] StreamCopy.h : 163 - StreamCopy::copy  288 -> 288 -> 288 bytes - in 1 hops
[I] TextToSpeech.h : 57 - Guru Meditation Error: Core  1 panic'ed (LoadProhibited). Exception was unhandled.

Core  1 register dump:
PC      : 0x40093cc1  PS      : 0x00060530  A0      : 0x801b6524  A1      : 0x3ffd7de0  
A2      : 0x00000000  A3      : 0xfffffffc  A4      : 0x000000ff  A5      : 0x0000ff00  
A6      : 0x00ff0000  A7      : 0xff000000  A8      : 0x00000000  A9      : 0x3ffd80b0  
A10     : 0x00000003  A11     : 0x00060523  A12     : 0x00060520  A13     : 0x0000ff00  
A14     : 0x00ff0000  A15     : 0xff000000  SAR     : 0x00000004  EXCCAUSE: 0x0000001c  
EXCVADDR: 0x00000000  LBEG    : 0x40093cc1  LEND    : 0x40093cd1  LCOUNT  : 0xffffffff  

Backtrace: 0x40093cbe:0x3ffd7de0 0x401b6521:0x3ffd7df0 0x401b32d9:0x3ffd8100 0x400dbe1f:0x3ffd81c0 0x400dcf1d:0x3ffd81e0 0x400dcd0d:0x3ffd8220 0x400dceaa:0x3ffd82f0 0x400e8e09:0x3ffd8380

ELF file SHA256: d474114e1fad3814

Rebooting...

Unfortunately, again, I don't understand the libraries well enough to work out where the error might be.

Perhaps I'll just go with TalkiePCM for now, as it works very well, and will achieve what I'm looking for.

[pschatzmann]

The logic was somehow generating a null pointer execption.
I committed a correction to the simple-tts library.

If the audio is breaking up, you can play around with the following A2DP parameters

    auto cfg = a2dp.defaultConfig(TX_MODE); 
    cfg.name = name;
    //cfg.silence_on_nodata = true; // allow delays with silence
    cfg.delay_ms = 0;
    cfg.buffer_size = 1024 * 7;
    a2dp.begin(cfg);

The above parameters were working for me...

[104TMR]

I downloaded and reinstalled the version of AudioTools from GitHub (although it states there that the last update was 3 weeks ago).
I understand SimpleTTS (your latest commit) will be incorporated in the AudioTools library(?).
However, the SimpleTTS example using libmad still shows the same runtime exception error.
Am I missing something?
Many thanks...

[pschatzmann]

You would not download the released version, but the main branch!
Just click on the Code button.

If you click on the Commits, you will see that the last commit was on Oct 24, 2024

[104TMR]

I'm sorry, Phil, I'm not a sophisticated programmer, and I do not understand where the different codes and 'commits' go in Github.
Could I ask for some more detailed directions as to just where I should get the latest updated files?
I have clicked on the code button, and downloaded the .zip file:

What else should I do?

I also had a look at the Commits page, and while, Yes, I see some files with commits dated yesterday, I do not know what to do with the files here:

Your advice appreciated.
Regards...

[pschatzmann]

How did you install this library in the past ?

You don't do anything with the commits: this just shows you the latest changes that you get when you download the main branch.

[pschatzmann]

No, it is it's own project that has it's own lifcycle

[104TMR]

I've found the "pschatzmann/arduino-simple-tts" portfolio, and downloaded and installed it.
Then flashed the SimpleTTS-A2DP sketch to the ESP32, and, then...Voila! - No more runtime exceptions!
Finally got there, and thanks for your patience.
However, the "drop-out effect" is still there, unfortunately.
I also tried incorporating the adjusted A2DP parameters you proposed in an earlier post, but they don't seem to have any effect.
A bit sad, but I think I'm going to have to accept that perhaps SimpleTTS-A2DP isn't going to work perfectly with my system, for some inexplicable reason.

[104TMR]

Phil, following on from the previous discussion, I have reverted to Simple-TTS (after trying to use TalkiePCM, I found it had problems, too, but we can review them another time - that's not the issue I would like to address here).
I have been able to get around the beginning speech dropout problem by introducing a 'silence' segment before speaking the first word of a sentence.
So I have now tried to combine the SimpleTTS-A2DP into the main project, which is a thermocouple data logger with TFT display of data (using Bodmer's TFT_eSPI library).
While both functionalities (ie. data logger/display and SimpleTTS) loaded and worked fine independently previously (flashed to an ESP32 WROVER 16MB flash memory, 4 MB PSRAM), when I add in the SimpleTTS-A2DP functions, it won't compile and reports 'IRAM0 segment data does not fit' and 'iram0_0_seg overflowed by 340 bytes'.
Have you experienced IRAM overflow before, and are there any features in AudioTools and/or A2DP/SimpleTTS features that could be modified to use less IRAM?
I have done some reading around, and it looks like a difficult problem to manage.
Apparently Bluetooth usage takes up quite a lot of IRAM, as do large array allocations.
I'm running ESP32 Arduino board definitions 2.0.14 (TFT_eSPI won't run on any higher versions), and I've found there's a 'memory.ld' file in "C:\Users<User Name>\AppData\Local\Arduino15\packages\esp32\hardware\esp32\2.0.14\tools\sdk\esp32\ld" directory, which seems to allow allocations between IRAM and DRAM.
I've tried changing the lengths of IRAM (increase by 0x2k) and DRAM (decrease by corresponding 0x2k), and while the code now compiles without complaint, the program just goes into an endless SW reset cycle when it tries to run.
So clearly I'm not changing the right things by the right amounts in this avenue.
If you have any suggestions about how this IRAM overrun issue might be managed, I'd be very grateful.

[pschatzmann]

If this is a PROGMEM issue: what Partition Scheme are you using ?
If it is a RAM issue, try to use PSRAM. Do you have some big arrays as global variables in your sketch ?

[104TMR]

Thanks for your response.
I don't think it's a progmem issue, but the flash partition scheme is 12MB app and 2MB spiffs.
Isn't progmem stored in flash, hence will not affect IRAM?
Re. large arrays, no, I'm not using them, and the few arrays I do have are only 7 x 10 elements, etc.
I've read that making data into a const type forces them into flash memory, but of course, this is not much use if the variables need to be dynamic within the program.
Have you ever tried adjusting the IRAM/DRAM allocations in the ESP32/Arduino IDE?
Having an overflow of 340 bytes doesn't sound like much, and it would seem a small tweak to IRAM/DRAM to try and get it accommodated.
I tried changing the memory.ld file to increase IRAM by 500 bytes, but the program won't run with this change.

[pschatzmann]

No, I have never seen this and if you check my projects, I do not use the IRAM_ATTR qualifier anywhere.

You might try if some prior ESP32 core versions are working for you...

[104TMR]

Thanks for a great suggestion - I rolled the esp32 board core version back to 2.0.13 (from 2.0.14), and... Voila! - now the code compiles and runs the way I expect it should! I have spent dozens and dozens of hours trying to get to the bottom of this problem, and it turns out to be a board core definition issue.
A bit frustrating, but so good to find a solution.
Now, may I go back to a problem mentioned in an earlier post in this thread, WRT TalkiePCM showing similar 'dropout' behaviour as I reported with Simple-TTS earlier?
I have written a sketch that uses/tests TalkiePCM to take random numbers that fall across a range of -2000.0 to +2000.0, and speak them as 'BiNumerals'. BiNumerals take a number and speak it as sets of single, or double numbers, such that a number such as 1213.3 doesn't get spoken as "One Thousand Two Hundred and Thirteen Point Three", but as "Twelve Thirteen Point Three".
The sketch just rolls through random numbers and TalkiePCM speaks them, and everything in this sketch works fine. No dropouts occur at the beginning of each spoken random number. This sketch is attached as "ESP32WROVER_TalkiePCM_BiNumeral_ToA2DP.ino".
I've also written a second sketch, similar to the first, but instead of TalkiePCM speaking random numbers, it speaks numbers that are entered via the keyboard into the Message field of Serial Monitor. This sketch is attached as "ESP32WROVER_TalkiePCM_BiNumeral_KbdInput_ToA2DP.ino".
You will notice that the loop section of this second sketch has two lines:
"voice.say(spPAUSE1);
voice.say(spPAUSE2);"
These are placed just before the call to "VoiceBiNumeral", and if they are not there, then TalkiePCM drops the beginning syllable(s) of the number to be spoken.
At least it does on my system.
Could I ask if you could check out the behaviour of these two sketches on your system, and if you comment out the two pauses (spPAUSE1 and spPAUSE2) in "ESP32WROVER_TalkiePCM_BiNumeral_KbdInput_ToA2DP" loop section, and find that TalkiePCM misses the opening syllable(s) on your system, then it will be a demonstration of the dropout effect that I have been finding on my system.
I'd be very appreciative if you could test this out, and I look forward to seeing what you find.
Thanks for your help.
ESP32WROVER_TalkiePCM_BiNumeral_KbdInput_ToA2DP.zip
ESP32WROVER_TalkiePCM_BiNumeral_ToA2DP.zip

[pschatzmann]

Oh my good: 2.0.14 ? The actual released version is 3.0.7 and 3.1 is in R3

[104TMR]

Ah, Yes. TFT_eSPI won't operate with board core >2.0.14.