[PD-dev] outlet_anything() & threads

Christian Klippel ck at mamalala.de
Tue May 16 17:52:01 CEST 2006


hi,

Am Montag, 15. Mai 2006 13:42 schrieb Hans-Christoph Steiner:
> This sounds like you are wrtiing a [libusb] object, which would be very
> nice.
>

not directly a general libusb object, altough some of the stuff may be reused 
for that...

> I have a different suggestion, related to the question I just posted.
> What about not using a thread at all, and instead having the first
> instance executed get the data from the USB bus, and stick it in an array.
> Then every other instance set to read the same device will just output the
> data from that array.  This relies on the OS doing some buffering, which
> in the case of HID, GNU/Linux, Mac OS X, and Windows already do.
>

well, first, there is more on usb than just hid. second, what about latency? 
if you dont use a thread, you can only poll the device at a defined 
intervall. if the "master" object is the last in the chain to be scheduled, 
the "slaves" can update on the next slice only, adding a lag of one "tick".
next, how to syncronize? i see the same problems as with using a single thread 
an a single/multiple listener(s). what about the following:

the object has a "static char slave" which is 0 on the first instance, and 1 
for each other. the object itself has a thread that constantly polls the usb 
bus. the master calls a "processsPacket(char *data)" function when data 
arrives, issuing a lock before the call and unlock after it. (note that the 
lock only happens when new data arrives....) or a similar thing, of course.
if an instance detects that it is a slave, it just doesnt start the thread, 
but instead registers itself to a small "list of listeners" within the 
master. the master then calls the processPacket() function for each 
registered listener. of course, slaves have to unregister upon deletion. 
also, if the master gets deleted, it should set the first slave in that list 
as the new master.

what do you think about that?

on a related matter: somehow libusb seems to be unstable/buggy on windows. i 
have some code here, using bulk read's and write's, that works just fine on 
linux, but is almost non-working on windows. the data drips in maybe one 
packet each second or two, with only -116 error inbetween. also, the formerly 
working stuff for the multio starts to make these problems on windows now. 
and that even without any changes to the firmware or the pd-object...

so we should definitely investigate that issue first.... do you have a pic 
programmer  and a usb pic at hand? if so, contact me off-list so we can setup 
a little test-bench for that purpose ....

oh, and a last thing: how do you intend to handle hid devices when they are 
claimed by some other driver already? there are syscalls at least in linux to 
detach devices from a driver by an external task. but imagine if, by 
accident, someone does that with the systems mouse & keyboard?

> .hc
>

greets,

chris

> On Tue, 2 May 2006, Christian Klippel wrote:
> > hi all,
> >
> > can anyone confirm that using outlet_anything() inside a thread is safe?
> > just wrote a little object that reads a usb device in a thread, and send
> > to the outlets from there directly via outlet_anything() .... so far it
> > doesnt crash or anything, it just works (of course there are some objects
> > connected to them), altough its only a few route's and
> > slider/bangs/toggles connected.
> >
> > since the thing does peak detection, there is a hell lot of toggles
> > comming in, plus some faders ... so its really quite some traffic ....
> >
> > but i want to make sure that i can do it that way, and not that there are
> > any surprises later when doing that ...
> >
> > thanks,
> >
> > chris
> >
> >
> > _______________________________________________
> > PD-dev mailing list
> > PD-dev at iem.at
> > http://lists.puredata.info/listinfo/pd-dev
>
>  	zen
>  	   \
>  	    \
>  	     \





More information about the Pd-dev mailing list