CFW/ftrobopy 1.62: Sound im Direct-Mode tut nicht

[richard.kunze]

Hallo Torsten,

ich bin gerade dabei, die aktuelle Version von ftrobopy (1.62) und spidev (3.2) in die CFW zu integrieren. Allerdings funktioniert damit bei mir im direct-Mode der Sound trotzdem nicht. Mit einem unveränderten ftrobopy 1.62 passiert (als ftc auf dem TXT mit CFW) das hier:

Code: Alles auswählen

$ python
Python 3.5.2 (default, Dec 19 2016, 21:26:20) 
[GCC 5.3.1 20160113] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import ftrobopy
>>> txt = ftrobopy.ftrobopy('auto')
Connected to  TXT direct firmware version not detected
>>> txt.play_sound(7)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.5/site-packages/ftrobopy.py", line 2575, in play_sound
    self.setSoundIndex(idx)
  File "/usr/lib/python3.5/site-packages/ftrobopy.py", line 794, in setSoundIndex
    self._sound_data     = [ord(x) for x in buf[44:]]
  File "/usr/lib/python3.5/site-packages/ftrobopy.py", line 794, in <listcomp>
    self._sound_data     = [ord(x) for x in buf[44:]]
TypeError: ord() expected string of length 1, but int found
>>> 

Und wenn ich in ftrobopy.py Zeile 794 auf

Code: Alles auswählen

self._sound_data     = [x for x in buf[44:]]

ändere, dann bekomme ich zwar eine Audio-Ausgabe, die ist aber komplett verzerrt.

Hast Du eine Ahnung, was da schiefläuft?

Liebe Grüße,

Richard

[Torsten]

Hallo Richard,

ich hatte die direct-Soundausgabe bisher nur mit der original fischertechnik-FW unter Python2.7 getestet, da funktionierte alles. Das Problem in Zeile 794 resultiert aus einer Inkompatibilität zwischen Python2.7 und Python3 bei der Behandlung von bytearrays, die ich noch übersehen hatte.

Du hast Recht, unter der community-FW gibt es noch ein Problem. Das SPI-Sound-Protokoll scheint da etwas anders auszusehen als unter der original-FW. Ich werde mir das noch etwas genauer anschauen. Auf jeden Fall sehen die Rückgabewerte, die von der Motorplatine kommen anderes aus, als bei der original-FW. Vielleicht wird der SPI-Treiber unter der community-FW anders initialisiert als unter der original-FW ?.

Edit: Kann es sein, dass die original-FW (4.2.4) und die CFW unterschiedliche Firmwareversionen in der Motorplatine haben ?

Viele Grüße
Torsten

[richard.kunze]

Hallo Torsten,

Du hast Recht, unter der community-FW gibt es noch ein Problem. Das SPI-Sound-Protokoll scheint da etwas anders auszusehen als unter der original-FW. Ich werde mir das noch etwas genauer anschauen. Auf jeden Fall sehen die Rückgabewerte, die von der Motorplatine kommen anderes aus, als bei der original-FW. Vielleicht wird der SPI-Treiber unter der community-FW anders initialisiert als unter der original-FW ?.

Möglich. Soweit ich sehen kann verwendest Du bei der Initialisierung bis auf _spi.mode überall die Defaults, und da kann ich mir durchaus vorstellen, dass es da zwischen CFW und Original-Firmware sowohl durch den anderen Kernel als auch durch die unterschiedlichen Python-Versionen Unterschiede gibt.

Ich werde das morgen oder übermorgen mal mit Python 2.7 auf der CFW ausprobieren (wenn Du mir nicht zuvorkommst) - mit was genau hast Du denn da getestet? Der Python-Build, den Du auch auf der Convention in Dreieich dabei hattest? Den hab ich hier nämlich auch noch rumliegen...

Edit: Kann es sein, dass die original-FW (4.2.4) und die CFW unterschiedliche Firmwareversionen in der Motorplatine haben ?

Das würde mich sehr wundern. Bewusst ändert die CFW an der Firmware der Motorplatine auf jeden Fall nichts. Und unterschiedliche Original-Firmwareversionen zwischen Deinem und meinem TXT können auch nicht der Grund sein, bei mir ist die Original-Firmware ebenfalls auf 4.2.4

Liebe Grüße,

Richard

[MasterOfGizmo]

Ich nehme an, dass Du SPI in ftrobopy gar nicht initialisierst. Dann klappt es nur auf der OriginalFirmware, weil dort txtcontrol die Initialisierung macht.

Richard, was passiert denn, wenn du einmal vorher die Original-GUI startest? Dann sollte es gehen.

Torsten, die nötigen Werte findest du in meinem txt_snd_cat.

[richard.kunze]

Richard, was passiert denn, wenn du einmal vorher die Original-GUI startest? Dann sollte es gehen.

Ja, das funktioniert - zumindest mit etwas Trickserei (die Original-GUI muss gestartet und gestoppt werden während der Python-Prozess schon läuft, aber bevor ftrobopy initialisiert wird).

Und mit der passenden Initialisierung klappts dann auch ohne Tricks...

@Torsten: Ich hab das hier lokal schon eingebaut und schick Dir gleich einen PR auf Github.

[Torsten]

Hallo Richard,

ja, danke ... ich hatte das auch inzwischen schon gefunden... habe aber trotzdem Deinen Pull-Request noch gemerged

Viele Grüße
Torsten