@Saile danke für dein Feedback. Schaue ich mir nochmal an.
Ich finde es ja irgendwie strange, dass BT bei Manchen funktioniert und bei Anderen (inkl. mir) nicht.
Habe gerade deine letzte Version installiert … Bluetooth funktioniert ( iPhone).
Hardware = Lolin D32 Pro und RC-522
Kann ich nicht bestätigen , es setzt bei mir immer noch kurz aus .
Ich habe gestern mal ein bisschen mit dem Port-Expander gearbeitet. Also er funktioniert auf jeden Fall auch im Refactoring-Branch. Bisher hatte ich das noch nicht getestet.
Da bin ich gerade dran. Das war gar nicht so wenig, das ordentlich zu abstrahieren. Funktioniert aber noch nicht vollständig. Techniker ist informiert 
@compactflash Ich habe das jetzt so vorgesehen, dass es ein #define namens DETECT_HP_ON_HIGH_LEVEL gibt. Ist das gesetzt, so wird der eingesteckte Kopfhörer dann erkannt, wenn der Level high ist (und umgekehrt). Per Default, also wenn man es nicht setzt, ist es wie bisher.
An der Stelle muss ich mein Lob nochmal an @tuniii aussprechen. Das mit den init/cycle-Funktionen pro Modul ist ne echt coole Sache. Da sieht man schnell, was initial gemacht wird und was dauernd 
BT ist mir aktuell noch ein Rätsel. Das scheint ja irgendwie auf ESP32-WROVER zu funktionieren aber auf ESP32-WROOM nicht.
1 „Gefällt mir“
Also … ich werde vermutlich da jetzt nicht mehr weiterkommen.
Grundsätzlich funktioniert der Ablauf jetzt so wie ich mir das vorgestellt hatte.
Aber:
- Ich habe immer noch das Problem, dass die Kommunikation „manchmal“ einfach abbricht. Der ESP bekommt dann ein ACK nicht (oder versteht es nicht). Dann gibt es timeouts / beide Seiten sind verwirrt. Das könnte man sicher softwareseitig noch abfangen…
- Ich habe mir einen Stress-Test gebaut, der permanent den Verzeichnisbaum abruft. Nach ca. 30 Durchgängen ist Schluss. Timeout, Reconnect und Heap geht massiv runter. Manchmal auch Reboots.
Insgesamt fühlt sich das nicht sehr zuverlässig an.
Ich habe jetzt noch zwei Ansätze, aber gerade keine rechte Motivation dafür.
- Den Buffer des websocketservers weniger stressen.
- Andere websocket-lib.
Ich werde mein Github noch aktualisieren, vielleicht mögt ihr ja noch einmal schauen.
Ich habe gleichzeitig einige (optische) Anpassungen an der Webgui gemacht, die würde ich als Pull-Request vorschlagen.
OK dann trotzdem danke für deine Mühen. Also entweder weniger stressen oder damit leben, dass die Größe des Baumes limitiert ist. Eija du kannst es ja mal hochladen und ich schaue es mir an. Vielleicht ist das in der Praxis ja gar nicht so tragisch.
Mal eine grundsätzliche Frage: Und zwar besteht eine Playlist ja immer aus einem oder vielen Files, wobei zu jedem File der komplette Pfad angehängt ist. Das müsste ja nicht sein, weil man könnte den Pfad auch einfach einzeln übertragen und dann mit allen Dateinamen konkattenieren.
Beispiel aktuell:
2
/Pfad/zum/File1.mp3
/Pfad/zum/File2.mp3
Beispiel zukünftig:
2
/Pfad/zum/
File1.mp3
File2.mp3
Also für die Playlist würde das auf jeden Fall Heap sparen und wäre vorteilhaft. Würde uns das für die GUI auch was bringen?
Das macht die WebGUI aktuell doch schon ;). Da der Client ja den Verzeichnispfad zu den Dateien kennt, überträgt der Esp nur die reinen Dateinamen ohne den Pfad. Wo man etwas sparen kann, ist das Json Format durch was proprietäres zu ersetzen. Das könnte 20 Bytes pro Eintrag sparen. Keine Ahnung ob es einen wirklichen Mehrwert hätte.
So, ich habe eben einen größere Commit gemacht. Mit diesem ist es möglich, per GPIO oder Port-Expander, einen Ausgang auf logisch 1 zu setzen, so dass Verstärker für Kopfhörer/Lautsprecher aktiviert/deaktiviert werden können. Entsprechend habe ich auch die Logik in den Code integriert, dass jeweils eines von beiden ausgeschaltet ist.
Mir ist hierbei leider noch ein Problem aufgefallen, was vor dem Refactoring entweder kein Problem war oder mir nicht aufgefallen ist. Und zwar führt der Einsatz eines Port-Expanders in meinem Testaufbau zu einer unsauberen Audiowidergabe. Ich vermute, dass das zyklische Auslesen des Port-Expanders zu lange dauert. Ggf. liegt es auch an meinem Aufbau hier (habe bisher keinen PCB dafür sondern den Port-Expander per Jumperwires angebunden). Ich denke ich werde an der Stelle doch darüber nachdenken müssen, den Interrupt-Pin des PCA9555 auszulesen (anstatt zyklisch zu pollen).
Benutzt den Port-Expander hier schon jmd. und kann den Test mal durchführen? Ich vermute ja mal nein 
Hi @biologist
Ich bin gerade dabei dein neues refactoring mit meiner neuer Hardware zu testen . Dabei habe ich folgendes Problem : Ich benutze keinen Portexpander . Die Software startet nicht weil ich sofort einen Brownout bekomme . Ich finde auch die Stelle nicht im Code wo Pin GPIO_PA_EN geschaltet wird ohne Portexpander . Fehlt da noch was ?
Der code von Tuniii mit OTA ( refactoring_tuniii ) funktioniert . Dort habe ich GPIO_PA_EN im Setup eingefügt
VG
Hi @compactflash,
das wird alles in der Port.cpp gemacht. Muss zugeben, dass ich es mit normalem gpio nicht getestet habe. Müsste ich wohl nochmal machen.
Nochmal eine Frage dazu: Wie ist deine Schaltung aufgebaut? Weil ich habe das als Output konfiguriert, d.h. das ist nicht einfach nur ein Pullup. Sorgt deine Schaltung für Strombegrenzung?
Ist bei mir auch ein Output , die Schaltung entspricht dem Original von AI-Thinker und es funktioniert ja auch .
Das in der Port.cpp hatte ich gefunden , da fehlt mir aber nach
#ifdef GPIO_PA_EN
…
sowas wie ein else
um auch ohne PA den GPIO zu schalten .
Aber vielleicht sehe ich das auch nicht .
Also es gibt in der Port.cpp eine Behandlung die greift, wenn HEADPHONE_ADJUST_ENABLE nicht aktiv ist.
Wenn HEADPHONE_ADJUST_ENABLE aktiv ist, dann greift eine Behandlung, die in Audioplayer.cpp liegt. Ich gebe zu, das ist nicht so ultimativ geschickt, das an zwei Stellen zu haben. Das werde ich nochmal in Ordnung bringen. Die Idee kam mir auch schon bei der Implementierung.
Danke @biologist , hab’s kapiert .
Hallo @biologist
Meine Probleme waren selbstverschuldet , Tippfehler in den settings . Deine Umsetzung funktioniert wieder mal hervorragend , danke dafür . Jetzt kann ich mein PCB final fertigstellen . War es eigentlich schon aber ich habe einen Fehler gamacht , der sich aber mittels Drahtbrücke korrigieren läßt . Aber eine andere Sache kann ich nicht korrigieren und erfordert ein neues PCB . Vielleicht hat ja jemand eine Lösung oder Antwort zu dem Problem .
Ich verwende ja den On/Off- Controller LTC2954 . Dieser hat zum Abschalten den Pin Kill .
Auf meinem ersten PCB , was auch schon lange online gestellt ist habe ich für den Pin Power(Kill) den GPIO21 benutzt . Dies war zufällig ausgewählt und funktioniert einwandfrei . Auf meinem neuen PCB habe ich wegen des einfacheren Routings den Pin auf GPIO13 verlegt . Dabei tritt ein merkwürdiges Problem auf , und ich weiß nicht warum . Der LTC2954 gibt beim Spannungseinschalten den Pin Kill erst nach ca. 0,5 Sekunden frei . In dieser Zeit muss der ESP32 den GPIO auf HIGH gezogen haben , wenn dies nicht erfolgt schaltet der LTC2954 wieder aus . Mit GPIO21 geht das , mit GPIO13 nicht . Ich habe leider kein Oszilloskop um die Länge des Impulses zu messen aber scheinbar braucht der ESP32 für GPIO13 länger als 0,5 Sekunden . Im Datenblatt des ESP32 Seite 50 ist eine Übersicht des Pinverhaltens nach Reset . Dort gibt es eine Unterschied aber ich weiß es nicht richtig zu deuten . Wahrscheinlich macht das weak pull_down den Unterschied auch wenn es nur ein paar Millisekunden sind .
Hat jemand Erfahrung und kann mir da helfen ?
Wenn ich den GPIO13 im Setup als erstes auf HIGH setze funktioniert es auch nicht . Ich habe mittels Drahtbrücken die beiden GPIO13 und GPIO21 getauscht und es funktioniert . Ich habe das schon im Layout geändert , es interessiert mich aber trotzdem warum da ein Unterschied ist .
EDIT: Habe diese Doku gefunden . Dort geht es eindeutiger hervor und es gibt einen Unterschied zwischen den beiden Pins. Die Angabe auf Seite 60 scheint bei GPIO13 fehlerhaft zu sein . Hatte bei der Auswahl der Pins Pech .
VG
Noch eine Anmerkung : ohne PSRAM ständig Aussetzer mit Radiostreams auch mit externer WLAN-Antenne , mit PSRAM bisher nie .
Fazit für mich : nur Wrover verwenden . Ich benutze z.Zt. Wrover IE 16Mb
1 „Gefällt mir“
Hi
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?
Das mit den Delay müsste einfach machbar sein.
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
Gruß Willmar
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 .
VG
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 .