Speech api: Fill audio buffer in a separate thread. #527
Conversation
882591b to
5a910e7
Compare
|
This seems to add a lot of complexity. Is this an edge case or a common case? |
|
Mm... so I think the way I was doing it before was actually incorrect. Here's my current understanding: before, there were two threads - one handling sending requests, and one handling receiving responses. However, there are actually three asynchronous things happening - requests, responses, and input from the microphone. Two threads works as long as your request thread consumes audio faster than realtime, because input devices have a buffer somewhere. But if your request thread stalls - because of network latency, or resource constraints, or what have you - then the audio buffer can overflow. So I think this is actually the Right Way to do it. If you have any ideas on how to express it more simply, I'm all ears :-) |
|
Actually, I have an idea... gimme a sec. |
|
Okay - let me know. |
|
@jonparrott I am afraid this may not be edge case. I think @jerjou is heading in the right direction, but I am thinking that with the same logic this code should be simplified by using futures. |
5a910e7 to
013d7d2
Compare
|
Okay - modified to make the three threads more explicit. |
|
@jerjou https://docs.python.org/3/library/concurrent.futures.html using Executors. |
|
This looks good to me. We can switch to |
|
@dpebot merge when travis passes |
|
Okay! I'll merge when all statuses are green. |
|
@puneith - can you be more specific? How can we use Executors to simplify things? I think a major refactor is outside the scope of this PR. If you'd like to refactor to use Executors, please submit a separate PR, which will also help the specificity. |
|
Sure, you can merge this and I will do that as a separate PR. |
013d7d2 to
4430595
Compare
|
@jerjou Other than travis this is merge eligible? |
4430595 to
7866f67
Compare
35e045d to
0051ea9
Compare
|
Okay, yeah. Now it's ready. |
0051ea9 to
2b8ba16
Compare
|
FYI the changes I made were somewhat non-trivial, so I'd appreciate another look. |
| @@ -126,25 +174,34 @@ def listen_print_loop(recognize_stream): | |||
|
|
|||
| # Exit recognition if any of the transcribed phrases could be | |||
| # one of our keywords. | |||
| if any(re.search(r'\b(exit|quit)\b', alt.transcript) | |||
| if any(re.search(r'\b(exit|quit)\b', alt.transcript, re.I) | |||
| for result in resp.results | |||
| for alt in result.alternatives): | |||
| print('Exiting..') | |||
There was a problem hiding this comment.
The program doesn't exit even when you say exit.
There was a problem hiding this comment.
It should - are you seeing that it doesn't? It should break out of the listen-print loop and return from the function, which should exit all the context handlers in the calling function. What behavior are you seeing?
There was a problem hiding this comment.
It prints "Exiting" but hangs there.
There was a problem hiding this comment.
Ah - probably one of the threads isn't exiting correctly -_-;
Just to make sure - you're sync'ed to the latest changes, right?
There was a problem hiding this comment.
Updated to explicitly cancel the request stream. See if that helps?
This is to avoid timing issues where the request thread doesn't poll the generator fast enough to consume all the incoming audio data from the input device. In that case, the audio device buffer overflows, leading to lost data and exceptions and other nastiness. Address #515
2b8ba16 to
1304bc8
Compare
This is to avoid timing issues where the request thread doesn't poll the
generator fast enough to consume all the incoming audio data from the input
device. In that case, the audio device buffer overflows, leading to lost data
and exceptions and other nastiness.
Address #515