Référence API

The single home of audio-format constants audit C1, plan 1.1. This is the ONLY file in app/src/main where a literal sample rate may appear — `ci/checks.sh` enforces it. Everything downstream of a loaded file must use that file's own `LoadedWavData.sampleRate`; only the live microphone pipeline uses LIVE_SAMPLE_RATE_HZ.

Filtre numérique IIR de type BiQuad. Implémentation basée sur les formules Audio EQ Cookbook de Robert Bristow-Johnson.

FFT + tonal-emergence processing for ONE audio stream. Stateful (EMA integration, shock detector): create one instance per stream and never share it between live capture and file analysis audit D3. The sample rate is fixed per instance and threaded from the actual source audit C1 — never assume a rate here. plan 3.7 DSP core polish: - real FFT (DoubleFFT_1D.realForward) on preallocated, reused buffers — half the work and zero per-frame allocation of the old complexForward with zeroed imaginary parts D6. The returned magnitude array is REUSED across calls: copy it if you retain it. - No sentinel arithmetic: the TTNR scale is emergence dB with 0 = none; temporal integration runs on LINEAR power with the honest time constant TTNR_INTEGRATION_TAU_SEC (α is derived from the real frame interval, so integration time no longer changes with FFT size) D2. - The shock detector compares energy RISE RATE (dB/s), not per-call deltas, and the first frame of a stream is ANALYZED (the historical −120 initialization squelched it unconditionally) D3. - Sub-30 Hz masking is display policy and lives in the display layer (AudioConfig.DISPLAY_MIN_FREQ_HZ) — magnitudes here are true D7.

C10/D4, plan 2.5/3.3 Builds and runs the playback/analysis biquad chain. One rendered PCM feeds BOTH what the user hears and what the display analyzes.

A filter request without UI baggage — what the DSP chain needs plan 3.3.

C6, L3, plan 2.2 ALL mutable live-DSP state lives here — the ViewModel keeps no analysis fields. Methods are synchronized as a belt on top of the single-DSP-thread confinement (reset() may be invoked from the main thread on mode/config transitions L7). Behavior is a faithful extraction of the historical live path (persistence counters, 150 ms retro-unmask buffer, 0.75/0.25 EMA). Order-domain work (EMA blend, tag detection) lives in OrderTrackingEngine plan 3.2.

α-β tracker over GNSS Doppler speed audit G1–G4, plan 2.4, now behind the SpeedEstimator contract plan-gps GPS-0.2. Purpose: turn ~1 Hz Doppler fixes into a continuously *predictable* speed (v + a·dt) so the live order projection needs no lookahead — this is what deletes the old 1.2 s display latency L5. Acceleration falls out of the filter as a by-product, replacing the raw 1 Hz derivative whose wall-clock dt made it spike on clock adjustments G1. Units and time base GPS-0.5: speeds m/s, accelerations m/s²; every timestamp is BOOTTIME nanoseconds (elapsedRealtimeNanos) — never UTC. Pure Kotlin — no Android imports — so it is JVM-unit-testable. Gains: α=0.5 with β=α²/(2−α)≈0.17 (critically damped pairing for ~1 Hz updates). PROVISIONAL until tuned on the Phase 0.8 field drive logs. Known limitations, deliberately pinned by `SpeedEstimatorContractTest` until the GPS plan replaces them (audit-gps §4): - beyond maxPredictAheadSeconds the numeric output freezes at v + a·cap; estimateAt *describes* that as INVALID but nothing enforces it GPS-01; - the measurement σv is recorded, not weighted — a ±5 m/s fix corrects the state exactly like a ±0.05 m/s one GPS-02; - no covariance: estimates carry null sigmas GPS-04; - a second consecutive implausible fix is accepted without testing its coherence with the first GPS-06.

Named, testable thresholds plan-gps §2 — PROVISIONAL until Gate GPS-5 tuning.

Named, versionable parameters GPS-2.1; provisional until Gate GPS-5.

Validity of a SpeedEstimate GPS-01, GPS-09. In GPS-0 this is DESCRIPTIVE only — nothing enforces it yet; GPS-1.1 makes it gate every kinematic use.

