CFW: Problem mit ftrobopy-Apps im Store beim Release

[MasterOfGizmo]

Ja klar gibts die Sachen noch bzw. irgendwann wieder. Man muss sie halt ab jetzt per Web-Interface manuell installieren. Die Apps, die ich betreue gibt es in Zukunft unter https://github.com/harbaum/cfw-apps. Da fehlen noch alle Apps, die auf ftrobopy aufbauen, also alle, die die FT-Ein- und Ausgänge verwenden. Sobald ich genau weiss, wie die in der nächsten Firmware-Version angesteuert werden müssen stelle ich auch die wieder Stück für Stück dort ein.

Ich denke, dass sich der App-Store auch wieder füllen wird, wenn die neue Firmware-Version sich etwas verbreitet hat und wenn mehr Leute Apps schreiben.

[MasterOfGizmo]

Gibt es schon Pläne, was die Audio-Ausgabe im nächsten Release angeht? Laufen die aktuellen Sound-Aufrufe nur ins Leere oder erzeugen sie in dem Fall einen Fehler? Dann würde ich in meinen Wrappern entspechend darum herum coden. Und wenn wieder Sound implementiert wird, wird das dann weiterhin via ftrobopy gehen? Und wird es die Original-TXT-Sounds dann noch geben? Die müsste ftrobopy dann ja seinerseits aus dem internen Flash lesen.

[ski7777]

Aktuell gibt ftrobopy einfach eine Ausgabe auf die Shell, dass Sound nicht verfügbar seien. Ein Feer entsteht nicht.
An einem neuen System zur Audioausgabe über ALSA arbeite ich noch.

Raphael

[MasterOfGizmo]

Aktuell gibt ftrobopy einfach eine Ausgabe auf die Shell, dass Sound nicht verfügbar seien. Ein Feer entsteht nicht.
An einem neuen System zur Audioausgabe über ALSA arbeite ich noch.

Da ich unter Brickly stdout in den Browser und in die App umleite würden diese Meldung dann auf dem Bildschirm und im Browser auftauchen, wahrscheinlich auf Englisch irgendwo zwischen den eigentlichen Programmausgaben, Und Dein Ansatz, das via ALSA zu machen scheint mir ja a) in recht weiter ferne zu liegen und b) auch nicht mit Richard abgestimmt zu sein. Also fange ich jetzt die Sound-Request in allen meinen Apps ab und schreibe Extra-Code, um die alte Funktion mit viel Aufwand wieder hertzustellen?

Ich muss sagen, dass ich sehr unzufrieden mit der Tatsache bin, dass hier größere Umbauten gestartet werden, bevor alle Konsequenzen überhaupt erkannt und durchdacht sind. Wir sind jetzt bei Firmware 0.9.3-RC. RC steht für Release-Candidate. Im Klartext: Nur noch Bug-Fixes bis zu Release, aber keine neuen Features. Ergo auch kein Sound, sondern stattdessen Fehlermeldungen. Raphael, kannst Du bitte sagen, wie es konkret weitergehen wird? Wird 0.9.3 Sound ausgeben können? Wann?

[ski7777]

Ich habe diese ganzen Veränderungen nicht angestoßen und habe die Version nicht auf Release Candidate gesetzt. Mein Ansatz ist im Moment nur eine Idee. Sobald ich erste Erfolge habe, werde ich diese präsentieren und bei Bedarf dann in ftrobopy implementieren. Mein Ziel ist es ohne Kollisionen mehrere Töne gleichzeitig abspielen zu können. Mein Plan:

Ferner könnte man so auch externe Soundkarten ansteuern.

Raphael, kannst Du bitte sagen, wie es konkret weitergehen wird? Wird 0.9.3 Sound ausgeben können? Wann?

Bin ich hier der Chef? nö

Raphael

[MasterOfGizmo]

Du hast alle Apps im Apps-Repository wegen eurer Ànderungen als inkompatibel markiert. Du wirst wohl einen Plan gehabt haben, wie es danach weitergeht. Was das angeht hast du dich in der Sache selbst zum Chef gemacht.

