That is possible, but 20ms is a lot of latency to add to an instrument.
I think generally, you'll be better off trying to reduce the latency
as much as possible, then use a smoothing algorithm to make things less
glitchy, though smoothing does add some latency.
As for dropping data, if you are using absolute axes, then dropped
extra data should fine for the most part since the data are just
position updates. Whatever you are controlling will end up in the same
place regardless if it got all of the messages in between. Of course,
button clicks would have to be handled so that the coords are outputted
with the click, and really fast movements could cause problems too when
data is dropped.
With relative axes like mice, its a totally different story, you need
to have all of the data in order to end up in the same place.
.hc
On Aug 28, 2005, at 7:39 PM, etienne deleflie wrote:
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
PD-list@iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
"Information wants to be free." -Stewart Brand