why breaking change on audio events?

[sdetweil]

change from audiostop to audio-stop

what useful value is that?

[synesthesiam]

I'm confused. The dashes have always been there. The very first commit has them:

wyoming/wyoming/audio.py

Line 11 in 892e01d

_STOP_TYPE = "audio-stop"

How are you using Wyoming?

[sdetweil]

weird indeed. I was looking at what I thought was 1.5 (master), but using 1.3 and couldnt get the is_type to work. at that point I wasn't using the class libs. so this was probably my fault. transcribe however was different. so I ass-umed.

[sdetweil]

sorry, didn't answer the second question..making a new asr. mostly cause I want to use it with an existing app
but needed a way to test it without all the HA baggage.. so I needed a client that can send a wav file that the asr can transcribe

the doc says 'asr that anything can connect to' .. so as I don't know python nearly at all, I chose nodejs , no response ..
bash nc next (but that had the connect/disconnect problem) , but I could send the tranactions
then python telnetlib, which stayed connected and did all the transactions except AudioChunk, samples showed needing a newline..
the nodejs trouble was the lack of a newline..

then gave up and cobbled together a python wyoming client.. and I don't know much about audio streams, or files.. so its all fun times..

[synesthesiam]

Yeah, I had misspelled "transcribe" early on 🤦‍♂️

Anything that can do TCP and JSON should be able to use Wyoming. It is important that the TCP connection be maintained through the session. I don't know much about nodejs, but I'm surprised it had problems :/

[sdetweil]

nodejs didn't have trouble, just needed to explicitly send a newline. then the server side responded. no info before that

[sdetweil]

closing, not an issue