Musiktitel hüpft während des Abspielens vor, spielt weiter bis zum Titelende und stoppt dann

Software
21

Wollte mich gerade auf Fehlersuche machen. Testweise habe ich die Audiobibliothek auf den aktuellen Commit gesetzt.

https://github.com/schreibfaul1/ESP32-audioI2S.git

Leider bekomme ich dann beim Kompilieren sehr viele Fehlermeldungen, ist das bei euch auch so? Hier nur eine davon:

Compiling .pio/build/lolin_d32_pro_sdmmc_pe/lib0d4/ESP32-audioI2S/Audio.cpp.o
.pio/libdeps/lolin_d32_pro_sdmmc_pe/ESP32-audioI2S/src/Audio.cpp: In constructor 'Audio::Audio(uint8_t)':
.pio/libdeps/lolin_d32_pro_sdmmc_pe/ESP32-audioI2S/src/Audio.cpp:187:5: error: 'm_i2s_chan_cfg' was not declared in this scope
     m_i2s_chan_cfg.id            = (i2s_port_t)m_i2s_num;  // I2S_NUM_AUTO, I2S_NUM_0, I2S_NUM_1
     ^~~~~~~~~~~~~~
.pio/libdeps/lolin_d32_pro_sdmmc_pe/ESP32-audioI2S/src/Audio.cpp:187:5: note: suggested alternative: 'm_i2s_config'
     m_i2s_chan_cfg.id            = (i2s_port_t)m_i2s_num;  // I2S_NUM_AUTO, I2S_NUM_0, I2S_NUM_1
     ^~~~~~~~~~~~~~
     m_i2s_config
22

Die aktuellen Versionen der Audio-Bibliothek benötigen das Arduino V3 Framework:

3.1.0
Only supports Arduino versions from V3 and therefore no longer supports an internal DAC

Im aktuellen DEV-Branch ist Arduino V3 aber noch nicht aktiviert. Habe soeben die neueste Version Arduino 3.2.0 (ESP-IDF 5.4.1) eingecheckt. So könnt Ihr es ausprobieren: Umstieg auf Arduino 3.x - #2 von tueddy

1 „Gefällt mir“
23

Ich konnte nur kurz testen, folgende Ergebnisse:

  • Geht man so vor, wie von @tueddy beschrieben, kann man auch den aktuellen Stand der audioI2S kompilieren. Es geht ohne Errors aber mit 21 Problems durch
  • Ich hatte bei dem mir vorliegenden Problemfile keine Probleme beim Abspielen. Vermutlich hatte sich also vorübergehend ein Fehler in audioI2S eingeschlichen, der mittlerweile wieder entfernt wurde. Somit macht es auch Sinn, dass @Wolle das Problem nicht nachvollziehen konnte.
  • Am Rande ist mir aufgefallen, dass der Dateiupload mit knapp 500kbit/s deutlich schneller ist, als er mir in Erinnerung ist (dachte, es seien früher so 350 gewesen). Allerdings hatte ich auf der SD-Karte viele Ordner mit „?“, wobei das ggf. an den schlechten Steckverbindungen lag, das müsste auf jeden Fall nochmal jemand anders testen.
  • Free Heap war etwas größer, Free PSRAM etwas kleiner als früher

Solange wir also nicht standardmäßig auf Arduino 3 gehen, solltet ihr den 567abd2 gepinnt halten.

1 „Gefällt mir“
24

@sfields Danke für’s Testen! Sieht ja schon ganz gut aus & deckt sich mit meinen bisher positiven Arduino 3 Tests.

Solange wir also nicht standardmäßig auf Arduino 3 gehen, solltet ihr den 567abd2 gepinnt halten.

Hmm, diese Version von AudioI2S ist von Mai 2024 und hat noch nicht die CPU-Optimierung drin, könnte also an anderer Stelle auch wieder Audio-Ruckeln verursachen. Aktueller ESPuino DEV hat den AudioI2S Stand von Nov. 2024 kurz bevor es wegen Arduino 3 Umstieg für uns inkompatibel wurde.

