Status: proposed experiments only. No app, device, or recording is running as a result of this note. The latest measured scheduled-MIDI trial ended with both symptoms present, and the app was stopped afterward. Keep the accepted 48 kHz / 512-frame baseline for SmartGrid trials.
The normal-DSP-to-tone substitution changed measured callback work from approximately 4.5 ms to 0.020 ms and removed DSP-driven MIDI, UI/state, and I/O work. Its 9.44-minute settled tone interval had zero MAYA transaction failures and zero long callback gaps, whereas comparison normal-DSP intervals had 30 failures in 13.15 minutes with inputs on, 10 in 2.99 minutes with app inputs off, and 7 in 6.84 minutes with app inputs off and WRLD.BLDR disconnected then attached. The tone later reproduced periodic analog corruption. This is evidence that one or more activities removed by tone mode affect the sporadic-failure rate; it does not identify which, or show that tone mode prevents failures in general. See the workload contrast.
The MIDI sender still calls JUCE startRealtimeThread on iOS with a requested 2 ms period, 0.05 ms computation, and 1 ms constraint, then sleeps 2 ms per loop. The requested withPriority(10) number is not used by the local Darwin implementation. The startup line’s literal real_time=1 reports the request, not an independently queried effective Mach policy. The measured trial confirms the worker ran at about 499 iterations/s and submitted native CoreMIDI packets. The earlier worker-off 16-minute run had 39 matched USB/callback/analog failures and a dense periodic episode while the worker stayed stopped, so that worker and its real-time policy are not necessary for either symptom. This does not exclude a rate-modifying interaction in other conditions. Worker-off result; scheduled-MIDI result.
The approximately seven app threads are not an unusual count by themselves. Thread scheduling class, runnable/waiting state, wakeup rate, what each worker does, and whether it holds a resource needed by audio are testable variables. In one captured long failure, the audio thread finished about 4.6 ms before the USB error and was waiting for the next service wakeup; it ran within microseconds once woken after recovery. The sampled hub-port/xHCI threads also had only microsecond wake-to-run delays. That event does not support simple UI/MIDI starvation of an already-runnable audio callback as the immediate cause. Native timing.
Build a continuously sounding Drambo patch using enough active voices, modulation, and effects to produce approximately 4–5 ms of audio rendering per 512-frame block at 48 kHz (about 40–50% of the 10.667 ms block interval). AUM-hosted Drambo AUv3 offers measured per-node render time in its Node Statistics Time/Max views; a standalone Drambo run is a distinct host-path control and needs its own timing estimate, rather than assuming the AUM reading carries over. Drambo’s visible CPU bars alone are an approximate load indicator. AUM statistics; Drambo manual.
Hold MAYA, Satechi hub, PD, attached WRLD.BLDR, Wi-Fi state, output route, actual sample rate and buffer size, iPad thermal state/history, and recording path as close to SmartGrid as possible. Verify accepted settings rather than only requests. Record K-Mix analog output and iPad USB/HAL logs for at least one hour, since SmartGrid has had clean stretches over 30 minutes; separately score long transaction/restart/callback gaps and shorter periodic holes. A clean loaded control would strengthen an app/backend-specific explanation without proving it; errors in the loaded control would weaken any claim that SmartGrid code is necessary. Earlier SonoBus and Drambo controls were useful but had lower or unmeasured render load, differing buffer/thermal histories, or short/no analog coverage.
Use independent test modes in the same instrumented build, preserving 48 kHz/512, output routing, diagnostics and topology. Start with (A) current tone-only, (B) tone plus synthetic render work calibrated to the normal callback duration, (C) full normal engine processing and side effects but tone substituted only at the returned output, and (D) normal output. If B promotes USB failures, generic render occupancy or its power/scheduling consequences gain plausibility. If B stays clean but C promotes them, something specific to the engine’s memory access or downstream work becomes more likely. These are interpretations of repeated paired runs, not guarantees from one quiet exposure. A synthetic busy loop does not perfectly reproduce engine memory traffic or OS power policy. Keep the long USB-restart symptom and periodic analog symptom as separate endpoints.
Further worker removal should target a demonstrated dependency. MIDI worker-off already reproduced both symptoms; UI rendering-off also reproduced both. The 100-microsecond I/O polling worker remains unisolated, but its count/rate alone is a weaker lead than the large normal-versus-tone workload contrast and the measured loaded-app control.
The existing iOS build already compiles an app-local patched JUCE 8.0.15 audio module. Eliminating exploratory rate requests reproduced both symptoms; single-start initialization also retained the sporadic USB failures, although no dense periodic burst was observed in that trial. SonoBus’s public native RemoteIO implementation is nearly the same as JUCE’s; no missing USB retry or different rendering strategy was found. Thus a native backend that deliberately duplicates JUCE’s API sequence and buffer handling has little diagnostic value. First identify a concrete behavior to change or measure, and patch the app-local JUCE copy directly when possible. Generated-module patch; explicit-rate result; single-start result; SonoBus source comparison.
AudioDeviceManager/AudioSourcePlayer with a minimal native RemoteIO output unit only to test a specified divergent setup or callback behavior. This retains iPadOS’s audio server and USB driver; absent such a difference, modify or instrument the JUCE module instead. A different wrapper also requires careful matching of accepted format, channel mapping and startup sequence before comparing outcomes.AVAudioSourceNode inside AVAudioEngine. Apple owns more of the graph; mixing/conversion and channel mapping may also change, so a clean result has more possible explanations. Apple source-node sample.All three still use the iPad’s system audio and USB path to reach the MAYA. They change which app layer configures and feeds that path; they do not grant direct control over individual USB audio transactions. A Mac-hosted rig or network audio to a separate host would bypass the iPad USB output path entirely, but changes the live-system architecture and latency.