This setup is strictly experimental — not a public release. It focuses on measuring event latency, jitter, and buffer performance during extended sessions.

Test Setup

• Android Versions: 7.0 → 14

• Devices: 3–8 GB RAM, typical mid-range models

• MIDI Interface: USB OTG

• Browser: Chrome (stable)

• Load Scenarios: idle vs moderate background processes

Testing Methodology

• External metronome at 120 BPM as timing reference

• Capture timestamps via JavaScript callbacks

• Record 500–1000 event cycles per test

• Analyze median latency and variance

Observations

Baseline / Idle

• Average latency: 9–13 ms

• Jitter range: ±3–5 ms

• UI performance stable at 60 FPS

Under Background Load

• Latency spikes: 17–22 ms on Android 7–9

• Minor jitter during USB reauthorization

• Drift visible after idle periods over 15–20 minutes

Android 11+ Improvements

• Event buffer consistency significantly better

• Fewer spikes and lower overall drift

Additional Insights

• Older Android kernels seem sensitive to USB polling intervals

• Chrome stable handles event queues more predictably than some Chromium forks

• Resetting USB authorization occasionally improves long-session stability

Open Questions / Discussion Points

• Any experience profiling Web MIDI timing on Android 7 or 8 with high-resolution instruments?

• Recommended buffering strategies to keep drift below 10 ms for long sessions?

• Known OTG limitations for mid-range devices under sustained MIDI playback?

• Best practices for maintaining stable Web MIDI sessions over 30–60 minutes on mobile?

• Benchmark comparisons from real-world 188CM setups outside controlled lab conditions?

Would love to hear insights or shared experiences from developers working with Web MIDI on Android — especially if you’ve tested long-duration sessions using 188CM environments.

The tests were conducted using an internal benchmark harness (code name: <a href=" removed link " target="_blank" rel="noopener">VN68 Lab, 2026 iteration), designed strictly for event timing diagnostics and routing simulation.

This is not a public software release — it is simply a controlled test environment used to observe real-time MIDI behavior under varying system conditions.

Environment

• Android 8–13 devices

• 3GB–6GB RAM range

• USB-MIDI via OTG

• Chrome (stable channel)

• Web MIDI API enabled

Observed Behavior

After approximately 15–25 minutes of inactivity:

• Initial incoming MIDI events show irregular timestamp offsets

• Short burst of jitter (~15–30ms)

• Stabilization typically occurs after 5–8 event cycles

The issue does not occur during continuous playback.

Interestingly, when replicating the same scenario inside the VN68 test harness, the behavior appears more pronounced on Android 8–9 compared to Android 11+.

Hypotheses

Possible contributing factors:

• OTG polling interval reset after low-power state

• Android kernel power management behavior

• Browser event queue reactivation delay

• USB permission reinitialization timing

Experiments Conducted

• Manually reinitializing USB permission → partially reduces first-spike latency

• Keeping a low-frequency MIDI clock active → reduces drift occurrence

• Disabling battery optimization → inconsistent improvement

Questions for the Community

• Has anyone observed OTG polling instability after extended idle?

• Are there known Android kernel behaviors affecting USB resume timing?

• Would maintaining a lightweight keep-alive clock be considered best practice?

• Any documented Web MIDI scheduling caveats on pre-Android 10 devices?

Interested in real-world implementation insights beyond lab conditions.

Appreciate any shared observations.

This is not a commercial release, but rather a controlled environment used to simulate multi-channel MIDI routing and real-time interaction.

Test Environment

Android

• Android 6.0 – 13

• 2GB–6GB RAM devices

• USB-MIDI via OTG

• Chrome (latest stable)

iOS

• iOS 12+

• CoreMIDI compatible devices

• Safari (latest)

Web

• Web MIDI API enabled

• PWA mode with offline cache

Observed Performance Metrics

Under standard conditions:

• Event processing latency: 8–14ms (USB-MIDI direct input)

• UI rendering: Stable 60FPS on mid-range devices

• Multi-channel routing: No noticeable jitter under 4-channel simulation

• Session encryption: AES-256 handshake (for preset sync validation testing)

Latency variance appears to increase when background processes are active, especially on Android 6–8 devices.

Installation Context (Test Build)

Android test build (~75MB APK):

• Signed package (SHA-256 checksum verified)

• Requires network + storage permissions

• USB device authorization required at runtime

iOS deployment:

• Distributed via TestFlight

• CoreMIDI authorization on first launch

Web fallback:

• Progressive Web App mode

• Add-to-home-screen supported

• Offline event logging enabled

Interesting Findings

1. Web MIDI performance on Android 6–8 shows greater timing drift compared to Android 10+.

2. Chrome seems to manage buffer scheduling more consistently than some Chromium-based alternatives.

3. USB permission reinitialization sometimes reduces latency spikes after extended idle time.

Open Questions for the Community

• Has anyone benchmarked Web MIDI API latency across older Android devices?

• Are there recommended buffer strategies to reduce 10–15ms fluctuation?

• Any known limitations of OTG MIDI handling on low-RAM devices?

• Best practices for stabilizing event timing in PWA environments?

I’m particularly interested in real-world field testing beyond lab measurements.

Appreciate any insight or shared benchmark data.

In M2-104-UM_v1-1-2_UMP_and_MIDI_2-0_Protocol_Specification of section 7.4.13 Registered Controller (RPN) for Sensitivity of Per-Note Pitch Bend (pp.57), the last sentence:

However, this RPN has no function within the MIDI 1.0 Protocol.

seems to me, 1.0 is typo of 2.0. Is this correct?

Thanks,
M. Suzuki

Recently, I took a little dive into the world of MIDI by programming a Raspberry Pi Pico (rp2040) to send messages like NoteOn, NoteOff, ControlChange, … to a PC via USB. My DAW (LMMS) is able to receive these messages and play notes or move sliders.

In order to let the DAW change the slider value of a motorised slider, the DAW needs to send messages to the device. Does it do that automaticly or does the device need to send a request? What messages are they? Are they ControlChange-messages or a completely ther format?

Thanks for further advice.

Yours faithfully

J.

90    22    7F    1  Bb 1 Note On
80    22    40    1  Bb 1 Note Off

Another one (FATAR 49 keyboard) sends:

90    2B    72    1  G  2 Note On               
90    2B    00    1  G  2 Note Off   

What can be said in favor of the one or the other method?