Pisound-btn get unresponsive sometimes

Hi there !
First a bit of context :

I’m developping a Real Time denoising application with Jack API backend, it got several threads running and can fully occupy up to 2/4 cores of my rpi 3b+.
I’d like to control the noise reduction with the button so I created a DBus target in my programm, and made a little executable which sends a method call over DBus to the target.
The executable works perfectly fine and successfully change the application parameter on the run.

Here is my problem :
I created a shell script which call this executable and put it in the scripts directory. I’ve modified the .conf file to make a 1-click on the button call this script.
But I’m having several bugs :

  1. Just after boot, there is already the pisound-btn executable running as root in background. I assume it is autolaunched by the pisound config (however I couldn’t find any ressources about it) and it is the one used in the following tutorial https://blokas.io/pisound/docs/the-button/#a-quick-tutorial as they don’t seems to run pisound-btn explicitly. But in my case, this already running script is not reacting to any of my button interaction.

  2. I then tried to run pisound-btn by myself. At first it worked well, even though a bit verbose (printing every shell script it is executing). But sometimes, when I kill and restart my own application, the pisound-btn executable stops working. It doesn’t respond to any button click until my application is killed. As mentionned here The Button unresponsive when pd gets busy, I thought it may be than my RT application is so high priority it doesn’t let the btn executable run at any time.
    But I got 2 cpus cores not used, more than 50% of free RAM, so I don’t get why it would lack ressources. Also, I recompiled the pisound-btn with debug option to see what is happening and it seems the main loop is running, but it simply doesn’t detect the change in button state (line 678 of pisound-btn.c).

Does someone knows or simply have a clue about what is going on there ?
Thanks !

Does the script you wrote start a long running process? If so, the process should get started in the background (the last line should end with a & symbol)

The button may become unresponsive if the triggered script is stuck or running long - it is waiting for the script to finish.

pisound-btn is started by systemd, via pisound-btn.service: https://github.com/BlokasLabs/pisound/blob/master/pisound-btn/debian/usr/lib/systemd/system/pisound-btn.service

You can disable automatic starting by running:

sudo systemctl stop pisound-btn
sudo systemctl disable pisound-btn

Thanks for the quick answer and the details about auto starting :slight_smile:

No the script simply run my executable, which is almost instantaneous. Anyway I got a output when it’s done and it always exit in time.

I’ve check the running process and it simply seems than, when using the auto-started pisound-btn both my shell script and the executable it is suppose to run are never started, even though it is ask to in my .conf file.

What does the service log say?

journalctl -u pisound-btn

hit ‘end’ on the keyboard to go to the latest lines. Note that due to log buffer, the latest lines logged may be unavailable immediately.

Don’t mind the “bug connection” messsage.
You can see a huge gap btw 12:08 and 12:35, when my application was running.
I pressed the button many times during this time interval.
It immediately worked again when I stopped it.

It does look like the script that was executed did not return control to pisound-btn until your application was closed. Does the last line in your script end with a &?

Yes it does, here is the whole shell script image

Up again, after some time I had no choice to get back to this. Here is some more details

  • I got a jackd2 server running fine with pisound binding
  • A jack client running in real-time scheduling with two thread also in real time, two of my cpu are still available
  • pisound-btn is actually running but the poll call (line 672 pisound-btn.c) never returns. I tried to set a timeout and it appears it is the kernel that no longer return events from the pisound.

When I say it is running is : as I’m using real time execution, I thought it could be the RT scheduler which doesn’t give to pisound-btn some execution time. But I tried to execute it also in RT with the highest priority, but it didn’t changed anything : the poll call does not return any button related event as long as main program is running.

pisound-btn depends on userspace sysfs GPIO driver to produce events, maybe some parts of kernel itself are having not enough time to run to be able to detect and forward hardware events to user processes? Or maybe something else manages to break the pin configuration, so it no longer senses voltage changes on it. The button on Pisound is simply wired to BCM17, so that when the button is pushed, the pin is pulled low, together with a simple RC low pass filter to reduce switching noise.

I don’t think this is a physical issue, because sometimes, still unable to understand why, it does work perfectly (I’d say 1/3 times). Besides, we got two rpi3b+ & pisound units and both get the same issue.

I started searching about this userspace driver you mentioned, would you have any resources about it ? Thanks a lot !

EDIT : I’ve made a monitoring script on /sys/class/gpio/gpio17/value and the value is indeed behaving properly even when pisound-btn seems not responding. So it is probably thay using poll in a real-time context is not safe enough as suggested here : http://www.krono-safe.com/using-time-triggered-approach-better-design-of-safety-critical-real-time-systems/
I’ll now take a look at time-based alternatives for pisound-btn and let you know :slight_smile:

Is there some way for me to reproduce the issue on my system?

Hi, I kinda solve my specific problem by reducing the amount of process using real time scheduling. But as many sound applications could ask for real-time scheduling it could still be a problem.

Try to start several process with real time scheduling. For my part I had the jack server, a jack client and a resampling routine.