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

@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??

@KMETE Alsa input error (snd_pcm_open) no such file or directory.... is normal..... as the RPI doesn't have an audio input. You should change the message at the top of the patch to.......
[audio-dialog 0 0 0 0 0 0 0 0 $1 0 0 0 2 0 0 0 44100 25 -1 64(
That will deselect audio input in the Pd audio settings.
Whether that will solve the sticking problem I don't know..... it might.

You seem to now know for sure that audio is stopping.
I will wait for you to find out whether changing the message solves the problem.
David.

@whale-av I connected small usb dongle audio card and for the moment it seems very stable. Not freezing. I get the feeling that indeed it was the built-in headphones output of the pi2B that is not so good apparently.

After many hours of pi running I can confirm the issue was caused by the built-in audio output. Adding the dongle USB audio interface indeed solved it.

@KMETE Excellent news.
David.