What the estimator did with one fix — the per-fix trace payload GPS-0.4, GPS-2.2.

plan-gps GPS-3.3 Observable GNSS signal quality, snapshotted from `GnssStatus` at each satellite-status change. These values serve DIAGNOSIS and trace analysis (multipath, canyon, windshield attenuation…). They never replace `speedAccuracy` as the mathematical variance of a fix GPS-12 — the estimator does not read them.

plan-gps GPS-3.3/3.4/3.5 GNSS observability around the speed chain: - snapshots `GnssStatus` (satellites, C/N0, constellations, L5) into latest for the drive traces — diagnostics only, never a variance substitute GPS-12; - requests full-tracking measurements (API 31+) ONLY while registered and only when fullTrackingRequested — the A/B switch of the GPS-5 campaign; the callback is consumed minimally (event count proves the cadence); - builds the per-device capability matrix stamped into trace headers. Owned by SpeedProvider; registered/unregistered with the LIVE session.

One qualified GNSS speed measurement, as delivered by Android. GPS-3 extends this with signal diagnostics (satellites, C/N0, constellations).

plan-gps GPS-1.1, GPS-1.3 The GNSS speed session: fix qualification, validity enforcement and session lifecycle around a SpeedEstimator. This is the single gate between Android's Location callbacks and the kinematic chain (RPM / H1 / order tracking): - every sample is qualified BEFORE it can touch the estimator — non-finite or negative speeds, mock fixes (unless allowed by Config.acceptMockFixes) and cached/backlogged fixes are rejected with a typed reason GPS-12, GPS-13; - kinematicSpeedMps is the ONLY speed the kinematic chain may consume GPS-09: it returns null — never a frozen number — once the estimate is INVALID (no fix, or beyond the prediction horizon) GPS-01; - reset starts a fresh session: callers MUST invoke it on every LIVE-mode entry/exit so no previous session's speed survives a restart GPS-08. The estimate's numeric fields remain populated even when INVALID — they are diagnostic values for traces and displays that show their own "--" state GPS-D4; computation goes through kinematicSpeedMps only. Units and time bases GPS-0.5: m/s, m/s², BOOTTIME nanoseconds. Horizontal position accuracy is deliberately absent here — it is never a mathematical substitute for speed accuracy GPS-1.3; the σv-less case is classified DEGRADED by the estimator instead. Pure Kotlin — no Android imports — JVM-unit-testable.

plan-gps GPS-2 Linear Kalman filter over GNSS Doppler speed — the uncertainty-aware replacement for the fixed-gain α-β tracker (closes GPS-02, GPS-04, GPS-05, GPS-06, GPS-14 estimator-side). Model: ``` x = v, a F(dt) = [1, dt, 0, 1] z = Android GNSS speed H = 1, 0 R = max(σv, floor)² Q(dt) = q · [dt³/3, dt²/2, dt²/2, dt] (white-jerk PSD q) ``` - Double precision core; covariance kept symmetric via a Joseph-form update; variable dt GPS-2.1. - The declared σv weights every update (R = σv²); a fix without σv gets the conservative Config.defaultSigmaMps and marks estimates DEGRADED GPS-02, GPS-1.3. - Robust rejection GPS-2.2: the normalized innovation NIS = y²/S gates each fix. A rejected fix leaves the state at its last accepted epoch, so prediction uncertainty keeps growing normally. Reacquisition needs two MUTUALLY COHERENT rejected fixes (implied acceleration plausible), a rejection streak (safety valve), or a gap long enough for a full re-seed. - Stationary state with hysteresis GPS-2.3: near zero the published speed/acceleration are an honest 0 instead of estimation flicker; the internal state is never silently saturated (no clamp substitutes for validity). Units and time bases GPS-0.5: m/s, m/s², BOOTTIME nanoseconds. Pure Kotlin — JVM-unit-testable. All parameters in Config are PROVISIONAL until the Gate GPS-5 field-tuning campaign.

One raw fix reduced to its measurement (z, R = σ²).

