Möchte Mal noch kurz paar Gedanken teilen:
Das Entfernen des Audio-Tasks wird sie Sache nicht lösen.
Unser Projekt ist zu groß, um mit den Beispielen Vergleichbar zu sein.
Unser Audio Task ist deutlich besser aus performance-Sicht als der Loop-Task und wird von diesem auch nicht unterbrochen (dank Prio).
Problematisch scheint nach dem Umbau in der I2S-Lib vor allem den RFID-Task beim PN -Rfid-Reader zu sein, dieser blockiert andere Tasks einfach zu lange um einen reibungslosen Ablauf zu gewährleisten.
Daher wären meine Ansätze:
Beweis, dass das Auflösen des Audio-Tasks nichts hilft (durch Umsetzen).
Untersuchung des RFID-Tasks auf weniger Blocker
Mal wieder Verbesserung der Task-Struktur nach erfolgreicher Analyse der jeweiligen Anforderungen
Habe mir jetzt mal die drei Beispiel-Audiodateien aus diesem Thread geladen und auf einen Ordner per Web-Upload hochgeladen. Dann mit Standard Mini-4L Konfiguration & aktuellen DEV-Branch abgespielt (Keine Kartenzuweisung, sondern Abspielen über die Web-UI - Rechte Maustaste/abspielen)
Ich bekomme bei keinem der Songs Hüpfer/Aussetzer!
Wo liegt hier das Problem, wie ist das reproduzierbar? Muss ich das noch auf eine Karte zuweisen? Die Audio-Bibliothek ist unverändert https://github.com/schreibfaul1/ESP32-audioI2S.git#83a9370 ;16.11.2024
Das Problem tritt - bei mir - i.d.R. erst nach etwas Betriebszeit auf (mindestens 5-10 Minuten). Ist also mit einer einzelnen Datei schwierig zu provozieren. Kann mir aber nicht vorstellen, dass der Start via Web-Interface oder RFID-Tag einen Unterschied macht.
bei meinen ESPUINO war der Akku recht leer. Ich kann mir jedoch nicht vorstellen, dass das daran liegt.
Vielleicht hat es doch etwas damit zu tun, weil weiter oben beschrieben wurde, dass es in Verbindung mit dem Setzen der Neopixel passiert.
Seltsam wäre dann, warum das nur mit neueren Versionen der lib auftritt.
Habe die Problembär-Songs mit einer Karte verknüpft (Hörspiel endlos) & den ganzen Abend laufen lassen, Ergebnis Keine Hüpfer/Aussetzer!
Getestet in Standard-Konfiguration, Mini4L, 24er NeoPixel, PN5180. Was ist anders bei Euch?
Mal ein kurzer Recap, vielleicht findet sich ja ein Muster:
Bei uns ist außerdem das Flag zum Pausieren bei Abnahme des Tags und bei minimaler Lautstärke gesetzt.
Wir haben nur drei Neopixel aber eine sehr hohe Anzahl an Abstufungen (ich glaub 200 oder so).
Beim Neinhorn ist es sogar mit sehr hoher Wahrscheinlichkeit an quasi der selben stelle, dass er auf den nächsten Track weiter schaltet und auch dort weiter spielt. Ich habs noch nicht ausprobiert, ob das aber an den track oder die Gesamtspielzeit gebunden ist, die könnte da etwa 5 Minuten sein…
Besonders nervig sind dann die Hänge-Sprünge, wo er an den Ende des Tracks springt und dann hängen bleibt. Da seh ich aber noch keinen Zusammenhang, wann er weiter oder ans Ende springt.
Akku leer hat auf jeden Fall eine höhere Rate an Sprüngen, aber auch voll aufgeladen passiert es immer wieder…
Wie ist das bei den anderen so? Irgendwelche Non-Standard-Setups?
Das ist wirklich interessant.
Wie @Wolle schon gesagt hat, ist es das zusammenspiel von dem auidio-loop (aus entweder dem System-Loop oder unserem Audio-Task) und dem Periodic-Task aus der Audio-Lib.
Bei mir ist es aktuell eigentlich in fast jedem Song, wenn ich sehr nahe am Dev bin (aktuell allerdings auf dem neusten Commit der Audio-Lib und Arduino 3).
In diesem Fall, bei selber Hardware wäre mein Best-Quess: bessere SD-Karte oder performatere Anordnung der Files auf dieser?
Hast du die Dateien per Upload, FTP oder über einen PC per SD-Reader/Write draufgeschrieben?
Zusätzlich könnte die Netzlast bei mir einen Unterschied machen (bei mir ist z.B. MQTT aktiv, das hat aber keinen großen Unterschied gemacht).
Bei mir sind es 30 Pixel.
Das Springen und das am Ende stehen bleiben ist das Selbe.
Wenn ein Sprung stattgefunden hat, wird das Ende nicht mehr erkannt.
Ich würde gerne auch mal noch die Buffer in der Audio-Lib genauer anschauen, das braucht gerade aber einfach alles Zeit. Da ich manchmal sogar in eine Assert im Audio.cpp springe, scheint es hier definitiv noch Race-Conditions in der Audio-Lib bei komplexeren Systemen wie unseren zu geben …
Werde bald nochmal auf exakt den dev-branch gehen und nochmal vergleichen.
Hier nochmal paar dieser Error-Codes:
I [353906] id3data : Artist: Various Artists
I [353910] id3data : ContentType: Kinder
I [353914] id3data : Track: 12/18
I [353918] id3data : SettingsForEncoding: Audiograbber 1.83.01, LAME dll 3.99, VBR 2 (New method), Joint Stereo, Normal quality
I [353932] info : Audio-Length: 5805802
I [353933] info : stream ready
I [353934] info : syncword found at pos 0
I [353939] info : MPEG-2.5, Layer I
I [353941] info : Channels: 2
I [353941] info : SampleRate: 44100
I [353951] info : BitsPerSample: 16
I [353952] info : BitRate: 128000
I [448726] info : MP3 decode error -6 : INVALID_FRAMEHEADER
I [448728] info : syncword found at pos 19
I [448729] info : syncword found at pos 0
I [448745] info : MP3 decode error -9 : INVALID_HUFFCODES
I [448747] info : syncword found at pos 72
I [448749] info : syncword found at pos 0
I [448758] info : MP3 decode error -6 : INVALID_FRAMEHEADER
I [448759] info : syncword found at pos 134
I [448761] info : syncword found at pos 0
I [448782] info : MP3 decode error -9 : INVALID_HUFFCODES
I [448785] info : syncword found at pos 521
I [448786] info : syncword found at pos 0
I [448812] info : MPEG-2.5, Layer I
I [448814] info : Channels: 2
I [448814] info : SampleRate: 44100
I [448814] info : BitsPerSample: 16
I [448825] info : BitRate: 320000
D [480026] RSSI: -45 dBm
I [496955] info : MP3 decode error -6 : INVALID_FRAMEHEADER
I [496956] info : syncword found at pos 303
I [496957] info : syncword found at pos 0
I [496984] info : MPEG-2.5, Layer I
I [496986] info : Channels: 2
I [496986] info : SampleRate: 44100
I [496986] info : BitsPerSample: 16
I [496999] info : BitRate: 192000
Und hier so ein Assert:
[1145957][E][Audio.cpp:129] bytesWritten(): m_writePtr 1066077118, m_endPtr 1066076650
assert failed: block_trim_free IDF\components\heap\tlsf\tlsf_control_functions.h:548 (block_is_free(block) && "block must be free")
Ich habe noch den Vorgänger, die miniD32pro mit dem Lolin D32 pro (Li-Ion), im Einsatz, ansonsten folgendes Setup bzw. folgende Beobachtungen:
Es tritt bei uns ausschließlich das Problem auf, dass innerhalb des Songs ein kurzes Stück übersprungen wird und der ESPuino anschließend hängt. Übersprungene Songs haben wir nicht.
Die Dateien wurden überwiegend direkt auf die SD kopiert, teils per FTP.
Dateien sind jedoch einwandfrei - zurück auf den PC kopiert gibt’s keine Probleme, und manchmal laufen sie ja auch am ESPuino problemlos durch (wie ja auch mit der alten Library-Version…).
Das Problem tritt sowohl im Akku- wie auch im „Netzbetrieb“ auf.
Wir nehmen den Tag immer nach dem Start vom Leser, weil der PN5180 ja bei uns sowieso etwas Probleme bereitet (wachte auch ohne Tag ständig auf, der Akku war quasi nach ein paar Tagen ohne Benutzung leer; bei Benutzung wurde der darauf liegende Tag teils für ein paar Sekunden nicht mehr erkannt und die Wiedergabe stoppte, fing dann wieder an, usw). Das könnte evtl. von Relevanz sein…
WLAN-Dichte ist bei uns überschaubar (Mehrparteienhaus mit 5 Wohnungen). MQTT haben wir deaktiviert. Webstream funktioniert grundsätzlich einwandfrei.
Ich würde das Problem bei Gelegenheit mal mit anderen Dateiformaten testen, um hier etwas Klarheit zu schaffen. Aktuell scheinen ja nur VBR-kodierte MP3s problematisch zu sein?
Ich kann bestätigen, dass auch bei mir der Reader alles mögliche Empfängt und tut… Auch ich habe meistens gar keine Karte aufliegen gehabt, als die Fehler gekommen sind.
Ich kann bestätigen, dass auch bei mir der Reader alles mögliche Empfängt und tut
Das darf nicht sein & könnte Ursache sein. Löte mal alle Pins am RFID-Stecker nach. Ich hatte dort eine kalte Lötstelle die so nicht zu sehen war. Dadurch stürzte ESPuino nach kurzer Zeit mit einem Watchdog-Reset ab.
Ansonsten habe ich auch Pause bei minimaler Lautstärke & feinere Abstufungen Neopixel probiert, kann das Problem aber weiterhin nicht nachstellen.
Warum passiert der Fehler mit bestimmten Versionen der Audio-Lib gar nicht und mit allen aktuellen sehr zuverlässig?
Warum sind diese Änderungen nur auf manchen (aber doch einigen) Systemen von Relevanz und machen auf anderne Systemen keine Probleme und wo sind hier die Unterschiede.
Zu 1. bin ich nochmal bisschen weitergekommen:
In der Audio.cpp wurden die Buffer in der m_i2s_chan_cfg vor etwa 8 Monaten angepasst (103c5b1).
Wenn ich diese Aufteilung wieder in die ursprüngliche Richtung anpasse, kommt auf default-Einstellungen auch über ein ganzes Album der Fehler bei mir nicht mehr vor:
m_i2s_chan_cfg.dma_desc_num = 8; // number of DMA buffer
m_i2s_chan_cfg.dma_frame_num = 1028; // I2S frame number in one DMA buffer.
Mache ich das Rückgängig habe ich es meistens schon direkt im ersten Lied. @Wolle: kannst du eventuell was zu dieser Buffer-Aufteilung sagen, warum die Aufteilung geändert wurde?
Völlig unabhängig von 1. sollten wir 2. verstehen und nicht einfach nur auf ein Workaround hoffen …
Wenn noch jemand anderes mit dem Problem das versuchen könnte, wäre das trotzdem eine super Rückmeldung.
An den PN5180 komme ich leider ohne Weiteres nicht mehr ran (passiert eben, wenn man so ein Gehäusedesign zum ersten Mal macht und die vermeintlich fixe Hälfte des Gehäuses dann verklebt… ). Da wäre eher noch die Nutzung der alten Library für mich die Endstation.
Irritiert mich aber dennoch, schließlich sollte der Audio-Task doch - unabhängig von wilden Hardware-Interrupts - inzwischen deutlich effizienter als vorher sein, sodass der Fehler eher vorher als nachher auftreten müsste?
Wo wir hier von der (vermeintlichen) (In-)Effizienz des RFID-Tasks sprechen… spricht denn eigentlich etwas dagegen, auch im regulären Betrieb die Kartenerkennung (bzw. ob die Karte entfernt wurde) per LPCD laufen zu lassen? Sollte das nicht auch hier Energie und Rechenleistung sparen?
Der RFID-Task verbraucht im Betrieb ca. 3% Rechenleistung eines Kerns. Das ist schon ausreichend effizient. Wenn aber z.B. der Leser eine Macke hat oder es anderweitig Probleme mit der SPI-Kommikation gibt, kann der Task evt. irgendwann nicht mehr reagieren. In meinem Fall war das dann immer ein Watchdog-Reset, und den kann man zu eurem Problem recht gut unterscheiden.
LPCD ist hier keine Option, das wäre viel zu träge für Kartenerkennung.
Meine Hardware:
ESP32: Wahlweise Lolin D32-Pro oder Develboard von @biologist SD-Karte: SanDisk Ultra 16GB, also recht schnelle & aktuelle Karte.
Mein Test-Album lief jetzt zweimal komplett mit Arduino 3 und dem letzten (angepassten) audioI2S-Commit durch, was für sich aber noch nicht wirklich aussagekräftig ist.
Beim zweiten Durchlauf habe ich es provoziert und währenddessen das Web-Interface offengelassen und zwischendurch mal Dateien per FTP übertragen - alles ohne Probleme. Der /stats-Endpunkt zeigte während des FTP-Transfers nichts auffälliges:
Memory:
Free heap: 108512
Largest free block: 57332
Free PSRAM heap: 3414992
Largest PSRAM block: 3407860
Tasklist:
Taskname State Prio Stack Num Core
async_tcp X 10 12696 21 1
rfid R 2 320 13 0
PeriodicTask R 2 812 11 0
mp3play R 2 3292 10 1
loopTask R 1 1996 8 1
Led_Task R 1 492 12 1
IDLE1 R 0 604 6 1
IDLE0 R 0 516 5 0
tiT B 18 1180 14 0
mdns B 1 2032 20 0
sys_evt B 20 1496 15 0
arduino_events B 19 3092 16 1
esp_timer S 22 3792 3 0
ipc0 S 24 488 1 0
wifi B 23 1204 19 0
ipc1 S 24 244 2 1
Tmr Svc B 1 1588 7 -1
Runtime statistics:
Taskname Runtime Percentage
async_tcp 2031995 <1%
rfid 34536677 3%
PeriodicTask 366392181 33%
mp3play 43938941 4%
Led_Task 27620869 2%
loopTask 126361863 11%
IDLE0 577687869 53%
IDLE1 886363307 81%
tiT 26212547 2%
sys_evt 2629 <1%
arduino_events 1412 <1%
esp_timer 2264711 <1%
ipc0 17449393 1%
wifi 61363755 5%
ipc1 187478 <1%
Tmr Svc 37 <1%
mdns 290588 <1%
Ich werde es die nächsten Tage noch mal etwas länger mit der o.g. Modifikation der Audio.cpp und den bestehenden MP3-Dateien testen.
Mit VBR-AAC wollte ich es auch testen, damit kommt die Bibliothek respektive der ESP32 aber nach wie vor augenscheinlich nicht gut zurecht. Da flackert der Neopixel-Ring und die Wiedergabe stottert häufger bspw. bei Auflegen eines unbekannten Tags.
…
). Da wäre eher noch die Nutzung der alten Library für mich die Endstation.
