Ich weiß es nicht sicher. Aber ich habe mal den PCB genommen für den Lolin D32 pro. Ohne HP_DETECT und ohne Kopfhörerplatine habe ich was gehört. Mit aktiviertem HP_DETECT und nur INPUT ging es nicht. Mit Pulldown auch nicht. Mit PullUp aber schon.
Vielleicht kann das mal noch jmd hier testen, weil ich habe es auch in den Masterbranch eingecheckt.
Ich hab mir hierzu mal das notiert, aber finde die Quelle gerade nicht:
- Die Verstärkung des MAX kann über die Beschaltung des GAIN Pins wie folgt angepasst werden.
| Gain Rate | Gain Pin Connection |
|---|---|
| 15 dB | Connected to GND through a 100k resistor |
| 12 dB | Connected to GND |
| 9 dB | Unconnected (Default) |
| 6 dB | Connected to VDD / Vin |
| 3dB | connected to VDD / Vin through a 100k resistor |
Das kommt aus dem Datenblatt vom max98357a. Aber Gain ist nochmal was Anderes. Der Pin zum Mute heißt glaube ich sd oder so (müsste nachschauen).
Ich habe das hier gefunden
One thing! A very loud POP at both power on and when the mpd/mpc “play” command was issued. Solved the
power on POP with a 10K pull-down resistor on the SD (mute) pin. Worked around the “play” POP by delaying
the un-mute for 2 seconds after starting “play”.
So, das neue Partitions-Layout ist nun im Refactoring-Branch aktiv. Es gibt ein Profil für 4 MB Flash und eines für 16 MB.
Wenn ihr also ein Update macht, dann beachtet das hier: 📗 Wechsel zum Refactoring-Branch: Was ist zu beachten?
Beim Neustart wird eine Warnung angezeigt, die nach fünfmaliger Anzeige nicht mehr erscheint.
@tuniii Du hattest ja mal eine Anzeige eingebaut, bei der man den derzeit größt-möglichen „Heap-Brocken“ angezeigt bekommt. Mit aktiviertem PSRAM wird da offenbar der PSRAM dazugezählt. So habe ich auf einem Lolin D32 pro gerade 3.881.772 Bytes. Ist halt nicht so zielführend 
Wollte es nur hier mal erwähnen, weil das erschwert dann die Fehlersuche ggf bei den WROVERn.
@MusikHexe / @tuniii Habe den Bug mit Bluetooth im Refactoring-Branch eben gefunden und gefixt.
Problem war, dass der Audiotask nicht gestartet werden darf, wenn der BT-Mode aktiv ist.
@compactflash Ich habe eben im Refactoring-Branch eine Anpassung eingecheckt, die dafür sorgt, dass die JSON-Objekte aus dem PSRAM allokiert werden (sofern dieser halt vorhanden ist). Kannst das mal auf deiner Hardware etwas testen? Auf dem Lolin D32 pro funktioniert es auf jeden Fall.
Hi @biologist
Habe heute Morgen mal die neue Version geflasht . Wrover mit 16Mb und SD_MMC , DAC PCM5102A .
Bis jetzt funktioniert alles , Restore kein Problem , Bluetooth , FTP geht und gefühlt läuft Webradio besser . Hatte immer ganz selten kurze Knackser zwischendurch was bisher nicht mehr aufgetreten ist . Kann das sein ?
Was soll ich mal besonders testen ?
VG
Ja den Eindruck hatte ich zwischenzeitlich auch, dass es die mal gibt.
Vielleicht mal das Playlist-Caching. Auch gerne mal mit größeren Playlists. 65 Titel habe ich gestern mal getestet; das gab weder bei WROOM noch bei WROVER Probleme.
Was ich zwischenzeitlich auch nochmal geändert habe ist die Speicherallokation beim Generieren der Playlist. Da hatte ich immer 512 Byte-Blöcke mit calloc() allokiert, welche bei größeren Playlists 512b-weise reallokiert wurden. Da habe ich jetzt mal 4096 Bytes draus gemacht und ich hatte den Eindruck, dass das im ungecachten Zustand spürbar schneller. Vielleicht reduziert es auch die Heap-Fragmentierung. Aber beim WROVER schöpfe ich da jetzt eh quasi aus dem Vollen und gehe gleich auf 64k. Weiß gar nicht, was ich mit den 4MB PSRAM alles machen soll, selbst wenn ich es gefühlt verschwende 
.
Abgesehen von der limitierten (statischen) JSON-Objektgröße beim ESP32-WROOM für den Dateibrowser in der GUI, bin ich aktuell der Meinung, dass wir auf einem guten Level sind. Ich gehe daher davon aus, dass ich jetzt im Juli den Refactoring-Branch zum neuen Master mache 
So, ich habe jetzt noch ein paar kosmetische Sachen vorgenommen.
TOGGLE_WIFI_STATUS oder CMD_ENABLE_FTP_SERVER. Die heißen nun CMD_TOGGLE_WIFI_STATUS oder CMDCMD_ENABLE_FTP_SERVER.Habe es heute mal mit 112 Files getestet . Habe es im Hörbuchmodus und mit alle Titel eines Verzeichnis (sortiert) probiert . Das erste Erstellen des Caches hat jeweils ca. 12 Sekunden gedauert und danach lief es . Gefühlt ist es jetzt auch bei kurzen Playlists ( <20 ) schneller . Schon wieder ein Punkt super erledigt .
Eine Sache ist mir dabei aber aufgefallen : Ich hatte versehentlich Files im Apple Lossless Format (M4A) aufgespielt . Wenn so ein File abgespielt wird gibt es einen Dauer-Reboot . Dumm wenn wie bei mir #define PLAY_LAST_RFID_AFTER_REBOOT aktiviert ist . Hilft nur noch Karte raus und die Files am PC löschen . Es passiert auch wenn cachen nicht aktiviert ist . Ich bin mir ziemlich sicher dass der Reboot bei einer älteren Version , evtl. auch ältere ESP32-audioI2S , nicht aufgetreten ist . Ich hatte damals mal alle möglichen Audioformate getestet . Bei nicht unterstützten wurde es einfach nicht abgespielt , aber es gab keinen Reboot .
Anbei mal die Monitorausgabe
Reboot Espuino.txt (3,2 KB)
VG Willmar
OK, dann muss ich auf m4a nochmal ein Auge werfen. Und das Remember-Feature muss ich etwas entschärfen. Vielleicht speichere ich im NVS eine Variable mit einem Count, den ich mit jedem Boot um 1 erhöhe. Nach zB 30s Betriebszeit ziehe ich davon wieder 1 ab. Diese 30s erreicht man im Fehlerfall ja nicht, so dass der Wert normalerweise nicht größer als 1 werden kann.
Auf jeden Fall wenn der Bootcount dann 3 erreichen sollte, dann wird das Remember-Feature übergangen, so dass man die Bootloop bricht.
Müsste so klappen.
Hab heute den Refractoring-Branch mit den A1S Board und I2C Kartenleser getestet. Die Version läuft bei mit ohne Probleme. Mir sind nur zwei „Kleinigkeiten“ aufgefallen.
„logmessages.h“ den Dateinamen von Kleinschreibung auf „LogMessages.h“ geändert
Die vielen Backslashes sind nicht unbedingt erforderlich,
ohne ist die Datei besser lesbar.
HTMLmanagement_DE.h.txt (45,0 KB)
mein Fazit: super Arbeit!
vG Wolle
Danke für dein Feedback, bislang hatte ich zum a1s noch keines 
Das kannte ich gar nicht mit der mehrzeiligen Darstellung.
@Wolle
Ich wüsste ja gerne mal, warum ich nicht in diesen Fehler gelaufen bin. Du arbeitest mit Eclipse, oder? In Platformio wurde mir das nicht angezeigt als Fehler, aber kann das nachvollziehen. Passe den Include in Log.h an.
Hattest du sonst noch was angepasst oder war das quasi „vanilla“? Weil i2c-Kartenleser habe ich selbst bisher noch nicht getestet.
So, habe den Fix eingebracht. Alle, die den Refactoring-Branch zusammen mit dem Feature PLAY_LAST_RFID_AFTER_REBOOT nutzen: bitte mal testen 
Ist bisschen schwer ein objektives Kriterium zu finden, das ein Bootvorgang erfolgreich war. Ich habe jetzt einfach mal unterstellt, dass dies nach einer Uptime von 30 Sekunden der Fall ist. Auch größere Playlists sollten bis dahin generiert worden sein.
Im Umkehrschluss bedeutet das natürlich: Wenn ihr euren ESPuino testet und ihn mehrfach vor Ablauf von 30s neu startet, dann wird das als Bootloop erkannt und der ESPuino wird die zuletzt aufgelegte Karte einerseits nicht automatisch neu aufrufen und andererseits diese aus dem Speicher (NVS) als zuletzt aufgerufene Karte löschen. Die Zuweisung zwischen Datei/Pfad und RFID selbst bleibt aber natürlich erhalten. Neu gestartet oder ausgeschaltet wird der ESPuino bei Bootloop-Erkennung nicht; es geht einfach nur darum, diese Bootloop zu brechen.
Wer PLAY_LAST_RFID_AFTER_REBOOT nicht nutzt, für den ändert sich nichts.
Liegt warscheinlich daran, dass du mit Win arbeitest, das achtet bei Dateinamen nicht auf Groß-Kleinschrift.
Hatten wir bei den Includefiles auch schon mal.
Programme egal ob eclipse, ArduinoIDE oder Platformio geben den Dateinamen so wie er geschrieben ist an das Betriebssystem welches dann das ganze bearbeitet.
Windows ist da sehr tollerant.
Ob das beim iOS auch so ist weiß ich nicht.
Linux ist da auf jeden Fall pingelig.
Grundsätzlich ist dieser Einwurf absolut richtig, aber ich nutze Mac OS. Als BSD-Derivat wird da auf jeden Fall Case-sensitive gearbeitet.
Könnte es auch an Visual Studio Code liegen, dass da etwas tolleranter gelesen wird.
Ich bin recht schnell nach dem 2. Austeigen nach Updates von VSCode auf Atom umgestiegen. Sieht ähnlich aus und ist mir noch nie abgeschmiert.
habe gerade mal gesucht,
https://discussions.apple.com/thread/251191099
Scheint per default nicht case-sensitiv zu sein. Liegt wohl an den Filesystemen.