Heute nochmals kompiliert und alles ist wieder gut 
Rockbox hat damals (2005!!!) den code von ffmpeg genommen:
https://git.rockbox.org/cgit/rockbox.git/tree/lib/rbcodec/codecs/libffmpegFLAC
Ich kenne mich nicht so gut mit codecs aus, aber eventuell ist die Datei README.rockbox interessant:
It was also changed to provide output as 32-bit integers (with the data left-shifted to 28 bit accuracy). The original flac.c provided 16-bit output. In order to minimise memory usage, a small number of hard-coded limits are present in decoder.h - mainly limiting the supported blocksize (number of samples in a frame) to 4608. This is the default value used by the reference FLAC encoder at all standard compression settings.
Das ist saugeil. Ich freue mich. Danke schon mal!
@tyllmoritz ich habe mir den Code von Rockbox angesehen. Mit den Problemen, die ich sehe kämpft er auch. FLAC ist zwar schnell bein Dekodieren benötigt aber für ESP32-Verhältnisse extrem viel Speicher . Und der ESPuino spart auch nicht mit SRAM. Koexistenz funktioniert nur wenn der Speicher des FLAC-Dekoders in den PSRAM verlagert wird. Leider, das geht nicht anders. Ich habe meinen FLAC Dekoder, den ich damals programmiert habe, eingehängt. Der Klang ist super. Zur Zeit läuft nur das Abspielen von SD. Für den Betrieb im ESPuino sind also zwei Sachen erforderlich:
- PSRAM muss aktiviert werden
- der Dateityp .flac muss in der SW freigegeben werden
P.S. ohne PSRAM stürzt der ESP32 beim Initialisieren der FLAC Dekoders wegen Mangel an SRAM ab, das wird mit der nächsten Version bereinigt.
vG Wolle
1 „Gefällt mir“
Dateityp freigeben ist schnell gemacht.
Wenn es dafür psram braucht, dann ist es halt so 🤷
Hallo zusammen,
nachdem hier bereits über Spulen im Titel berichtet wurde, hoffe ich, dass ich mich hier an die richtigen Leute wende.
Nachdem ich das neue 4L PCB in Betrieb genommen habe, bekomme ich beim Spulen (egal ob vorwärts oder rückwärts) in mp3/aac Dateien immer folgende Meldung im Terminal:
[ 253359 ] 30 Sekunden nach vorne gesprungen
[E][Audio.cpp:2766] processLocalFile(): audioHeader reading timeout
und der ESP geht in den Wartezustand (4 weiße LED, die sich im Kreis drehen).
Habe es bei mehreren mp3, wie auch aac Dateien ausprobiert - immer das selbe.
Hat das auch schon mal jemand beobachtet oder kann sich das erklären?
Ich glaube das Verhalten hatte ich mal mit einer anderen bestimmte SD Karte. Hast du zu Testzwecken noch eine andere SD Karte?
Danke für die Rückmeldung.
Ich hab es mit 3 SD Cards versucht:
- 32GB SanDisk Ultra
- 128GB SanDisk Ultra
- 16GB Transcend Premium
Leider jedes Mal das selbe Ergebnis.
Schade, dass das nicht geklappt hat. Mehr Ideen, woran das liegen könnte, habe ich leider nicht.
Trotzdem vielen Dank für den Hinweis.
Mein Problem tritt scheinbar nur sehr selten auf, sonst wäre das hier sicherlich schon öfter ein Thema gewesen.
Bevor ich die HW bekam, hatte ich Deinen Artikel hier bereits gelesen und mich voll gefreut, dass das Spulen wohl endlich (im Vergleich zum Tonuino) geht.
Naja, vielleicht finde ich noch eine 4. SD-Card und kann dann über einen Erfolg berichten 
Das spulen geht schon…man springt um 30Sekunden nach vorn und hinten (die Sprungweite ist ein einstellbar)
Ich hab leider nur das Problem, dass das Spulen bei mir während des Abspielens einer MP3 Datei immer diesen Fehler hier auswirft
[E][Audio.cpp:2766] processLocalFile(): audioHeader reading timeout
und danach dann plötzlich die vier weißen LEDs im Neopixel sich „drehen“ und somit auch die Wiedergabe gestoppt wird.
Versteh ich…
Das Problem mit den weißen LEDs hatte ich auch aber da war die andere SD-Karte die Lösung.
Welche Version verwendest du?
Ich habe einen ca. 1Monat alten Master-Abzug und das Spulen habe ich auf Lange-Drücken der Vor- oder Zurücktaste gelegt und das funktioniert hier. Ich mache später mal ein Update, vielleicht ist es ja als Begleiterscheinung durch etwas anderes gestorben.
Ich glaube das Spulen im Titel nutzen nicht viele und dann auch nur selten
Bin auf origin/master (Commit c578f88a).
Ich schau mir das ganze aber morgen Abend noch mal genau an.
Aber vielen Dank für den Hinweis.
Hmmm…ich bekomme den Fehler jetzt auch, egal ob vbr oder normale MP3 - das lief aber schon mal
[E][Audio.cpp:2766] processLocalFile(): audioHeader reading timeout
ich bin jetzt auf
[ 1134 ] Software-revision: 20230214-1
[ 1138 ] Git-revision: c578f88-dirty
Da muss ich mal probieren
Dann versuch ich doch mal etwas weiter zurück in die Vergangenheit zu gehen.
Könnt ja doch auch durch Abhängigkeiten zu anderen SW-Komponenten zu diesem Problem gekommen sein.
Ich habe gerade nicht die Hardware zum Testen hier…
Ich kann es auch nicht technisch erklären aber mein Bauchgefühl sagt, dass die Änderung von Wolle hier reingrätscht. Das passt auch zeitlich, man müsste es aber noch testen
Hallo joker,
den Fehler kann ich reproduzieren, den hab ich in der Testumgebung auch.
Ich kenne die Ursache noch nicht, vielleicht ist deine Vermutung richtig.
Das schaue ich mir demnächst an.
vG
Wolle
1 „Gefällt mir“
Deine Vermutung war richtig, wenn die Audiodatei am Anfang oder Ende beschädigt ist soll eine Fehlerroutine greifen. Leider hat sich dadurch der dumme Nebeneffekt mit der Zeitüberschreitung eingeschlichen. Das Spulen funktioniert jetzt wieder ordentlich.
1 „Gefällt mir“
Wahrscheinlich verstoße ich gerade gegen den Codex, aber ich hatte etwas geschrieben gehabt, das in der Zwischenzeit von Wolle gefixt wurde und ersetze es mit diesen Zeilen - ich hoffe ihr verzeiht mir.
Das Spulen funktioniert jetzt endlich bei mir!!!
Vielen Dank Wolle und auch joker für die Hilfe.