Modulentwicklung für Rhasspy Sprachassistent

[JensS]

@Alle
Kennt jemand eine gute Noice-Reduction und/oder Echo-Canceling für den RPI0W mit ReSpeaker 2-Mics Pi HAT?
Meine Versuche in Richtung Pulse mit ec, etc. waren mit mäßigem Erfolg gekrönt...

Gruß Jens

[JensS]

Auf der Suche nach einer Lösung zu den per Standard deaktivierten Intents, war folgende Ergänzung in https://github.com/rhasspy/rhasspy-nlu-hermes/blob/master/rhasspynlu_hermes/__init__.py#L87 erfolgreich:

Code Auswählen Erweitern

                def intent_filter(intent_name: str) -> bool:
                    """Filter out intents."""
                    if not query.intent_filter and "_disabled" in intent_name:
                        return False
                    if query.intent_filter and "_disabled" in intent_name and not intent_name in query.intent_filter:
                        return False
                    if query.intent_filter:
                        return intent_name in query.intent_filter
                    return True

Durch das Einfügen von

Code Auswählen Erweitern

                    if not query.intent_filter and "_disabled" in intent_name:
                        return False
                    if query.intent_filter and "_disabled" in intent_name and not intent_name in query.intent_filter:
                        return False
in der Base, wird es nun möglich, [de.fhem:IntentName_disabled] per Standard zu deaktivieren.
Aktiviert wird der Intent, wenn er in "hermes/dialogueManager/configure->intents" oder/und in "hermes/dialogueManager/continueSession->intentFilter" aufgenommen wird.
Somit entfällt eine aufwändige Abfrage der Intents und Eintragung in die Negativliste von RHASSPY.
RHASSPY müsste dabei auf die erweiterten Namen angepasst und ein eventuelles Notify auf "event: start" deaktiviert werden.

Gruß Jens

[Beta-User]

Hmm, mal sehen, ob das Eingang findet...

Schöner wäre es ja, wenn man diesen Namensbestandteil prinzipiell weglassen könnte, aber es ist in FHEM ja kein größeres Problem, ggf. die Intents umzuleiten.
Fyi: Ein notify gibt es nicht, FHEM macht das disable hat bei jedem Start und/oder wenn es feststellt, dass ein erwarteter Filter nicht aktiv zu sein scheint (bei silent cancellation).

Das würde dann eben eine gewisse Sicherheit zum Zusstand von Rhasspy nach dem Start reinbringen, aber leider nicht das Problem beseitigen, dass deaktivierte Intents halt zu "not recognized"-Messages führen, der Intent an sich aber weiter "da" ist.

Mehr fällt mir im Moment dazu nicht ein.

[Prof. Dr. Peter Henning]

Kennt jemand eine gute Noice-Reduction und/oder Echo-Canceling für den RPI0W mit ReSpeaker 2-Mics Pi HAT?
Meine Versuche in Richtung Pulse mit ec, etc. waren mit mäßigem Erfolg gekrönt...

Alle diese Systeme bauen in das Audiosignal Artefakte ein, die wiederum die Wakeword-Erkennung stören.

LG

pah

[JensS]

... aber leider nicht das Problem beseitigen, dass deaktivierte Intents halt zu "not recognized"-Messages führen, der Intent an sich aber weiter "da" ist...

Dazu wird es derzeit auch keine Lösung geben, da der Text von der STT erkannt wird und der NLU übergeben wird. Man müsste die Worte/Wortgruppen bei deaktiviertem Intent im ASR "abtrainieren" und bei Aktivierung neu lernen. Das kostet Zeit. Der "_disabled"-Vorschlag verschlankt jedenfalls die MQTT-Pakete, da bei jedem NLU- und Dialogvorgang fast alle Intentnamen übertragen werden müssen. Mal sehen, was draus wird...

Alle diese Systeme bauen in das Audiosignal Artefakte ein, die wiederum die Wakeword-Erkennung stören.

Das klingt interessant. Hast du einen Tipp, was man sonst machen kann?
Neulich habe ich ein Echo 2 geschenkt bekommen. Da kommt natürlich Rhasspy drauf.  Vielleicht läuft es da etwas besser, als beim ReSpeaker.

Gruß Jens

[drhirn]

Neulich habe ich ein Echo 2 geschenkt bekommen. Da kommt natürlich Rhasspy drauf.  Vielleicht läuft es da etwas besser, als beim ReSpeaker.

Moment mal. Wie? Hast du da eine brauchbare Anleitung bei der Hand?

[dkreutz]