Ist die Version 567abd2 wirklich ein guter Übergang?

25

Das weiß ich nicht, vielleicht dann doch nur für die Leute, die die obigen Probleme hatten und die Allgemeinheit lässt es so wie gehabt?

1 „Gefällt mir“
26

Ich hatte mit der Version 83a9370 und folgender Datei Probleme (reproduzierbar).

Mitten im Song wurde auf ca 3/4 des Liedes gesprungen, der Rest dann normal abgespielt aber am Schluss stoppte die Wiedergabe und der LED Ring war komplett gefüllt und nix passierte mehr.

Version 567abd2 macht keine Probleme bei mir.

27

Meine Tochter hat am Wochenende viel mit der Box gehört, bei der ich die I2S Library auf #567abd2 gepinnt habe. Ohne merkliche Aussetzer oder andere Probleme.

Allerdings konnte ich einen Bluetooth-Kopfhörer nicht dazu bringen Musik abzuspielen - nach erfolgreichem Pairing spielt immer noch der Lautsprecher (Die Steuerung start-/stop über die Kopfhörer Taste geht aber). Vielleicht hängt das zusammen.

Ich werde vermutlich erst am nächsten WE dazu kommen auf Arduino 3 zu wechseln und das Pinning aufzuheben, melde mich dann zurück.

28

