search

IDMIL / T-Stick

T-Stick Digital Musical Instrument (DMI)
4 stars 8 forks source link

Call mpr_dev_update_maps() once all signals have been updated. #44

Open malloch opened 9 months ago

malloch commented 9 months ago

This change will cause libmapper to send updates to mapped peers immediately rather than waiting for the next call to mpr_dev_poll().

aburt2 commented 8 months ago

tested with the esp32s3, just needs resolve conflicts with the main branch before merging

malloch commented 8 months ago

Would be interesting to re-run the latency & throughput benchmarks once this PR and the liblo updates merged...

aburt2 commented 8 months ago

On the branch I'm working on to add support for 5G T-Sticks I have added this PR already, under good network conditions & PC connected to ethernet to router, OSC throughput is between 104-106Hz, with round-trip latency ranging from 2ms - 13ms

aburt2 commented 8 months ago

under poor network conditions (ie: using my phone as an access point) the round trip latency can range from 20ms to the ESP32 doesn't respond to pings once it gets that high, libmapper does not work (ESP32 is not visible) but you can still maintain a 104-106Hz throughput via OSC just a very delayed 104Hz

malloch commented 8 months ago

The "ESP32 not visible to libmapper" condition is 100% due to dropped packets. I have a branch where I'm integrating TCP for administrative traffic (which should resolve visibility) but the dropped packets are still very problematic. Some of the signals generated by the T-Stick (e.g. jabs) are ballistic/event-based so a single dropped packet can have bad consequences!

Out of curiosity, are the latency/throughput tests done with both libmapper signals and non-libmapper OSC running?

aburt2 commented 8 months ago

yes they are, still need to test them individually, what I don't get, is if I'm dropping packets shouldn't I also experience a drop in the OSC throughput as well

malloch commented 6 months ago

yes they are, still need to test them individually, what I don't get, is if I'm dropping packets shouldn't I also experience a drop in the OSC throughput as well

There would be a drop compared to transmitted packets but throughput might still increase if the drops are intermittent. It might make sense to transmit an incremented counter and check the received values.

aburt2 commented 2 months ago

@malloch I've tested this before between 2 ESP32 Boards and got around 2-3% packet loss when connected to a router with no other devices on the network and 30-50% packet loss when connected to the rasberry pi 4 (T-Tree at IDMIL).

Even the best case scenario has much higher packet loss in comparison to OSC which was 0.01%-0.05% packet loss under similar conditions. I'll test with this firmware on the ESP32S3 and see the packet loss when connecting to my laptop.

malloch commented 2 months ago

@aburt2 thanks for testing this! I have a few questions...

  1. Which version of libmapper are you using? (there have been some recent optimizations)
  2. Was this testing done with the call to mpr_dev_update_maps() included?
  3. I notice the call to vTaskDelay() in loop() is commented out – is there another delay being called somewhere in the function or are you just running loop() as fast as possible?
  4. the OSC bundle sizes created by libmapper and plain-OSC are likely different since updates to brush/multibrush, rub/multirub, shake, jab, count, tap/dtap/ttap, and battery are gated for plain-OSC but always included in libmapper updates. Perhaps the OSC bundle created by libmapper is becoming large enough to cause problems with the ESP32 networking stack? If you have time could you add the same update gating to the mpr_sig_set_value() calls and re-test?

Thanks!

aburt2 commented 1 month ago

Hello Joe to answer your questions.

  1. The ESP32 boards are using the libmapper-arduino library which is still using libmapper v2.3. I can't remember what version of libmapper I was using on my laptop it was at least libmapper v2.4.
  2. There was no delay the messages were sent as fast as possible.

For your other two questions, this initial test was done just between two esp32 boards sending a counter. I haven't gotten around to testing the mpr_dev_update_maps() call or on the T-Stick just yet. Just wanted to give an initial update. I'll do what you suggested in point 4 when testing on a 5G T-Stick.

aburt2 commented 1 month ago

@malloch

malloch commented 1 month ago

Thanks @aburt2 for the information – could you share the esp32 firmware you used for the test? I'd love to replicate & debug this issue.

aburt2 commented 1 month ago

I had this firmware running on the ESP32 boards: https://github.com/aburt2/TStick-tester/tree/main/firmware/Wifi%20Testing%20(Libmapper)

I read the data via the serial monitor and analysed it.