Guten Tag,
ich habe mein Board heute mit einem RC522 in Betrieb genommen und habe das Thema, dass der Ton so gar nicht gut ist. Siehe Video.
Meine Config findet sich auf Github.
Geflasht habe ich aus dem aktuellen Stand von master von vor 5 minuten 
Habe ich irgendwas triviales übersehen?
Vielen Dank im Voraus!
Viele Grüße,
Uli
Ich frage mich gerade, warum das Board überhaupt startet 
Schau mal, ob das was ändert.
Jetzt frag mich nicht wie ich das geschafft habe… 
Hatte wohl aus der falschen Seite In vscode raus kopiert als ich mir die Unterschiede zur Quelle angeschaut habe. Die Konfig war bereits korrekt angepasst (pin und INVERT_POWER). Aktualisiere ich natürlich auf Github noch - aber das wars leider nicht 
Hab auch grad nochmal einen Build gemacht - es bleibt beim ruckeln.
Muss man bei den MP3s vielleicht was beachten? Die hier liegt als 124kbps vor.
Viele Grüsse, Uli
Puh das klingt ja gruselig! Wird es auch zu langsam abgespielt?
Kannst Du das MP3 bereitstellen? Um auszuschließen das es an der Audio-Bibliothek liegt…
Hi,
Ich hab gerade verschiedene MP3s durchprobiert, u.a.: Folk Festival Massacre - Promise - Free Music Archive Es hakt bei allen.
Ja ich würde auch sagen, dass es zu langsam abgespielt wird.
Ich habe als SD-Karte eine Sandisk Ultra 64Gb drin (wie hier im Thread: Werden 64 Gb SD Karten unterstützt? - #9 von fetzerch) - nur falls das relevant ist. natürlich auf Fat32 formatiert - wird ja auch erkannt. Die Lieder habe ich via FTP oder Webinterface hochgeladen - gleiches ergebnis in beiden Fällen.
Viele Grüße,
Uli
OK, am MP3 klemmt es wohl nicht.
Der Audio Task scheint zu wenig Rechenzeit zu bekommen.
Kannst Du #define MQTT_ENABLE einmal auskommentieren und neu testen?
Hast Du einen NeoPixel angeschlossen mit 24 LEDs?
anderes Thema aber gleicher Effekt , TellIP hört sich bei mir seit einigen Wochen genau so an.
Unterschiedliche Boards , Dac´s und SW-Versionen, alles andere geht .
Wohoo! Wenn ich das mache funktioniert die Wiedergabe problemlos. Hmm aber ich bin ja vermutlich eher nicht der einzige der auch gerne MQTT nutzen würde oder?
Ja
Nee, du bist nicht der Einzige.
Ich kompiliere mqtt immer ein und da gibt es keine Probleme. Gerade gestern habe ich mich drüber gefreut, dass ich die Ethernet-LED am Raspi durch Drehen am Drehencoder quasi auf Kommando blinken lassen kann 
(Manchmal muss man sich über die kleinen Dinge des Lebens freuen.)
Ist der Broker denn erreichbar? Stimmt das (optional konfigurierbare) Passwort?
@compactflash Das mit der Sprachsynthese ist mir auch aufgefallen. Aber ich hatte bisher keine Lust, mich drum zu kümmern.
@Wolle Ist dir da was bekannt? Da gab es ja glaube ich Umstellungen schon vor Monaten, weil Google nicht mehr ordentlich funktioniert hat.
Zumindest kommen die Nachrichten des espuino auf dem broker (mosquitto) an → Erreichen kann er ihn wohl
Wenn man weiss, dass das Passwort kürzer als 15 Zeichen sein muss (mehr zeichen funktionieren nicht) dann stimmt es 
Ja, das stimmt, GoogleTTS weist manchmal die Anfragen zurückt (vielleicht Lastabwehr?)
Ich habe schon mal mit anderen Diensten experimentiert, aber es ist entweder die Anzahl der Worte innerhalb eines Zeitraumes begrenzt oder kostenpflichtig. Dann gibt es noch MaryTTS, längere Texte möglich, aber schlechte Qualität und häufig offline.
Wer einen guten Sprachdienst kennt kann mir das gerne mitteilen.
Vllt einfach 0 bis 9 und „Punkt“ aufnehmen und lokal als dynamische generierte Playlist abspielen? Könnte man ja als Files irgendwo unter espuino.de ablegen und bei Abwesenheit (z.B. neue Karte eingelegt) neu auf die Karte laden.
Ich will euch wirklich nicht dazwischen funken aber mein Thema ist NICHT die Sprachausgabe sondern ganz normale Musik.
So wie ich das verstehe, sollte es klappen bei eingeschaltetem MQTT. Habe ich möglichkeiten herauszufinden wo die Zeit verloren geht?
Da musst du dir serielle Debugausgaben machen, wo die Zeiten für Funktionsabschnitte berechnet werden. Dabei musst du allerdings aufpassen, dass du die serielle Konsole nicht mit Ausgaben flutest, weil die serielle Ausgabe selbst vergleichsweise viel Zeit benötigt.
Ich habe bei bei meinem aktuellen 2. Testsetup ebenfalls Problemchen im Zusammenhang mit MQTT. Allerdings nur komplette Tonaussetzer von einigen 100ms da sich bei mir immer wieder in sporadischen Abstaänden in Minutenbereich die Verbindung zum ioBroker wieder erneut aufbauen muss und daher alle Properties zu übertragen doch etwas Zeit einnimmt.
Habe daher begonnen, die Task CPU Zuweisungen und die Taskprios etwas zu ändern.
Insbesondere wollte ich den Audiotask möglichst alleine eine CPU (in diesem Fall 0) zuweisen.
Auswirkung: Gefühlt weniger Störgeräusche bei Wechsel der Tracks. Dafür bei WebStreaming bei Start kurzzeitig nicht perfekter Ton, aber man merkt, dass es zügig reiner wird und dann stabil bleibt.
Ich würde sagen, ohne es provoziert zu haben, dass kurzfristige Streamingunterbrechungen besser abgefangen werden, denn der Audiotask läuft auf der anderen CPU als der WebTask.
Möglicherweise kann es auch bei deinem Problem helfen.#
Einen Versuch würde ich wagen.
Du kannst die Files einfach in dein lokalen Workspace kopieren. Sie entsprechen ausser den beschriebenen Änderungen in der _ReadMe.md dem aktuellsten Stand vom biologist79/master
Good Luck!
Tests_Task_Core&Prio.zip (32,9 KB)
schon probiert?
@Niko sorry bin heute erst von einer Reise zurück gekommen - probiere ich aus! Danke sehr!
Gerade getestet - in der Leds.cpp fehlte aber noch der define. Ich habe es zunächst so probiert:
#if CONFIG_FREERTOS_UNICORE
#define ARDUINO_RUNNING_CORE 0
#else
#define ARDUINO_RUNNING_CORE 1
#endif
Wenn ich MQTT einschalte, dann hört sich die Musik ziemlich genau so an wie vorher aber nach ein paar Sekunden kommt folgendes auf der Konsole:
E (15503) task_wdt: Task watchdog got triggered. The following tasks did not reset the watchdog in time:
E (15503) task_wdt: - IDLE0 (CPU 0)
E (15503) task_wdt: Tasks currently running:
E (15503) task_wdt: CPU 0: mp3play
E (15503) task_wdt: CPU 1: IDLE1
E (15503) task_wdt: Aborting.
abort() was called at PC 0x401ed114 on core 0
ELF file SHA256: 0000000000000000
Backtrace: 0x400974d0:0x3ffc0000 0x40097749:0x3ffc0020 0x401ed114:0x3ffc0040 0x40092999:0x3ffc0060 0x400e988d:0x3ffd2270 0x400e9ce2:0x3ffd22b0 0x400ebddc:0x3ffd22e0 0x400ebe6a:0x3ffd2310 0x400ec3ff:0x3ffd2330 0x400f0a96:0x3ffd25b0 0x400d4d8a:0x3ffd25d0 0x400992ba:0x3ffd2640
Rebooting...
Wenn ich die beiden defines der Leds.cpp tausche (also die Cores tausche):
#if CONFIG_FREERTOS_UNICORE
#define ARDUINO_RUNNING_CORE 1
#else
#define ARDUINO_RUNNING_CORE 0
#endif
Dann kann ich einige Files hören. Bei anderen kommt nach ein paar Sekunden:
E (28299) task_wdt: Task watchdog got triggered. The following tasks did not reset the watchdog in time:
E (28299) task_wdt: - IDLE0 (CPU 0)
E (28299) task_wdt: Tasks currently running:
E (28299) task_wdt: CPU 0: mp3play
E (28299) task_wdt: CPU 1: IDLE1
E (28299) task_wdt: Aborting.
abort() was called at PC 0x401ed110 on core 0
ELF file SHA256: 0000000000000000
Backtrace: 0x400974d0:0x3ffc0000 0x40097749:0x3ffc0020 0x401ed110:0x3ffc0040 0x40092999:0x3ffc0060 0x400d5c7f:0x3ffd2230 0x400d5531:0x3ffd2250 0x400e9a35:0x3ffd2270 0x400e9cde:0x3ffd22b0 0x400ebdd8:0x3ffd22e0 0x400ebe66:0x3ffd2310 0x400ec3fb:0x3ffd2330 0x400f0a92:0x3ffd25b0 0x400d4d8a:0x3ffd25d0 0x400992ba:0x3ffd2640
Rebooting...
Hum. Also teilweise Verbesserung. Aber Absturz ist natürlich auch nicht optimal
Die defines sollte man hier nicht ändern, sondern die CPU Zuweisung ändert man beim Aufruf der xTaskCreatePinnedToCore:
Habe nun auch dieses übernommene Definitionskonstrukt nochmals genauer nachgelesen und werde das gänzlich entfernen. In diesem Projekt haben wir 2 Cores, d.h. bei xTaskCreate… einfach Core 0 oder 1 angeben.
Im Falle von LEDs heißt das, du muss an folgender Stelle ändern:
xTaskCreatePinnedToCore(
Led_Task, /* Function to implement the task */
"Led_Task", /* Name of the task */
1512, /* Stack size in words */
NULL, /* Task input parameter */
0, /* Priority of the task */
NULL, /* Task handle. */
ARDUINO_RUNNING_CORE /* (1) Core where the task should run */
);
wieder zurück auf
0 /* Core where the task should run */
xTaskCreatePinnedToCore(
Led_Task, /* Function to implement the task */
"Led_Task", /* Name of the task */
1512, /* Stack size in words */
NULL, /* Task input parameter */
0, /* Priority of the task */
NULL, /* Task handle. */
0 /* Core where the task should run */
);
nach dieser Rückstellung läuft LED wieder auf Core 0 wie auch der AudioTask.
Try It!
OK, hier wird der WatchDog nicht mehr getriggert.
Ich melde mich via PN