The first capture is complete and analyzed. Eight sustained analog corruption bursts match the user’s listening reports, including the coarse episode around 17:00. Both channels show synchronized short cuts with timing near the configured 512-frame period. The evidence favors a downstream buffer/timing-alignment hypothesis but does not locate the failing component. Clean generated DSP remains established prior evidence; this experiment did not repeat that test. No reset, app restart, deployment, cable/power change or sysdiagnose was performed during that first capture. The user subsequently performed an upstream reconnect during the continuation, recorded below.
The separate 15-minute continuation ran from 17:07:33 through 17:22:33 PDT and also completed successfully. Both recording and live logging are now stopped. The continuation includes the user’s upstream reconnect; its changed musical material limits automatic before/after classification. Completion details and the later powered-idle observation are below.
The user requested recording physical interface inputs 3/4 and explicitly identified periodic corruption rather than startup silence. The Mac’s K-Mix receives Maya’s analog output. The verified main recording contains 1,575 seconds, stereo, 48 kHz, 24-bit. Recorder launch was 16:38:21.601 PDT and successful exit was 17:04:36.975.
| Approximate local onset | Approximate recovery | Spectral duration | Seconds since preceding onset |
|---|---|---|---|
| 16:39:15 | 16:39:25 | 10.3 s | — |
| 16:41:06 | 16:41:13 | 7.6 s | 111.0 |
| 16:42:34 | 16:42:38 | 3.7 s | 88.2 |
| 16:44:25 | 16:44:33 | 8.0 s | 110.7 |
| 16:46:59 | 16:47:14 | 15.5 s | 153.9 |
| 16:50:22 | 16:50:41 | 19.0 s | 203.3 |
| 16:54:55 | 16:55:14 | 19.3 s | 273.0 |
| 17:00:19 | 17:00:46 | 27.0 s | 323.8 |
These are recorder launch plus sample offsets, rounded to seconds, not calibrated wall-clock boundaries. Recorder warnings below add alignment uncertainty. The user initially dictated 4:44:57-ish to 4:55:15, then explicitly confirmed 16:54:57–16:55:15. The eighth event was reported as “5:00-ish” and “really coarse.” Earlier reports included approximately 16:35, before the reliable recording began.
The proposed fixed two-minute recurrence is not supported. Later onset intervals lengthen markedly, and later bursts also last longer. A changing relative clock/buffer phase could produce such behavior, but this time series alone does not prove that mechanism or a thermal cause.
Material change: the spectral detector also flags intervals after approximately 17:02. The user confirmed starting to jam and changing the material then. Those are unclassified spectral candidates, not additional confirmed glitches. The machine-generated finalizer’s spectral_bursts list is a detector output and includes those candidates; use the eight-event table above for the user-matched result.
Unrecorded follow-up: the user reported another burst at 17:06:13–17:06:38. This lies after the completed recording and before the continuation started; its waveform was not captured. Preserve the listening observation without presenting it as a measured analog interval.
All eight matched episodes contain broadband disturbance and repeated short near-silence intervals in both channels. A 150 ms comparison from the first and eighth episodes visually shows aligned abrupt cuts and flat sections in both channels. Their similarity supports treating the coarse 17:00 episode as the same observed waveform phenomenon.
The eighth episode lasts 27.0 seconds, compared with 19.0 and 19.3 seconds for the preceding two. Its detector finds 310 stereo quiet runs of at least 1 ms; their maximum length is approximately 7.02 ms, versus 7.42 ms in the first episode. Its greater total duration is established; the data do not show uniquely longer individual holes. The count depends on signal content and threshold and is not a count of USB errors, all inserted zero intervals, or a perceptual severity scale.
There is evidence of block-related timing beyond selecting adjacent holes near an expected separation:
Working interpretation: repeated partial blanking tied to a buffer-scale period, with changing cut width, is compatible with two timing/buffer boundaries moving relative to one another. Candidate locations include the native output handoff, iOS USB audio buffering/clock handling, and the Maya side. It is stronger evidence for investigating downstream timing than for revisiting the synthesizer’s sample generation. It does not establish which candidate is responsible, prove implicit feedback, or exclude the physical USB path as an initiating factor.
The retained message is AUAInputTransferManager_completeBlock USB underflow, emitted by Apple’s usbaudiod for Maya input transfer manager 0x390. This describes the Maya → iPad input path, while the audible symptom is iPad → Maya playback. The negative numeric argument is undocumented in the sources found; do not label it frames, packets, milliseconds or an OSStatus code.
The initial archive contains four earlier input-underflow messages at 16:32:58.580, 16:34:11.371, 16:34:11.443 and 16:34:11.483, before the first capture request. The live stream then contains 612 additional messages between device times 16:39:44.041 and 16:49:01.112. The final historical archive contains the same 612 numeric arguments in the same order, with rendered wall times approximately 16:39:44.063–16:49:01.149. Do not add the live and historical counts together as separate incidents.
The user raised an important interpretation correction: repeated driver errors may be throttled. Agreement between the live stream and historical archive makes loss confined to our live collector less likely, but both can share driver-side suppression or unified-logging loss. No explicit Maya-underflow suppression notice was found, and no public source for this private call site’s throttle policy was established. Absence of a suppression notice is not evidence that suppression is absent.
Therefore:
The earlier live checkpoints noted later bursts after the last recorded underflow. Withdraw any implication that the underlying underflows necessarily stopped at that timestamp. Only the retained messages stopped. The waveform establishes the audible intervals independently.
Apple’s USB audio design considerations describe clock/feedback arrangements that can couple input and output timing. Maya’s actual feedback/clock arrangement is not established here; do not assert it uses implicit feedback.
The initial archive retains events from 16:19:19.000 through 16:34:20.999 PDT. Maya enumerates at 16:30:18.843; device object 0x376 and input transfer manager 0x390 are explicitly associated with it. The last recorded startup StartIO is at 16:30:53.965. The private ioDriftNS field increases to 250,519,000 at 16:33:27.491, before the reliable analog capture. This is not a calibrated analog delay and is not available through the later measured bursts. Three transaction errors at 16:30:23 identify WRLD endpoint zero, not Maya; they are not evidence that the resolved WRLD firmware defect returned.
Live audio/USB logging retains device events from 16:36:09.678 through 17:04:36.969. It received 232,293 events and saved 2,912 matching records; the helper stopped at its deadline. The final historical archive retains 16:34:49.000 through 17:04:51.968. It has no retained StartIO, StopIO, USB transaction-error or ioDriftNS message in the inspected audio/USB records. Treat these as coverage-qualified log observations, not guaranteed absence of the corresponding internal activity.
The final SmartGrid log retains records through 17:04:10. It continues reporting Maya at 48 kHz/512 frames, four inputs and four outputs, nominal thermal state, low-power mode off and no MIDI submission errors. Only the initial audio-timing record at 16:30:54 is present (one processing overrun, no xruns, long gaps or format mutes); no subsequent timing-counter change or app audio reopen is retained. This is aggregate evidence, not a per-callback trace. Periodic Delay buffer wrap around messages are not by themselves fault evidence.
The finalizer completed successfully at 17:05:42.620, including app/system captures, waveform analysis, closed-header verification and archive decoding. Its success concerns capture and analysis, not resolution of the Maya fault.
The original FFmpeg/AVFoundation recorder began around 16:34:37 and wrote one-minute wall-clock files, but the first nominal minute contains only 53.152 seconds of PCM. Those files remain preserved, including the 16:35 report, with unreliable timing/continuity. FFmpeg was stopped at 16:38:57.442 after verifying the SoX replacement.
The main SoX/CoreAudio recording selects K-Mix physical channels using -c 8 K-Mix ... remix 3 4, at 48 kHz/24-bit. Its closed WAV header verifies 1,575 seconds and 453,600,080 bytes. SHA-256: 71e561e5573db2ca435573fd485857c50b8fb4716246997c27b202c2839aa185.
There are five Mac recorder discarded-buffer warnings at approximate recorded elapsed seconds 12.15, 322.75, 1184.57 (twice), and 1508.45. All lie outside the eight matched burst intervals; the final warning is during the changed-material interval. The discarded durations are unknown, so this is not a globally lossless capture or a calibrated sample-to-wall-clock mapping. These Mac recording warnings are separate from iPad USB input underflows. User listening reports independently corroborate the sustained episodes.
The spectral detector calculates 6–20 kHz RMS in each channel with 100 ms Hann-windowed FFTs, requires both channels above -80 dBFS, bridges gaps up to 0.5 seconds and retains intervals at least one second long. All eight matched events persist at thresholds from -85 to -75 dBFS, shifting boundaries by at most 0.2 seconds. Typical earlier background high-band RMS is about -104 dBFS. This criterion depends on the material, as the post-17:02 change demonstrates; it is not a universal glitch detector.
Quiet-run detection requires both channels below -65 dBFS for at least 1 ms. It can miss inserted flat regions because of analog residuals and can include naturally quiet material. A bounded-memory, ten-second chunk implementation was verified identical to the original implementation over their shared first 377.3 seconds. Use actual PCM bytes for an active WAV; its provisional header duration is not valid until close.
Raw data and derived artifacts remain outside Git in:
/Users/joyo/Documents/SmartGridOne/diagnostics/20261006T233430Z-periodic-maya/
Key files:
sox-kmix-inputs-3-4.wav, sox-status.json, sox-recorder.log, final-wav-validation.log, completed-capture-qualification.json.analysis-final.json, analyze-maya-periodic-chunks-20261006.py, maya-burst-details.json, maya-period-coherence.json, summarize-maya-capture-20261006.py.maya-waveform-comparison.png compares first/eighth episodes; sox-50-70s-spectrum.png and burst-1647-spectrum.png show earlier spectra. Excerpt time axes are recording-relative, not wall-clock time.user-observations.jsonl preserves reports and corrections.live-audio-usb.jsonl, live-status.json, live-collector.log, maya-periodic-live-20261006.py.final-app/2026-10-06T16-30-51-324.log, final-system.logarchive/, final-system-audio.log, final-system-all.log, finalization-status.json, finalizer.log, finalize-maya-periodic-20261006.py.kmix-inputs-3-4-20261006T*.wav, recorder.log, recorder-change.json and checkpoint analysis files remain for provenance.sox-continuation-1706.wav, sox-continuation-1706-status.json, sox-continuation-1706.log, maya-continuation-20261006.py. The filename refers to the triggering report; actual launch was 17:07:33.108. The verified closed file contains 900 seconds. See the completion qualification below.Initial app snapshot: /Users/joyo/Documents/SmartGridOne/diagnostics/20261006T233422.751006Z-app/2026-10-06T16-30-51-324.log.
Intermediate app snapshot: /Users/joyo/Documents/SmartGridOne/diagnostics/20261006T234913.166614Z-app/2026-10-06T16-30-51-324.log.
Initial system archive: /Users/joyo/Documents/SmartGridOne/diagnostics/20261006T233419.377615Z-system.logarchive/; decoded initial logs are in the run directory.
The capture establishes a repeatable waveform shape and timing scale, not a root cause. A future native output-boundary trace aligned with analog capture could establish whether valid blocks reach iOS on time while the analog signal is being cut. That would test the handoff after the already-established clean DSP, not retest the synthesizer. The requested audio-reset button would provide a separate controlled recovery experiment; no such reset was performed here. A software recovery result still would not establish that Maya was power-cycled or uniquely locate the original fault.
The user chose to unplug/replug and explicitly identified the iPad-to-hub cable. The continuation recorder was already running. A historical archive retains actual events from 17:01:33.000 through 17:11:33.996 PDT, including the unrecorded 17:06 listening report and the reconnect. The log shows:
lockDelayMS from 24 through 100, 150, 200 to 250. The final recorded StartIO in this archive completes at 17:10:04.848. These are observed startup/recovery messages, not proof of the cause of the preceding periodic symptom.This test rebuilds the upstream USB topology and Maya driver/stream state. It is not an isolated Maya-only disconnect, does not establish that Maya lost power, and cannot by itself distinguish host, hub, device or connection-state causes. A sustained clean post-reconnect interval would be useful; immediate recovery is ambiguous because earlier episodes already self-cleared. No successful recovery or disappearance of recurrence is claimed at this checkpoint.
Artifacts are in the same local run directory: reconnect-system.logarchive/, reconnect-system-all.log, reconnect-system-audio-selected.log. A separate filtered live stream began at device time 17:11:21.967 and is bounded to 17:22:33: reconnect-live-audio-usb.jsonl, reconnect-live-status.json, reconnect-live-collector.log, with helper maya-reconnect-live-20261006.py. It started after the physical reconnect; the historical archive supplies that transition. The continuation WAV still requires final header/quality verification and analysis.
SoX exited successfully at 17:22:33.327 PDT. The closed WAV is verified as 900.000 seconds, stereo 48 kHz/24-bit, 259,200,080 bytes. There is one discarded-buffer warning at recording elapsed 260.93 seconds, approximately 17:11:54. The final continuation analysis and helper are retained as analysis-continuation-final.json and analyze-maya-continuation-20261006.py; validation and limits are in continuation-completion.json.
The second live collector ended at its deadline at 17:22:33.013, saving 805 records from 86,870 received events. Retained device timestamps span 17:11:21.967–17:22:32.202. No Maya underflow, drift, start/stop, zero-length or transaction-error message is retained in that stream. This is not proof of clean hardware operation or absence of suppressed errors.
The simple high-band detector is unsuitable for classifying the changed material after the user began jamming. An exploratory screen for seconds with at least eight detected quiet-run starts and circular coherence above 0.7 at 512 samples finds no qualifying seconds either in the continuation before unplug (offsets 0–140.4) or after reconnect (155–900). Because it is also negative before the intervention, this cannot establish that reconnect removed the periodic failure. The recorder covers roughly 12.5 minutes after the settled StartIO. Preserve the user’s recovery report separately from an unproven automated waveform classification.
After the capture, the user reported that every remembered occurrence of this rare bug (four total) followed the hub/Maya remaining externally powered for “a while” with the iPad disconnected. In today’s case the powered interval was overnight. The sequence was: leave iPad disconnected while hub/Maya stay powered; later attach iPad; encounter the bad state; a subsequent iPad-to-hub unplug/replug clears that state. The four count refers to the user’s remembered occasions of entering the rare bad state, rather than the individual within-session bursts measured above. This is retrospective user evidence, not four independently logged controlled exposures. The number of uneventful attachments after the same preparation is unknown. Do not call the recipe reliably reproducible yet.
This elevates first attachment after long powered idle as a candidate trigger for the periodic state. It does not establish the same prerequisite for the separate startup-silence symptom or override older deliberately induced laboratory results. The historical observation that the iPad had been asleep is also potentially confounded with this sequence; peripheral powered-idle state and host wake/first-attachment state have not been isolated.
A plausible mechanism is incomplete initialization when a long-idle, powered peripheral chain first joins an active host. The first attachment may change the clock, firmware or hub state while creating an incorrect stream/timing relationship. A second attachment then rebuilds the USB/audio relationship from a different, recently active starting state. This explains why two physically similar connections could behave differently; it is a hypothesis, not proof that Maya firmware, the hub or iPad owns the defect.
The power/attach transition could be a one-time trigger, with recurring buffer-phase corruption afterward; no repeated PD renegotiation every few minutes is needed by that model. If Maya remains powered and warm through successful recovery, a fixed overheating condition alone becomes a less satisfying explanation, although temperature-dependent startup timing and power transients remain possible. No peripheral rail was measured during reconnect.
The observed zero-length startup packets and driver lock-delay escalation at today’s reconnect are concrete evidence that stream startup involved settling/retries. They motivate inspecting the first attachment as well as recovery; they do not prove clock-lock failure, Maya’s feedback mode, or causality for the periodic waveform. Apple’s USB audio design guidance distinguishes clock synchronization/feedback modes and, for programmable ADC2+ clocks, says rate-setting completion should await a valid clock. That general requirement must not be assigned to Maya’s implementation without establishing its actual mode.
Next controlled comparison, proposed only: record from before the first iPad attachment after a documented long powered/no-host interval. Compare that preparation on another occasion with the same long-powered hub but power-cycle only Maya via its own USB cable immediately before attaching the still-disconnected iPad. Keep hub external power, app/version, playback material, cables and first-attachment procedure matched. The Maya-only preparation changes its power/USB presence while retaining hub powered history. Repeated prevention under that condition would implicate Maya’s pre-attachment state or its interaction with hub initialization; a failure would not uniquely clear Maya. If the bad state appears, preserve the first-attachment logs before recovery, then use Maya-only recovery to test whether rebuilding the whole upstream hub is necessary. These are proposals, not remotely executed interventions or demonstrated fixes.
The user asked whether the attachment near 16:00 was captured. A new read-only historical retrieval requested 15:55 PDT onward and retained dated events from 15:55:00.000 through 17:39:38.985 (937,461 dated records). The first retained hub/Maya attachment is at 16:30, with no earlier matching USB plug, hub/Maya/WRLD enumeration or termination event found in that retained window. This is a log observation, not a guarantee that every possible event was emitted. The original 16:19–16:34 archive already contains this attachment; the new archive establishes earlier coverage.
| Time, PDT | Retained observation |
|---|---|
| 16:30:12 | USB-C connection becomes active; kernel and powerd report wake due to USBPlugEvent. |
| 16:30:12.553 | SpringBoard changes AC status from NO to YES; Wi-Fi reports external power at 16:30:12.555. This is iPad power telemetry, not a measurement of Maya’s supply. |
| 16:30:14.050 / .074 | USB2 and USB3 hub functions enumerate. |
| 16:30:18.843 | Maya enumerates at 12 Mbps. |
| 16:30:23.700 | WRLD enumerates at 12 Mbps. |
| 16:30:35.933 | First retained Maya StartIO, before SmartGrid’s foreground launch. |
| 16:30:50.101 | SmartGrid process 9918 is marked running/foreground; initial launch state follows. |
| 16:30:53.965–16:30:54 | Settled Maya StartIO completes; SmartGrid reports actual 48 kHz/512, four inputs and outputs. |
| 16:32:58.580 | First retained Maya input-underflow message in this session. |
The initial Maya device is configured at 48 kHz at 16:30:20.202. Its explicit subsequent rate changes are 44.1 kHz at 16:30:36.686, 48 kHz at 16:30:51.539, 44.1 kHz at 16:30:52.292 and 48 kHz at 16:30:53.275. Across eight initial StartIO calls, every emitted startup lockDelayMS is 24. There are no retained excessive-zero-length/startup-delay-escalation messages in the initial archive. Do not describe these eight calls as eight failed starts; some are ordinary lifecycle/rate changes.
The later recovery reconnect explicitly sets Maya to 48 kHz, has six StartIO calls with startup delays 24, 100, 150, 200, 250, 250 ms, and logs excessive zero-length input packets causing the first four increases. Thus first attachment and recovery differ in both rate-change history and the driver’s startup settling delay. The private lockDelayMS field is not the app’s buffer duration or measured end-to-end latency, and these differences are not causal proof. Earlier explicit-48-only and single-start trials still reproduced faults, so do not present suppressing sample-rate probes or startup cycling as an untested guaranteed cure.
The timeline shows iPad external power recognized about six seconds before Maya enumeration, consistent with attachment to the already-powered hub. It cannot independently establish how long the disconnected hub/Maya had been powered; that part remains the user’s overnight observation. Audio I/O on Maya began before SmartGrid launched, so the first stream transition is not confined to the app’s own startup.
Local artifacts in the existing run directory: first-attach-history-system.logarchive/, first-attach-history-all.log, first-attach-history-summary.json, and first-attach-versus-reconnect-selected.log. These include both first attachment and recovery. No new device reset, deployment, playback or power intervention was performed for this retrieval.
Closer inspection identifies the first 44.1 kHz request: at 16:30:36.667, audiomxd names SpringBoard session 0x13bc057 as the rate-controlling session, with preferred output rate 44100. The physical Maya rate-setting call follows at 16:30:36.686. Thus this first change precedes SmartGrid’s launch and belongs to system audio configuration.
SmartGrid session 0x13bc058 later requests preferred rates 4000 at 16:30:51.520, 192000 at 16:30:51.522, 45100 at 16:30:52.273, 44100 at 16:30:52.279, and 48000 at 16:30:53.261. These match the known JUCE capability-probing sequence documented in the earlier initialization audit. They are preferences, not evidence that Maya ran at 4 or 192 kHz. The actual logged physical changes in this session remain 48 → 44.1 → 48 → 44.1 → 48 kHz. This is software-requested device reconfiguration, not proof that the hardware clock spontaneously switched rates during the later bursts. The logs distinguish request ownership; exact installed-binary source mapping was not re-established in this clarification.
The USB Audio Class 1 specification, section 4.6.1.2 defines endpoint lock-delay descriptors as information about the time clock-recovery circuitry needs to stabilize so meaningful stream data is not lost during startup. Its applicability depends on endpoint synchronization type. We have not established Maya’s raw descriptor values, so do not claim the observed 24 ms necessarily came from a Maya-advertised descriptor.
Apple’s private AUALockDelay log shows an actual scheduled startup interval: for the first stream, startingLockDelayFrame 15265, numTransactions 24, and data start frame 15289. This supports interpreting lockDelayMS 24 as the driver’s startup settling interval. It is not a measurement proving the physical clock locked within 24 ms, not a software mutex wait, and not the steady 512-frame app buffer duration (10.667 ms at 48 kHz). Similarly, the recovery’s 250 ms value concerns stream startup, not a demonstrated permanent quarter-second playback latency.
At recovery, the driver reports excessive zero-length input packets and responds by stopping/restarting I/O with a larger startup interval. A zero-length transfer contains no payload; it is different from a full-size packet containing silent PCM. The observations cannot determine whether extra settling time, repeated initialization, or another aspect of the upstream reconnect caused recovery. An isolated 24-versus-250 ms comparison has not been performed, and the private field is not established as an app-configurable setting. Local excerpt: rate-request-ownership-and-lock-delay.log in the run directory.
When asked which earlier experiment supported the rate-probing statement, rechecked the September 11 cooled explicit-48 result, protocol and machine-readable summary. The measured interval was 20:09:13–20:24:13 PDT, with JUCE_IOS_AUDIO_EXPLICIT_SAMPLERATES=48000; instrumented SmartGrid preferred-rate requests were only 48000, and measured callbacks remained 48 kHz/512. This does not establish that system audio never configured Maya at another rate before the app’s recorded initialization or during the preceding attachment history.
That run had two distinct recorded findings: 30 short USB-error/restart/callback/analog interruptions, with flat interiors approximately 172–180 ms; and one visually confirmed cluster of repeated stereo near-flat plateaus spanning about 1.196 seconds, near 20:13:21, immediately before a long interruption. The latter had 44 threshold candidates, predominantly 21.33 ms spacing, and strict flat interiors 0.25–1.417 ms. It was not a recorded series of minutes-separated, 10–27-second bursts following the overnight powered/no-host preparation now under investigation. Its preparation did not control that newly reported history.
Narrow conclusion: eliminating SmartGrid’s exploratory sample-rate requests did not eliminate all periodic sub-buffer blanking in that September test. Do not promote this to proof that rate changes cannot trigger the particular rare state captured on October 6, that the two periodic manifestations share a cause, or that the whole USB device remained at 48 kHz from attachment onward. The earlier conversational statement that “the 48-kHz-only experiment still reproduced the bug” was too broad without these symptom and exposure distinctions. Startup silence and the independently resolved one-way MIDI defect are not findings of that control.