plan-gps GPS-4.4 Deferred speed reconstruction: a forward Kalman pass (same model and KalmanSpeedEstimator.Config parameters as the LIVE estimator) followed by a backward Rauch–Tung–Striebel pass. A recorded analysis has the FUTURE fixes too — the smoothed trajectory uses them, which the causal LIVE filter never may plan-gps §2. Statistically implausible fixes (NIS gate) are simply dropped offline; a gap longer than the re-seed threshold splits the trace into independently smoothed segments (no information crosses a re-seed boundary). Frame-by-frame EXTRAPOLATED speeds are never fed back in as truth — input is raw fixes only. Units and time bases GPS-0.5: m/s, m/s², BOOTTIME nanoseconds. Pure Kotlin — JVM-unit-testable.

Why a sample did not update the estimator state normally GPS-06, GPS-12, GPS-13.

One smoothed state knot at a fix instant.

The estimator's answer at one instant — speed plus age, uncertainty and validity.

plan-gps GPS-0.2 The speed-estimation contract. GPS-2 swaps the α-β implementation for a Kalman filter behind this same interface.

GNSS speed acquisition audit §3b G1–G4, plan 2.4; plan-gps GPS-1/GPS-3: - GPS_PROVIDER is the ONLY metrological source G2, GPS-07: its listener is registered even while the provider is disabled (so enable/disable state changes arrive mid-session GPS-3.2); on API 31+ the subscription is an explicit high-accuracy, zero-interval, unbatched LocationRequest GPS-3.1. The fallback provider runs only while GPS is off and is INFORMATION_ONLY — its fixes never feed the estimator unless their provider field claims GNSS provenance. - All callbacks are delivered on the dedicated "nvh-gnss" thread, never on main GPS-3.1; delivery latency (callback − fix time) is in every trace row GPS-13. - The estimator behind GnssSpeedSession (Kalman since GPS-2) enforces qualification and validity; telemetryAt evaluates it at the audio capture instant GPS-03. - GnssDiagnosticsMonitor snapshots signal quality for traces and owns the full-tracking A/B switch and capability matrix GPS-3.3/3.4/3.5. - Runs only while started — LIVE mode only C7; start()/stop() reset the speed session GPS-08; stop() releases every GNSS resource. Units and time bases GPS-0.5: estimator I/O is m/s and BOOTTIME nanoseconds; TelemetryData speeds are km/h for display. Location.time (UTC) is logged for labeling only — it never enters interval math G1.

plan-gps GPS-4.4 Speed reconstruction for DEFERRED analyses (WAV/video replays, recorded reports): RTS smoothing over the sidecar's RAW fixes, evaluated at each sample's audio instant. The recorder appends telemetry at frame rate (~43 fps) while GNSS fixes arrive at ~1 Hz, so runs of samples share one fix — the smoother sees each DISTINCT fix once, never the frame-rate copies, and never an already extrapolated per-frame speed (those must not be recycled as truth). Sidecars without usable monotonic fix times (v1, or synthetic imports) fall back to the historical corner interpolation; Result.statusLabel says which path produced the speeds — the label the report must print Gate GPS-4.

Which subscription produced a speed sample GPS-07.

A v, a state with symmetric covariance (p11, p12, p22).

Entrée accumulée pour le rapport synthétique d'émergences.

One analysis frame, in the source's own bin grid (df = sampleRate / fftSize).

Serializable so the painstakingly-entered chain survives process death S1, plan 3.6.

plan-gps GPS-4.1, GPS-4.2 Kinematic error budget and the dynamic tracked-order search window it implies (closes GPS-10). Error budget (speeds in km/h): ``` rpm = v · 1000 / V1000 σrpm = σv · 1000 / V1000 f(Hn) = n · rpm / 60 σf(Hn) = n · σrpm / 60 ``` The historical search radius was a FIXED ±1 bin (±Δf) while σf(H18) at the default V1000 and a 0.5 m/s speed σ is ≈ 54 Hz — the true line usually sat OUTSIDE the window and the tracker read noise at the projected bin. The window is now built from the actual uncertainty: k·σf + Δf, and BOUNDED — a window wider than the bound cannot pick one order's line apart from its neighbours', so tracking is SUSPENDED ("ordre non identifiable") instead of silently reporting an ambiguous value. V1000's own uncertainty (dynamic tire radius, gear-ratio rounding) is NOT modeled here — it can dominate the GNSS term and is characterized separately in the plan-5.3 validation document. When σ is UNKNOWN (α-β estimator, pre-v3 sidecars) the policy falls back to the historical fixed radius — legacy analyses keep their behavior and are marked "incertitude inconnue" by their DEGRADED validity instead. All constants PROVISIONAL until the Gate GPS-5 campaign.

