Read-only investigation, 2026-09-10. No app source, settings, devices, recording state, or builds were changed. Downloaded public source and this report are the only new artifacts.
The strongest source result is the two current native audio paths are almost the same. SonoBus’s JUCE fork contains no distinct USB retry mechanism, RemoteIO render algorithm, maximum-frame allocation strategy, or audio-workgroup setup that explains its preliminary clean playback. Device settings and app workload remain meaningful differences. This comparison identifies follow-up experiments; it does not establish a root cause or prove the App Store binary equals the public source.
The supplied experimental context establishes two symptoms: sporadic approximately 225 ms interruptions associated with USB input-endpoint transaction errors and driver restarts, and separate periodic partial-buffer holes sometimes with regular app callbacks. SmartGrid reproduced failures on JUCE 8.0.2 and 8.0.15 at verified 48 kHz/512. Input-enabled SmartGrid also failed; removing WRLD BLDR did not eliminate failures; pure tone bypassing normal callback processing and LED generation still reproduced periodic holes, with sporadic drops reported in a later tone run. These facts were supplied by the parent investigation and were not re-derived from recordings here.
The current SonoBus 1.7.3/build 90 standalone local-file trial uses the unchanged iPad/MAYA44 USB+/Satechi hub/PD topology. At handoff, the user reported no glitches and local analysis found no near-silence interval of at least 20 ms through 28 minutes. This is a preliminary time slice, not a completed clean-hour result. That silence criterion alone does not exclude shorter partial-buffer holes, clicks, substitutions, or discontinuities. SonoBus’s actual rate, native frame cadence, session options, and input/output selections were not queried during the run.
SmartGrid’s permanent 48 kHz/512 requirement is retained. Future matching should bring the SonoBus control to those settings if needed; this report does not propose changing SmartGrid to 256.
/private/tmp/smartgrid-juce-8.0.15/modules to PROJECT_TEMP_DIR/SmartGridJuceModules; that directory leads the header search path. The preparation script applies only the on-device default-buffer 256→512 change for 8.0.15; the old 8.0.2 branch additionally removes the one-frame preference offset.36eef099f39b09a68c8ceda47be47de54c6704a8f1d45a1cff7d5b0cbc57b650. SonoBus native file SHA-256: 1e3c59bc212e8a2ff6f8c9bd1c03f4634985e04af5ba3343e6f71868419ea58e.AudioSourcePlayer.cpp and AudioProcessorPlayer.cpp are byte-identical to upstream 8.0.15. Tagged AudioDeviceManager.cpp differs only by lacking the newer destructor’s enabledMidiInputs.clear() before device teardown. That difference does not alter steady-state rendering.| Area | Source finding | Consequence and limits |
|---|---|---|
| Preferred setup | SonoBus requests 48 kHz/256 in createWindow. Its saved audioSetup and override handling can replace the rate, buffer, and channel defaults; disabling rate override removes the requested rate. SmartGrid explicitly requests 48 kHz/512 with no saved device XML in OpenAudioDevice. | A real difference in defaults, with current SonoBus runtime choices unknown. The test cannot yet be described as a matched 48/512 control. |
| App channel selection and session category | SonoBus initially declares stereo input and output in getDefaultLayout and requests those buses unless permission/settings change them in holder initialization and reloadAudioDeviceState. SmartGrid currently requests 0 inputs/7 outputs, clamped to the reported four hardware outputs. Native code chooses PlayAndRecord for a nonzero input mask, Playback otherwise: SonoBus open, SmartGrid open. | Probable stereo duplex versus confirmed app-output-only comparison, not confirmed live SonoBus behavior. Input-enabled SmartGrid failures rule out Playback/zero inputs as a necessary cause of all failures. |
| Session options | Both compile to MixWithOthers unless overridden; neither inspected project defines the disabling flag. On PlayAndRecord both request DefaultToSpeaker, AllowAirPlay, and AllowBluetoothA2DP. Upstream additionally requests HFP/AllowBluetooth. SonoBus disables HFP by default, with a saved user toggle: category builder, Bluetooth setter, holder defaults, upstream options. | The principal fork-specific session difference. Low explanatory weight while the verified route is USB and SmartGrid’s final output-only category also omits HFP; a startup route-state effect is speculation. SonoBus is not shown to use an exclusive/nonmixable session. |
| Mode and voice processing | Both native backends implement Default/Measurement switching only through setAudioPreprocessingEnabled: SonoBus setter, SmartGrid setter. No caller was found in the inspected app integration, SonoBus processor/options, or shared JUCE initialization path. Both construct RemoteIO, not VoiceProcessingIO. |
No confirmed mode difference and no source evidence for a SonoBus Measurement-mode cure. Default mode is the expected initial choice, but current mode needs runtime verification. |
| Activation ordering | Both constructors use PlayAndRecord→active→hardware probing→inactive. Both open paths then activate, choose the final category, configure channels, request rate/buffer, probe/update hardware, create RemoteIO, and start. Both use the same temporary RemoteIO callback wait on iOS 18+: constructor and activation, open order. |
No alternate SonoBus activation sequence was found. Changing this order would test a shared backend hypothesis, not reproduce a SonoBus-specific fix. |
| Rate and buffer negotiation | Both use exact duration requests on iOS 18+, both assume a newly requested buffer will take effect, and both use the same sample-rate probing/cache. SonoBus’s AudioQueue sample-rate workaround stops at iOS 26; 8.0.15 stops at 18.7.3. Both use the direct session sample rate on this iPadOS 26.6.1 device: buffer negotiation, sample-rate selection. | The version cutoff difference is inactive here. On iOS 18+, JUCE’s stored buffer size can reflect the requested value, so a settings label alone does not prove native frames or timing. |
| RemoteIO format and channel enablement | Both enable input element 1 only when input channels are active/available. Both install the output render callback on input scope/bus 0, and set float32 noninterleaved PCM formats using max(hardware input channels, hardware output channels), not active app channel count. Both write both relevant client stream formats: RemoteIO creation, SmartGrid configuration. | Selecting two output channels in SonoBus does not establish a two-channel USB stream or half the bus traffic. Unused hardware outputs are zero-filled. Zero app inputs also do not prove iPadOS stopped every USB input-endpoint transaction. |
| Native buffers and rendering | Both query MaximumFramesPerSlice after AudioUnitInitialize and size internal float buffers accordingly. Both can resize if a larger callback arrives. Both call AudioUnitRender for enabled input, take the same callback try-lock, call the app, copy all active output samples, zero inactive channels, and return input-render status: process, maximum-frame allocation. | No fork-specific guard, prefill, retry, concealment, or maximum-frame policy was found. Native try-lock failure zeros a whole native buffer and skips the app callback; it is shared behavior. Successful app entry does not prove every later output copy reached the USB device. |
| Callback size enforcement | SonoBus’s custom holder adds a CallbackMaxSizeEnforcer. The tagged and upstream 8.0.15 AudioDeviceManager already enforce the same maximum for all device callbacks. | The extra holder guard is redundant with the current manager. Its presence is not a current SonoBus-only stability feature. Original 8.0.2 lacked the manager guard, but upgraded SmartGrid still failed. |
| Adapter and locking | SmartGrid attaches AudioSourcePlayer after device initialization. SonoBus registers the holder before initialization, then sets the processor after restoring state: SmartGrid attachment, SonoBus ordering, callback registration. SourcePlayer takes its read lock; ProcessorPlayer takes its own lock plus the processor callback lock; both sit behind the manager callback lock. See SourcePlayer callback and ProcessorPlayer callback. | The startup silence window differs, but there is no evidence it causes periodic faults long after startup. SonoBus’s adapter is not lock-free and does not confer automatic USB protection. |
| Workgroups | Both native files query OSWorkgroup identically. ProcessorPlayer forwards changes via audioWorkgroupContextChanged; SonobusAudioProcessor declares no override or workgroup use in its header/implementation. See native workgroup and player forwarding. |
Forwarding a context is not evidence that SonoBus workers join it. No special workgroup scheduling remedy was found. Runtime worker scheduling is a separate parent audit. |
| Other fork additions | SonoBus adds input-gain APIs and classifies USB/line/headphone outputs as headphones for feedback muting. The holder’s mute merely substitutes zeros for input data after native input rendering: gain APIs, route classification, input mute. | These affect input level and feedback handling; they do not create USB recovery or disable hardware input when muted. |
| IAA/lifecycle | SonoBus enables Inter-App Audio in its project, publishes its RemoteIO unit, and installs IAA listeners/MIDI callbacks. It closes audio on suspension with no peers/IAA and restarts when resumed: IAA publication, lifecycle. SmartGrid is a regular GUI app. | A real build/lifecycle difference, with no evidence of an active IAA connection here. It is weak for continuous foreground playback faults; do not switch app lifecycle while the control is recording. |
| File playback | SonoBus uses a normal-priority disk thread and 65,536 samples of file read-ahead, with source-rate correction; the transport still runs within processBlock and the same RemoteIO path: transport loading, transport rendering. | Read-ahead protects file availability, not a stalled audio callback or USB driver reset. SonoBus’s network jitter buffering cannot be assumed to mask a local USB dropout. |
The common native backend also leaves many AudioUnitSetProperty/initialize statuses unchecked. That is a shared diagnostic blind spot, not evidence that SonoBus has a stronger error strategy.
Apple explicitly distinguishes preferred settings from current values after activation and notes that changing preferences while active can restart I/O. That supports measuring actual session state; it does not establish that the shared JUCE activation sequence caused these failures. Apple QA1631.
Ranks reflect diagnostic value within this comparison, not a claim about causal probability. All are future work after the current capture, with the current topology retained.
Verify and match the SonoBus rate/buffer control. First record its audio-device settings, channel masks, rate-override toggle, and Bluetooth-input toggle without changing them. Obtain actual AVAudioSession rate/IOBufferDuration and native cadence if existing system diagnostics can provide them; if unavailable, explicitly leave them unverified. If SonoBus differs, change one setting per separate run toward 48 kHz/512 while retaining the current file and routing. A clean SonoBus result at 48/512 sharply weakens the default-256 explanation. A change-dependent failure identifies an operating-point interaction, not automatically a bad USB device or a specific JUCE bug. Do not change SmartGrid’s baseline.
Locate the periodic hole at the native boundary. In a separately instrumented SmartGrid trial, retain its existing deterministic tone and 48/512. Compare app output immediately after rendering, the final native output just before returning to RemoteIO, and the external recording. Record native frame count, sample/host timestamps, input-render status, try-lock result, and lifecycle/route events in bounded preallocated storage. Use sample snippets or tone phase residuals to locate partial holes; per-block average/RMS alone can hide them. Clean app output followed by damaged native output points to the adapter/native copy/zero path. Clean native output with damaged external capture shifts the investigation below that boundary, including Apple’s audio/USB path and capture integrity. This is the best discriminating experiment for the periodic symptom; no source fix is justified yet.
Match active channels and category after the rate/buffer control. If SonoBus is stereo duplex, test four active outputs at the same settings while retaining the same inputs; then, in a different run, test zero active inputs. Ensure the same measured output pair carries the same signal. This separates an app channel-layout or session-category interaction from rate/buffer differences. Because both backends configure the hardware channel count, avoid interpreting stereo selection as reduced USB bandwidth. Earlier input-enabled SmartGrid failures already weaken a simple “zero input is the cause” explanation.
Test the only substantial session-option fork difference only if the above remains unexplained. With SonoBus otherwise stable and fully documented at 48/512, change only Allow Bluetooth Input and repeat a separate run. Prefer the same launch procedure so startup and live-reconfiguration effects are not conflated. A changed failure rate would justify investigating route/option interactions. No effect would lower its already modest ranking. There is no evidence to change SmartGrid to Measurement mode, disable mixing, or transplant the whole fork as a remedy.
Use a minimal app-boundary control if native output is not already decisive. A future SmartGrid diagnostic can feed the same file/tone through its existing AudioSourcePlayer while suppressing one background activity at a time, preserving the device setup. The parent is separately assessing realtime worker requests, MIDI activity, and callback logging. Normal DSP load, WRLD BLDR, and absent app input have each already been weakened as sole causes by prior trials; repeated broad “simplify everything” runs would confound variables. A wholesale conversion to SonoBus’s AudioProcessorPlayer would change too much to identify a cause.
A separate denormal-control test is low priority: SonoBus uses ScopedNoDenormals at processBlock entry, whereas SmartGrid’s AudioSourcePlayer path does not add that guard. The pure-tone reproduction and short reported DSP work weaken this as an explanation of the observed periodic holes. Likewise, the shared enforcer, same maximum-frame code, and inactive iOS-version cutoff should not consume new test runs.
A clean alternate app on the same topology would establish that the hardware/software combination can work under at least one operating state. It would not by itself identify whose bug is involved, rule out a state-dependent Apple/hub interaction, or show that a source patch in SonoBus cured anything.
The generated native patch was byte-verified; exact-tag player sources were byte-compared; the entire native diff was inspected; saved-setting precedence, input/category selection, callback routing, lock behavior, maximum frames, workgroup forwarding, and local-file transport were traced. Source references use local absolute paths and exact line starts. No device query, app action, code change, or build was performed for this investigation. The current recording outcome remains owned by the parent investigation.