Continuing the discussion from UDP Audio Streaming without satellite:
I have read several posts on this subject but I still have not managed to have a correct operation!
I am in Rhasspy version 2.5.10 installed from the .deb package
and therefore my installation directory is in / usr / lib / rhasspy
I have a seeed-voicecard 6 mic Array sound card.
in sound version by MQTT everything is OK and works perfectly
the examples given on the forum are on old versions.
It says to << just add a free UDP port >> As in the post
but version 2.5.10 is a little different and so for arecord I proceeded in the same way:
For Arecord :
the MQTT flow stops but the WakeWord no longer works
If I use WakeUP (yellow Web interface button) my requests are well recognized I see a few MQTT -> AudioFrame frames passing through which stop once the intention is recognized
Probably needs a complete overhaul as who ever thought raw wavs over encrypted MQTT was a good idea was obviously having some form of cognitive dissonance to practically every form of audio technology post Ipod, Herpes audio is a real stinker.
@synesthesiam and authors probably know that I find the whole hermes thing is a bemusement to me, as its a direction was to create a skill platform that it seems it completely fails to provide and much else whilst seemly adding wads of load and complexity…?!
So maybe don’t reply to me as you know I think its a total brainfart but when someone is more polite and curious to work with the current framework and shift raw wavs out of a lightweight msg and control protocol do you think you could supply some pointers or at least an explanation why not?
Its critique of an extremely bad part of rhasspy that is part of user led community software that allows software to evolve and get better due to feedback.
Its extremely bad and lets down other parts as I don’t dislike Rhasspy but I do dislike Hermes audio because its an absolutely atrocious implementation.
Unlike some I am just being honest.
But you are voicing your opinion in every thread that even remotely relates to it, and after a while that is just too much. I am pretty sure everyone that is active on the forum read at least 3 posts about it in various topics and everyone interested in it can just use the search function.
We have never had a single reply to why you are loading raw wavs over MQTT and there is nothing to search for.
Its just like this thread you just ignore and don’t answer.
Its just like
Where I was replying to a total mistruth that there is no NN for a KWS on ESP32 as its just untrue and its not me who is ranting I am just stating the truth.
‘Hijacked’ !? it was purely a reply to a response that was clearly wrong in detail.
I admit not having understood everything in the posts which aim only to denigrate a solution (which may not be the best but which is the one that exists) and above all nobody gave me an answer to my problem . If some do not find it advisable to transfer wav on the MQTT the fact is that Rhasspy was designed like that and I am not criticizing this solution and for the moment I am trying to overcome this defect by going through UDP.
I would be entirely ready to apply another solution (which would be developed by those who find it to be an error) but for the moment I would like some help to make Snowboy work in UDP
and explain the parameters requested in ver 2.5.10, namely the 3 parameters requested as follows:
My server has for parameters: IP=192.168.0.28 and ID=Master
I (assumed) and put at home:
host1 = Master
port1 = Port identical to the one I put for AudioRecording (12222)
siteId1 = Master (I think it’s id in case of satellite)
but Snowboy does not detect anything and does not trigger the hermes / asr / startListening
On the other hand if I use the WakeUP key I can see the AudioFrame frames which are triggered on MQTT and which stop once the hermes / asr / stopListening has been issued
because I redid the test and the results are:
localhost + port -> ok
local ip(192.168.0.28) + port -> does not work
127.0.0.1 + port -> ok
here is thank’s Kaykoch
Arpagor
Are you running docker. If so, your container most likely has an ip from the docker internal network, so that not working makes sense. You can run a container in host mode and then I think they share the ip but that is not recommended vor various reasons. See here for that.
No I am using the package version installed from .deb https://github.com/rhasspy/rhasspy/releases/tag/v2.5.10
which once installed is found in / usr / lib / rhasspy
so it is not the “Docker” version nor the one installed from a git clone that it works in “venv”
