Hello,
I'm getting stuttering data output from my wacom tablet using the latest HID.
stuttering .... I put a [timer] on the output of the abs X position messages, and discovered that the HID object spits out around 4 X position messages in one go ..... i.e. without any time delay.
I've got a patch where you can really hear this (it is using a vd~ to do a dopler effect on ambisonic spatialisation stuff).... if I do a straight consistent line on my Wacom, the output comes out all stuttery and spitty.... and I have traced the reason to the fact that (around) 4 messages get spat out at once. NOTE: changeing the poll value of the HID object does not aleviate the problem.
I concluded that this is what the timestamp (inlcuded in the USB messages) is for.... right? .......... the USB driver _or_ the USB device( I dont know about these things) instantaneously spits out 4 X positions and includes the timestamp between them.... so it should be (by using those timestamps) possible to get PureData to space out those 4 messages in time and hence get a smooth data line.
do I sound like I dont know what I am talking about? does anyone want to educate me?
Etienne
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.
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.
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.
.hc
On Aug 27, 2005, at 1:50 AM, etienne deleflie wrote:
Hello,
I'm getting stuttering data output from my wacom tablet using the
latest HID.stuttering .... I put a [timer] on the output of the abs X position
messages, and discovered that the HID object spits out around 4 X
position messages in one go ..... i.e. without any time delay.I've got a patch where you can really hear this (it is using a vd~ to
do a dopler effect on ambisonic spatialisation stuff).... if I do a
straight consistent line on my Wacom, the output comes out all
stuttery and spitty.... and I have traced the reason to the fact that
(around) 4 messages get spat out at once. NOTE: changeing the poll
value of the HID object does not aleviate the problem.I concluded that this is what the timestamp (inlcuded in the USB
messages) is for.... right? .......... the USB driver _or_ the USB
device( I dont know about these things) instantaneously spits out 4 X
positions and includes the timestamp between them.... so it should be
(by using those timestamps) possible to get PureData to space out
those 4 messages in time and hence get a smooth data line.do I sound like I dont know what I am talking about? does anyone want
to educate me?Etienne
PD-list@iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
As we enjoy great advantages from inventions of others, we should be
glad of an opportunity to serve others by any invention of ours; and
this we should do freely and generously.
- Benjamin Franklin
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
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
hello etienne,
Am Montag 29 August 2005 01:39 schrieb 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.
and what if a coordinate changes happens, and then a button click, which is sent "in one block" to the host? that would introduce a delay between these two that might not be wanted. or if the x and y coordinate changes at once ...
but of course, it may be better than just spilling out the whole batch of messages .... but while waiting a milisecond to send the next event, there may be 2 other have arrived already ..... what then? and with the dsp running at 44.1 khz, with a blocksize of 64, the time between two reads is always a little bit bigger than 1 ms.....
etienne
greets,
chris
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
-
Christian Klippel -
etienne deleflie -
Hans-Christoph Steiner