bei mir floatet der Pin HP_detect , da fehlt der Pullup in der Audio.cpp #ifdef HEADPHONE_ADJUST_ENABLE
pinMode(HP_DETECT, INPUT_PULLUP);
Beim Ausschalten habe ich ein leichtes Knacken , kannst du bitte den GPIO_PA_EN vor Abschalten deaktivieren . Je nach verwendeter Hardware passiert das auch beim Systemstart . Auch da wäre ein kurzer delay 200-500ms von Vorteil
VG
Edit: Ich habe es beim Abschalten mit der aktuellen Version noch nicht getestet ob es da auch passiert , war vorher irgendwann mal so .
Ok, danke für dein Feedback.
Das muss ich dann aber auf den Fall einschränken, dass es ein GPIO und nicht der Port-Expander ist. Ich überlege jetzt nur gerade: Was machen wir denn, wenn DETECT_HP_ON_HIGH gesetzt ist? Dann muss ich ja nen Pulldown setzen, oder?
Ja , das hatte ich auch schon überlegt und war mir unsicher .
Ich habe im Moment mit der Cliff ( bei gestecktem Hörer ist Kontakt offen ) #define DETECT_HP_ON_HIGH , das funktioniert . Umgekehrt müßte es doch auch gehen . Da frage ich doch auf LOW ab . Ich denke das klappt . Werde ich mal ausprobieren . In der Praxis ist man ja vor Überraschungen nicht sicher
Das delay habe ich schon drin und ich denke so max 500 ms sind ok
Also … es funktioniert mit dem Pullup in beiden Fällen. Ich hatte mal diese Buchsen bestellt und ein Layout erstellt mit der Möglichkeit HIGH oder LOW-aktiv zu jumpern . Damit habe ich es probiert . Die Buchsen sind sehr billig , wirken aber robust und sind damit eine sehr gute Alternative zu den recht teuren Cliff-Kopfhörerbuchsen . Außerdem sind zusätzlich zu den Schaltkontakten für Audio noch 2 potentialfreie Umschaltekontakte vorhanden .
So, ich habe das jetzt mal angepasst. Wenn ich so drüber nachdenke: Vielleicht bringt das auch dem ein oder anderen hier was, der Probleme mit meinen PCBs ohne Kopfhörerplatine hatte.
Teste bitte mal, ob das jetzt passt. Ich habe beim Einschalten ein Delay derart eingebaut, dass die Amps frühestens nach 500ms Uptime aktiviert werden. Und beim Ausschalten werden die Amps zuerst deaktiviert.
Funktioniert natürlich nur, wenn man GPIO_PA_EN und/oder GPIO_HP_EN definiert hat. Ich habe bei mir keinen Testaufbau, um das testen zu können. Es ist also ungetestet, aber kompilieren lässt es sich auf jeden Fall
Hi @biologist
Ich glaube meine Idee zum Pullup an HP_detect ist für Nutzer des MAX98357 eher kontraproduktiv .
Da war doch mal was .
Die Arbeitsweise des MAX98357 wird doch mit Widerständen an Pin SD eingestellt . Damit verändert ein Pullup die Werte und ich weiß im Moment nicht was dann passiert . Ich verwende auf meinem neuen Board keinen MAX mehr und daher tritt das Floaten bei meiner Hardware auf .
Das müßte man nochmals in allen Hardwarevarianten testen . Ich glaube ja auch dass es durch die damals eingeführte Variante Play_Mono_Speaker nicht mehr passiert .
Gruß Willmar
Die andere Änderung werde ich am WE mal ausprobieren .
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 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 ?
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.
DREHENCODER heißt jetzt aus Konsistenzgründen ROTARYENCODER
Alle Commands fangen nun auch wirklich mit CMD an. Beispielsweise hieß es bisher TOGGLE_WIFI_STATUS oder CMD_ENABLE_FTP_SERVER. Die heißen nun CMD_TOGGLE_WIFI_STATUS oder CMDCMD_ENABLE_FTP_SERVER.
Language-Code ist jetzt nicht mehr 1 oder 2 sondern DE bzw. EN. Ich denke das ist besser lesbar.
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)
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)
.
