Ich wollte jetzt schon schreiben NEIN, aber du bringst mich da auf eine Idee. Und zwar allokiere ich den Speicher für die Playlist auf dem Heap. Beim PRO haben wir jedoch einen WROVER und der hat ja PSRAM. Das wäre durchaus möglich in diesem Falle die Playlist (statt auf dem Heap) im PSRAM zu allokieren. Ich denke da gibt es, wenn ich so drüber nachdenke, auch noch diverse andere Stellen, an denen man optimieren könnte.
Wie das dann aber in der GUI skaliert bei vielen Files kann ich dir nicht sagen.
Ja genau. Also ich könnte natürlich auch einen anderen Integer nehmen, aber ich habe das damals so festgelegt, weil sonst am Ende ggf zu wenig Heap frei ist.
Ist hier im Prinzip völlig wurscht, wie schnell die Karte ist. Limitierend ist auf jeden Fall der ESP32.
Da der Fix relativ einfach war, habe ich den gestern schon eingebracht. D.h., wenn man einen WROVER verwendet, dann wird der künftig seinen Heap auf dem PSRAM allokieren.
Ein größerer Batzen wäre noch ein dynamisches JSON-Objekt. Aber da hatte ich gestern Abend keine Zeit für, weil ich noch mit dem PCA9555 weitermachen musste.
Ich habe heute ein wenig den Code für ein MiBand2 auseinandergenommen.
Steuere damit Abends meine Hörbuch App aber man kann auch mit MQTT arbeiten wenn das Ding merkt das man eingeschlafen ist. Habe auch sowas mit python mal gebaut.
Überlege noch ein wenig wie man das pausieren verbessern kann, wenn die Kids was größer sind.
Nein. Das ist ein N-Channel-Mosfet. Du brauchst einen P-Channel
Ist der passende Typ. Vgs liegt bei -2 bis -4V. Wenn man ein Modell hat, das Richtung -4V streut, wird es nicht gehen. Aber „normalerweise“ sollte es passen.
Das Gleiche wie IRF4905. Wurde hier von Leuten afaik bereits verwendet.
Hallo,
Ich hänge mich jetzt einfach einmal an diesen tread an, ich hoffe das ist okay.
Wir haben einen ersten Test-Espuino zum laufen bekommen, darüber bin ich super glücklich. Für die ersten Tests ist es jetzt doch ein Lolin32 geworden.
Ich habe einen Ordner mit Hörspielen auf die SD gepackt und im Hörbuchmodus angelernt.
Leider habe ich genau das gleiche Problem wie @DrBabbage
Ich habe dann versucht verschiede Fehlerquellen auszumerzen:
Da einige Hörspiele mit 30min je Datei in dem Ordner waren, habe ich als erstes einmal nur ein Hörspiel ausgewählt. Als das nicht half habe ich ein Hörspiel in 5min Etappen geteilt und als einen Ordner genommen. Auch hier speichert er nur den Track und nicht wo er genau ist. Zuletzt habe ich es ohne Erfolg in 1 Minuten Teile geteilt.
Um sicher zu sein das der Dateiname keine Probleme macht habe ich die Tracks einfach durchnummeriert, ohne Namen.
Oder verstehe ich die Funktion falsch, das es auch innerhalb eines Titels speichert?
Sonst würde ja aber ein Hörbuch aus einem Titel wie hier beschrieben
Keinen Sinn machen, oder?
Was könnte noch ein möglicher Fehler sein? Als Pausetaste habe ich den Drehencoder short press. Aber der tut ansonsten was er soll.
Ja, also wenn ein Titel als Hörspiel klassifiziert ist, dann sollte die Position z.B. beim Drücken der Pausetaste gespeichert werden. Bin mir gerade nicht sicher, aber ich glaube der String, der ins NVS geschrieben wird, ist auch über die serielle Konsole zu sehen.
Das Projekt hat die Möglichkeit dazu, allerdings ist der Teil der das tut noch nicht im Code eingebaut. Die reine Position wird allerdings in der Backup.txt gespeichert. Derzeit nimmt der Epuino aber nur den zuletzt gespielten Track, wie beim Tonuino.
Es macht also derzeit wenig Sinn eine Datei für ein großes Hörbuch zu benutzen, für kleinere Serien wie Was ist Was oder die Drei Fragezeichen ist es aber schon recht bequem zufällig eins auszuwählen und dann schlafen zu gehen.
Wenn du ein großes Hörbuch in kleine Stücke teilst (zB mit mp3splt), solltest du den Pfad nicht über das Webmenü auswählen, es klappt jedoch wenn den absoluten Pfad unten direkt einträgst.
Ich habe das ganze mit der Unendlichen Geschichte in den Stresstest geschickt und mit dem absoluten Pfad hat das ganz gut funktioniert. (es gibt auch ein schönes Auryn Amulett auf thingiverse)
Momentan arbeite ich an einer BLE Schnittstelle zu einem billigen Miband um zu messen wann jemand eingeschlafen ist, da es sehr lange braucht die richtige position zu finden wenn man denn eingeschlafen ist.
Weiß nicht, ob ich dich richtig verstehe.
Also erstmal ist es ja so, dass ein Hörspiel ein File oder ein ganzer Ordner mit Files sein kann. Wenn es mehrere Files sind, dann werden alle Files alphabetisch sortiert und dann die Titelnummern daraus abgeleitet. Drückst du dann auf Pause, dann sollten Titelnummer und auch die Position im Titel gespeichert werden. Durcheinander kommt das System natürlich dann, wenn man nachträglich neue Dateien in den Ordner kopiert, die alphabetisch vor dem Titel spielen, der abgespeichert wurde. Weil es wird nicht der Dateiname gespeichert sondern einfach nur die Nummer. Es verschiebt sich dann halt alles.
Sollte das Speichern der Titelnummer und der Position darin aktuell nicht klappen, dann ist das ein Bug.
Nein, du verstehst mich und @MusikHexe glaube ich falsch.
Natürlich kannst du ein Hörbuch nehmen und das in ein File packen. Wenn man Pause drückt, wird auch in der Datei Backup.txt die Position gespeichert. Wenn man pause drückt und dann die Kiste ausschaltet wird beim wieder einschalten allerdings nur der zuletzt gespielte track abgespielt und nicht die position in der MP3. Heißt zB wenn du dein Hörbuch in 1 minuten Teile geteilt hast und 59 Sekunden gehört hast, wird beim Neustart der erste Track von Anfang an gespielt.
Das ist allerdings Stand von vor einem Monat gewesen. Ich teste heute Abend nochmal wie es heute ist. Hier gab es ja auch schon Updates Spulen im Titel - #27 von tyllmoritz
OK, dann habe ich euch tatsächlich falsch verstanden. Hätte allerdings erwartet, dass das trotzdem geht. Weil der Recall simuliert ja im Endeffekt einfach das Auflegen einer Karte.
Muss ich mir anschauen. Aber vielleicht warte ich einfach, bis tuniii mit seinem Refactoring fertig ist. Sonst muss man da 2mal Arbeit reinstecken.
Hallo, vielen Dank für die Antworten. @DrBabbage
Was du beschreibst kann ich eins zu eins unterschreiben. Der Track wird ausgewählt, aber keine Position.
Aber so wie ich euch verstanden habe heißt es hier einfach erst einmal Geduld haben. Das bekomme ich hin!
Dankeschön
Hallo Zusammen. Da Geduld offensichtlich nicht zu den Kernkompetenzen meiner Frau gehört, kapere ich mal kurz den Account um meine Beobachtungen zu schildern (Im Refactoring Branch). Zur Einordnung: ich habe mit embedded Programmierung eher nichts am Hut, wenn dann habe ich eher mit Fortran (77/90) zu kämpfen .
Ich habe versucht mal die Handhabung der Position nachzuvollziehen. Es sieht für mich folgender Maßen aus:
Das Schreiben und wieder Auslesen von Position#Modus#Track ins/aus NVS scheint so weit zu funktionieren. Bei dem Ablauf (soweit ich ihn überblicke) kommt man im AudioPlayer.cpp zum Setzen der Position bei der if-Abfrage für „gPlayProperties.playMode“ für SD mit „audio->setFilePos(gPlayProperties.startAtFilePos);“.
Bis hierher funktioniert alles wie vorgesehen. Aber in „setFilePos“ in Audio.cpp wird die durchschnittliche Bitrate „m_avr_bitrate“ abgefragt: „if(!m_avr_bitrate) return false;“, welche aber 0 ist. Diese wird verwendet um die Position im Track aus der gespeicherten Position und der Bitrate zu berechnen, was aber nicht geschieht und damit der Track bei 0 anfängt.
Soweit ich es überblicke, wird die durchschnittliche Bitrate erst später gesetzt. Ich habe versucht „getBitRate()“ zu nutzen (was „m_bitRate // current bitrate given fom decoder“ als Wert ausgeben soll) um dort („setFilePos“) den Wert zu setzen, es funktioniert aber nicht. Ich nehme an das der Decoder da noch gar nichts liefert und der Wert deswegen weiterhin 0 bleibt.
Zum Test habe ich eine konstante Bitrate für „m_avr_bitrate“ im „setFilePos“ gesetzt, die passend für den verwendeten Track war (und wieder zurück auf 0 am Ende von „setFilePos“ um den Rest nicht zu beeinflussen) und dann hat es tatsächlich funktioniert.
Somit liegt mMn der Fehler bei der nicht gesetzten „m_avr_bitrate“, mir fehlt allerdings der Überblick in dem Ablauf und den vorhandenen Funktionen um einzuschätzen ob ein Setzen vor diesem Aufruf schon sinnvoll möglich ist. Alternativ, wäre vielleicht das Speichern der durchschnittlichen Bitrate des Tracks im NVS möglich, dann muss aber auch für das Durchreichen und möglicherweise auch Zurücksetzen der Werte gesorgt werden.
Hallo @MusikHexe,
Deine Beobachtungen sind korrekt. Bei konstanter Bitrate (CBR) ist die Bitrate häufig schon an Anfang der Audiodate bekannt oder wird spätestens zum zweiten Audioframe gesetzt. Bei variabler Bitrate funktioniert das nicht so. Mediaplayer auf dem PC lesen häufig die gesamte Datei ein, bilden den Index und errechnen die durchschnittliche Bitrate des Audioblocks. Das ist aus Performancegründen beim ESP32 schlecht umsetzbar. Hier wird das Prinzip der Hochrechnungen bei Wahlen angewendet. Es reicht, wenn eine bestimmte Anzahl von Wählern befragt wird um auf das Wahlergebnis zu schließen. In der Audio Lib werden die ersten 200 Audioframes betrachtet und daraus der Durchschnitt errechnet und in m_avr_bitrate abgelegt. Der erste Wert erscheint nach 20 Audioframes, daher ist die Abfrage von getBitrate() zum Anfang 0.
Von der Benutzung der Methode setFilePos(pos) würde ich abraten. Meistens ist es nicht bekannt wo der Audioblock innerhalb einer Datei beginnt, da zusätzlich Metadaten oder Bilder in der Audiodatei integriert sein können. Wenn Du zum Beispiel in die Mitte des Audioblocks springen willst mach das besser so:
setAudioPlayPosition(getAudioFileDuration()/2);
oder von der aktuellen Position 10 Sekunden zurück:
setTimeOffset(-10);
das funktioniert bei .m4a aktuell noch nicht, dafür aber bei .flac .mp3 und .wav
Da muss ich an der Stelle nochmal nachfragen. Tatsächlich benutzt ESPuino diese Funktion. Jedoch nicht einfach beliebig, sondern es ist ein Rückgabewert, den mir die Audiolib beim Speichern zurückgegeben hat. Daraus würde ich ableiten, dass es auch eine für die Audiolib „bestimmbare“ Position war, die anschließend zum Wiedereinsprung auch taugt.
Kannst du das bestätigen?
Ja, das kann man machen. Wenn die Sprungadresse bekannt ist, z.B. weil die die aktuelle Position vorher gespeichert wurde spricht nichts dagegen.
Das funktioniert völlig unabhängig von der Bitrate. Nach der Fragestellung war ich der Meinung, es soll an eine noch unbekannte Position gesprungen werden.
Hier springe ich noch mal rein. Ich denke @biologist hat recht er holt sich die Sprungadresse und diese wird dann verwendet um mit setFilePos(pos) die Position wieder herzustellen. D.h. er benötigt die Bitrate nicht, wie @Wolle sagt. Das große ABER ist, dass m_avr_bitrate inerhalb setFilePos(pos) verwendet wird um aus dem Sprungpunkt und der Bitrate die richtige Stelle zum anspringen zu berechnen. Es sieht aber so aus das im Moment des Aufrufs von setFilePos m_avr_bitrate noch nicht definiert ist.
Mit setFilePos() wird immer zur physikalischen Stelle innerhalb der Datei gesprungen. Der Wert von m_avr_bitrate kommt in der Routine vor hat aber eine andere Funktion. Es gibt Projekte bei denen die Audio Lib zusammen mit einem Display z.B. als MP3 Player verwendet wird. Dann wird mittels m_avr_bitrate die zeitliche Stellung inerhalb der Datei errechnet um einen Fortschrittsbalken neu zu setzen. Dazu kann getAudioCurrentTime(); aufgerufen werden.
Ich glaube, der Espuino benötigt die Zeitfunktion nicht, sondern erledigt die Fortschrittsanzeige auf dem LED-Ring intern.
Ja genau. Ich arbeite nur mit Dateigrößen und hole mir die aktuelle Position. Damit rechne ich dann den prozentualen Fortschritt zur Gesamtgröße einer Datei aus und entsprechend anteilig leuchten LEDs auf dem Ring.
