During recent mobile Web MIDI testing, I encountered a recurring timing instability after extended idle sessions on several Android devices.

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.