speech_streaming.py got an error on a Raspberry Pi

I got an error on a Raspberry Pi (Raspberry Pi 2 Model B, Raspbian Jessie May 2016) as follows. I could run the example successfully only once, but fails in many cases due to same error.

$ python speech_streaming.py 
...
Traceback (most recent call last):
  File "speech_streaming.py", line 145, in <module>
    main()
  File "speech_streaming.py", line 137, in main
    service.Recognize(request_stream(stop_audio), DEADLINE_SECS))
  File "speech_streaming.py", line 114, in listen_print_loop
    for resp in recognize_stream:
  File "/usr/local/lib/python2.7/dist-packages/grpc/framework/crust/_control.py", line 415, in next
    raise self._termination.abortion_error
grpc.framework.interfaces.face.face.LocalError: LocalError(code=None, details="None")

I confirmed that the following example works as expected, so the hardware (i.e. a USB microphone) and the PyAudio library seems to be fine.

https://gist.github.com/kotobuki/f8e7ca76186a6b575c9bf1e86bed5eb1

$ pip list
...
gcloud (0.14.0)
google-api-python-client (1.5.1)
googleapis-common-protos (1.1.0)
...
grpc-google-cloud-speech (1.0.4)
grpcio (0.14.0)
...
pyalsaaudio (0.7)
...
PyAudio (0.2.9)

+1 exact same problem here, except on Ubuntu 14.04. Maybe the python generator returned by service.Recognize(request_stream(stop_audio), DEADLINE_SECS)) has some sort of issue with iteration? Or is this even a normal python generator? Looking through the stub code was not enlightening.

Yeah - the stub code isn't great.
Usually when I hit a LocalError, it meant that some exception was being thrown in the background thread - ie the thread that generates RecognizeRequests. Unfortunately there's a bug in grpc that swallows the actual exception, so you'll get a LocalError for all sorts of things that go wrong.

You might try creating a recognize_stream manually and iterating through it, and making sure it's giving you sane objects instead of throwing exceptions :)

For future reference, When grpcio==0.14.0 was installed (as per the requirements file) the type returned by service.Recognize() is "grpc.framework.crust._control.Rendezvous object".

With grpcio==0.15.0 or grpcio==0.16.0 the type returned is grpc.beta._client_adaptations._Rendezvous object.

Interestingly enough both of these work fine.

edit: In my own code I had forgotten to put parentheses next to the generator function I passed to Recognize. This resulted in the infrastructure attempting to iterate over the function instead of a generator object, which eventually manifested itself in a LocalError.