Die Audio, Enkoder, Bluetooth & JSON Bibliotheken sind auf den neuesten Stand gebracht:
Unter anderem hat @Wolle ein Problem mit der Auswertung von ID3-Metadaten (MP3 Titel, Album usw.) behoben, Vielen Dank dafür!
@Knoddler mit der aktuellen Audiobiblithek kann ich Deine MP3-Dateien problemlos abspielen & auch das Coverbild anzeigen. Evt. ersetzt Du die Zeile in platform.ini durch:
https://github.com/schreibfaul1/ESP32-audioI2S.git#5a1bd13
Hallo zusammen,
Ich habe 2 Bugs und eine kleine Verbesserung gefunden 
.
Bug 1:
Mein git weigert sich standhaft AruinoJson mit der @ Notation zu laden. Habe es auf den Hash von dem Release fixieren müssen damit es funktioniert
Bug 2:
Wenn Bluetooth deaktiviert wird, kann bei mir sporadisch vor, dass der Webserver vor dem WLAN gestartet worden ist (vor allem wenn Bestes-WLAN-nach-Scan-verwenden aktiviert ist). Habe ich damit beheben können, dass die Funktion Wlan_IsConnected statt WiFi.status() die neue Zustandsmaschine verwendet. Seitdem ist es nimmer aufgetreten.
Bug/Verbesserung 3:
In Web.cpp waren des Öfteren static String in Funktionen enthalten. Um sie raus zu bekommen & ein wenig zu optimieren, habe ich auf Callbacks zurückgegriffen um die Informationen vom Wlan Modul zu bekommen (plus statt nur der SSID, hole ich mir alle Infos, damit wäre es theoretisch auch möglich Wlan Einstellungen in der GUI editierbar zu machen).
Die Branch: GitHub - laszloh/ESPuino at bugfix/multi_wlan
Gruß,
Laszlo
Evt. hat sich Problem 1 schon gerade erledigt?
Ja, das löst das erste Problem. Du warst ca 30 Minuten schneller 
Ich habe jetzt eine Branch erstellt mit den beiden anderen Verbesserungen. Läuft aktuell erst seit paar Stunden auf meinem Testsystem, könnte also noch Bugs haben.
Gruß,
Laszlo
@laszloh Deine Fixes für Bug 2/Verbesserung 3 sehen für mich gut & richtig aus!
Kannst Du einen PR für den DEV-Branch erstellen? Hast ja schon Alles vorbereitet 
done, PR ist offen
Der PR ist eingecheckt, @laszloh Vielen Dank!
Ein kleiner Bug hat sich jetzt eingeschlichen: Die WLAN-Verbindungszeit beim Start ist jetzt deutlich länger. Oder nur gefühlt? Jedenfalls blinken die grünen LEDs jetzt 2-3 Sekunden länger und die Logausgabe scheint zu blocken bis die NTP-Zeit empfangen wurde.
Entweder kommt die Verzögerung durch das Warten auf WIFI_STATE_CONNECTED oder die NTP-Zeit wird jetzt doch blockierend geholt (Wechsel von SNTP_SYNC_MODE_IMMED auf SNTP_SYNC_MODE_IMMED )?
Das ist mir heute auch aufgefallen. Allerdings nur, wenn der ESP32 vorher nicht im Deepsleep war.
Nach dem Deepsleep geht’s zuweilen „sau schnell“.
Ist mir auch aufgefallen, bei mir sind es grob 5s (hatte es aber auf die Scan-vor-WLAN geschoben gehabt):
I [408] Hostname aus NVS geladen: ESPuino
N [410] SSID 0 von NVS geladen: NERV
[ 524][E][Wlan.cpp:417] Wlan_Cyclic(): state: 1
[ 525][E][Wlan.cpp:186] handleWifiStateConnectLast(): start conneting
N [610] Versuche mit WLAN 'NERV' zu verbinden...
D [649] Freier Heap-Speicher nach Setup-Routine: 119792
D [649] PSRAM: 4191947 bytes
D [649] Flash-size: 4194304 bytes
[ 650][E][main.cpp:230] setup(): vor getLocalTime
[ 5656][E][main.cpp:236] setup(): nach getLocalTime
Der Schuldige scheint getLocalTime(&timeinfo) in Zeile 231 zu sein. Der blockiert die Ausführung des Codes bis a) eine Uhrzeit vom NTP erhalten wird, bzw b) ein 5s timeout ausläuft (kann man schön hier sehen).
Damit wird auch die Ausführung der WLAN Zustandmaschine angehalten (bzw nie weiter ausgeführt).
Auffallen tut es erst mit meiner Änderung, da bis davor der WiFi Treiber direkt über den Verbindungsstatus abgefragt wurde. Die Tasks für die LEDs sind zu dem Zeitpunkt wo wir blockieren schon hochgefahren. Somit bekam dieser direkt mit, dass das WiFi verbunden ist.
Dadurch dass die WLAN FSM nicht aufgerufen wird (da dieser in der Main „loop“ Task läuft und dieser durch getLocalTime blockiert wird), ändert sich auch der WLAN Status nicht.
Wie wir dem Abhilfe schaffen muss ich noch schauen… Wahrscheinlich werden wir die Uhrzeit nur nach WLAN holen können (oder es vorher auf einen Dummy-Wert fixieren müssen).
Meine Vermutung wegen dem schnellen Boot aus deepsleep: localtime_r / ntp speichert die Uhrzeit im RTC-RAM ab, damit ist diese nach einem Deep-Sleep valide, nach einem power on nicht.
edit (die x-te):
Ohne getLocalTime braucht es 1,4s mit scannen:
N [408] SSID 0 von NVS geladen: NERV
[ 522][E][Wlan.cpp:186] handleWifiStateConnectLast(): start conneting
N [608] Versuche mit WLAN 'NERV' zu verbinden...
D [649] Freier Heap-Speicher nach Setup-Routine: 120024
D [650] PSRAM: 4191947 bytes
D [650] Flash-size: 4194304 bytes
[ 650][E][main.cpp:230] setup(): vor getLocalTime
[ 653][E][main.cpp:236] setup(): nach getLocalTime
N [1396] Verbunden mit WLAN 'NERV' (Signalstärke: -53 dBm, Kanal: 3, MAC-Adresse: 2C:C8:1B:3F:6B:DC)
N [1406] Aktuelle IP: 192.168.88.55
Ich hatte jetzt diese Änderung in Verdacht:
von
// Smooth time updating (non blocking)
sntp_set_sync_mode(SNTP_SYNC_MODE_SMOOTH);
zu
sntp_set_sync_mode(SNTP_SYNC_MODE_IMMED);
Wenn ich getLocalTime(&timeinfo, 5) also mit 5ms Timeout verwende scheint Alles schnell zu funktionieren, NTP-Zeit nach Hard-Reset & RTC Zeit nach Aufwecken aus Deep-Sleep. Ist das die richtige Lösung?
Schaut gut aus. Kann auch keine negativen Nebeneffekt erkennen mit dem 5ms Timeout 
Das ändern auf https://github.com/schreibfaul1/ESP32-audioI2S.git#5a1bd13 hat leider nichts gebracht.
Beim starten der Datei, alle Pixel aus,
dann zirkulieren vier Pixel weiß mit 90Grad-Versatz.
Manchmal blitzt kurz ein güner Pixel auf, bevor die weißen zirkulieren.
Neues aus dem DEV-Branch:
Ein schönes Bastelwochenende!
Passt, vielen Dank!
Vor allem die WLAN-Anpassung war wichtig. Ich teste ja ständig neue Sets und muss die Einrichtungsprozedur dann immer durchlaufen.
Ich habe seit dem letzten Update der Audio-Bibliothek Kracksel-Sound:
lib_deps =
https://github.com/schreibfaul1/ESP32-audioI2S.git#2ef8cf7 ; clear sound (one behind latest commit)
; https://github.com/schreibfaul1/ESP32-audioI2S.git#5a1bd13 ; crackling sound (latest commit)
Die Änderung betrifft ja nur die Auswertung von ID3 Metatags und hat überhaupt nichts mit der Audioausgabe zu tun.
Kann das jemand bestätigen oder habe ich etwas übersehen?
Habe gestern die neueste dev installiert. Auch massive Störungen bei Audio . Hatte aber noch keine Zeit es einzugrenzen.
Habe ich auch bemerkt, aber es auch vorest nicht gernauer verfolgt. Bei mir hat es abhilfe geschafft, die Prioirtät des AudioTasks von 2 auf 3 zu erhöhen. Damit bekommt er mehr Rechenzeit und das Problem war weg.
Audiotask mit Priorität 3 funktioniert bei mir, auch in allen Modi (+BT-Source/Sink). Kann sonst keine Nebenwirkungen feststellen.
Die Taskauslastung kann man sich ja auch zur Laufzeit anzeigen lassen mit
„http://espuino.local/stats“
Die Audiobibliothek kann immer mehr, ist aber auch „hungriger“ geworden…
Neues aus dem DEV-Branch:
