Desktop-first initialization comparison — September 11
User priority: SmartGrid desktop is the stronger working comparison because it retains the app workload. SonoBus is simpler; its clean hour remains useful but failure to reproduce there should not veto a shared-backend/workload interaction. Deprioritize proposed hub substitution and another matched SonoBus exposure. No new test/build/deployment was started in this comparison.
Verified source and archived behavior
- Desktop JUCE uses CoreAudio device properties and AudioDevice IOProc registration/start. It obtains supported rates with kAudioDevicePropertyAvailableNominalSampleRates (local /Users/joyo/JUCE/modules/juce_audio_devices/native/juce_CoreAudio_mac.cpp:380); reopen sets nominal rate and buffer size before start (line645). It does not execute the iOS AVAudioSession/RemoteIO setup sequence.
- iOS JUCE8.0.15 constructor selects temporary PlayAndRecord, activates, starts/disposes a SubstituteAudioUnit to observe a callback, updates hardware info and deactivates. Open activates again (another substitute unit), selects final category, requests rate/buffer, updates hardware, then creates/starts real RemoteIO.
- Supported-rate discovery is active probing: trySampleRate4000,192000, intermediate candidates, restore original. Source /private/tmp/smartgrid-juce-8.0.15/modules/juce_audio_devices/native/juce_Audio_ios.cpp:571. Latest lifecycle trace confirms TWO probing passes: requests4000,192000,45100,44100 before final setup; then48000/512 followed by another4000,192000,45100 pass. These are preference requests, not claims that hardware operated at4000or192000. Steady measured callbacks remain48k/512.
- Same source contains an existing bypass: JUCE_IOS_AUDIO_EXPLICIT_SAMPLERATES; if nonempty, updateAvailableSampleRates returns the explicit list without active rate probing. No definition found in current SmartGrid project/source. Setting this to48000 is a narrowly scoped test, not a whole backend rewrite.
- SonoBus public tagged backend shares constructor/activation/probing machinery. Archived installed SonoBus PID18546 setup independently confirms requests4000,192000,45100,44100 then48000. Thus active probing alone is not sufficient for failure. It can still interact with workload or session state. Exact request evidence extracted to /private/tmp/sonobus-init-comparison-evidence.json.
- SonoBus archived startup confirms PlayAndRecord/Default, EnableBluetoothRecording=false/disallowHFP1. Current SmartGrid starts PlayAndRecord withoptions109 (including HFP) and ends Playback/options1. SonoBus native fork deliberately omits HFP by default. Earlier input-enabled SmartGrid failures mean final Playback/zero-input state is not necessary for the historical symptom.
- SonoBus registers application callback holder before device initialization; current SmartGrid attaches AudioSourcePlayer after initialization. This app ordering also differs from SonoBus on desktop, so it is not itself an iOS-only distinction; an interaction remains possible.
- SonoBus enables Inter-App Audio publication in public project/backend. Current SmartGrid regular app does not define JucePlugin_Enable_IAA; an Xcode capability entry alone is not compiled publication. No demonstrated mechanism ties this difference to USB errors.
Proposed sequence reflecting user priority
- Keep normal SmartGrid DSP/UI/MIDI,48k/512,zero inputs,current hardware and capture conditions. Set only JUCE_IOS_AUDIO_EXPLICIT_SAMPLERATES=48000 for all relevant compilation units. Verify startup traces contain no exploratory sample-rate requests, actual48k/512 and normal workload. Compare against existing failing setup, then reverse the change to verify any apparent benefit. This is an initialization/workload interaction test; it is not presented as copying a unique SonoBus remedy.
- If probing removal has no reproducible benefit, separately test unnecessary session activation/deactivation and temporary RemoteIO units. Preserve final settings and workload; check actual settings after activation since the temporary unit exists to work around asynchronous iOS updates. Specify which operation changes before building; do not bundle all lifecycle changes blindly.
- Keep actual iOS-only fork differences (HFP startup option, IAA publication) as concrete but currently weak mechanism candidates. Prefer findings from the preceding tests over blindly transplanting the fork. Keep both sporadic failures and sustained periodic artifacts as independent outcomes.
This is a hypothesis ranking, not a claim that initialization caused the errors. Completed native traces already exclude measured callback overruns and app-driven steady-state restarts in the latest window; they do not exclude a persistent state established during startup.