[ski7777]

Ich habe ur mit Richard zusammen mich auf das nächste Release vorbereitet und dabei einige Apps als inkompatibel zur 0.9.3 makiert. Das war auch kein Anlass diese für alle anderen Versionen zu entfernen. Für das Soundproblem bin auch nicht ich verantwortlich, da ich nicht für ftrobopy verantwortlich bin.
Vielleicht sollten wir einfach mal mit den Schuldzuweisungen aufhören und uns zusammen überlegen, wie es weitergeht.

Raphael

[richard.kunze]

Ich muss sagen, dass ich sehr unzufrieden mit der Tatsache bin, dass hier größere Umbauten gestartet werden, bevor alle Konsequenzen überhaupt erkannt und durchdacht sind.

Der "größere Umbau" war am 19. 11., mit der aktuellen Version von ftrobopy und in Konsequenz der Abschaltung des TxtMainControl-Hintergrund-Prozesses

Die Änderungen jetzt waren eigentlich dazu gedacht, die dadurch notwendigen Änderungen an den Apps (deren Notwendigkeit mir selbst auch erst jetzt aufgefallen ist) durchführen zu können ohne dieselben Apps für die 0.9.2-er Version der Firmware kaputtzumachen. Hätte denke ich auch prima funktioniert, aber Du hast es vorgezogen deine Apps stattdessen gleich aus dem Store zu nehmen.

Wir sind jetzt bei Firmware 0.9.3-RC. RC steht für Release-Candidate. Im Klartext: Nur noch Bug-Fixes bis zu Release, aber keine neuen Features. Ergo auch kein Sound, sondern stattdessen Fehlermeldungen. Raphael, kannst Du bitte sagen, wie es konkret weitergehen wird? Wird 0.9.3 Sound ausgeben können? Wann?

Wir sind bei Version 0.9.3-irgendwas. Wichtig dabei ist lediglich das 0.9.3 vorne, damit der Store weiss dass die API eben nicht mehr die 0.9.2 ist. Wenn Du Dich am "rc" störst, dann benenne es halt in -alpha oder -dev oder sonst was um...

Und Sound in ftrobopy wird es wieder geben, sobald ich a) txt_snd_cat aus der MP3-App rausgepult und direkt in die Firmware integriert habe (falls Du nichts dagegen hast), b) ftrobopy beigebracht habe, im Direct-mode txt_sind_cat zu benutzen und c) einen PR dafür an Torsten gestellt habe. Das mach ich alles, sobald ich am nächsten Wochenende wieder aus dem Urlaub zurück bin...

[PHabermehl]

Hallo Jungs,

bitte streitet Euch nicht! Vertagt das Thema auf nächstes Jahr...

Guten Rutsch und bis dann!

[Torsten]

Hallo Richard,

Und Sound in ftrobopy wird es wieder geben, sobald ich a) txt_snd_cat aus der MP3-App rausgepult und direkt in die Firmware integriert habe (falls Du nichts dagegen hast), b) ftrobopy beigebracht habe, im Direct-mode txt_sind_cat zu benutzen und c) einen PR dafür an Torsten gestellt habe. Das mach ich alles, sobald ich am nächsten Wochenende wieder aus dem Urlaub zurück bin...

