12 octobre 2015

Nagle's algorithm workaround with websockets

Finally found a workaround for the random 200-300ms latency problem that would make MIDI playing practically useless from the app. I isolated the problem in this project : https://github.com/valsteen/socketio-nagle-experiment

Tried 3 approaches :
  • send ack from server after each client message
  • send filler packets each 10ms from client
  • send filler packets each 10ms from server
Conclusion on chrome for android, same wifi network:
  • without any strategy, pure client->server data, about 25% of the messages come with a latency > 50ms
  • with acks from server after each client message: unexpectedly gives no significant change
  • with filler packets each 10ms from server to client: actually great! 0% messages over 50ms. Average latency 4.47 which is great
  • filler packets from client to server each 10ms gives similar results
I applied this trick on the control surface app, with some fine-tuning because the browser tends to be overwhelmed if I send packets each 10ms. So the trick is this: if I use MIDI ( because I'm playing on an instrument widget or an USB MIDI device is plugged into the tablet ), I send filler packets each 50ms for maximum one second after the last MIDI note was sent. This tricks the algorithm which, I guess, sees those messages as being responses, triggering the immediate flush of the send buffer.

Here is how I fixed it in my app, if it can help anyone with a similar problem : https://github.com/valsteen/ableton-live-html5-control-surface/commit/43551ef5d32c7fe5a4af7e15b66d6ee7f2d1410b

08 octobre 2015

HTML5 Control surface : first public release

I just opened the sources, the project is on github.

For now it's mostly to allow peer review and for the sake of opening the sources. License is UNLICENSE, so go ahead, help yourself.

Later on I'll work on making it installable for everyone, but evolving from a proof of concept to a deployable and configurable software requires quite some time.

07 octobre 2015

Project update: application state as an aurelia template


The last important design decision I had to take is how to express dependencies between widgets and live controls or other widgets without relying on code. In other words, some kind of "save state".

Instead of creating yet another json state that itself creates objects and layout, I figured that directly using aurelia templates actually allows me to express those dependencies. Live's parameters happen to be custom tags without any view, but that can then be bound to visible and controllable widgets.


Hopefully it won't become a tag soup and stay focussed on layout and dependencies. Additional behavior can always be declared in the ViewModel or as new custom tags.

This is one of the last thing I wanted to implement before the first public release, so stay tuned, it's coming soon.