Vielen Dank dir!
Wenn wir das Problem voll verstanden oder weitere Abhängigkeiten geklärt haben können wir da ja dann nochmal draufschauen…
Werde eine Rückmeldung geben, wenn ausreichend Tests durchgeführt wurden…
War die Änderung aufgrund von einem Problem oder einfach so? Wollte erstmal nicht nur reverten, weshalb ich auf diese Werte gegangen bin…
Okay, habt ihr mal versucht vor dem audio.loop() ein vTaskDelay von etwa 1ms zu setzen? Durch den internen Task ist im loop() nicht mehr viel zu tun, manchmal gar nichts und das würde anderen Tasks mehr Zeit geben.
Ja, das ist bereits der Fall. Jeden Zyklus im AudioPlayer warten wir nach dem loop() aufruf eine ms. Die Probleme mit den Unterbrechungen waren aber auch weniger auf Core 1 (wo der Audioplayer läuft) sondern vor allem auf Core 0, wo der interne Task läuft.
Aber das ist alles noch vorläufig…
Nur zur Vollständigkeit.
Ich nutze die Platine ESPuino-mini 4Layer in REV 3. Zusammen mit einem Lolin D32 pro (Li-Ion), und dem PN5180.
- Der Neopixel hat 24 LED
- kein MQTT
- Dafür an 3 PINs des Portexpander jeweils eine LED (Taster)
Ich habe immer noch die Vermutung, dass die Spannung mit verantwortlich ist.
Ich habe zumindestens alles neu kompiliert und jetzt habe ich nur einen Sprung trotz langer Verwendung provozieren können.
Ich warte mal bis der Akku noch etwas runtergenuttelt ist, dann versuche ich es noch einmal und dann werde ich mal die LEDs abschalten
Ich habe meinen ESPuino inzwischen mehrere Stunden mit dem neuesten dev-Branch und Arduino 3 in einer Schleife laufen lassen - und zumindest hier auf dem Schreibtisch mit USB-Stromversorgung gab es bislang keine Abbrüche mehr. 
Vorher hatte ich das (mit der problematischen Version) auch mit CBR-MP3s getestet, hier trat der Fehler auch auf (interessanterweise wieder beim selben Song…). Nicht allerdings bei einem MP3-Webstream. Die SD-Karte würde ich dennoch tendenziell ausschließen, ist eine 16GB Class 10/U1-Karte. Sollte das Problem wieder auftreten, hätte ich noch eine U3-MicroSD hier, um ganz sicher zu gehen.
1 „Gefällt mir“
Dann wird es wohl langsam Zeit im DEV-Branch auf Arduino 3 und die neueste Audio-Bibliothek zu wechseln., es ist ja bereits Alles vorbereitet, leider bislang wenig bis null Rückmeldungen.
Ich frage mich aber warum ich das Problem überhaupt nicht nachvollziehen kann trotz gleicher Konfiguration & Hardware, wo liegt die Ursache?
Ich nehme mir vor, dev nochmal kurzfristig zu testen mit Arduino3.
1 „Gefällt mir“
Das frage ich mich auch - aber selbst bei mir ließ sich das Problem ja nicht provozieren, sondern trat immer zufällig auf. Vielleicht auch relevant: bei den Tests ist es zwei Mal passiert, dass sich der ESPuino (genauso zufällig) neugestartet hat. Das ist mir ansonsten noch nie aufgefallen. Leider war keine serielle Verbindung angeschlossen, sodass die Ursache nicht geloggt wurde. Mit Verbindung zum PC konnte ich es bislang nicht nachstellen. Eventuell doch was mit dem störrischen RFID-Leser?
Egal warum das Problem hier so war, ich würde es einfach gerne nachvollziehen & verstehen 
So wie ich das sehe, sind die Aussetzer tief unten in der Audio-Library: Änderung des DMA-Buffers, DMA = Direct Memory Access = ein Speicherbereich, auf den der Prozessor für zeitkritische Anwendungen schnell zugreifen kann = bisserl magic
Der Fix, Umstieg auf Arduino 3 + aktuelle Audio-Library: Das ist ein kleinerer & unproblematischerer Schritt als von Arduino 1 auf 2. Für mich passt da alles. Aber z.B. MQTT ist erst letzte Woche dazugekommen, also gerne nochmal testen! Von meiner Seite können wir das gern updaten, das Angebot gibt es schon seit Mai 2024, muss halt auch Alles andere laufen..
Das Problem ist auch mit der Umstellung des Buffers nicht weg, allerdings ist immer noch absolut nicht nachvollziebar warum es nur bei einigen auftritt.
Habe jetzt nochmal eine andere SD-Karte und auch dort tritt es noch mit dem „Fix“ auf.
Aus meier Sicht spricht nichts gegen den Umstieg auf Arduino 3.
Das Problem ist auf beiden Ständen gleich .
So, habe mal wieder ein Update:
- nach einigen Versuchen hatte ich einen Stand, bei dem es auch mit den geänderten Buffern und neuster Audio-Lib (V3.2) ziemlich häufig aufgetreten ist
- mit dem neusten Stand deultich seltener, aber trotzdem weiterhin vorgekommen
- Habe dann den Audio-Taks aufgelöst
Es kommt zwar immer noch ganz vereinzelt zu den Encoder-Fehlern (wirklich nur noch ganz selten), allerdings hüpft jetzt die Position nicht mehr und man bleibt auch nicht mehr am Titelende stehen. Ich konnte die Fehler nur im Log sehen, aber nicht hören.
Habe erstmal allen Code gleich gelassen und nur den Audio-Task aufgelöst.
Werde mal einen MR dafür erstellen, falls noch mehr Testen wollen…
Hatte wirklich nicht erwartet, dass das so einen großen Unterschied macht, aber @Wolle hatte hier absolut recht!
Weitere Bedingung ist allerdings, dass der RFID-Task (PN5180) nicht mehr auf Core 0 laufen sollte, das scheint aber kein Problem zu sein, wenn dieser weniger blockierend ist…
Update: Leider doch noch nicht die Lösung für das Problem. Es tritt weiterhin auf. Scheinbar läuft bei uns aktuell einfach zu viel nebenher für die Audio-Lib unter manchen Bedingungen. Werde weitermachen, die Auflösung des Tasks ist aber vermutlich in jedem Fall sinnvoll…
Habe noch paar Ideen und melde mich dann wieder. Sorry, für die falsche Hoffnung.
Was wirklich richtig gemein ist: Es ist teilweise weg. Dann startet man den ESPUINO neu, und plötzlich ist es wieder da. Hier passieren irgendwelche sehr komischen Dinge…
3 „Gefällt mir“
So, ich wage es nochmal …
Was ist jetzt anders:
- Audio-Taks wurde aufgelöst und ist jetzt in der Main-Loop
- Led-Task wurde ebenfalls aufgelöst und ist in der Main-Loop
- Fast-LED lib wurde aktualisiert und ein Flag im Treiber geändert (leider scheint user ESP32 nicht die Clockless-SPI zu unterstützen, das wäre die vermutlich beste Lösung) - bei mir tritt damit jetzt kein ghosting mehr auf den LEDs auf.
- @Wolle hat ein Bug gefixed, bei dem das Setzen der Position nicht mehr ging
- Sowohl der main-loop-Task als auch der PeriodicTask laufen jetzt auf Core 1! Das sorgt dafür, dass es nicht mehr zu den Problemen mit dem Audio-Buffer duch das Multitasking kommt. Das war in der letzen Version durch Semaphoren gelöst, die mittlerweile wieder entfernt wurden und wodurch es jetzt in diesen seltenen Sondersituationen zu Problemen kommt. Vielen Dank an @Wolle für all die Ideen und Ansätze zum eingrenzen und besseren verstehen!
- Habe dann ein paar Dinge auf Core 0 verschoben. Hat den Vorteil von einer klaren Trennung und höherer Stabilität. Bis jetzt einziger Nachteil ein geringerer Upload-Speed im Webserver, dafür aber ein problemloser Betrieb von LED und Audio während dem Upload möglich. Hier können wir über die beste Lösung diskutieren (hängt vor allem am async-tcp-task, dass dieser auf einem anderen Core als der Wlan-Task laufen sollte). Auch der Stand zwei Commits früher funktioniert wunderbar, mit gefällt diese Lösung aber besser.
- Nur noch ein Task-Delay in der main-loop. Scheint der stabilste Weg zu sein
- Deutlich reduzierte CPU-Last und gleichmäßig verteilte Last in den Standard-Szenarien
Offene Punkte:
- Feedback durch testen!
- Audio-loop kann durch das Auflösen des Tasks jetzt blockierend wirken. Z.B. ca. 400 ms beim Wechsel eines Songs. Eventuell müsste man da noch ran und diese Spezial-Fälle weniger blockierend abändern, das halte ich aber für gut möglich. Hier sollten wir uns mit @Wolle abstimmen was die beste lösung sein könnte.
- Wenn alles passt, muss ich vermutlich noch paar Stellen aufräumen
Bin gespannt auf eure Rückmeldungen!
(Durch das auflösen der Tasks könnte man jetzt auch noch ein paar Dinge verschönern, wollte aber jetzt erstmal so viel wie möglich den originalen Code beibehalten.)
5 „Gefällt mir“
Ich hatte jetzt ein wenig Zeit den PR zu testen:
@Joe91: Es läuft zunächst alles wie gewünscht, danke für deine Arbeit:+1:
Wir sind uns ja einig, dass Audio Task-im-Task entfernt werden soll, und das klappt mit diesem PR sehr gut. Audio-Aussetzer konnte ich bisher mit den hier angefügten MP3-Files nicht nachvollziehen und Aussetzer gibt es mit diesem PR auch nicht, check!
Was mir aufgefallen ist:
- Beim Webupload wird der LED-Task nicht pausiert, die LEDs blinken munter weiter. Als Folge erreiche ich nur noch eine Uploadrate von unter 100 KB, zuvor > 400 KB
- Die FastLED-Bibliothek wurde geforkt, um das Flackern/Ghosting zu verhindern. Das klappt aber nicht, denn die LEDs flackern bei ca. 40 % Fortschritt munter weiter. Das ist ein anderes Problem, ich würde es im PR rückgängig machen weil anderes Thema
Kann es noch jemand testen?
Bin mit den LEDs auch nochmal weitergekommen und habe auch das wieder aktivieren des Tasks vorbereitet.
Scheinbar macht es jetzt auf Arduino 3 mit der led-strp-lib einen unterschied, aus welchem Core das init aufgerufen wird, da dort noch eine alte Version des RMT Treiber verwendet wird, der damit irgendwelche Probleme hat. Wenn ich die LEDs im Core 1 initialisiere, ist bei mir das Problem mit dem Flackern ebenfalls behoben, auch wenn es wieder im Task läuft.
Den fork der FastLED brauchen wir auch nicht mehr, da mein MR dort bereits im master ist, wenn auch noch nicht in einem offiziellen Release.
Kann ich gerne die nächsten Tage noch so pushen, wenn das die Richtung ist, in die wir gehen wollen.
Das mit dem Upload liegt nicht am LED-pausieren, sondern am Core, auf dem async-tcp läuft. Ich finde es super, wenn während dem Upload die Box einfach normal weiergenutz werden kann, baue das aber gerne auch wieder zurück
habe nochmal was gepusht:
- LED-Task wieder rein gemacht
- Async-TCP wieder auf Core 1 (schnellerer Web-Upload)
- Init von LED-Task auf Core 1 (dadurch auch mit Task bei mir kein Flickern / Ghosting mehr)
- LED-Task wird nicht während dem Web-Upload angehalten, da der RMT-Treiber damit nicht gut zurecht kommt und in seltenen Fällen ein Hard-Fault aus der LED-Strip-Lib kommt! (allerdings auch keine große Auswirkung auf die Performance)
- Wieder die original fastl-led lib rein, auf einem neuen master mit dem entsprechenden MR
Da das Flackern bei mir auch davor zuverlässig weg war, bitte nochmal Rückmeldung geben, ob es das jetzt auch für euch löst…
2 „Gefällt mir“
Moin Joe,
vielen Dank für deine Mühe. Ich hab deinen PR mal kompiliert und teste gerade, ob die Wiedergabe durchläuft. Was ich dir aber bereits jetzt sagen kann ist, dass die LEDs leider noch flackern… 
FastLED hat gerade ein neues Release veröffentlicht. @fox wenn Du gerade dabei bist, kannst Du es mit dieser Version einmal testen? Flackert es noch?
Ja, leider unverändert. Hab’s mal gefilmt, es wirkt so, als würden zwei Animationen parallel laufen und sich in die Quere kommen:
Hi Zusammen,
danke für die Rückmeldung.
Bin nochmal tiefer eingetaucht: das Flackern ist nicht weg, sondern verändert nur die Art auf was für Störungen es anfällig ist. Dummerweise habe ich damit einen Fall erwischt, bei dem in meinem Last-Szenario kein Flackern mehr auftritt.
Ich vermute fast, dass wir das nicht gelöst bekommen, solange die led_strip nicht auf den neuen RMT-Treiber geupdatet wird.
Bis dahin:
- vielleicht bekomme ich doch noch irgendwie den SPI-Modus für die LEDs zum Laufen. Der soll deutlich stabiler sein, könnte aber mit den GPIOs herausfordernd werden
- Wir könnten selbst versuchen led_strip auf den neuen RMT-Treiber umzubauen, garantiert uns aber vermutlich auch nicht unbedingt Erfolg.
Ich versuche das mit dem SPI-Modus auf jeden Fall die Tage nochmal