Modulentwicklung für Rhasspy Sprachassistent

Beta-User · 11 Januar 2022, 15:00:40

Woher nimmst du die Sicherheit, dass es _keine Audiodaten_ sind, auf die (auch!) (via MQTT) gewartet wird?

JensS · 11 Januar 2022, 16:35:04

Das steht so in der ref und meine Teststellung läuft fehlerfrei.
TTS erzeugt eine WAV und sendet das im RIFF-Format zum Audioserver, welcher dann mit playFinished das Ende des Abspielens bekannt gibt.
Wenn man die, mit eigenem TTS erzeugte Sonddatei, lokal verarbeitet, muss natürlich auch die Info playFinished bekannt gegeben werden.
Wie es allerdings aussieht, wenn man die Bestätingungstöne einschaltet, habe ich nicht getestet.
Dabei wird vom Session-Manager eine vorhandene WAV an den Audioserver (Audio Playing) per RIFF über MQTT gesandt.
Sollte "Audio Playing" deaktiviert sein, sollte (vermutlich) auch kein Bestätigungston durch den MQTT geschoben werden.

Beta-User · 11 Januar 2022, 16:53:27

Aus den Ausführungen werde ich nicht so recht schlau.
Wenn (wav-riff) Audiodaten via MQTT gesendet werden, ist das genau das, was ich behauptet hatte: Es wird bei "Hermes MQTT" darauf gewartet, dass der Audio-Server mit Daten gefüttert wird. Das erfolgt aber nach meinem Verständnis in pah's Experimenten bislang nicht, bei ihm wird das Audio-Ergbnis ohne den MQTT-Umweg direkt auf die Soundausgabe gegeben (aplay o.ä.). Damit ist Rhasspy aber nicht einig, weil (Audio-) Datenlieferung per MQTT "zugesagt" worden war.
Kann auch sein, dass ich falsch liege, aber deine Schilderung bestätigt doch gerade diese Annahme, oder verstehe ich das nicht richtig?

Prof. Dr. Peter Henning · 11 Januar 2022, 16:57:38

Ich denke, dass Ihr beide falsch liegt. Rhasspy wartet nicht auf Audiodaten, weil es dafür nicht zuständig ist. Und weder aus der Spezifikation, noch aus dem tatsächlichen Ablauf ist irgendetwas von "ContinueSession" zu lesen.

Das wäre auch nicht Stand der Technik bei solchen Protokollen.

LG

pah

Beta-User · 11 Januar 2022, 17:12:20

Aha. Du hättest uns ja früher verraten können, dass Audio-Output bei dir auf "dummy" steht. Mit "ContinueSession" hat das ganze m.E. im Übrigen erst mal nichts zu tun.

Ansonsten sehe ich einen gewissen Missmatch in der Doku:
Unter
https://rhasspy.readthedocs.io/en/latest/services/#text-to-speech - Output messages findet sich:

ZitatFinished generating audio (actually spoken with playBytes)

In https://rhasspy.readthedocs.io/en/latest/reference/#tts_sayfinished steht dagegen:

ZitatIndicates that the text to speech system has finished speaking

Das erstere (samt der Hervorhebung in kursiv) passt eher zu den bisherigen Beobachtungen, aber ich habe ja in der Tat keine Ahnung vom "Stand der Technik bei solchen Protokollen"...

JensS · 11 Januar 2022, 17:19:48

Zitat von: Prof. Dr. Peter Henning am 11 Januar 2022, 16:57:38
Ich denke, dass Ihr beide falsch liegt. Rhasspy wartet nicht auf Audiodaten, weil es dafür nicht zuständig ist. Und weder aus der Spezifikation, noch aus dem tatsächlichen Ablauf ist irgendetwas von "ContinueSession" zu lesen.

Das wäre auch nicht Stand der Technik bei solchen Protokollen.

LG

pah

Das behauptet keiner... Rhasspy ist nur der Vermittler. Die Daten werden zwischen den Modulen getauscht und diese nutzen Rhasspy zur Bekanntgabe der dazugehörigen Mitteilungen.
ContinueSession wird dir schon noch begegnen, wenn du tiefer ins erweiterte Dialog-Thema einsteigst. Das brauchst auf jeden Fall für einen Bot o.ä..

