OSCIn latencies

I’m trying to use the OSCIn CHOP to stream in data at 120hz. I set all the queue values to zero, hoping this would result in Touch not falling behind. I let the system run over night and when I came in it was at least 30 seconds behind the streaming data source. I’d much prefer that it simply discard missed packets, sampling the most recent value at all times. What settings can I use to insure that this happens?
Thanks,
Michael

Hi, Im currently going through the UDP code for some new functionality, but I’ll have a look at this.

Normally you set the max queue size to a small number,
and min and max target about one third, and two-thirds of that value.
It will automatically discard or repeat samples as necessary
in order to maintain that buffer size.

Have you tried again with small non-zero values?

I’ll try on my end,
Rob.

I tried again with small values in max target and max queue (.01) but it seemed to the make the latency show up even faster.

What are you using as a source (just to help us reproduce it)?

I’m using custom software that I wrote… (it’s ultimately data from a polhemus). I can write an app to generate data and transmit it if it will help.

Do you want to send us a standalone app that just generates periodic data? We’ll test with that if you wish, but we’ll first try reproducing your results with another OSC CHOP here.

Rob.

So, I wrote a standalone app that has its own timing loop, rather than relying upon the polhemus. I ran it for about 20 minutes and didn’t see any drift. Perhaps the polhemus transmits slightly greater than 120hz.

However, I’d think that even if the source did exceed the polling rate, setting the queue to be zero in length would mean that it would discard old data. If you create an OSCIn CHOP listening on port 6666, and set the polling rate to be less than 120hz (say, 60hz) and run my program, you will very quickly see the drift, regardless of how the queue variables are set.

The application can be downloaded here: relayit.net/?c=bb6FRmsCK5Kh … 9dQMdpLF2M

It includes the full source code, but you need only execute OSCTester\OSCTester\bin\Release\OSCTester.exe.

I think that I can mitigate this by oversampling (at 130hz rather than 120hz). I’ll let it run overnight to find out.

Hi mji.

Ive been able to confirm the drift on the OSC In CHOP with your standalone app and am working towards a solution.

In the meantime, we’ve completed an OSC In DAT that bypasses all queing and simply logs the last N messages as human-readable messages in a scrolling table format. This experiences no delay and simply processes the messages as they arrive.

I’ll let you know about the OSC CHOP In very soon.

Rob.

I just re-discovered the the original queining of this CHOP was not behaving as expected so it was internally disabled.
I will reimplement this very soon…

Your current options are to send the packets at a rate less than the frame rate of Touch, use the OSC In DAT, or await the new queining implementation, which I hope to implement shortly.

Thanks for your support.
Rob.

Okay, thanks. If I over-sample on the OSCIn chop (or under-sample on the source) it seems to
work reliably, so I’ll probably stick to this for now.

Thanks,
Michael

Sounds good Michael.
In the meantime, Ive now repaired the OSC In CHOP to properly maintain a queue. Look for it in a future release built after today’s date.

Cheers,
Rob.