Core usage at maximum on a fresh install.

[shandrios]

Hi, I'm a big fan of the project, but I'm having a big problem with the program getting hung up at maximum core usage after a while. I tried to solve this by removing all words from the dictionary and removing all plugins except the print plugin, but the problem persisted. I even did a fresh reinstall of Raspbian and installed only Sopare and its dependencies, but that still didn't solve it.

I'm using a Raspberry Pi 3 Model B+, and I'm using the stream settings from the audio test. Is there anything I could change in the config file to resolve this issue?

[bishoph]

If there are no entries in the dict how do you determine hanging? How do you measure max. core usage and what tools are you using?

If the dict is empty and are using the default config and plugin the load is near zero as SOPARE does nearly nothing. What maybe happened is that you delete the dict entries but not the trained files as described which means you end up with a full dict all the time.

From the Quick start:

Delete your training files and the dictionary entries before continue:

./sopare.py -d "*"
rm dict/*.raw

If the dict is really empty and you still encounter the issue try to add some beef in terms of steps to reproduce, versions in use, helpful output, error messages, ...

[shandrios]

There are two ways i determine that the program is hanging: Firstly, the default print plugin stops printing empty brackets when a sound is detected. Secondly, htop clearly shows sopare.py using 100% of one core. If I leave it running, sometimes it changes which core is in use, but it never drops below 100% until I terminate the program.

I mentioned I tried running the program from a clean install, which would mean the dict is completely empty, but I also tried with your deletion command which predictably didn't do anything.

In terms of steps to reproduce, it's as simple as installing the program with your instructions and then running it in endless loop mode. For me it hangs after around 30 sec-1 min, but sometimes it takes longer. Here's a screenshot of the htop and sopare terminal windows.

Versions: Sopare is ofc version 1.5.0, Raspbian GNU/Linux 9, kernel version 4.9.80 v7.

When I terminate the program with ctrl-c, the error report I get is different every time. Here's 3 different examples (I left the top part in to show it follows soon after i launch the program)

I got the stream values to use from the audio-test program, and they are: CHUNK = 512 SAMPLE_RATE = 48000 THRESHOLD = 300 MAX_SILENCE_AFTER_START = 1.4 MAX_TIME = 2.4 LONG_SILENCE = 20 CHUNKS = 3072

[bishoph]

Enable the WARNING log level and check if you get stream read (error) messages or anything related to the input stream and potentially pyAudio.

[shandrios]

I changed the log level to 4 (KERNEL_WARNING) and updated my alsa-lib to version 1.1.9 from 1.1.3. The program stayed running for about 10 minutes before it once again spiked one of the cores to 100% usage and got hung up. It doesn't seem like the error log is giving any more information about warnings though. I left the initial ALSA errors out of the earlier posts, but I've left them in these screenshots. Do you happen to know what they could mean/if they are causing the problem?

[bishoph]

Please change the SOPARE log level to WARING by changing the value

LOGLEVEL = WARNING

in the file default.int or the config file you are using. My guess is that you get stream read errors or other related stream errors.

[shandrios]

You were correct. After a couple minutes the program got infinitely stuck in a stream read error that didn't stop until I terminated it. Is it caused by something outside of sopare itself?

[shandrios]

I had a look at the other issues on here and on your blog, and found others with the same stream errors. I've changed the CHUNK, CHUNKS and SAMPLE_RATE values to 1000, 4000 and 44100 respectively, and it seems to be stable now, although it feels slightly slower. Thanks for the quick help, I'll follow up if it still doesn't work.