@Beta-User
Wie oben geschrieben, wartet Rhasspy lediglich auf Nachrichten und weist den Modulen Aufgaben zu. Die einzige Ausnahme sollten die Bestätigungstöne sein. Darum habe ich mich aber noch nicht gekümmert, da ich die Bestätigungen über LEDs machen lasse.

Gruß Jens

Beta-User · 11 Januar 2022, 17:40:07

Zitat von: JensS am 11 Januar 2022, 17:19:48
@Beta-User
Wie oben geschrieben, wartet Rhasspy lediglich auf Nachrichten und weist den Modulen Aufgaben zu. Die einzige Ausnahme sollten die Bestätigungstöne sein. Darum habe ich mich aber noch nicht gekümmert, da ich die Bestätigungen über LEDs machen lasse.

...was auch immer man unter "Nachrichten" versteht. Jedenfalls wäre mein Verständnis von https://rhasspy.readthedocs.io/en/latest/audio-output/#mqtthermes, dass der Audio-Server auf Nachrichten des Typs "Audio" (riff-wav) wartet und in einen timeout läuft, wenn er diese nicht bekommt.
Da steht übrigens auch eine (mögliche) Erklärung, wie der Wechsel der ID zustande gekommen sein könnte:

ZitatRhasspy plays WAV audio data sent with the hermes/audioServer/<siteId>/playBytes/<requestId> topic. The requestId part of the topic is simply a unique ID that will be sent back in id field of the hermes/audioServer/playFinished response.

JensS · 11 Januar 2022, 19:15:16

Grundlegend stimmt da was nicht im Session-Management (sh. Beitrag zu sessionId = ""). Es wird sich nicht an eigene Konventionen gehalten.
Jetzt habe ich den Fehler nachstellen können. Er tritt bei meiner Installation nur auf, wenn auf der WebGUI der Basis das "Speak"-Kommando genutzt wird.
Heraus kommt, dass in der Tat wirklich auf RIFF-Daten gewartet wird. Das sieht aber eher nach einem Fehler in der Folge der Verarbeitung der Webanfrage aus.

Code Auswählen

[ERROR:2022-01-11 19:13:09,638] rhasspyserver_hermes: 
Traceback (most recent call last):
  File "/usr/lib/rhasspy/usr/local/lib/python3.7/site-packages/quart/app.py", line 1821, in full_dispatch_request
    result = await self.dispatch_request(request_context)
  File "/usr/lib/rhasspy/usr/local/lib/python3.7/site-packages/quart/app.py", line 1869, in dispatch_request
    return await handler(**request_.view_args)
  File "/usr/lib/rhasspy/rhasspy-server-hermes/rhasspyserver_hermes/__main__.py", line 1699, in api_text_to_speech
    results = await asyncio.gather(*aws)
  File "/usr/lib/rhasspy/rhasspy-server-hermes/rhasspyserver_hermes/__main__.py", line 1685, in speak
    say_chars_per_second=say_chars_per_second,
  File "/usr/lib/rhasspy/rhasspy-server-hermes/rhasspyserver_hermes/__init__.py", line 617, in speak_sentence
    handle_finished(), messages, message_types, timeout_seconds=timeout_seconds
  File "/usr/lib/rhasspy/rhasspy-server-hermes/rhasspyserver_hermes/__init__.py", line 995, in publish_wait
    result_awaitable, timeout=timeout_seconds
  File "/usr/lib/rhasspy/usr/local/lib/python3.7/asyncio/tasks.py", line 449, in wait_for
    raise futures.TimeoutError()
concurrent.futures._base.TimeoutError
[DEBUG:2022-01-11 19:12:39,649] rhasspyserver_hermes: Handling TtsSayFinished (topic=hermes/tts/sayFinished, id=bf0de8b5-a8c3-44b0-a520-3da7b1fa8ae1)
[DEBUG:2022-01-11 19:12:39,649] rhasspyserver_hermes: Handling TtsSayFinished (topic=hermes/tts/sayFinished, id=01758859-a148-432a-b4a7-7adc255b5db7)
[DEBUG:2022-01-11 19:12:39,648] rhasspyserver_hermes: Handling TtsSayFinished (topic=hermes/tts/sayFinished, id=645e0969-1bb6-4b23-aad6-b9ab792adabb)
[DEBUG:2022-01-11 19:12:39,648] rhasspyserver_hermes: Handling TtsSayFinished (topic=hermes/tts/sayFinished, id=db95c2ae-dec4-4dab-b5c5-d194b288d70d)
[DEBUG:2022-01-11 19:12:39,606] rhasspyserver_hermes: Publishing 139 bytes(s) to hermes/tts/say
[DEBUG:2022-01-11 19:12:39,605] rhasspyserver_hermes: -> TtsSay(text='Das ist ein Test', site_id='boden', lang=None, id='2c22cf7f-1ab8-4ca3-980f-c8c33de72e99', session_id='', volume=1.0)
[DEBUG:2022-01-11 19:12:39,603] rhasspyserver_hermes: TTS timeout will be 30 second(s)

