I'm running Pd on a cubieboard 2 (armf), together with jack in realtime mode. In order to access an adc with i2c within Pd I created externals and it worked, but I couldn't find a way to get rid of clicks and pops when reading values in my audio patches with this setup..
Then I made a standalone version of one of them to be launched in regular terminal, and got its output redirected to pdsend application (standalone, part of the pd package on linux platforms). This saved my day, no more clicks, data is sampled from the standalone application and sent via TCP to pd, that retreives it with a [netreceive] object. Next step will be integrating the pdsend program within my program, as advised by the authors.

My guess is that as I launch PD with a fairly high rt priority, the externals loaded in a patch do run with the same rt priority, leading to problems as my i2c port may have a significantly lower rt priority. The point is that I want audio to be clean at all costs, but really don't need to read i2c data with such a time accuracy.

What do you think about it ? Could my guess be right ? I don't have an arduino, but I heard there are pd objects that do the job, is everything good ? No cracks and pops I suppose ?

Note : it's not a matter of putting "line" objects in order to smooth out the commands here, really

Thanx,

Nau

Cheers~

this looks like exactly what I needed. I'm gonna try it soon !

Nau

The point is that in your secondary thread you are locking PD with sys_lock
whenever you want to use PD API functions (like getbytes or outlet
functions) and unlock it with sys_unlock when done. Clearly this time should
be as short as possible. This ensures that your calls into PD happen when PD
itself doesn't do that (as it is in "idle" state).

From:
http://markmail.org/search/?q=sys_lock&q=list%3Aat.iem.pd-list#query:sys_lock list%3Aat.iem.pd-list+page:2+mid:xyejpscgjtqclasg+state:results

Here's another external thread implementation: http://sourceforge.net/p/pure-data/svn/HEAD/tree/trunk/externals/bbogart/gphoto/

Cheers~

I tried to compile it and got these lines :

nau@labo:~/Bureau/threadtemplate$ make pd_linux 
cc -DPD -O2 -funroll-loops -fomit-frame-pointer -fPIC -Wall -W -Wshadow -Wstrict-prototypes -Wno-unused -Wno-parentheses -Wno-switch -I/usr/include -o threadtemplate.o -c threadtemplate.c
threadtemplate.c: In function ‘thread_read’:
threadtemplate.c:57:1: warning: no return statement in function returning non-void [-Wreturn-type]
ld -export_dynamic  -shared -o threadtemplate.pd_linux threadtemplate.o -lc -lpthread
ld: warning: cannot find entry symbol xport_dynamic; defaulting to 0000000000000740
strip --strip-unneeded threadtemplate.pd_linux
rm threadtemplate.o

and trying to create the object leads to a frozen pd ("signalling pd...." in console), same behaviour on a PC and on the cubie.
I put a usleep(1000000); at line 55, this lowered the cpu but froze pd the same.

Any hint ?
Thanks,

Nau

Makefile (line 79)
    ld --export-dynamic -shared -o $*.pd_linux $*.o -lc -lpthread

threadtemplate.c (line 49)
void *thread_read(void *w)

This external will eat 100% of a core because the while(1) doesn't do any real work. So yes you could add a clock_interval or a simple uspleep.

You should see in the console something like:

threadtemplate version 0.1
threadtemplate: thread 226944768 launched

Cheers~

this didn't work. I got these lines : ,
but the behaviour when creating a threadtemplate object in pd is the same, a freeze...
As I don't see any error I don't know from where to start.

edit : the sys_lock() and sys_unlock() calls are what freezes everything. Removing only the two of them framing the "thread blablah launched" post leads to a working external. But I guess I lost exactly what I was looking for at the same time!

Nau

Cheers~

The threaded version of my i2c reading external seems to work very well (it seems that in my case there's no need for any sys_lock() sys_unlock() ).

The previous version of the external was written with a method for incoming bangs, and was meant to output 4 values each time it was banged. The higher the frequency of the connected metro, the higher the "density" of clicks'n pops. This lead me to try a non-threaded version with no need of continuous banging... a single bang triggering a while(1) loop, just to see if the threading was really needed. But I never managed to do this...(signaling pd... again and again) Maybe the thread is exactly what one needs in order to create externals based on the infinite loop principle...

Now I'll have to find a way to adapt the external used to write thing onto my lcd (every letter written makes noises in the audio). As I read that opening/closing threads repeatedly is not very good I'll have to find a way to keep a thread open but still receive messages and bring them to the thread for writing characters, change position, cursor on/off etc.
Should be easy for a coder...which I am not

Thank you again,

Nau