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.