grpc streaming example crashes and hangs #515
Comments
|
Would you mind posting a snippet of the code that works with pyaudio, and the output that you get? |
|
Here is what I have working: |
|
Two things:
|
|
will do. thanks |
|
The output when it is successful: pi@raspberrypi:~/gopigo/Projects/Awareness/voice/pyaudio_test $ python pyaudio_test.py ALSA lib pulse.c:243:(pulse_connect) PulseAudio: Unable to connect: Connection refused ALSA lib pcm_dmix.c:1022:(snd_pcm_dmix_open) unable to open slave
The diff is in the attachment: |
|
By the way: This works --- > (grpc) pi@raspberrypi: |
|
I'm not seeing the diff? I'm seeing a dump of your audio devices in the attachment.. |
|
Sorry: 1 sec -- |
|
Okay, I can't seem to reproduce the error on my box (I don't have a raspberry pi handy at the moment). Googling around, it looks like it happens because audio data is coming in faster than you're using it, and the portaudio buffer overflows. I'd guess that this is because, on the raspberry pi, the hardware is just a tad too slow / constrained to keep up with the sampling. I would try playing with your chunk size (increasing it, perhaps?) and using the lowest sample rate your audio device supports (44100, from what you said). There are also a number of workarounds posted in that stackoverflow thread that you might try. Notably, since you know what platform you're running it on (I used pyaudio in this sample mostly because it's cross-platform), one answer suggests using the Alternatively, you could spin up a thread to consume and store the input stream, and then have the Let us know what you try / what results you get! |
|
@jerjou if you'll remind me next time you come to Seattle I can bring in my RPi2. |
|
@jerjou - I concur with your analysis. If the alsaaudio example works, that is it can keep up with the sampling, then it does suggest that this is an efficiency issue. I am also looking at what the enormously popular (but somewhat limited) Amazon Echo 'on yur pi' project does to guarantee audio can get to the service and responses come back pretty quickly on a Raspi. I am building a voice-controlled robot car, not a virtual assistant. Although, conceptually, I could with the GCP/Voice, NLP, etc, etc which I strive to do eventually. What I need to do first if I want to use the streaming grpc service is to get a test program working. Once there, I can slice and dice things, build a simple library which my mains can call and I know it will work each time. Right now, I cannot get past this problem. FYI - Googlers: Kas Sata and Glen Shires @io16 built a gopigo voice-controlled car with vision based on GCP that was the inspiration for my project. If you have access to them, they may know how to get this working on a Pi. Cheers! |
|
I just pushed a quick-and-dirty version that fills an input buffer in a separate thread. See if this works for you: |
|
Still getting this error with the separate thread version. (grpc) pi@raspberrypi:~/gopigo/Projects/Awareness/voice/python-docs-samples/speech/grpc $ python transcribe_streaming_thread.py ALSA lib pulse.c:243:(pulse_connect) PulseAudio: Unable to connect: Connection refused ALSA lib pcm_dmix.c:1022:(snd_pcm_dmix_open) unable to open slave |
|
That looks like a different error. Did you double-check that the sample rate you defined in the code is one that's supported by your input device? |
|
No, I will try that. |
|
Eureka! That works. Huge thanks. |
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
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
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
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
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
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
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
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
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
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
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
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
|
FYI cleaned up the thread handling, and merged into master. |
Just cloned the latest repo for grpc -
running this on Raspbian (Raspberry Pi)
Cannot even break out of the program at all.
The sample rate of my usb mic is limited to 44100 and 48000. I tried changing those in the example but I get the same results.
I have pyaudio installed up to date.
Sound recording and playback both work with pyaudio.
The ~/.asoundrc script is here:
Here is the output of the program.
The text was updated successfully, but these errors were encountered: