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@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list