rubber glove wrote:
Hi:
I am currently developing a system using PD will record users' responses to audio and video files. Essentially, the subject (this is for psychology experiments) will turn a knob indicating their like/dislike (or whatnot) of an audio or video file. For input, I am trying to use a Griffin PowerMate knob with the HID object ( http://at.or.at/hans/pd/hid.html ). I have written a simple external which keeps track of timing (using a timer from flext), and writes the data to a text file.
Timing is important to the researcher. She has a system called the 'black box toolkit' http://www.blackboxtoolkit.co.uk/ and I have done some tests to determine the latency and timing accuracy. For the test, I have a puredata playing an audio file consisting of noise bursts at regular intervals, while I periodically press the knob. The 'Black Box' listens to the sound output and is also wired into the knob. I expected to see the values recorded by my PD external to be offset by 50ms (the latency setting) in comparison to the Black Box recorded values, but I was a bit surprised to see the offset vary between 48 and 62 ms (especially the 48ms!), which gives an uncertainty of 14ms. I was hoping for less than 10ms. The latency is not a problem at all, I am more concerned with accuracy and consistency (so that I can simply compensate for the latency)
Where I should begin to try to improve this uncertainty (would I call it jitter?). What are the likely and most significant factors? Currently I have only tried the test under OS X, with the powermate knob. I will try again under linux, when I can get a LiveCD that will install easily on the old eMacs present in the lab. I will also try with a midi controller, when I find one that I don't mind soldering some test leads onto.
Is the timing error most likely in PD, the HID object, the knob hardware (I know, probably), or just usb? Would a midi controller knob be expected to perform better? And really, what would be the limit of this kind of timing accuracy? Is 10ms as good as I can hope for?
The main factor seems to be that pd only processes control messages in between audio frames. Reducing the audio latency seems to bring the jitter down to about 5ms but no further when I try it on WinXP or Linux. The processor speed is not a factor, since I get roughly the same jitter with a 200MHz processor as a 2GHz. Tracking it on a scope using comport or midi objects, the jitter seems to be bimodal: there is a jitter of about 1ms superimposed on a 5ms frame. If the GUI is doing a lot, things get bumped to the next frame, also if you're moving the mouse or running other programs at the same time the OS will steal time for those processes too. I would expect USB to add more jitter, as it passes through a more complex path than serial or MIDI data before being handed to pd. If you need better timing, why not record the audio into one channel along with the button on the other channel? There is essentially no jitter with the audio stream because it passes through the sound hardware at a fixed rate. The button could just emit a click when pressed. Then you have no jitter beyond the time it takes to push the button.
Martin