[PD] PD latency and timing accuracy with HID

[Hans-Christoph Steiner]

Very interesting, I'd love to see more info, like the numbers and the  
patch you used to run these tests.  Its a good start.

.hc

On Jul 19, 2006, at 10:35 AM, rubber glove wrote:

> 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
>
>
>


------------------------------------------------------------------------

If you are not part of the solution, you are part of the  
problem.        - Eldridge Cleaver


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20060720/15f752f9/attachment.htm>