Raspberry Pi4 Buster : ValueError: Invalid chunk size: 0

[varungujjar]

Hey Guyz... some reason unable to get precise working on pi4 buster..

what I have tried:
Changing USB Posts
Pip reinstalling everything again (everything satisfies)
checking Alsa Sound Configuration
reinstalling portaudio

am using pyaudio with following config

audio = pyaudio.PyAudio()
self.audio_stream = audio.open(
format=pyaudio.paInt16,
channels=1,
rate=16000,
input=True,
frames_per_buffer=2048,
input_device_index=1 (my USB Sound Card)
)

while True:
self.stream.write(self.audio_stream.read(2048))

What Works
precise-listen <model_name> works perfectly fine

get the following error

Exception in thread Thread-1:
Traceback (most recent call last):
File "/usr/lib/python3.7/threading.py", line 917, in _bootstrap_inner
self.run()
File "/usr/lib/python3.7/threading.py", line 865, in run
self._target(*self._args, **self._kwargs)
File "/home/pi/homie-agent/scripts/mycroft-precise/runner/precise_runner/runner.py", line 240, in _handle_predictions
prob = self.engine.get_prediction(chunk)
File "/home/pi/homie-agent/scripts/mycroft-precise/runner/precise_runner/runner.py", line 64, in get_prediction
raise ValueError('Invalid chunk size: ' + str(len(chunk)))
ValueError: Invalid chunk size: 0

[jessecooper]

You ever figure this out? Getting this on precise-runner==0.3.1

[jessecooper]

https://github.com/MycroftAI/mycroft-precise/blob/dev/runner/precise_runner/runner.py#L235

Should this line ever return an empty chunk?
If yes or no this exception should be handled here: https://github.com/MycroftAI/mycroft-precise/blob/dev/runner/precise_runner/runner.py#L240
With some kind of description on why the runner is about to bomb out.

Guessing the goal of this loop is to be a daemon loop and it should not bomb out unless it is unable to lock on to the mic with pyaudio for some reason?

To add to this:
I added logging to the precise_runner and added a continue on exception this fixes the problem. So, I am guessing the stream should never return 0 or at least that is not an expected behavior:

Log output:

2021-10-26 20:00:23.890 | INFO     |  4342 | precise_runner.runner | 0
2021-10-26 20:00:23.890 | INFO     |  4342 | precise_runner.runner | 0
2021-10-26 20:00:23.890 | INFO     |  4342 | precise_runner.runner | 0
2021-10-26 20:00:23.890 | INFO     |  4342 | precise_runner.runner | 0
2021-10-26 20:00:23.890 | INFO     |  4342 | precise_runner.runner | 0
2021-10-26 20:00:23.890 | INFO     |  4342 | precise_runner.runner | 0
2021-10-26 20:00:23.891 | INFO     |  4342 | precise_runner.runner | 0
2021-10-26 20:00:23.891 | INFO     |  4342 | precise_runner.runner | 0
2021-10-26 20:00:23.891 | INFO     |  4342 | precise_runner.runner | 2048
2021-10-26 20:00:23.899 | INFO     |  4342 | precise_runner.runner | 2048

Debug Code:

def _handle_predictions(self):
        """Continuously check Precise process output"""
        while self.running:
            chunk = self.stream.read(self.chunk_size)
            #print(len(chunk))
            self.logger.info(len(chunk))

            if self.is_paused:
                continue
            try:
                prob = self.engine.get_prediction(chunk)
                self.on_prediction(prob)
            except:
                continue
            if self.detector.update(prob):
                self.on_activation()

After adding this my VA is working since the prediction handler daemon loop is not exiting.

Would gladly open up a PR with cleaner exception handling and less verbose logging but looking for feedback of expected behaviors.

Guessing also pyaudio stream returning no data could be an issue with my pulse audio configuration.

[ShamoX]

I think it is treated by management of the EOF of the new actual runner.

Even if the actual management:

             chunk = self.stream.read(self.chunk_size)

             if len(chunk) < self.chunk_size:  # EOF

seems a little hard for me. It may cut at the end of the stream and through away the last little chunk that may contain a wake word. Depending on the bitrate and duration of the wake word I guess it may not represent a big issue.