Kennt jemand eine gute Noice-Reduction und/oder Echo-Canceling für den RPI0W mit ReSpeaker 2-Mics Pi HAT?
Meine Versuche in Richtung Pulse mit ec, etc. waren mit mäßigem Erfolg gekrönt...

Ergänzend zu dem was pah bereits angemerkt hat:

Ich habe eine Übersicht deutschsprachiger STT-Modelle erstellt. Dabei habe ich auch Testreihen mit RNNoise durchgeführt und das Audiosignal damit mit "entrauscht". Das hat die Erkennungsrate nur marginal verbessert, bei manchen Modellen sogar verschlechtert (vermutlich weil diese mit "verrauschtem" Audio trainiert worden sind).
Das RNNoise-LADSPA-Plugin kann über PulseAudio eingebunden werden, erzeugt aber zusätzliche Latenzen und der Nutzen ist begrenzt.

Rein softwarebasiertes Echo-Cancelling funktioniert auf dem RPI3 nur leidlich, zumindest war ich mit VoiceEngine-EC nicht erfolgreich. Der Respeaker 2Mic-Hat hat mWn auch keinen Hardware-Loopback, was für Echo-Cancelling sehr hilfreich wäre...

[JensS]

Moment mal. Wie? Hast du da eine brauchbare Anleitung bei der Hand?

https://andrerh.gitlab.io/echoroot/
https://github.com/echohacking/wiki/wiki/Echo#amazon-echo-hardware-root-via-emmc-debug-pins

@dkreutz
Danke für die Links, welche wie bei dir gewohnt, sehr gut recherchiert sind.
Auf deinem Github findet man viel zu Mycroft. Was meinst du zu Rhasspy vs. Mycroft?
Michael Hansen hat ja seit dem 10.11.21 nur noch in "The Future of Rhasspy" geposted.

Gruß Jens

[dkreutz]

Danke für die Links, welche wie bei dir gewohnt, sehr gut recherchiert sind.
Auf deinem Github findet man viel zu Mycroft. Was meinst du zu Rhasspy vs. Mycroft?
Michael Hansen hat ja seit dem 10.11.21 nur noch in "The Future of Rhasspy" geposted.

Ich habe bisher ausschließlich Mycroft genutzt, für Rhasspy habe ich mir bisher nicht  die Zeit genommen. Rhasspy hat einige interessante Features, z.B. das Hermes-Protocol für Satelliten-Lösungen oder MQTT statt dem propietären Message-Bus bei Mycroft. Dem Ziel des kompletten Offline-Betriebs ist Rhasspy inzwischen vermutlich  näher als es Mycroft ist. Aber Michael Hansen hat ja angekündigt, dass er diverse Features in Mycroft übernehmen will.

Bei Mycroft nervt ein wenig der Fokus auf die englische Sprache. Es kommt immer wieder vor, dass Skills nach einem Update nicht funktionieren, weil die Lokalisierung neuer Intents/Features fehlt und dann der Skill in Gänze nicht mehr geladen wird.

Aktuell beschäftige ich mich viel mit deutschsprachigen STT und TTS, da kommt die Pflege meiner Mycroft-Skills auch etwas zu kurz...

[JensS]

Im Rhasspy-Forum wird nun auch die Werbetrommel für Mycroft gerührt...
Das Hermes-Protokoll-Konzept finde ich super zur zentralen Steuerung der einzelnen Prozesse aller Teilnehmer im Base-Satellite-Umfeld.
Jedoch ist MQTT nicht für Audiostreams, sondern für kurze Message-Slots gedacht. Da heißt es mitunter "schlangestehen" am Server und die MQTT-Übertragung von RIFF-Elementen ist nicht sonderlich effektiv.
Die Lösung von pah, alles ab der TTS auf eine andere Schiene zu legen, begrüße ich daher. Auch die Übertragung (Base+Sat.) der Sprache zur ASR, sollte abgekoppelt sein.
Die generelle Auslagerung der Audio-Streams zu einem STUN der Basis mit einem großen Cache wäre ein Ansatz. Das Hermes-Protokoll gibt dabei reichlich Möglichkeiten zu den Statusmeldungen der ausgelagerten Prozesse vor.
Nun warte ich erstmal ab, wann/wie die Anfragen im Forum beantwortet werden.

Gruß Jens

[Beta-User]

Im Rhasspy-Forum wird nun auch die Werbetrommel für Mycroft gerührt...

Das habe ich bisher nicht unbedingt so empfunden - die dortige Community scheint teils erhebliche Vorbehalte gegen jeglichen kommerziellen Mitbewerber zu haben.