THE order-tracking engine audit A2, D7, plan 3.2 — the single implementation of order-domain folding, EMA smoothing, harmonic-tag detection and emergence-report accumulation. The live pipeline and the WAV sweep both consume this class; the two historical ~130-line copies (which had already drifted) are gone. Stateful (order-domain EMA): one instance per stream — the ViewModel owns one for live capture, and each WAV sweep creates a fresh local one. Methods are synchronized as a belt on top of single-thread confinement (reset() may be invoked from the main thread on transitions L7).

The one description of where a plot's data area is, and how zoom/pan map data to pixels U3, U4, plan 4.2. Two audit findings share this object as their fix: - **U3** — margins and text sizes were raw pixel literals (`150f`, `60f`, `32f`), duplicated across two `pointerInput` blocks and the draw pass. On an xxxhdpi phone the axis gutter measured ~34 dp with ~9 sp text; on mdpi it was enormous. The caller now converts dp/sp ONCE via `Density` and hands the pixel values here, so touch handling and drawing cannot drift apart — they read the same object. - **U4** — pinch-zoom cropped the spectrogram bitmap, but the playhead, emergence beacons, harmonic tags and the H1 overlay were positioned in *unzoomed* plot coordinates, so every overlay detached from the image the moment the user zoomed. Overlays now place themselves through xForFraction/yForFraction, which apply the same transform the bitmap crop does, and containsPlot clips what falls outside the viewport. Coordinates: a *fraction* is a position in the DATA, 0..1 (u across time/frames, v down from the top of the frequency band). Pixels are canvas coordinates. Pure Kotlin: this is the geometry, not the rendering, so it is unit-testable.

plan 3.3, audit §13.4 Assisted manual order tracing — pure and JVM-tested. From the user's anchor points, follows the spectral ridge between them: guide-line interpolation, local-max scoring with jump/guide penalties, sub-bin parabolic refinement, jump clamping, and a 5-point moving average.

A manually-validated tracked order (report mode). Lives in :app, not :core, because its display color is a Compose type plan 3.1.

The single index/time mapping between parallel, uniformly-sampled timelines (FFT frames ↔ telemetry samples ↔ playback position) audit C17, plan 1.4. FFT-frame indices are NOT telemetry indices: a 5-minute WAV has ~12,900 frames but maybe 30 telemetry samples. Every cross-timeline lookup goes through these two functions — never index one list with another's index.

Balise d'harmonique active avec timestamp de persistance pour rémanence visuelle.

Max level around one tracked order's target frequency.

The window the tracked-order search must use, or a suspension.

Where the numbers on screen (and in the exported report) came from plan 4.5, U7. Whoever knows a fact records it here: the live path knows which microphone route the platform actually granted, the analyzer knows the file and how its speeds were reconstructed. A report that prints measurements without saying how they were produced cannot be defended after the fact.

plan-gps GPS-1.2, GPS-03 Maps audio frame indices to BOOTTIME nanoseconds from a (framePosition, nanoTime) anchor — the relation `AudioRecord.getTimestamp` exposes. Guarantees monotonic non-decreasing output across calls even when a fresh anchor steps slightly backward (hardware timestamps jitter): a regression is clamped to the last returned value instead of ever going back in time. Units and time bases GPS-0.5: frame indices are sample frames since capture start; times are BOOTTIME nanoseconds. Pure Kotlin, single-threaded use (the capture loop owns it).

How a frame's capture timestamp was obtained plan-gps GPS-1.2.

