I'm running simple patch using Pi2 - I'm reading data from on button using arduino

After a while patch is stuck and data is not pass from the comport to the rest of the patch.

Any idea what can it be? I don't think patch is High in CPU usage

the patch is open via the pi folder that start on boot. I got a feeling the audio output is crashing and this what cause the fault?

After running for around two hours the patch was stacked and no audio or any message is cumming.
I'm guessing the pi2 is strong enough for running that patch. What else can it be? maybe my pd version is corrupted? issue with the output that stuck the whole patch?
Any suggestion to solve it?

edit: I also try to run it via terminal without gui and the issue also happened so I don't think is related to the gui.

I'm using non official pi power supply )I'm using 5V 2.1A phone charger). Sometimes I'm getting error of: not enough power please check your power supply (or error similar to that). Could it be the issue?

@KMETE Yes. I have had a RPI play up because of a bad power supply.
If you are still using a usb soundcard then try connecting it through a powered hub.
I think the RPI 2 uses about 250mA though, and a soundcard usually no more than 500mA so maybe you just have a bad usb supply.
The usb power supply cable needs to be good though or you will have a voltage drop..... even the micro usb connector is lossy.
If you try a powered hub it might cause hum problems if it is grounded....!
David.

@whale-av I'm using the built-in headphone output(bcm2835 (hardware)
. The problem in that case is not the quality of the audio which is just fine, rather the patch will stuck after some times.

I'll try different cable for the power supply. I hope that is the issue because the patch is really not heavy on cpu and I'm guessing Pi2B should run it.

@KMETE Try another phone charger first then...... and see if that makes a difference.
Can you open another patch when it gets stuck..... or is Pd stuck as well?
Does the "Test audio and midi" menu produce any sound when that happens?
David.

@whale-av said:

Can you open another patch when it gets stuck..... or is Pd stuck as well?

I'll check that asap. If I recall correctly I can open another patch. is just the patch currently using is stuck.

Does the "Test audio and midi" menu produce any sound when that happens?

Will check asap.

@KMETE Also.... you should put a [print] in a few places..... as you are not getting any helpful error messages.
[print sf-play2_input] on the outlet of the [gate 1 1] above.
[print og.filter_output]
[print comport_output]
And maybe others in places that could help you find the problem.
David.

This morning I start pd and the patch and this time is stuck at the second time pressing the button (that starting the audio). I then press file >> and open the same patch. the moment I open the same patch it came back to work.
I did not get any power- supply issue message.

Maybe I should uninstall and then reinstall pure data?

@whale-av when patch is run all printing is just fine but the moment it freeze nothing is printed and everything is freezes(the scope~ as well).

as you can see it stuck again. I press all the messages and bangs and they are all stuck (bold black) . No printing .
the moment I open the same patch it worked in the new opened patch.

@KMETE Assuming that you put a [print] on the output of [comport]..... does anything print on the first button press?
If nothing is printing then the [comport] connection has failed....... but if it prints on the first button press and not on the second then that is very strange.

You could send a [verbose 1( message into [comport] as the patch starts.... after the [open 0( message..... and put a [print] on its right outlet... which might tell you something.

Maybe because you are sending nothing at all into [comport]..... only receiving.... the socket is dropped after a while.
You could create a "keep alive"....... a useless message like [print alive( could be banged into [comport] from the patch every 60 seconds by a [metro 60000]. That might help.... no idea but worth trying I think.
Actually [print alive, info( would send the "alive" message and then print the status of comport to its right outlet every 60 seconds.... that might be very useful.

Last thought...... Is there a sleep mode set for the Arduino?
David.

@whale-av
I don't think the problem is with comport rather with pd itself because not only that the comport is not passing data when stuck it also when pressing manual - everything is stuck (as you can see in the last picture I shared. all messages were pressed manual. everything seems stuck.)

The moment i open a window with the same patch it back to work.

@KMETE Ah.. ! so the patch itself really is stuck.
I should have noticed the exact problem in the screenshot....... the bang stuck on and the message boxes with thick outlines.

I remember that you had multiple bangs from the right outlet of [sf-play2~] when the track ended.
they are sent to [vline~] ....... no problem...... and [gate]
[change] will not stop them....... and I just noticed (should have spotted it earlier) that the [bang] after [change] is stuck in your screenshot.
So the patch is trying to start the track read many times almost at once.

Try this......... time-gate.pd instead of [change]
I don't know how rapidly those bangs arrive..... maybe [time-gate 1] will kill the repeats but maybe a higher number of milliseconds will be required if they are further apart...... [time-gate 2] or higher? It auto resets after the argument time.

Put it on the right outlet of [sf-play2~]
David.

@whale-av Thank you very much David. I put [time-gate 2] and for the moment it all work without stucking. I'll run it for few hours and will see if it really helps. Seems good for the moment

btw - I'm getting a popup message of i/o error and I think is because the audio dialog choose a inputdevice that doesn't really exist(?)
Is it possible to untick the audio input device via thr [audio-dialog] message i'm banging when patch is first loaded, so it will not be choose?

some updates:
I came back to the pi after two hours and press the button. Patch is stacked again...
so perhaps it was not the multiple bangs from the right outlet the sf-play~ causing the problem. Any idea what can I try else?

Pressing manually after patch was stacked

some extra update: i noticed that after patch is stacked - when I un-tick and tick again the DSP message in the pd console the patch is back to work and all the messages are printed again. it might be an issue with the builtin output the is crashing??