Hallo Torsten,
die Frage lässt sich pauschal nicht ganz einfach beantworten. Es gibt einen InputBuffer, der nach dem Prinzip des „leaky bucket“ arbeitet. Das ist also ein Eimer, in dem die Audiodaten aus dem Netz eingefüllt werden, und der über ein Leck die Daten an den Dekoder weitergibt. Die Datenmenge, die an den Dekoder abfließt ist vorgegeben, durch die SampleRate, der KompressionsRate…
Somit ist also der Zufluss interessant und tatsächlich füllt sich in den meisten Fällen der Eimer. Bei Verwendung eines PSRAM ist der Buffer ausreichend groß bemessen. Die meisten Radiostationen liefern bei verzögerungsfreier Dekodierung etwa 60…200KB Daten im Voraus und das ist dann der Füllstand und kann mit audio.inBufferFilled() abgefragt werden.
DIe Daten die abfließen werden in „Paketen“ dem Dekoder übergeben. Ist der Grund des Eimers sichtbar, also das Datenpaket wahrscheinlich nicht ausreichend groß genug, wird die Meldung „slow stream, dropouts are possible“ ausgegeben. Der Dekoder bekommt dann keine Daten um einen „MAINDATA_UNDERFLOW“ zu vermeiden. Der I2S-DMA kann einige Zeit überbrücken, so dass es nicht immer zu Tonaussetzern kommt.
Nach meiner Erkenntnis ist nicht der ESP32 das Problem, meistens auch nicht die Internetverbindung, sondern der WiFiClient ist der Flaschnhals.
Ich habe versucht durch Änderung der Parameter etwas zu verbessern, das ist mir nicht gelungen. Es gibt hier ein Repo GitHub - schreibfaul1/ESP32_Arduino_ESPIDF in meinem Github, bei dem über menuconfig Einstellungen verändert werden können und Arduino damit neu kompiliert wird. Vielleicht habe ich an den falschen Stellschrauben gedreht, Möglichkeiten gibt es viele.
Eine andere Idee ist es den WiFiClient zu ersetzen. Dazu fehlt mir das Wissen, gerade hinsichtlich SSL/mbedTLS.
Wer weitere Ideen hat, oder Möglickeiten zur Verbesserung sieht, kann das hier gene posten.