ich habe bereits damit angefangen, Sound-Support für den "direct"-Mode von ftrobopy zu implementieren. Ich verwende dafür das Python-Modul "SpiDev 3.2" (zu finden unter https://pypi.python.org/pypi/spidev). Ich schlage deshalb vor, das SpiDev-Modul per Default in das nächste CFW-Release mit aufzunehmen.
Der "direct" Sound-Support wird völlig transparent sein, so dass an bestehenden ftrobopy-Programmen keine Änderungen bei der Soundausgabe notwendig sein werden.

Ich werde in den nächsten Tagen eine neue ftrobopy-Version auf github hochladen.

Ich wünsche allen einen Guten Rutsch !

Viele Grüße
Torsten

Edit:
@richard: über welchen Directory-Pfad soll ich am Besten auf die original ft-Soundfiles zugreifen ? oder sollte der Pfad ein (optionaler) Parameter bei der Initialisierung von ftrobopy sein ?

[richard.kunze]

ich habe bereits damit angefangen, Sound-Support für den "direct"-Mode von ftrobopy zu implementieren. Ich verwende dafür das Python-Modul "SpiDev 3.2" (zu finden unter https://pypi.python.org/pypi/spidev). Ich schlage deshalb vor, das SpiDev-Modul per Default in das nächste CFW-Release mit aufzunehmen.

Ok, das ist noch besser - ich baue das Spidev-Modul dann nächstes Wochenende ein.

"direct" Sound-Support wird völlig transparent sein, so dass an bestehenden ftrobopy-Programmen keine Änderungen bei der Soundausgabe notwendig sein werden.

Eigentlich kann man im Direktmode über SPI ja sogar zusätzliche eigene Sounds abspielen und muss sich nicht auf die paar "fest eingebauten" Soundfiles beschränken...

Ich werde in den nächsten Tagen eine neue ftrobopy-Version auf github hochladen.

OK, ich baue das dann ein.

Ich wünsche allen einen Guten Rutsch !

Von mir ebenfalls Guten Rutsch an alle!

[richard.kunze]

@richard: über welchen Directory-Pfad soll ich am Besten auf die original ft-Soundfiles zugreifen ? oder sollte der Pfad ein (optionaler) Parameter bei der Initialisierung von ftrobopy sein ?

Die Original-Firmware wird in der CFW unter /rom eingehängt (read-only), der Pfad ist also derselbe bis auf das Präfix.

[MasterOfGizmo]

Der "größere Umbau" war am 19. 11., mit der aktuellen Version von ftrobopy und in Konsequenz der Abschaltung des TxtMainControl-Hintergrund-Prozesses

Dann stimme ich hiermit dafür, diese Änderung rückgängig zu machen bzw. in einen eigenen Entwicklungszweig zu verschieben bis alles Konsequenzen erkannt und gemeinschaftlich geklärt wurden. Da die aktuelle Lösung absolut stabil läuft ist gibt es m.E. keinen Grund zur Eile.

[ski7777]

Nach einigen Mühen habe ich aloop jetzt zum Laufen gebracht. Der Rest sollte jetzt ein Kinderspiel sein. Das ganze könnte man dann noch einfacher in ftrobopy implementieren.

Raphael

[ski7777]

Ich revidiere.
Irgendwas scheint mit den sample rates nicht ganz zu stimmen, aber vielleicht kann man das auch einfach in der txt_snd_cat lösen.
Mein Grundaufbau findet sich hier: https://github.com/ski7777/ftcommunity- ... e/alsa-spi
Der entscheidende Commit: https://github.com/ski7777/ftcommunity- ... 5b5247a5c8
Nach dem starten führe ich folgendes aus:

Code: Alles auswählen

sudo modprobe snd-aloop

Jetzt brauche ich zwei Terminals:

• Im aktuellen Ordner muss die txt_snd_cat kompiliert liegen

  Code: Alles auswählen

  arecord -fS16_LE -r22050 -c1 -traw -Ddsnoop:Loopback,1 | ./txt_snd_cat

• Code: Alles auswählen

  aplay -twav -Dplug:dmix:Loopback pfad_zu_einer_wav_datei

Problem:
arecord will nicht arbeiten:

Code: Alles auswählen

Recording raw data 'stdin' : Signed 16 bit Little Endian, Rate 22050 Hz, Mono
arecord: set_params:1297: Sample format non available
Available formats:
- S32_LE

Wo soll da das Problem sein?

Raphael

[Torsten]

Hallo,

die neue Version 1.6 von ftrobopy mit Sound-Unterstützung im 'direct'-Modus ist jetzt online auf github. Ausserdem werden die Werte 'auto', '127.0.0.1' und 'localhost' für den host-Parameter bei der Initialisierung von ftrobopy aus Gründen der Abwärtskompatibilität nun identisch behandelt.

Alle alten Apps aus dem App-Store sollten damit unverändert auch mit dem neuen Firmware-Release laufen.

Edit: Falls die Version 1.6 auch mit dem alten Firmware-Release im 'direct'-Modus verwendet werden soll, muss das spidev-Modul zusätzlich zur Verfügung gestellt werden. (die Datei spidev.so könnte ich bei Bedarf noch hochladen).

Viele Grüße
Torsten

[MasterOfGizmo]

Das klingt gut. Ein paar Anmerkungen habe ich noch:

- Du machst am Hostname fest, ob ftrobopy direkt auf dem TXT. Vor dem Problem, das festzustellen, stehe ich auch manchmal. Vielleicht sollten wir uns da mal einen rebusten Weg überlegen. Hostname scheint mir etwas unsicher. Ich habe es schon von der Anwesenheit der /etc/fw-ver.txt und /etc/sysversion bzw. /rom/etc/sysversion abhängig gemacht. Ist aber beides auch irgendwie nicht das wahre ...

- Dass Du "localhost" und "auto" nun synonym verwendest verstehe ich als Angebot an mich. Danke sehr. Aber ich kann die Argumente dagegen durchaus verstehen. Daher mein Vorschlag: "auto" bleibt wie's ist. Aber bei localhost versucht ftrobopy wirklich nur auf dem lokalen Gerät einen Dienst anzusprechen (weil ja "localhost" auch genau das bedeutet). Also wenn ftrobopy auf dem TXT läuft und TxtControlMain aktiv spricht es TxtControlMain via localhost an. Wenn es auf einem TXT läuft und TxtControlMain nicht aktiv ist nimmt es den Direct-Modus. Das ist m.E. ein schlüssiges Verhalten zumal man mit der Angabe von "localhost" auf einem TXT ohne TxtControlMain ja auch wirklich nichts erreichen könnte. Aber der TXT sollte in dem Fall dann nicht versuchen, die anderen IP-Adressen anzusprechen (also 192.168.X.2). Das wiederspricht in der Tat dem Gedanken hinter "localhost" recht deutlich. Dazu würde ich gerne auch Richards Meinung hören.

- An manchen Stellen gibst Du Daten auf stdout aus. Könnte man das bitte komplett unterdrücken? Bei Prorammen, die auch selbst Daten auf stdout ausgeben mischen sich so die programmeigenen Ausgaben mit denen der ftrobopy. Das könnte User ggf. verwirren. Wenn ftrobopy Fehler, Infos u.ä. melden muss, dann m.E. über Rückgabewerte, so dass man das als App-Entwickler z.B. auch in andere Sprachen übersetzen könnte.

- Wo sind denn Deine Sound-Routinen über SPI her? Hast Du mit Deinen Routinen schonmal Hänger bei der Audio-Ausgabe gehabt? Ich habe sowas sporadisch mal. Ich sehe, dass Du immer 441-Byte-Frames sendest und zur Not mit Nullbytes auffüllst. Warum sendest Du am Ende der Datei keine kürzeren Frames? Zweitens hatte ich das Problem, dass in den Sound-Daten das Reset-Kommando nicht vorkommen darf (also das Byte 0x90), daher filtere ich das raus. Ich sehe nirgends, dass Du das machst. Hast Du das Problem nicht? Oder sind die Sound-Files auf dem TXT entsprechend vorbereitet, so dass das Byte da nicht drin vorkommt?

Edit: In den Sound-Files sind auch 0x90-Bytes drin. Wieso hast Du das Problem nicht, die abzuspielen? ... hmmm ...

[Torsten]

Hallo MoG,

- Du machst am Hostname fest, ob ftrobopy direkt auf dem TXT. Vor dem Problem, das festzustellen, stehe ich auch manchmal. Vielleicht sollten wir uns da mal einen rebusten Weg überlegen. Hostname scheint mir etwas unsicher. Ich habe es schon von der Anwesenheit der /etc/fw-ver.txt und /etc/sysversion bzw. /rom/etc/sysversion abhängig gemacht. Ist aber beides auch irgendwie nicht das wahre ...

Ja, da stimme ich Dir zu. Die Abfrage des Hostnamens ist eine Notlösung, bis ich etwas Besseres habe.

[...] "auto" bleibt wie's ist. Aber bei localhost versucht ftrobopy wirklich nur auf dem lokalen Gerät einen Dienst anzusprechen (weil ja "localhost" auch genau das bedeutet). Also wenn ftrobopy auf dem TXT läuft und TxtControlMain aktiv spricht es TxtControlMain via localhost an. Wenn es auf einem TXT läuft und TxtControlMain nicht aktiv ist nimmt es den Direct-Modus.

Das macht mehr Sinn ... habe ich jetzt so implementiert.

- An manchen Stellen gibst Du Daten auf stdout aus. Könnte man das bitte komplett unterdrücken? Bei Prorammen, die auch selbst Daten auf stdout ausgeben mischen sich so die programmeigenen Ausgaben mit denen der ftrobopy. Das könnte User ggf. verwirren. Wenn ftrobopy Fehler, Infos u.ä. melden muss, dann m.E. über Rückgabewerte, so dass man das als App-Entwickler z.B. auch in andere Sprachen übersetzen könnte.

Ein vernünftiges Error-Handling steht schon seit Längerem auf meiner ToDo-Liste, bin bloss bisher noch nicht dazu gekommen... muss ich mir mal wieder anschauen.

- Wo sind denn Deine Sound-Routinen über SPI her?

Die habe ich mir aus den (unvollständigen) Sourcen und durch Ausprobieren zusammengereimt.

Hast Du mit Deinen Routinen schonmal Hänger bei der Audio-Ausgabe gehabt? Ich habe sowas sporadisch mal.

s.u.

Ich sehe, dass Du immer 441-Byte-Frames sendest und zur Not mit Nullbytes auffüllst.

Ich fülle nicht mit 0x00-Bytes auf, das hatte ich zuerst versucht, das ergab aber Knackser im Sound. Ich fülle jetzt mit 0x80-Bytes auf, das knackst nicht mehr.

Warum sendest Du am Ende der Datei keine kürzeren Frames?

Zunächst hatte ich am Ende der Dateien den (wie ich dachte) korrekten kürzeren Frame gesendet, das führte aber immer wieder zu Audio-Hängern und unvorhersehbarem Verhalten (möglicherweise durch 0x90 Bytes, habe ich aber nicht genau untersucht). In einem Kommentar in den ft-Sourcen habe ich aber dann einen Hinweis gefunden, der darauf hindeutet, dass ROBOPro auch nur volle 441 Frames sendet. Nachdem ich das dann auch so implementiert hatte, waren die Probleme weg. Die DMA-Routinen der Motorplatine, die die Daten vom SPI-Bus entgegen nehmen, liegen mir leider nicht im Sourcecode vor. Es ist deshalb schwierig, genau zu sagen, was da vorgeht.

Zweitens hatte ich das Problem, dass in den Sound-Daten das Reset-Kommando nicht vorkommen darf (also das Byte 0x90), daher filtere ich das raus. Ich sehe nirgends, dass Du das machst. Hast Du das Problem nicht? Oder sind die Sound-Files auf dem TXT entsprechend vorbereitet, so dass das Byte da nicht drin vorkommt?

Edit: In den Sound-Files sind auch 0x90-Bytes drin. Wieso hast Du das Problem nicht, die abzuspielen? ... hmmm ...

s.o.

Gruß
Torsten

[MasterOfGizmo]

Ich habe gerade gesehen, dass Du das Data-Kommando und die Nutzdaten in einem SPI-Transfer schickst. Bei mir sind das zwei getrennte. Kann mir gut vorstellen, dass das der Grund für meine Probleme mit den Reset-Bytes ist.

Und wenn man nur volle Vielfache von 441 Bytes schicken könnte wäre das ja schade ... vielleicht gibt's dazu ja irgendwann mal ein Statement von den Machern des TXT ...