plan-gps GPS-1.2, GPS-03 One analysis window with its CAPTURE time. The speed estimate for a spectrum must be evaluated at the BOOTTIME instant the sound was captured — `estimateAt(centerTimeNanos)` — never at the instant the DSP got around to processing it: a backlogged DSP queue used to silently pair a spectrum with a speed newer than the audio. Units and time bases GPS-0.5: times are BOOTTIME nanoseconds (elapsedRealtimeNanos base); pcm is 16-bit mono at sampleRateHz. Deliberately NOT a data class: pcm is a reused-content array and structural equality over it would be wrong and expensive.

GPS quality for the UI LED — driven by SPEED accuracy where available audit G3.

plan 3.3, audit A1/L7 The shared measurement-session state machine — the ONE holder of everything the three ViewModels (live, analyzer, report) measure and display together: source mode, spectral histories, telemetry, order tags/report, kinematics and display settings. Mode/config transitions run through here so the L7 contract has a single enforcement point: registered resettables (the live DSP engines, the analyzer's per-frame tag map) are wiped synchronously on every transition — no EMA or tag built under a previous config survives into the next one. Pure Kotlin: owners register hooks for their Android-side effects (mic enable, player release) instead of the session touching them.

plan 3.3 The pure computation core of the WAV/video analyzer — extracted from the ViewModel so the full-file pipeline is JVM-testable: STFT sweep, theoretical-speed interpolation and the order-tracking sweep.

Raised when the microphone cannot be opened or keeps failing C9 — surfaced to the UI, never a crash.

C5, C7, plan 2.1 The ONE owner of live microphone capture. Settings and enablement changes flow through flatMapLatest: the previous capture is cancelled (mic released via AudioRepository.awaitClose) before a new one starts — the historical bug class where every settings change stacked another producer/consumer pair is structurally impossible here. Disabled (mode != LIVE, or user stop) means no capture flow at all: the mic indicator goes off. A capture error (mic busy, init failure) is reported via onCaptureError and completes only the inner flow — a later re-enable retries cleanly.

Everything a deferred analysis needs from a sidecar GPS-4.4.

The decode loop's mutable state, split out so the loop body reads as two steps. Sample rate / channel count / PCM encoding start from the *input* track format and are corrected the moment the decoder announces its own output format — the two can differ, and believing the input one silently puts the whole analysis on the wrong frequency grid C1 class.

A local, rotating diagnostic log V3, plan 4.7. The audit's error-handling census: 17 `catch` blocks, 10 ending in `printStackTrace()` and the rest silent; no logging framework, no crash reporting, and — for a field tool — no way for an operator to tell anyone *what* went wrong. A failed save, an unreadable WAV or a mic that would not open meant a lost test session with no explanation and nothing to send. Deliberate properties: - **Local only.** The app has no INTERNET permission and this must not create a reason to add one. Nothing is uploaded; the file leaves the device only through an explicit, user-initiated share. - **Bounded.** Two files of MAX_BYTES; the current one rotates onto the previous, which is discarded. A measurement instrument must not fill a phone with logs. - **Off the caller's thread.** A single writer thread, so logging from the DSP or capture path never blocks it C6. - **Never fatal.** Logging failures are swallowed after one Logcat warning: an error while reporting an error must not become the error.

A file the app could not read at all.

Debug-build drive logger — AAA plan step 0.8, schema v2 per plan-gps GPS-0.4. Appends every raw GNSS/fused fix PLUS the estimator's outcome for it to a CSV under the app's external files dir (no storage permission needed; pull with `adb pull /sdcard/Android/data/<pkg>/files/field_logs`). The format is FieldTraceV2 — pure, round-trip-tested — and is the dataset the GPS-2 Kalman is tuned against GPS-13. The header carries an anonymized identity: a random per-install UUID plus the device model (needed for the GPS-5 device matrix; no serial, no account data). Time bases GPS-0.5: nanos columns are BOOTTIME; utcTimeMs is Location.time for human labeling only G1. Absent values are empty fields, never NaN. Must never affect the app: all I/O on its own single thread, all failures swallowed after one log line. Callers gate on BuildConfig.DEBUG.

plan-gps GPS-0.4, GPS-13 Drive-trace schema v2 — the pure codec behind the debug FieldLocationLogger. Schema v1 recorded raw Location fields only and used NaN as its absence marker. v2 adds the callback delivery time, the estimator's outcome per fix (state, validity, rejection), and an anonymized device identity in the header — exactly the data the GPS-2 Kalman is tuned and validated against. Absence is an EMPTY CSV field, never a numeric sentinel (Gate GPS-0). Units and time bases GPS-0.5: `*Nanos` columns are BOOTTIME (elapsedRealtimeNanos); `utcTimeMs` is `Location.time`, kept for human labeling only — never for interval math audit G1. Speeds m/s, accelerations m/s², distances meters, bearings degrees.

The analyzed audio of a loaded WAV/video source, in its OWN sample rate audit C1.

`model=` is last on the header line: device models may contain spaces.

One raw fix + the estimator's outcome for it. Null = value absent.

One saved measurement: WAV plus optional telemetry JSON sidecar.

Recording persistence audit C4/S3, plan 1.7. API 29+: MediaStore.Downloads under Download/NVH_Spectro_Exports/<name>/ — the supported path on scoped storage (the old direct-File writes failed silently on Android 10). Below API 29 the legacy public-directory path is used; failures there surface to the caller instead of losing data silently. All methods are blocking — call from Dispatchers.IO.

Typed outcome: the caller can say *why* an extraction produced nothing.

S1, plan 3.6 Settings + kinematics survive process death. The historical app persisted NOTHING — an overnight OS kill silently discarded the whole test configuration, including the painstakingly-entered GMPe chain. Restore runs once at startup (before observers start, so defaults never clobber stored values); every later change is written back, debounced so slider drags do not hammer the disk.

S2, plan 3.6; plan-gps GPS-4.3 The telemetry sidecar format — kotlinx-serialization replaces the historical string-concatenation writer. Schema v2 added `schemaVersion`, `appVersion`, per-sample monotonic `elapsedRealtimeNanos`, `altitude` and `speedAccuracyMs`. Schema v3 makes the sidecar metrologically complete GPS-09/13/14 surfaces: per sample the ESTIMATED speed with its 1-σ and validity plus the paired audio-frame BOOTTIME; per document the estimator identity/parameters, the capture-time speed status ("causale" — deferred RTS smoothing happens at analysis, not capture GPS-4.4) and the order-search confidence level GPS-4.2. The reader decodes every version: v3 restores σ/validity; v1/v2 sidecars carry no uncertainty, so their estimates come back DEGRADED (usable, "incertitude inconnue") with σ = null — never 0-as-unknown.

A file the app can read but deliberately refuses to analyse (24-bit, float, 5.1…). detail is the offending value (bit depth, channel count) for the message.

Decodes a video's audio track to mono 16-bit PCM for analysis C12, plan 4.8. Four defects the audit found in the previous implementation are fixed here: - the decode loop exited as soon as the *input* side queued EOS, dropping every output buffer still in flight — the last fraction of a second of audio was silently lost; - PCM accumulated in an `ArrayList<Short>`, i.e. ~13 M boxed objects for a 5-minute file (hundreds of MB of object overhead and GC storms on mid-range devices); - `INFO_OUTPUT_FORMAT_CHANGED` was ignored, so the decoder's *actual* sample rate, channel count and PCM encoding were assumed rather than read — a decoder that resamples produced a correct-looking spectrogram on the wrong frequency grid C1 class; - failures printed a stack trace and returned null, so the caller could not tell "no audio track" from "unsupported encoding". Progress is reported through onProgress (0..1) so the UI can show real progress instead of an indeterminate spinner for the many seconds a long video takes.

Real RIFF parser audit C2: walks chunks (tolerates LIST/fact/bext/JUNK…), takes the audio format from the `fmt ` chunk instead of assuming a canonical 44-byte layout, downmixes stereo to mono, and rejects what it cannot decode honestly (non-PCM, non-16-bit) instead of producing spectral garbage. Buffers are sized from the actual data chunk — no blind max-size allocation.

Why a WAV import failed audit C2, plan 1.2; §12, plan 4.4. The reader reports *what* happened; the UI decides how to say it. The messages used to be French literals built inside the RIFF walker, which made them impossible to localise and impossible to assert on without string matching.

Typed outcome of a WAV import audit C2, plan 1.2.

plan 3.3 The analyzer third of the historical MainViewModel: WAV/video loading, the full-file sweep (computed in :core's WavAnalysis), playback ownership and the audio filter chain. Shared state lives in session.

plan 3.3 Application-scoped object graph: the ONE MeasurementSession the three ViewModels share. Recreated only with the process.

Data class représentant un pic d'émergence tonale détecté sur la trame courante

plan 3.3 The live-capture third of the historical MainViewModel: microphone pipeline (one consumer, DSP on the "nvh-dsp" thread C5, C6), GPS speed, the 30 s field recorder, and live display settings. All shared measurement state lives in session.

What the app is actually allowed to do right now U1, plan 4.1. Each capability degrades on its own. The old flow demanded all three permissions and parked forever on "En attente des permissions…" if any was denied — with no rationale, no retry and no way to reach the system settings, so denying *location* (which a user who only wants a spectrogram will do) bricked the app until reinstall.

Builds the session-sharing ViewModels plan 3.3.

L1, L2, L4, L6 — plan 2.3 The one owner of the playback MediaPlayer. - prepareAsync via a suspending API — no more synchronous prepare() on the main thread L4. - Original vs filtered sources are explicit (replaces the fragile "filtered_playback.wav" filename check) L2. - Every acquisition path releases the previous player; release() is idempotent and called from onCleared L1.

Every plot margin and canvas text size, in dp/sp, converted once U3, plan 4.2. The audit found these as raw pixel literals (`150f`, `60f`, `120f`, `40f`, `32f`, `26f`, `22f`) repeated in two `pointerInput` blocks and the draw pass of each canvas. Physical pixels mean the axis gutter is ~34 dp with ~9 sp text on an xxxhdpi phone and enormous on mdpi — very plausibly the "layout bugs found on device" class this project already hit — and duplicating them means touch handling can silently disagree with what is drawn. Canvas text also has to honour the user's font scale: `sp.toPx()` applies it, a raw pixel size ignores it entirely, which is why the old canvases were unreadable at large font scales while the rest of the UI grew §12.

plan 3.3, C6-export PNG snapshot export of the frozen view — bitmap rendering on a background thread, MediaStore write on IO (the historical exportData built a 1400×1850 canvas plus a per-pixel spectrogram loop on the MAIN thread).

The traceability block printed on every exported report U7, D1, plan 4.5, DEV-43. A customer-facing engineering deliverable that carries measurements but not *when*, *by which build*, *from which source* and *with which speed reconstruction* they were produced cannot be defended once it leaves the room. The audit found the PDF carried none of it. Everything here is a fact the app already knows; nothing is inferred.

plan 3.3 The report third of the historical MainViewModel: report-mode snapshots, assisted manual order tracing (computed in :core's SmartPathTracker) and the PNG/PDF exports (rendered off the UI thread in the export/ package). Shared state lives in session.

P1, P2, U2 — plan 3.5 Owns the spectrogram pixel pipeline. - Full-file renders are DOWNSAMPLED to at most MAX_COLUMNS columns — a 5-minute file no longer allocates a ~13k-column bitmap (~52 MB) painted pixel-by-pixel on the main thread. - Rendering runs on a background dispatcher (the caller dispatches); the result is double-buffered so every update returns a DIFFERENT Bitmap instance — Compose repaints on data change, replacing the historical mutate-and-hope-for-recomposition hack (the "black until first interaction" quirk, U2). - One pixel buffer and two bitmaps for the producer's lifetime: zero per-frame allocation in the live path.

Everything the transport row and the picture need, in one value.

plan 3.3 Drives the analyzer's playback position: play/pause/seek state, the per-frame position poll that feeds the spectrum cursor, and the analyzed-end stop C3. The MediaPlayer itself is owned by PlaybackController; the loaded data lives in the session.