Hi all,
I am currently working on a threaded implementation of a wiimote external. The reason I was hoping threaded design would help is to avoid dropped samples when issuing commands to wiimote (e.g. rumble/led status change). So far, it seems that reading from wiimote, no matter how fast, has no impact on the audio thread. However, writing even when such action is generated through a separate thread seems to cause drop-outs in the audio thread. The external (which was not originally built by me) uses cwiid to communicate with wiimotes and my understanding is that cwiid is heavily threaded in and of itself. An example of a threaded code is below:
void *cwiid_pthread2_setRumble(void *ptr)
{
threadedFunctionParams *rPars = (threadedFunctionParams*)ptr;
t_wiimote *x = rPars->wiimote;
t_floatarg f = rPars->f;
if (x->connected)
{
if (cwiid_command(x->wiimote, CWIID_CMD_RUMBLE, f)) post("wiiremote
error: problem setting rumble."); } }
void cwiid_pthread_setRumble(t_wiimote *x, t_floatarg f)
{
threadedFunctionParams rPars;
rPars.wiimote = x;
rPars.f = f;
pthread_t thread;
int iret1;
iret1 = pthread_create( &thread, NULL, cwiid_pthread2_setRumble,
(void*) &rPars); pthread_join(thread, NULL); }
So, cwiid_pthread_setRumble is called from Pd and then it in turn creates a thread that sends info to cwiid library against which the external is linked. I am confused as to why the new thread once it has been created still affects the Pd's audio thread. Any ideas?
Best wishes,
Ico