Bei mir tritt das Problem leider auch mit Arduino 3 und der neuesten ESP32-audioI2S-Version (#d300302) auf. Das sind Songs, die manchmal ohne Probleme durchlaufen und manchmal, scheinbar willkürlich, einfach diesen Fehler bringen und den ESPuino in den Absturz reißen…

I [1533250] info        : Reading file: "[...].mp3"
I [1533283] info        : MP3Decoder has been initialized, free Heap: 133176 bytes , free stack 3212 DWORDs
N [1533283] '[...].mp3' wird abgespielt (13 von 14)
I [1533779] info        : Content-Length: 3677877
I [1533779] info        : ID3 framesSize: 139558
I [1533779] info        : ID3 version: 2.4
I [1533790] info        : ID3 normal frames
I [1533798] id3data     : [...]
I [1533962] info        : Audio-Length: 3538319
I [1533963] info        : stream ready
I [1533964] info        : syncword found at pos 0
I [1533970] info        : MPEG-2.5, Layer I
I [1533971] info        : Channels: 2
I [1533972] info        : SampleRate: 44100
I [1533982] info        : BitsPerSample: 16
I [1533982] info        : BitRate: 64000
I [1555663] info        : MP3 decode error -6 : INVALID_FRAMEHEADER
I [1555664] info        : syncword found at pos 674
I [1555665] info        : syncword found at pos 0
I [1555677] info        : MP3 decode error -9 : INVALID_HUFFCODES
I [1555678] info        : syncword found at pos 834
I [1555679] info        : syncword found at pos 0
I [1555699] info        : MPEG-2.5, Layer I
I [1555700] info        : Channels: 2
I [1555701] info        : SampleRate: 44100
I [1555701] info        : BitsPerSample: 16
I [1555712] info        : BitRate: 320000

[Edit] Anmerkung: Beim Durchlauf mit der alten Version (Arduino 2, Commit #567abd2) ist die Log-Ausgabe (mit Ausnahme der Zeitstempel und freiem Heap/Stack sowie der Fehlermeldung) identisch - allerdings fehlt die Zeile

I [1555699] info : MPEG-2.5, Layer I

Das macht mich etwas stutzig und ich hab mal kurz die Suchmaschine meines Vertrauens bemüht. Zum einen sind mp3-Dateien ja eigentlich „MPEG-1 / MPEG-2 Audio Layer 3“ und zum anderen wird sowohl im Quellcode von ESP32-audioI2S als auch bei Hydrogenaudio für dieses Format eine Abtastrate von 8-12 kHz beschrieben.

Die Datei hat aber nun eindeutig eine übliche Abtastrate von 44,1 kHz, wie sowohl in der Logdatei (korrekt) steht, als auch sonstige Medientools bestätigen (Ausgabe gekürzt):

➜ file test.mp3
test.mp3: Audio file with ID3 version 2.4.0, contains: MPEG ADTS, layer III, v1, 64 kbps, 44.1 kHz, Stereo

➜ mediainfo test.mp3
General
Complete name : test.mp3
Format : MPEG Audio
File size : 3.51 MiB
Duration : 1 min 50 s
Overall bit rate mode : Variable
Overall bit rate : 255 kb/s
Writing library : Lavf61.7.100
Cover : Yes
Cover type : Cover (front)
Cover MIME : image/jpeg

Audio
Format : MPEG Audio
Format version : Version 1
Format profile : Layer 3
Format settings : Joint stereo
Duration : 1 min 50 s
Bit rate mode : Variable
Bit rate : 256 kb/s
Channel(s) : 2 channels
Sampling rate : 44.1 kHz
Frame rate : 38.281 FPS (1152 SPF)
Compression mode : Lossy
Stream size : 3.37 MiB (96%)

Ich konnte im Quelltext leider nicht erkennen, wo diese Logausgabe herkommt - womöglich hat das aber etwas mit der (manchmal) fehlerhaften Dekodierung zu tun?

29

Hi Zusammen,
bin auch mal wieder hier :slight_smile: …
Habe exakt die selben Probleme, unabhängig von Arduino 3 oder 2.
Erst das Ändern der I2S audio auf besagte rev. 567abd2 fixt das Problem bei mir.
Habe testweise auch noch die neuste Version (d7b8837) getestet, jedoch sind auch dort die Probleme wieder da.

Was anderes:
MQTT ist mit Arduino 3 noch nicht verfügbar. Schaut sich das schon jemand an, oder soll ich mal mein Glück versuchen?

2 „Gefällt mir“
30

Wenn das Hüpfproblem mit der aktuellen Audio-Bibliothek noch auftritt könntet Ihr hier einen Bug-Report aufmachen. Das hat @Wolle immer schnell lösen können. Bislang konnte er den Bug ja nicht nachvollziehen weil wir noch mit einer älteren Versionen unterwegs sind.

Funktioniert denn 567abd2 auch mit BT-Kopfhörer? Weil es gab einige AudioI2S-Versionen wo diese Funktion kaputt war. Daher habe ich die Version nicht übernommen. Ich würde hier lieber nach vorn schauen, weil nur so können Bugs in 3.Party Bibliotheken auch gefixt werden.

@Joe91 Wäre toll wenn Du Dir MQTT für Arduino 3 anschauen könntest :heart:

2 „Gefällt mir“
31

Ich hatte, schon vor einer ganzen Weile, mal angefangen, unsere MQTT-Implementierung nativ auf IDF umzustellen. Weil im Prinzip kann man sich Arduino-Libs da komplett sparen. Irgendwie bin ich aber doch leider wieder versackt :frowning:.

Wäre tatsächlich mal an der Zeit, diesen Teil zu renovieren, da an Pubsubclient auch schon lange nichts mehr passiert. Für Input wäre ich da total dankbar.

1 „Gefällt mir“
32

Hatte mal versucht mit git-bisect den Ursprung des Fehlers zu finden, bin aber dann auf größere Kompilierfehler gestoßen.

Habe die ESP32-audioI2S dependency jetzt auf 5f44939 gesetzt (basierend auf dem ESPuino Stand 1ea5bd3) und hier springen die Lieder noch nicht & BT-Modi gehen beide.

33

Leider noch keine Lösung, aber paar Infos:

Müsste man vermutlich näher untersuchen…

2 „Gefällt mir“
34

Update:
Der Interne Task der Audio-Lib „PeriodicTask“ ist entscheidend für den Fehler.
Wird dort die Priortät erhöht, verschwindet der Fehler bei mir komplett.
Da wir durch das update sehr viel weniger Rechenlast haben erreichen wir den selben Effekt auch dadurch, dass wir den RFID-Task (vom PN5180) wieder zu Core 1 verschieben (und optional die Prio auf 1 runter nehmen).
Was haltet ihr davon? Wollt ihr das auch mal testen?

35

An alle Leute, bei denen der Fehler auftritt:
Habt ihr dies nur mit der biologist firmware getestet, oder habt ihr dies stand-alone mit der Audio-I2S Bibliothek getestet und falls ja, tritt der Fehler dann genauso auf?

Z.B damit kann man es testen: ESP32-audioI2S/examples/plays all files in a directory at master · schreibfaul1/ESP32-audioI2S · GitHub

Ich vermute, dass der Fehler eher auf „unserer“ Seite liegt als auf der Seite der Audio-Bibliothek, z.B. der doppelte Audio-Task, leider fehlt mir gerade etwas die Zeit um zu testen.

36

Kann ich morgen zum Eingrenzen des Fehlers mal testen. Damit ich das richtig verstehe, du meinst diese Zeilen hier in der RfidPn5180.cpp?

xTaskCreatePinnedToCore(
	/* [...] */
	2 | portPRIVILEGE_BIT, /* Priority of the task */
	/* [...] */
	0 /* Core where the task should run */
);
37

Bin nicht wirklich glücklich mit der Lösung, da es uns die Reaktion kaputt macht.
Ich versuche mal das Entfernen des Audio-Tasks auf einem branch umzusetzten.
Besser für den Moment nur die Prio an genau dieser Stelle von 2 auf 1 setzten. Auch das macht schon einen großen Unterschied und behält die Reaktion der Buttons und LEDs bei.
Der Interne Audio-Task verwendet Core 0 mit Prio 2, das ist in jedem Fall ungünstig wenn der RFID-Task die gleiche Prio hat.

38

Es geht um den Audiotask. Sieht aber so ähnlich aus.

Diese Task-Geschichten sind ein ziemliches Spannungsfeld, in dem wir schon mehrere Runden gedreht haben. Nicht nur die Priorisierung, sondern auch, auf welchem Core was laufen muss. Da hatten wir schon:

  • Komisches Geblinke von irgendwelchen Neopixel-LEDs
  • Schlechte Performance bei Webuploads
  • Probleme bei der Audiowiedergabe
  • Probleme mit RFID-Erkennung
  • ggf. noch mehr, was ich gerade vergesse

Also da muss man gut aufpassen und weitreichend testen, wenn man hier Änderungen vornimmt.

Das ist denke ich die beste Lösung, weil wir das aktuell Task-in-Task laufen haben; da hat sich bis dato niemand so wirklich dran getraut.

39

Das herabsetzen der Priorität bezog sich aber auf andere Tasks, nicht auf den Audio-Task, nicht? Mit dem RFID-Task auf Prio. 1 habe ich aber jedenfalls das gleiche Problem nach einiger Zeit.

Ich bin aber auch der Meinung, dass als allererste Maßnahme dieser doppelte Task, wie auch von Wolle angesprochen, entfernt werden sollte. @Joe91 melde dich gerne, wenn ich deine Anpassung testen soll. Vielen Dank dir!

Habt ihr denn eine Vermutung, weshalb die Bibliothek die Dateien als MPEG-2.5, Layer I erkennt? Oder ist das nur eine Nebelkerze, die nichts mit dem eigentlichen Problem zu tun hat?

40

Bei mir macht 567abd2 MIT FixVBR keine Probleme…

Vor FixVBR machte der aktuelle dev sogar weniger Probleme wie der Stand 567abd2

Da machte 567abd2
E (14732) sdmmc_cmd: sdmmc_read_sectors_dma: sdmmc_send_cmd returned 0x107
E (14732) diskio_sdmmc: sdmmc_read_blocks failed (263)

der aktuelle dev nur einen „Hüpfer“.

Kommt wohl auf beides an, „gute“ mp3s und die richtige Version der Lib