Also schnell den "kleinen TTS" angepasst, dass es so aussieht, als würden Audiodaten gesendet:

Code Auswählen

#!/usr/bin/perl -w
use Net::MQTT::Simple "localhost";
use JSON;
use strict;
use Net::MQTT::Simple;

my $mqtt = Net::MQTT::Simple->new("localhost");
$mqtt->run(
    "hermes/tts/say" => sub {
        my ($topic, $message) = @_;
        my $tts_json = JSON->new->allow_nonref->decode( $message );
        my $siteId = $tts_json->{siteId};
        my $id = $tts_json->{id};
        my $sessionId = $tts_json->{sessionId};
        my $text = '"'.$tts_json->{text}.'"';
        my $ausgabe = {id => $id, sessionId => $sessionId, siteId => $siteId};
        my $sayFinish = JSON->new->utf8->encode( $ausgabe );
        my $bytes = "leer";
        my $bytesausgabe = {siteId => $siteId, requestId => $id, wav_bytes => $bytes};
        my $playBytes = JSON->new->utf8->encode( $bytesausgabe );
        qx(pico2wave -l "de-DE" -w test.wav $text);
        $mqtt->publish("hermes/tts/sayFinished" => $sayFinish);
        qx(aplay test.wav);
        my $playausgabe = {id => $id, sessionId => $sessionId};
        my $playFinish = JSON->new->utf8->encode( $playausgabe );
        $mqtt->publish("hermes/audioServer/$siteId/playBytes/$id" => $playBytes);
        $mqtt->publish("hermes/audioServer/$siteId/playFinished" => $playFinish);
    },
);

Nun geht's auch über das Webinterface der Basis:

Code Auswählen

[DEBUG:2022-01-11 19:14:45,849] rhasspyserver_hermes: Handling AudioPlayBytes (topic=hermes/audioServer/boden/playBytes/f58fd47e-41b8-4b60-80e2-bc8d02b54122, id=9fd73023-db86-44cd-91b3-486deadd553f)
[DEBUG:2022-01-11 19:14:45,848] rhasspyserver_hermes: Handling AudioPlayBytes (topic=hermes/audioServer/boden/playBytes/f58fd47e-41b8-4b60-80e2-bc8d02b54122, id=bf0de8b5-a8c3-44b0-a520-3da7b1fa8ae1)
[DEBUG:2022-01-11 19:14:45,848] rhasspyserver_hermes: Handling AudioPlayBytes (topic=hermes/audioServer/boden/playBytes/f58fd47e-41b8-4b60-80e2-bc8d02b54122, id=01758859-a148-432a-b4a7-7adc255b5db7)
[DEBUG:2022-01-11 19:14:45,847] rhasspyserver_hermes: Handling AudioPlayBytes (topic=hermes/audioServer/boden/playBytes/f58fd47e-41b8-4b60-80e2-bc8d02b54122, id=645e0969-1bb6-4b23-aad6-b9ab792adabb)
[DEBUG:2022-01-11 19:14:45,847] rhasspyserver_hermes: Handling AudioPlayBytes (topic=hermes/audioServer/boden/playBytes/f58fd47e-41b8-4b60-80e2-bc8d02b54122, id=db95c2ae-dec4-4dab-b5c5-d194b288d70d)
[DEBUG:2022-01-11 19:14:44,300] rhasspyserver_hermes: Handling TtsSayFinished (topic=hermes/tts/sayFinished, id=9fd73023-db86-44cd-91b3-486deadd553f)
[DEBUG:2022-01-11 19:14:44,300] rhasspyserver_hermes: Handling TtsSayFinished (topic=hermes/tts/sayFinished, id=bf0de8b5-a8c3-44b0-a520-3da7b1fa8ae1)
[DEBUG:2022-01-11 19:14:44,299] rhasspyserver_hermes: Handling TtsSayFinished (topic=hermes/tts/sayFinished, id=01758859-a148-432a-b4a7-7adc255b5db7)
[DEBUG:2022-01-11 19:14:44,299] rhasspyserver_hermes: Handling TtsSayFinished (topic=hermes/tts/sayFinished, id=645e0969-1bb6-4b23-aad6-b9ab792adabb)
[DEBUG:2022-01-11 19:14:44,299] rhasspyserver_hermes: Handling TtsSayFinished (topic=hermes/tts/sayFinished, id=db95c2ae-dec4-4dab-b5c5-d194b288d70d)
[DEBUG:2022-01-11 19:14:44,258] rhasspyserver_hermes: Publishing 139 bytes(s) to hermes/tts/say
[DEBUG:2022-01-11 19:14:44,257] rhasspyserver_hermes: -> TtsSay(text='Das ist ein Test', site_id='boden', lang=None, id='f58fd47e-41b8-4b60-80e2-bc8d02b54122', session_id='', volume=1.0)
[DEBUG:2022-01-11 19:14:44,253] rhasspyserver_hermes: TTS timeout will be 30 second(s)

