Für jedes meiner Kinder, die einen ESPuino haben, habe ich ein MP3 aufgenommen, das einfach sagt „Ich bin die Musikbox von Kind x“.
Da wir ja nun virtuelle RFID-Karten kriegen (siehe Added virtual RFID-Cards by caco3 · Pull Request #319 · biologist79/ESPuino · GitHub), möchte ich dieses MP3 natürlich auf eine Taste legen. Und ich hätte gerne, dass, wenn das MP3 fertig ist, das vorherige MP3/Playlist weitergeführt wird. Also so, wie bei CMD_TELL_IP_ADDRESS und CMD_TELL_CURRENT_TIME.
Leider bin ich aber aus dem Code noch nicht schlau geworden. Vermutlich müsste man das MP3 abspielen, aber ohne, dass man die currentRfid ins NVS schreibt, da man ja danach die vorherige currentRfid wieder von da zurücklesen muss.
Hat jemand eine Idee, ob und wie das einfach umsetzbar wäre?
Das geht so einfach nicht.
Die beiden genannten Funktionen unterscheiden sich insofern von einem klassischen Playback, als dass die Audiolib diese Funktionalität wegkapselt. D.h. eine Playlist, die wir ja immer anlegen, ist weiterhin aktiv, die Wiedergabe ist nur pausiert. D.h. bis auf ein paar Statusflags zu setzen und die jeweiligen Methoden aufzurufen, haben wir da keine Arbeit mit. Nice.
Wenn du aktiv ein anderes mp3 abspielen willst, dann müsstest du entweder die aktuelle Playlist modifizieren (DER TOD!) oder du müsstest den aktuellen Playliststand im NVS wegspeichern (das passiert aktuell aber nur bei Hörbüchern und klappt im Zufallsmodus nicht sicher, weil immer wieder neu gewürfelt wird), eine neue Playlist generieren, den Kram abspielen und dann wieder die alte Playlist starten.
Gefällt mir ehrlich gesagt nicht, dass du das Bedienkonzept von ESPuino so verwässern willst. Zumal: Fangen wir dann an, dass manche Tasten die aktuelle Playlist nur kurz unterbrechen, während sie andere Tasten aber ablösen?
Verträgt sich das alles auch mit DONT_ACCEPT_SAME_RFID_TWICE?
Deine Kinder haben doch bestimmt Lieblingstiere, oder? Mach’ nen Aufkleber mit dem Lieblingstier auf die Box. Problem gelöst, kein Engineering notwendig .
Ja, genau etwa so habe ich mir das vorgestellt.
Aber (wie das doch so meist ist), es mir als viel einfacher vorgestellt.
Soweit ich sehe, verwendet die Bibliothek GoogleTTS. Theoretisch könnte ich da ja auch meinen einen Text übergeben, so wie es ja auch in Feature Text To Speech by Joe91 · Pull Request #191 · biologist79/ESPuino · GitHub gemacht wird (wieso ging es bei dem MR nicht weiter?).
Kann man GoogleTTS ohne Token nutzen? Oder habt Ihr ein Token hinterlegt und hofft, dass das kostenlose Limit nie erreicht wird?
Ich war mir bewusst, dass sich das beissen könnte, ich habe mir das auch eher als Patch für mich und nicht einer allgemeinen Lösung vorgestellt.
Das haben die Kinder bereits selber mit Filzstiften (Holzboxen) gemacht → Man lerne; Kinder und Erwachsene haben andere Schönheitsvorstellungen
Ja, das hatte ich eben auch im Hinterkopf. Aber das hat natürlich die Einschränkung, dass es eine Internet-Verbindung braucht. Und ggf. klingt’s auch nicht so gut wie der Papa .
Wir waren hier schon 2-3 mal an dem Punkt, dass das Hinzunehmen einzelner Zeilen Code (!) dazu geführt hat, dass die Audiowiedergabe geruckelt hat. Also Sachen an eigentlich ganz unkritischen Stellen. Irgendwie haben wir es wieder in den Griff bekommen mit verschiedenen Maßnahmen, aber ich glaube was wirklich zum Ruckeln geführt hat, haben wir eigentlich nie verstanden. Dazu halt noch, dass ESPuino Unmengen an Features hat und wir immer mal wieder das Problem haben, dass abseits des „Mainstreams“ regulär wenig getestet wird. Also ich will hier eigentlich gar nicht so der Gatekeeper sein, aber wir haben Unmengen an Features und ich glaube aber, dass einige von denen von extrem wenigen Leuten benutzt werden. Insofern sind wir dann durchaus auch hingegangen und haben Features zur Disposition gestellt und gefragt, ob auch wirklich ein paar Leute hier ihr Interesse dafür bekunden. Und ich glaube da gab’s damals bei diesem Feature wenig Resonanz. @Niko benutzt das für sein Smarthome und hatte da mal irgendwo ein Video gezeigt.
Wie das im Detail läuft müsste @Wolle beantworten, aber ich weiß, dass es in der Vergangenheit immer mal wieder zu Problemen gekommen ist, weil irgendwelche Limits erreicht wurden. Ich meine es wurde zeitweise dann was Anderes benutzt, das war aber noch weniger verlässlich. Also irgendwie so…
Ja ok, für dich alleine ist das natürlich was Anderes.
Ich habe die Codebasis noch zuwenig studiert, ev. macht Ihr das ja schon richtig. Ich habe bei der Arbeit auch einige Projekte mit FreeRTOS gemacht, was ja hier auch verwendet wird. Wenn man die Threads richtig priorisiert, sollte es eigentlich keine solche Probleme gehen. Also man müsste den Audioplayer in einem separaten Thread mit höchster Priorität haben. Das UI und alles andere, nicht zeitkritische, wird dann nachgestellt.
Ja schon, aber wir waren hier schon an einem Punkt, da hast du irgendwo im Code (völlig unkritisch) ein serial.print eingefügt und dann hat’s geruckelt. Also es muss wohl irgendwas mit Speicher zu tun haben.
Letztlich ist es halt so, dass die Audiolib in den letzten Jahren seeeehr viel dazu gelernt hat, aber das macht sich natürlich auch in deren „Footprint“ bemerkbar. Wir haben auch schon einige Tweaks vorgenommen (z.B. Arduino als Komponente), aber sind schon irgendwie an der Grenze.
Kam bei mir erst letztens wieder vor, ein serial.print (das kein einziges Mal ausgeführt wurde) führte zum Ruckeln, dann habe ich es mit der Zeile untendrunter vertauscht und das Ruckeln war weg. Stranger geht es nicht.
Gemäss Dokumentation sollte serial.print* mittlerweile non-blocking sein, das dürfte also keinen Einfluss haben.
Wenn ich mir aber die Thread-Prioritäten anschaue (xTaskCreate*), sehe ich folgendes:
Thread
Priority
Core
AudioPlayer_Task
2, portPRIVILEGE_BIT
1
Led_Task
1
1
Rfid_Task
2 , portPRIVILEGE_BIT
1 (MFRC522) resp. 0 (PN51800)
fileStorageTask
1
1
Offenbar haben wir ja 2 Cores. Ev. würde es helfen, in einem Core nur den Audioplayer laufen zu lassen?
Und wieso haben die zwei RFID-Module unterschiedliche Cores? Auf jeden Fall sollte der Audioplayer höhere Priorität haben als der RFID-Task!
.
→ Man lerne; Kinder und Erwachsene haben andere Schönheitsvorstellungen 
.