[jm_l]

Since webrtc uses UDP jitter is occasionally an issue. If you monitor the ping on the site you'll likely see occasional jumps to 100-200ms every once in a while. These can cause irregularities in the rhythms but for the most part you can still make out the phrase even when there's jitter. (I think this is kind of like how we can read those scrambled word sentences because we read not letter-by-letter, but word-by-word.)

For a jitterlesss demo you can also check out piano.jminjie.com (central server, not p2p), where I've introduced an artificial delay so that the notes can be snet with timing info, and scheduled ahead of time to avoid jitter.

Latency can also impede a smooth jamming experience, but seems to be manageable in general when it's under 20ms one-way delay (I have been able to achieve this on a wired connection at 50 miles distance in the middle of the day). There's also relationship between bpm of the song and acceptable latency similar to the concept behind sampling frequencies (https://en.wikipedia.org/wiki/Sampling_(signal_processing)). The faster you're playing, the more latency matters.

[radiowave]

Given that MIDI expects 100% reliable delivery, I'm curious to know if there's any special technique used here to prevent (e.g.) intermittent packet loss causing stuck notes.

[jm_l]

I'm not sending all the MIDI data, just a simple 3-integer representation:

1. command 2. note (or byte1) 3. velocity (or byte2)

From testing you don't tend to get stuck notes (though in theory this could happen if a note-up command was lost forever and never sent), though you do see some jitter.