Rhasspy 2.5 Pre-Release

I am trying to install docker rhasspy image on Raspberry Pi First version.
But It doesn’t start with some “parallels” errors.

Is rhasspy definitivility incompatible with rpi 1?
Thanks you

The Raspberry Pi 1 has the same ARMv6 architecture as the Raspberry Pi Zero, it probably has something to do with it, because the images with 2.5.0-pre and latest tags on Docker Hub are only built for ARMv7, ARM64 and AMD64.

Have you tried the 2.5.0-pre-arm32v6 image?

@koan is correct. I had tried to bundle the ARMv6 image in with the others, but my Pi Zero kept downloading the ARMv7 image and failing to start it. I’ll revisit this at some point, but you can at least manually specify the image for now :slight_smile:

I tried 2.5.0-pre-arm32v6 and it works perfectly. Thanks you!

1 Like

AFAIK, porcupine and mycroft-precise don’t work on ARMv6?
Or have you seen something else?

@synesthesiam, what is the best way to update an 2.5 pre-release version to the latest github version. I did a git pull and a make, and after that all seemed to work untill I tried to access the api. I get the following error:

[ERROR:2020-04-13 22:08:56,774] rhasspyserver_hermes: ‘servers’
Traceback (most recent call last):
File “/home/vandaag/rhasspy-voltron/.venv/lib/python3.7/site-packages/quart/app.py”, line 1821, in full_dispatch_request
result = await self.dispatch_request(request_context)
File “/home/vandaag/rhasspy-voltron/.venv/lib/python3.7/site-packages/quart/app.py”, line 1869, in dispatch_request
return await handler(**request_.view_args)
File “/home/vandaag/rhasspy-voltron/.venv/lib/python3.7/site-packages/swagger_ui/core.py”, line 202, in swagger_blueprint_config_handler
return jsonify(self.get_config(request.host))
File “/home/vandaag/rhasspy-voltron/.venv/lib/python3.7/site-packages/swagger_ui/core.py”, line 79, in get_config
for server in config[‘servers’]:
KeyError: ‘servers’

I did do a remove of the rhasspy directory in .config aswell.

Regards,

Richard

That’s the question I’m trying to answer now… Does anyone know?
I’m using the same config, but the timeout is about 30 sec, not 4 sec

    "command": {
        "webrtcvad": {
            "min_sec": 3,
            "speech_buffers": 7,
            "throwaway_buffers": 9,
            "timeout_sec": 4,
            "vad_mode": 2
        }
    },

I really like 2.5 version… Now it can recognize my voice :blush:

Porcupine should with the latest update, but Precise won’t.

Timeouts are now controlled by the dialogue session timeout setting (should be dialogue.session_timeout). I don’t have that exposed yet on the Web UI.

2 Likes

Hi @Vandaag, this error would occur if the git submodules were out of date, specifically rhasspy-server-hermes. I had to add a “servers” section to the swagger.yaml file in that service,

Perhaps someone with more git experience can give better advice, but I’ve just been running git submodule foreach git pull origin master in the rhasspy-voltron root to update. So the steps would look like:

  1. git submodule foreach git pull origin master
  2. git pull origin master
  3. make

Submodules are still a bit of a mystery to me, so hopefully these aren’t terrible practices :nerd_face:

Finally getting a chance to work on rhasspy :slight_smile: Going to jump straight in to 2.5. Will a pi 3 be sufficient at this time? My end goal once I have a better understanding of it is to remove all the audio pieces from it and hopefully run the main dockers on a vm or more powerful piece of hardware in my rack and just have satellites. but for now, i have a pi3 sitting on my desk i am about to get another microsd card for and a playstation eye camera/mic.

So would the pi3 work for 2.5 and what size card is needed?

Can’t wait to get running :slight_smile:

Will a pi 3 be sufficient at this time?

Yes, a Pi 3 should is sufficient. I just tested Rhasspy 2.5 on a 3B+ without any issues. Thanks to the new “rapidfuzz” drop-in replacement you can now even use “fuzzywuzzy” for intent recognition - which was quite slow before version 2.5.

2 Likes

I am pleased to see that the speed improvements make it more usable :slight_smile:

2 Likes

Just a quick update on what’s coming in the next Docker image. I’ve got Mozilla’s DeepSpeech 0.6 added now for English and German (still uploading). Works on the Raspberry Pi 3/4 as well as long as you don’t have aarch64. Please point me in the direction of any more v0.6 models you can find!

I’m also having to make changes to the UDP audio settings for microphone/wake. In short, udp_audio_port is now udp_audio in the profile. In long, udp_audio can contain multiple host:port:siteId triples; the plan is to allow master servers to do wake word detection for multiple satellites simultaneously over UDP.

Currently working on integrating Snips NLU, but training is not finished yet. I may need some advice on how to translate Rhasspy’s concept of slots/entities over to Snips.

2 Likes

Just curious but why snips nlu ?
If something from snips is to be kept alive I would take wakeword detection. Actually nlu works nice.

1 Like

Well the Snips NLU is fully open source and at least I really like how its performing. The snips wakeword detection worked pretty well, but as far as i remember that is not open sourced. (Would love to be proven wrong on this xD)

The main problem people appear to have with it is that cross compiling their rust stuff for the pi sucks a bit. :thinking:
Are the slots/entities of Rhasspy any different to the slots/entities of the snips NLU? There is basically a json structure the Snips NLU is using for the training examples, that you would have to generate and then there should be a training feature of the NLU you can pass it to that will train the model for the NLU.

1 Like

Hi all,
Just pulled the latest Docker of Rhasspy 2.5.0-pre and very impressed by the general speed of response - it’s much slicker than the earlier version I was trying before. Thanks @synesthesiam and all involved in this great project!
I’ve got just one issue which I’m hoping for advice about - When I speak with an intent which involves feedback speech (from Home Assistant, such as GetTime), I get more than one (sometimes upto 10) repeats of the end of speech sound, and then the same number of repeats of the reply speech. In the log in Portainer for my Rhasspy container, I see this warning:-

[WARNING:2020-04-16 19:27:58,685] rhasspytts_cli_hermes: Did not receive playFinished before timeout

How can I diagnose/fix this?

1 Like

It has good language support and seems like a nice complement to fsticuffs and fuzzywuzzy. Not as strict as fsticuffs, but intelligently flexible instead of literally matching text.

Rhasspy’s slots can have substitutions and conversions inside them, so I’ll do my best to take those into account. A Rhasspy slot value like foo:bar!upper will match foo from the ASR, but should output BAR in the intent.

Yikes, that’s really bad. I’ll test speech again from HA and see if I have the same issue. Is this with master/satellite or just a single system?

The audio output issues are much more difficult to diagnose than in 2.4, where everything was in the same Python process. The dialogue manager pauses the wakeword/ASR systems when TTS or audio is played to avoid feedback, but what to do if the playFinished message never comes (service crash, etc.)? So I guess the WAV duration and timeout then. Maybe I should add a small delay to give the audio service more time…

Answering my own question - something made me try switching from the internal MQTT broker, to External broker (which is the Mosquitto 5.1 MQTT Addon of Home Assistant, running in a different Docker container on the same machine) - and Dada! the multiple repeats stopped! (For completeness, I had also just rebooted the whole machine about 10 mins earlier).
I have the feeling that the broker built in to Rhasspy is somehow more sluggish, but no idea why.
Hope this experience may help others. :smile: