Ich habe ein sehr seltsames Verhalten bei einer Playliste (122 m4a Dateien ca. 5 MB pro Titel Bitrate 192k, alle Titel zufällig). Die Karte wird ganz normal erkannt und die Musik spielt ab, aber ich kann über die Tasten und den Drehencoder nur noch sporadisch Aktionen auslösen. Die Web-UI funktioniert und darüber kann ich den Espuino bedienen. Teilweise ruckelt auch die Wiedergabe. Ich verwende eine Complete mit dem aktuellen Dev Branch. Alle anderen Ordner funktionieren (größtenteils mp3) wie erwartet.
Was ich bisher erfolglos getestet habe: alle Dateien nochmal aufgespielt, nur einen Titel zugewiesen, Dateien mit ffmpeg -v error -i „$i“ -f null - geprüft
Kann es sich um ein Speicherproblem handeln? Bei Bedarf kann ich Dateien teilen
Die Taster werden bei uns im normalen loop() ausgelesen. Dieser liegt auf Core 1 genauso wie der Audio-Task.
Die Web-UI liegt auf Core 0.
Das passt gut zu deiner Beobachtung.
Ich vermute, der ESPUINO kommt mit den M4a- Dateien an seine Grenzen.
Mit den Corezuweisungen haben wir oft rumgespielt. @biologist weiß da sicherlich noch die Einzelheiten.
Man könnte:
zum Test den Audiotask auf den Core 0 schieben (da sollte es aber Einschränkungen mit Netzwerkdingen geben) audio->setAudioTaskCore(1); → audio->setAudioTaskCore(0);
mal versuchen die Dateien als mp3 oder als AAC-LC umzurechnen
Wenn man an die Webinterface-Adresse noch /stats hängt, kann man die aktuelle Auslastung sehen. Vielleicht mal schauen, wie sich das bei mp3 im Vergleich zu m4a verändert.
Wir hatten da verschiedenste Probleme wie schlechter Netzwerk-Durchsatz und flackernde LEDs. Ich habe nicht vor, hier nochmal was zu verschieben - das zieht massig Abhängigkeiten und Testaufwand nach sich.
Genau das würde ich machen. Vielleicht fällt @Joe91 dazu noch was ein, der hat sich demletzt ja recht viel mit der Audiolib beschäftigt.
VU_LEVEL = nutzen wir eh nicht, da muss das nicht berechnet werden
IIR_FILTER = brauchen wir für die Klangeinstellungen (Höhen/Mitten/Bass), vielleicht mal testweise deaktivieren oder man macht den EQ aktivierbar
Vielen Dank für eure Einschätzung. Das konvertieren zu mp3 behebt den Fehler (wobei ich jetzt nur eine Datei getestet habe). Bei den Stats konnte ich keine großen Unterschiede erkennen.
@Verena Ich habe auf dem aktuellen dev (aktuell zu master identisch) mal einen Fix gemacht, der den Weg geht, den @joker vorgeschlagen hat. Firmware habe ich für die complete mal kompiliert:
– wieder gelöscht --.
Teste doch mal bitte, ob das Abhilfe bringt. Also ob das die Rechenzeit wiederbringt, die benötigt wird, um das sauber abspielen zu lassen.
Diese Firmware werde ich ein paar Tagen hier wieder löschen. Die ist nur zum kurzfristigen Test gedacht. Und nur für die complete!
Ok, das klingt doch gut. Es gibt eine Sache zu erwähnen:
VU_LEVEL wird generell deaktiviert, aber IIR_FILTER kann laut Claude nur auf false gesetzt werden, wenn der Equalizer „flat“ eingestellt ist. Ob das jetzt neg. Einfluss haben kann bei non-flat weiß ich nicht.
Gut, wie auch immer, dann comitte ich das mal. Verlieren tun wir dadurch auf jeden Fall nix.
Laut ChatGPT bedeutet das, der EQ ist ausgeschalten. Ich würde da beim EQ Fenster einen Schalter einbauen oder wir packen in den code, wenn alle drei Regler (Bass/mitte/hochton) auf 0 stehen, dann setzte IIR_FILTER auf false.
Ich habe mir eine Verison mit schaltern gebaut wenn ich den auf false setzt, dann geht der EQ aus.
Interessanter weise hatte ich kein Stottern mit der m4a- Datei aber die Zeitanzeige in der Web-UI wurde unregelmäßig aktualisiert. Nach Deaktivieren des VU konnte ich es nicht mehr beobachten
Genau so wurde das umgesetzt. Nur was ich meinte: Wenn jmd. einen EQ nonflat hat, dann weiß ich nicht, ob das entsprechend wieder mehr CPU-Zeit braucht, die dann zu Problemen führt.
Wir werden sehen .
.
.