rhasspy / wyoming

Peer-to-peer protocol for voice assistants
MIT License
136 stars 20 forks source link

client disconnect after wakeword interaction #29

Open sdetweil opened 2 days ago

sdetweil commented 2 days ago

SO I am building my own workflow coordinator(aka satelltie) on on machine, to be the wake/stt components to replace hard coded versions (snowboy)

so I have Mic snowboy wakeword my own google asr

will and tts and sound later

so I have my full time async task() running the event handlers and can get wake and transcription working. once..

my debug logs show the same flow, before and after processing wake/sst.... but wake never responds the second time..

debugging the snowboy wakeword shows the 'client' (my coordiantor) disconnected after the wakework (pro or con) response I have debugged my code and cannot find a call to disconnect that is invoked.

DEBUG:root:Client connected: 414308984955112
DEBUG:root:detector names passed=smart_mirror
DEBUG:root:data =/home/sam/wyoming/wyoming-snowboy/config
DEBUG:root:custom=custom
DEBUG:root:kwdir is folder=/home/sam/wyoming/wyoming-snowboy/config
DEBUG:root:kwpath is =/home/sam/wyoming/wyoming-snowboy/config/smart_mirror.umdl kwname='smart_mirror' == keyword_name='smart_mirror'
DEBUG:root:found keyword=smart_mirror
DEBUG:root:Loading smart_mirror with sensitivity=0.5, audio_gain=1.0, apply_frontend=False
DEBUG:root:detector names passed=smart_mirror
DEBUG:root:data =/home/sam/wyoming/wyoming-snowboy/config
DEBUG:root:custom=custom
DEBUG:root:kwdir is folder=/home/sam/wyoming/wyoming-snowboy/config
DEBUG:root:kwpath is =/home/sam/wyoming/wyoming-snowboy/config/smart_mirror.umdl kwname='smart_mirror' == keyword_name='smart_mirror'
DEBUG:root:found keyword=smart_mirror
DEBUG:root:Loading smart_mirror with sensitivity=0.5, audio_gain=1.0, apply_frontend=False
DEBUG:root:Detected smart_mirror from client 414308984955112   <----- detect
DEBUG:root:Client disconnected: 414308984955112   <---- disconnected

and if I terminate it cause of silence or timeout

DEBUG:root:Audio stopped without detection from client: 414682858463196
DEBUG:root:Client disconnected: 414682858463196   <---- disconnected

but my corrdinator keeps sending mic generated AudioChunk async_client.write() and there are no errors

so the service thinks the connection is closed, but my app thinks its still open.

is there an implied disconnect somewhere? the fact that my client side can write, and not get an error is really the issue. but I really don't know why the connection is closed

using tcp:// connection types. the snowboy part is using wyoming 1.5.3 my app is using wyoming==1.6.0

I did discover A path thru the code which causes a close()..

IF you have an asyncio.task, which DOES NOT have an

except asyncio.CancelledError:

handler.. and IF that task is canceled.. then the previous LAST task created gets the exception.. which I think is a bug myself

task A should never be affected by task B's problems.. that doesn't solve the disconnect issue tho

sdetweil commented 7 hours ago

ok, i see, if the event handler returns false the server is dead

the snowboy wakeword does that when it doesnt find a match. not very useful over a long period of time. got to think they are only 90%