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
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.
and if I terminate it cause of silence or timeout
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
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