@Wolle Ich habe neben der Arbeit ziemlich einen ESPuino nebenher rödeln und höre da fast immer Webradio. Und zwar im Speziellen das hier: bassdrive.com/bassdrive.m3u (wenn man kein Drum’n’Bass mag ist das eher nix, hehe).
Was mir da vergleichsweise oft passiert ist die Anzeige „Slow stream“ (oder so ähnlich - weiß es gerade nicht auswendig). Manchmal hört man das nicht, aber oft doch schon und manchmal kriegt man das dann auch nicht mehr gerettet. Außer man legt die Karte halt neu auf.
Frage an dich: Siehst du da innerhalb der Lib vielleicht ne Möglichkeit, dass man den Stream dann neu startet? Weil ansonsten bin ich am überlegen, ob ich in ESPuino vielleicht versuche, einen solchen Mechanismus einzubauen.
Zur Gesamteinschätzung: Dieser Radiosender kommt aus Amerika, es gibt jedoch auch eine Adresse, die nach uk zeigt. Grundsätzlich kommt es auch auf dem Laptop zB mal vor, dass es Streamingprobleme gibt, allerdings ist das recht selten. Mitunter höre ich auch ganz Tage ohne irgendwelche Probleme, aber früher oder später treten normalerweise welche auf.
Also ich wollte einfach nur mal hören, ob du das Möglichkeiten innerhalb der Lib siehst, wie man das angehen könnte. Ansonsten versuche ich mich extern an dem Problem .
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.
.