[PD] PD latency and timing accuracy with HID

[Hans-Christoph Steiner]

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/20060705/c6d98924/attachment.htm>