Gruß Jens

p.s. Dabei muss "Audio Playing" deaktiviert sein, sonst meckert der Audioserver zu Recht

Code Auswählen

wave.Error: file does not start with RIFF idund es kommt "leer" als Knackser aus dem Lautsprecher.
Natürlich kann man ein leeres RIFF mit RIFF-ID erzeugen, doch die Audioausgabe soll ja sowieso andere Wege gehen.

p.p.s. Die Ursache des Timeouts geht auf die Web-Api zurück, welche mit

Code Auswählen

if isinstance(play_bytes, AudioPlayBytes):
return play_bytes.wav_bytes

auf die Info der abzuspielenden Audiodatei wartet. Diese Info soll vom Audioserver kommen.

Code Auswählen

from rhasspyhermes.audioserver import (
    AudioPlayBytes,

Hier wäre es angebracht, die Abfrage auf "AudioPlayFinished" umzustellen. Zumindestens für die Web-Api. Die normale MQTT-Api ist davon ja nicht betroffen.
https://github.com/rhasspy/rhasspy-server-hermes/blob/master/rhasspyserver_hermes/__main__.py#L1688f.
https://github.com/rhasspy/rhasspy-server-hermes/blob/master/rhasspyserver_hermes/__init__.py#L621ff.

JensS · 12 Januar 2022, 10:41:22

Bei der Testerei mit dem externen TTS ist mir aufgefallen - wie bereits von pah bemerkt - , dass der Audioserver von Rhasspy die sessionId in playFinished falsch ausgibt. Das kann der "kleine TTS" besser.

Beta-User · 12 Januar 2022, 10:50:45

Schön, dass wir mit dem Thema anscheinend ein paar Schritte weiter sind. Wäre nett, wenn die Erkenntnisse auch ihren Weg ins Rhasspy-Forum fänden.

Fühle mich erst mal in der Sichtweise bestärkt, dass man (mind.) für TTS also eine eigene siteId für (partielle) "externe" Lösungen an der "base" ("default") registrieren sollte (oder den jeweiligen Dienst (und teilweise das drumrum?) an "default" ganz abschalten muss). Leider sind die Zusammenhänge insgesamt reichlich undurchsichtig - egal ob mit oder ohne Verbesserungsbedarf auf der Rhasspy-Sessionmanagement-Seite...

JensS · 12 Januar 2022, 11:05:27

Ich warte erst einmal die Ergebnisse von pah ab und es wäre mir auch lieber, wenn ihr das ins ausländische übersetzt postet. Wie schon erwähnt, geht's bei mir nur mit Hilfe von Go+.*?le.

Die siteId "default" hatte ich getestet und die Verarbeitung lief durch - also doch kein Problem.

Gruß Jens

Prof. Dr. Peter Henning · 13 Januar 2022, 09:58:47

Dieses ganze Dialogmanagement ist ein einziges Chaos, und auch die Protokolle sind nicht sauber implementiert.

Rhasspy sollte über MQTT die Sprachausgabe anstoßen, und dann nur noch auf eine einzelne Meldung warten. Es ist nunmal nicht Aufgabe der zentralen Instanz, den Versand an irgendeinen Audioserver sicherzustellen.

Wenn Du als Chef den Versand einer Broschüre an die Kunden einleitest, gehst Du ja auch nicht in die Poststelle und schaust, ob die Briefe auch ordentlich frankiert werden.

LG

pah

Beta-User · 13 Januar 2022, 10:16:01

Bin nicht sicher, ob der Vergleich trägt. Wenn du "Audio per MQTT" zusagst, ist das m.E. eher so, wie wenn du einem konkreten Päckchenempfänger eine Sendung ankündigst und dann deiner Sekretärin sagst, sie soll das verschicken.
Kommt nichts an, wunderst du dich auch nicht, wenn dein Päckchenempfänger nach ein paar Tagen nachhakt, ob das denn versendet wurde...

Das ganze ändert aber nichts daran, dass es vermutlich buggy ist, aber hier eigentlich der falsche Ort ist, das zu diskutieren. Im Moment können wir hier nicht viel mehr tun wie die Fragen (und Lösungsansätze) in Richtung Rhasspy zu adressieren und auf der RHASSPY/FHEM-Seite dafür zu sorgen, dass wir nicht grade dort unser Glück versuchen, wo wir wissen, dass es fraglich ist, ob es klappt...

Beta-User · 13 Januar 2022, 11:12:42

Nachtrag noch zu dem hier:

Zitat von: Prof. Dr. Peter Henning am 13 Januar 2022, 09:58:47
Es ist nunmal nicht Aufgabe der zentralen Instanz

Was ist denn in einem Rhasspy-Setup die zentrale Instanz?

Auf jeder Rhasspy-Instanz wird konkret festgelegt, wie sie zu adressieren ist (default-siteId ist "default", bei allen anderen muss man m.E. was anderes nehmen), und für was sie welchen Dienst verwendet. Es gibt keine Verpflichtung für keine Instanz, bestimmte Aufgaben zu übernehmen, oder anders gesagt: Es gibt gar keine allgemeingültige Festlegung einer Zentrale... Das betrifft jeweils nur einzelne Aspekte.

JensS · 13 Januar 2022, 11:40:52

@pah
Es ist etwas komplexer.

Der kleine TTS macht seinen Dienst auf MQTT-Ebene ohne Timeout oder Fehlermeldungen, selbst wenn playBytes und playFinished auskommentiert sind.
Es wird nach ref verfahren. Hier steht einer Bereitstellung eines eigenen TTS nichts im Weg.

Sollte der TTS auch noch den Ausgangspart des Audioservers übernehmen, ist es gerechtfertigt, dass Rhasspy die Statusmeldung playFinished erhält. Diese Meldung ist optional und kann zusätzlich zum Echo-Canceling des Satelliten genutzt werden.

Wird die Web-Api bemüht, wird auf playBytes gewartet.
Dazu habe ich die Vermutung, dass die Web-Api ausschließlich für die GUI entwickelt wurde, um den User bei der lokalen Konfiguration zu unterstützen und fehlerhafte Einstellungen sofort zu melden.
Die Prüfung sollte aber an die tatsächliche Konfiguration angepasst sein und maximal auf ein playFinished warten. Alles Weitere kann man der Log entnehmen.

Diese Web-Konfigurations-Api wird in der Form adäquat zur MQTT-Api vollständig zur Verfügung gestellt. Das macht wenig Sinn. Zielführender wäre die Schaffung einer separaten Web-Api für die Nutzung externer Dienste. Bei einem Gemischt-Betrieb wäre es sinnvoll, der Rhasspy-Web-Instanz, einen AudioFile2RIFF-Konverter zu spendieren. Bei Nur-Web-Betrieb sollte auf Forderung von RIFF verzichtet werden und mit AudioFile2WAV bzw. nur mit WAV gearbeitet werden.

Insgesamt sehe ich Rhasspy als gut durchdacht an. Es müsste - genau wie die Referenz - , nur mal "ins Reine" geschrieben werden.

Gruß Jens

p.s. Es gibt zwei Wege, den TTS anzusteueren. Einmal durch den Dialogmanager, der im tts/say den Text und die vorhandene SessionId übergibt und zum anderen, eine direkte Übergabe des Textes mit tts/say optional mit einer erdachten sessionId.