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