[PD] PD latency and timing accuracy with HID

[rubber glove]

I managed to run some tests on the HID timing.

The contestants were:
-regular HID object in OS X
-regular HID object in OS X with blocksize=64
-dissected HID object in OS X
   (i basically tore the read functions out of the hid code, and put them in
my own object, which was recording the values. I did a messy, quick job of
it, but...)
-ctlin midi object in os x
-regular HID object in Linux

the winner, with < 4 ms of timing error was:

linux... I was short on time in the lab (getting the eMac machines booting
off the livecd took a bit of time), so I wasn't able to try out different
latency settings, or try the midi controller in linux.

the others were all approximately the same, at around or just above a 10 ms
spread in timing offsets (I don't have the numbers in front of me.... but
One interesting thing is the standard deviation. it seems like mostly the
timing error is very close to a mean value, then periodically, there will be
a value that is way off, which throws off the average. I haven't made enough
measurements to see if there is some sort of periodicity to those 'way off'
readings, maybe due to some process switching/memory management by the
kernel?)

the smaller blocksize did slightly better than the default setting, the
dissected object did slightly better than that...
so I would hazard the guess that the delays due to control message passing
are not a huge contribution.

and for some reason, the midi object did even worse than the hid object. not
at all sure why that is, but it could have to do with the midi devices I was
using - who knows.

One thing I realize I should have done is try pd in os x as superuser, as
this may give the process a higher priority? I ran sudo pd in linux to have
access to the hid devices...

I'm not sure how much more experimentation I will be doing on this, as they
are pretty satisfied with < 5 ms error and probably won't pay me to just
play around with their expensive timing test equipment....


-martin

On 7/5/06, Hans-Christoph Steiner <hans at eds.org> wrote:
>
>
> On Jul 4, 2006, at 10:08 AM, rubber glove wrote:
>
>
> 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.
>
>
> Aha... that makes sense to me. So it is not so much just the 'hardware to
> pd' step, but also the control message passing within PD that is throwing
> off the timing here.
>
>
>
> > 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.
>
>
> I think I am basically stuck with USB no matter how I go, as the computers
> involved here are all eMacs. Using midi or serial would involve a USB
> interface anyway.
>
>
>
> > 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.
>
>
> That's an interesting possibility, but I am only really using the button
> clicking as a simple way to test the timing. In actual use, the input would
> be a range of values from the rotary encoder of the knob... converting that
> into audio and back into numerical values seems altogether too complicated
> (frequency modulation?)
>
> However, it brings to mind other possibilities:
>
> If I modify the HID object to convert it into a signal-based external,
> then pass the values as signals, the timing should be much tighter? This
> seems to have the advantage that the input values will always be
> automatically lined up with the audio, no matter what the latency is set to.
>
>
> Alternatively, If I incorporate the HID code into my external, and process
> the knob events myself, I would avoid any additional timing errors and be
> left with only the jitter inherent to the device, no?
>
> Thanks much for the info...
>
>
> I would also like to see the [hid] code be as low jitter as possible.  I
> haven't had a chance to measure it yet tho.  Unless things are really taxing
> the CPU, I don't think that the Pd messaging will cause more than ~1.5ms of
> jitter (1 block of 64 samples divided by 44100 samples).  Perhaps running Pd
> at 96KHz or 192KHz would reduce that jitter, provided that the block size
> remains 64.
>
> I think that the first step is to devise some tests to find the true
> source of the jitter.  I did some quick searches about USB HID jitter and
> didn't find much, except this:
>
> http://elists.resynthesize.com/max-msp/2005/08/1515529/
>
> It seems that this person thinks that Mac OS X's USB MIDI driver has lower
> jitter than the USB HID driver.  Ultimately, if we find the source of the
> problem, I would like to include it in the next version of [hid].
>
> .hc
>
>
> ------------------------------------------------------------------------
>
> Using ReBirth is like trying to play an 808 with a long stick.    -David
> Zicarelli
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20060719/78729f10/attachment.htm>