Mir ist aufgefallen, dass es im Master derweil Probleme mit MQTT gibt, wenn man von SD abspielt. Und zwar derart, dass es ganz übel knackt.
Das muss jetzt erstmal behoben werden. Vorher schaue ich mir keine PRs mehr an.
Habe mir das jetzt (für’s Erste) mal angeschaut und festgestellt, dass das Problem erst ab folgendem Commit auftritt: fix ESP crashes during playing local MP3 file with ID3 Tag v2.2 · schreibfaul1/ESP32-audioI2S@fe1f37c · GitHub.
Davor ist alles fein.
Settings:
- Standard für ESPuino-mini
- +MQTT
- -RC522
- +PN5180
- +INVERT_POWER
- Power 32 => 115
Ohne MQTT keine Probleme. Mit, und zwar auch bei Webstream, gehen die Probleme mit dem o.g. Commit los.
@Wolle Ich hatte demletzt mal hier was geschrieben, dass es vielleicht irgendwie ein Speicherproblem geben könnte.
Fällt dir da rein zufällig irgendwas zu ein?
Ich habe hier keinen MQTT-Broker und kann das leider auch nicht wirklich testen, aber:
Hatte mal MQTT einkompiliert und dann heftige Aussetzer.
Könnte das Problem nicht auch daran liegen das die MQTT Implementierung keinen eigenen Task verwendet sondern Alles im Hauptthread macht?
Bin da jetzt nicht so im Code drin aber auf den ersten Anschein könnten einige Methoden in loop() blockierend wirken und dann das füttern der Audiodaten stören?
Nur so eine Idee…
Ja schon, aber stutzig macht mich:
a) Bis zum Commit vor kurzem lief es.
b) Bei dem Problem, das ich kürzlich verlinkt hatte, hat die Allokation von nem Leerstring gereicht, um das Problem auszulösen.
c) Ich bin dann vorhin mal hingegangen und habe den Loop-Aufruf von MQTT mal nur in jede zehnte Loop gelegt. Das hat das Problem aber kein bisschen verbessert. Das hätte ich aber irgendwie erwartet, wenn es wirklich ein Problem mit der Rechenzeit ist.
Also speziell wegen b habe ich irgendwie so ein bisschen die Vermutung, dass das was mit Heap-Fragmentierung und/oder PSRAM zu tun hat. Ich hatte vor Ewigkeiten mal Speicherprobleme mit statischem Speicher. Das hat damals aber zu Bootloops geführt und es hat ewig gedauert, bis ich den Zusammenhang verstanden hatte.
Das ist für mich (noch) nicht nachvollziehbar. Die Änderung beschriebene wird nur bei der alten ID3 V2.2 wirksam und dann auch nur vor dem Audioblock. Das ist während der Audioausgabe nicht aktiv. Das Knacken hat sicher andere Ursachen. Bitte grenzt den Fehler weiter ein, oder überprüft mit „HighWatermark“ ob die Stacks ausreichend bemessen sind.
Kannst mal zum Testen test.mosquitto.org (als Broker) verwenden, da können einfach alle so was hin „pusten“…
(und auch alle das lesen, daher nichts geheimes hinschicken 
)
Hab jetzt mal MQTT mit einkompiliert:
Zunächst hatte ich noch die voreingestellte IP (192.168.2.3 oder so) drin und damit hat sich der ESPuino komplett weggehängt bis zum Timeout. Keine Eingaben mehr möglich!
Ist eigentlich auch klar, die IP gibt es hier nicht und der MQTT-Client blockiert bis zum Timeout. Nach dem Eintragen des Testservers klappte dann Alles wie gewünscht.
Aus meiner Sicht müsste der ganze MQTT-Teil in einen eigenen Task um nicht zu blockieren.
Wenn der Broker langsam reagiert oder im Netzwerk Verzögerungen verursacht würde dies die Audio-Aussetzer erklären…
Ja, muss ich vielleicht mal testen, das in einen eigenen Task zu stecken.
Unter Arduino2 tritt das Problem übrigens nicht auf habe ich gerade gesehen. Da ist auch die WebGUI schneller, wenn was nachgeladen werden muss.
Gibt es hier schon Lösungen?
Ich bin gerade über das Problem gestolpert und finde aktuell keine Lösung für mich.
Leider habe ich die alte Firmware nicht mehr zur Verfügung und Arduino2 fällt bei mir leider raus, da der deepsleep nicht funktioniert.
Nein, gibt es nicht. Das Problem mit dem Knacken ist auch schon aufgetreten in einer älteren Revision, wenn man zB in der main.cpp ein paar simple Zeilen Code eingefügt hat, die mit MQTT gar nix zu tun haben und auch nicht viel CPU-Zeit gefressen haben. Also das scheint irgendwie ein Speicherproblem zu sein und das wird mit einem Task eher schlimmer als besser.
Es gibt, wenn du das nicht selbst programmieren möchtest, aus meiner Sicht zwei Möglichkeiten:
a) Wechsel auf eine ältere Revision und kompilierst dir die Version neu (*). Beispielsweise läuft auf dem ESPuino von meinem Sohnemann die 20221230-1. Da gibt’s keine Probleme.
b) Du wechselst auf neuere Hardware. Mit der mini4L hatte ich das Problem mit dem Deepsleep nicht mehr.
Für mich selbst scheidet die zweite Variante auch aus (mir geht’s also nicht besser), da das Gehäuse auf Kopfhörerplatine basierend auf UDA1334 / PJ306b angepasst ist und die mini4L halt keinen IDC-Anschluss mehr hat.
(*) Das geht mit git ja ohne Probleme. Der Code muss lokal ausgecheckt sein und dann halt so, wie es hier beschrieben ist: git checkout - How do I revert a Git repository to a previous commit? - Stack Overflow
- Code mit git auschecken.
-
git checkout -b old-state d0c0ef8
Letztgenanntes bewirkt, dass du einen extra Branch lokal bei dir dafür anlegst, der in diesem Falle „old-state“ heißt. Du kannst dem auch einen anderen Namen geben (würde Sinn machen). Vorteil an diesem Branch ist einfach, dass du da immer wieder raus- und reinspringen kannst, wenn du das möchtest. Der lebt nur lokal bei dir und da ändert sich nix dran.
Ganz grundsätzlich kannst du dir auch die Commit-History anschauen (Commits · biologist79/ESPuino · GitHub) und versuchen, zu einem neueren Punkt zu springen. Und springst halt nur soweit, wie es keine Probleme gibt.
1 „Gefällt mir“
Ich konnte jetzt für mich eine Lösung finden.
Ich habe in der platformio.ini die folgende lib angepasst:
lib_deps =
xhttps://github.com/schreibfaul1/ESP32-audioI2S.git#be30592
(das x steht vor dem https, da ansonten die Forum den Code direkt in einen Link umwandelt)
damit tritt bei mir kein knacken mehr auf und ich kann MQTT nutzen.
1 „Gefällt mir“
Das ist ja spannend. Kannst du das eventuell noch weiter einschränken? Ist es direkt bei diesem Commit wo es zuletzt funktioniert hat und danach nicht mehr?
Das ist der Commit, den Biologist am Anfang des Beitrags erwähnt hat, nur einer davor.
Ich habe nicht wirklich getestet, on danach der Fehler wieder auftritt.