Hello all, this is my multi-hour recording of me piping bash {1…100000} >> testfile and having a tail -f | mycroft-speak.
I noticed a couple of oddities in the speech (lower more robotic voice), on a couple of numbers. I plan on going though and finding them again, but for now I figured I would post the full audio clip, so other might listen for them, if they are so inclined.
Other issue I found is that the messages would queue far more than what has been said. (It is just a while loop sending each line of /dev/stdin to the mycroft message bus so that isn’t that surprising.)
A useful thing I think would be a way to clear the queue.
Another interesting test I might try to look at is, how many messages can be queued before issues arise.
I believe that these are being rendered by our Mimic service. I’d be curious to know if piping 2352 gives you one of the abnormalities.
It may be the model, for whatever reason, doesn’t render certain numbers properly. It could also be a function of your firmware. We’ve found that the Re-Speaker firmware sometimes decides ( randomly ) to play audio with significant distortion.
Can you try just 2352 and get back?
In terms of queing the messages, might make sense to detect the completion of the prior execution before calling the next one. Seems like you may be starting an individual thread for each request which basically acts like a fork bomb.
It returned distorted even as the only message in the queue. I tested it 10 times, with no deviance all of them distorted.
So I am guess all of the distorted ones are probably also just distorted number.
Is there anyway of clearing the message queue?
That said, from [what I read] (mycroft package — Mycroft v21.2.2 documentation) , the api you can indeed set the wait ``var to true in the call, causing it to block. I don’t know if I can do that via the message send that the cl tool is doing.
The Mimic II server has a caching mechanism so that it doesn’t have to render every phrase every time. As a result, once you call it for a number the output lives ( forever? ) or at least until the cache is pruned.
@ChrisVeilleux - can you reach into the Mimic II cache and nuke “2352” and see if re-rendering it solves the distortion problem?
Interesting. Just tried 2352 thru mycroft-cli-client “say 2352” and can confirm the odd audio - sounds like it is being played twice with a very small time offset between start times. 2351 and 2353 are normal.
I don’t think I have used 2352 previously, so shouldn’t be a local cache problem.
I just realized you were referring to the server cache - sorry