Clarify limits of meeting audio diagnostics - #1725
Draft
r3dbars wants to merge 2 commits into
Draft
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
A healthy Transcripted recording does not establish that another meeting app transmitted speech. The existing
output_ducking_detected=falseflag only means sampled hardware volume scalars did not drop; it cannot exclude software ducking.Product Impact
What changed
Add three fixed scope descriptors to existing capture diagnostic contexts:
capture_health_scope=own_capture,cross_app_capture_status=unmeasured, andoutput_ducking_measurement=hardware_volume_scalars. Preserve them through the eight existing capture analytics schemas, support packets, and existing Sentry failure tags without forwarding new event types. Events without capture snapshots and older events can lack these descriptors.Add regression coverage for unchanged legacy classifications and privacy/policy delivery. Require receiving-participant audio proof in the meeting QA matrix and add a same-build, built-in microphone crossover checklist. Remove the old suggestion that clean telemetry substitutes for manual audio proof. No automatic capture harness is needed for this first test.
How I checked it
bash build-deps.sh --force.TRANSCRIPTED_SKIP_LAUNCH_SMOKE=1 bash build.sh --no-open; bundle performance budget passed. Launch smoke intentionally skipped to preserve the running app/audio environment.bash run-tests.sh: 12,719 passed, zero failed.bash run-integration-smoke.sh: core and wake smoke passed; sevenMicRecordingFileMergerTestspassed.792d82e159b2f5546e2b474d4a3100a4fe6fa442through head7d36c2490ed282b83c5793dea10e888c5efafa97: no remaining actionable findings.Test binaries used
TRANSCRIPTED_DISABLE_FILE_LOGGER=1. The root Core package and public seam are unchanged; integration ran its mapped package-test filter.Risk Review
Privacy and existing event consumers were reviewed. New values are constant categorical descriptors; there are no new hardware reads, process identities, audio content, storage migrations, or release/update changes. No customer screenshots or diagnostic payloads are included. Draft for human review; no merge or release.
Agent handoff
COORD_DONE: GREEN | this draft PR | diagnostic scope, regression coverage, receiving-audio QA | no cleanup | same-build live test remains | mapped checks and independent review passed | run checklist with a willing receiving participant