Wie dem auch sei, wir werden es erleben, wie es weitergeht, und bis dato funktioniert ja auch "alles" (bis auf dieses Wolfram-Thema bei der Installation, das sich sicher auch leicht lösen liese) weiter "as expected".

Bisher habe ich (entgegen meinen Erwartungen) auch noch keine großartigen Auswirkungen des "Missbrauchs" von MQTT als Transportmittel für Audio-Daten gespürt und finde es auch nicht dramatisch, dass die default-TTS-engine jetzt keine berauschenden Ergebnisse zeitigt.

Trotzdem wäre es natürlich interessant zu wissen, ob denn die experimentellen features im RHASSPY-Modul (insbesondere für externe TTS-Verarbeitung innerhalb der FHEM-Welt, v.a. mit AMAD.*) schon jemand getestet hat....? Ich selbst nutze wenn, dann die Telegram-Anbindung, und die ist rein text-basiert.

[Prof. Dr. Peter Henning]

Trotzdem wäre es natürlich interessant zu wissen, ob denn die experimentellen features im RHASSPY-Modul (insbesondere für externe TTS-Verarbeitung innerhalb der FHEM-Welt, v.a. mit AMAD.*) schon jemand getestet hat....? Ich selbst nutze wenn, dann die Telegram-Anbindung, und die ist rein text-basiert.

Die Anbindung der Wakeword-Engine (mit selbsttrainiertem Modell) precise an meine AMAD-Devices läuft astrein, das ist schon eine Produktiversion. Womit ich derzeit noch kämpfe, ist die Verzweigung der Rückgaben.

"Hallo Jeannie" => precise => Rhasspy => MQTT-Device => aktiviere Spracheingabe auf einem AMAD-Device => TTS via Google => Ausführung via Babble.

Wenn allerdings der im TTS empfangene Satz beginnt mit "Sage Mycroft, <HIER KOMMT DER REST>...", soll dieser rest nahtlos via MQTT an Rhasspy weitergeleitet werden.

Best Erfahrungen mache ich dabei (auch fürs Training) mit dem Mikro hier: https://www.amazon.de/Blue-Microphones-Snowball-iCE-Microphone/dp/B014PYGTUQ/

Was noch kommen soll, sind diverse Satelliten. Und wünschen würde ich mir auch, dass ich eine gute (!) und selbst trainierbare Wakeword-Engine find, die auf mindestens 2 verschiedene Wakewords lauschen kann.

Leider bin ich derzeit beruflich stark belastet, so dass das alles sehr langsam geht.

LG

pah

P.S.: Unter AMAD ist immer noch nur halb gelöst, was bei fehlender Audio-Eingabe passiert, e.g., wie man das doofe Google-Fenster wegbekommt, das zur Wiederholung auffordert. Ich habe zwar einen Automagic-Prozess, der automatisch auf den Wiederholungsbutton klickt - aber ohne Audioeingabe bekommt man das derzeit eben nicht weg.

[JensS]

Wenn allerdings der im TTS empfangene Satz beginnt mit "Sage Mycroft, <HIER KOMMT DER REST>...", soll dieser rest nahtlos via MQTT an Rhasspy weitergeleitet werden.

Was meinst du mit "nahtlos ... an Rhasspy weitergeleitet"? Ein if-else-Problem, sowie Probleme bei der Mustererkennung, schließe ich bei dir aus.

Gruß Jens

[Beta-User]

Die Anbindung der Wakeword-Engine (mit selbsttrainiertem Modell) precise an meine AMAD-Devices läuft astrein, das ist schon eine Produktiversion. Womit ich derzeit noch kämpfe, ist die Verzweigung der Rückgaben.

"Hallo Jeannie" => precise => Rhasspy => MQTT-Device => aktiviere Spracheingabe auf einem AMAD-Device => TTS via Google => Ausführung via Babble.

Wenn allerdings der im TTS empfangene Satz beginnt mit "Sage Mycroft, <HIER KOMMT DER REST>...", soll dieser rest nahtlos via MQTT an Rhasspy weitergeleitet werden.

Aha, du testest im Moment also noch mit der zweigleisigen Lösung.

Die letzte gepostete Dev-Version von RHASSPY sollte diese Unterscheidung zwanglos intern und ohne die Hilfsdevices ermöglichen, allerdings (ohne Eingriff) mit "Sage Rhasspy" statt "Sage Mycroft" (wo auch immer das herkam, aber auch eingestellt werden kann).

[Prof. Dr. Peter Henning]

Du meinst die Version vom 29.12. ?

gegen das "Sage Rhasspy" habe ich noch den Vorbehalt, dass dies eine Anleitung erfordert, wie man das auszusprechen hat.

LG

pah