The tone substitution is strong evidence that the sporadic failure rate depends on something changed by bypassing normal processing. It does not yet identify that dependency. The earlier reset-masking explanation addresses why periodic damage could emerge; it leaves the disappearance of hard failures unexplained.
This follow-up on September 10 uses existing data and source. It makes no app, deployment, or device changes. Exact counts and callback checks are in tone-workload-contrast.json.
| Stable logged playback | Minutes | MAYA transaction failures | Reported zero-length input transfers |
|---|---|---|---|
| Normal processing, 48 kHz / 512, inputs enabled | 13.15 | 30 | 2 |
| Normal processing, 48 kHz / 512, output only | 2.99 | 10 | 6 |
| Normal processing, output only, controller absent then connected | 6.84 | 7 | 0 |
| Tone, output only, same requested rate/block size | 9.44 | 0 | 26 |
Counts use the previously defined stable system-log intervals, including playback before analog capture begins. They exclude startup and final disconnect. All 44 failures occurring within the three normal runs’ analog captures match long dropouts and native xrun increases. The tone also has zero such long callback gaps, native xrun increases, and playback restarts. Its missing sporadic failures are consequently not just an auditory detection difference caused by a quieter tone.
The event counts strongly motivate testing a processing-dependent effect. They are not a formal common-rate probability estimate: runs are sequential and bursty, startup/peripheral state is not randomized, and an earlier normal-processing SmartGrid run also remained free of transaction failures for about 2.5 minutes. One tone trial cannot prove normal processing is necessary for every hard failure or that bypassing it reliably prevents them.
What the intervention actually changed. A direct diff of the preserved pre-tone header and the installed tone source confirms that the normal m_nonagon.Process(bufferToFill, MakeIOInfo()) call was replaced by an all-channel, continuous 1 kHz sine. The JUCE initialization code, requested 48 kHz / 512 frames, output-only setting and worker construction were not changed by that edit. Source equality is not proof of identical hidden runtime startup state.
The replacement removed several experimentally inseparable activities: normal synthesis and its memory accesses; sample/control-frame advancement; processing-driven MIDI production and output; UI/scope state production; I/O acknowledgements and tasks driven by processing. It also changed the delivered signal’s level, spectrum and channel content. It reduced typical measured callback work from about 4.5 ms to 0.020 ms, roughly 225-fold. The MIDI and I/O polling loops still exist, but work arriving at them and their interaction with the render workload can differ. Their mere continued existence is not a useful explanation of the contrast by itself.
Physical WRLD.BLDR traffic is not required: six matched failures occurred while the controller was absent. Removing app input consumption also failed to remove sporadic failures. These prior controls narrow the dependency but leave normal processing, its other effects and the signal itself unseparated.
New preceding-callback check. Across all 44 captured sporadic failures, the immediately preceding measured processing call took 3.649–5.120 ms; the entry spacing of that preceding callback was 10.642–10.684 ms. The largest measured processing duration in any event’s preceding 94 callbacks was 6.270 ms. Thus there is no measured long processing spike or abnormal preceding entry gap that directly explains these failures. The 10.667 ms callback period is not itself a measurement of the time remaining until the entire audio system’s deadline. Native work, log formatting, downstream service and scheduled presentation are incompletely traced.
Apple describes the audio server and client render threads as cooperating toward a shared deadline; the server waits for the client output. That supports distinguishing one measured function’s duration from the complete I/O deadline. It does not establish that our app starved USB service or that such starvation produces this particular transaction status. Apple: Understanding Audio Workgroups
The best current hypothesis is a workload-dependent failure outcome. Something in normal processing or its side effects promotes occasional hard failures in the iPad audio/USB path. With that activity removed, nonfatal input-transfer/timestamp disturbances still occur and drift accumulates. Hard restarts, when present, can clear state and suppress the later periodic symptom. The original 44.1 kHz recording provides a direct example of a restart clearing periodic distortion at an unchanged sample rate.
This is a useful, falsifiable hypothesis family, not a completed causal mechanism. A concrete scheduling version would say that normal rendering and its triggered work reduce service margin elsewhere in the shared pipeline; the observed input transaction failure then triggers recovery. The missing evidence is the affected thread/queue/deadline and the link to that transfer status. A distinct normal-processing side effect or memory defect could also produce a workload-dependent result. The data does not prove that the hard failures and periodic blanking are independent bugs or share one initiating condition.
The most direct next diagnostic comparison would keep the output tone and restore normal work underneath it. Run the ordinary processing path with its normal side effects, then overwrite all returned output channels with the same continuous tone. Compare it with the existing tone-only mode while retaining the same JUCE revision, physical topology and accepted format. Keep measurements of transaction failures and drift steps separate. A later within-session comparison can reduce startup-state differences, provided mode transitions and state catch-up are handled and excluded from event counting.
Upgrading JUCE remains a practical compatibility intervention and could change the same workload/driver interaction. A clean upgraded tone run would assess the periodic failure only; normal processing must be tested again to assess the sporadic failures. The existing tone comparison gives more direct evidence for a processing-dependent sporadic trigger than for a generic defect in the unchanged idle workers or unchanged JUCE code alone.