[PD] HID and timestamp

[etienne deleflie]

I'm not sure if this logic is correct, but would it not be possible to 
introduce a delay that is the size of the maximum number of messages 
sent in one chunk?

for example. If the system spits out on average 4 messages together 
(every 20 msecs).... then one could introduce a 20msec delay, and then  
use the 4 messages' timestamp to define a smaller delay to spit out the 
individual messages evenly over that 20msec.

It sounds as though the logic forced by the constraints of the system 
will be: introduce a delay and get a smooth (in time) set of messages, 
or have no delay and lose some of the data.

etienne

>hello,
>
>Am Sonntag 28 August 2005 23:32 schrieb Hans-Christoph Steiner:
>  
>
>>Yes, this is an area that needs some work, but its not an easy problem
>>unfortunately.  Have you tried setting the poll time to 2ms?  That's
>>about as fast as it can go.  Basically, you can't expect smooth data
>>out of a device or sensor even it the values were coming out one at a
>>time.  I recommend smoothing the output using averaging or low-pass
>>filtering.  Try [hid_average] for example.
>>
>>    
>>
>
>one problem with that is that the actual polling intervall is somewhat defined 
>inside the device itself.
>an usb endpoint descriptor contains the _maximum_ intervall period time. this 
>is the guaranteed period after which the device gets polled.
>
>however, this time can also be shorter if possible. the usb spec say that this 
>is really only the maximum intervall. but is not guaranteed to be shorter, 
>anyways.
>
>now if you have multiple messages that the device has to send, they will be 
>sent one after each other as long as the bus active for that device.
>
>(on a sidenote:
>i have found out that i can be that when a device is polled too fast, the 
>output gets even slower! i am not sure if that is due to libusb i use, or if 
>that is a general problem on linux.)
>
>in case of multi-axis devices, like mice, tablets, etc..., it can be that two 
>messages come directly after each other. usually that is as fast the device 
>can send events, and stops only when either there are no more messages or the 
>current time-slice on the usb is over and the next device gets polled (by usb 
>itself). 
>
>this brings me to:
>
>  
>
>>Going forward, it would be a good idea for [hid] to output one value
>>per cycle when polling absolute axes like what the Wacom gives you.
>>    
>>
>
>what do you do when you have multiple messages at once in the incomming 
>stream? discard all exept the first/last? 
>
>i think, if a bunch of messages appears at once, they should be sent at once 
>(in the order they are read).
>
>  
>
>>Its on the TODO list, but I have had little time recently to work on
>>[hid] since I am working numerous freelance jobs to pay the bills.  I
>>have applied for a 1 year fellowship to work on this, let's hope I get
>>it.
>>
>>    
>>
>
>wish you best luck!
>
>  
>
>>.hc
>>
>>    
>>
>
>greetings,
>
>chris
>
>
>_______________________________________________
>PD-list at iem.at mailing list
>UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
>
>
>  
>