Audio output can be confirmed without playing a test sound

Problem

During the media preflight, the Sound status currently displays:

Sound — play a test sound and confirm you heard it.

This wording suggests that playing a test sound is required before confirming audio output.

However, the current implementation intentionally allows candidates to confirm their audio output directly without first playing the test tone or test voice.

The instruction should clarify that audio playback is optional.

Root Cause Analysis

In web/interview.js, runAudioCheck() intentionally enables the confirmation button. The source comment explains that the candidate is the only reliable output sensor, so confirmation is accepted whenever the candidate clicks rather than being gated on tone timing.

The confirmOutput() handler sets outputConfirmed = true and calls unblockOutput() to preserve browser audio activation.

Therefore, direct confirmation is intentional. The issue is the wording of the preflight instruction, which implies that test playback is mandatory.

Proposed Change

Current text:

Sound — play a test sound and confirm you heard it.

Proposed text:

Sound — Play a test sound to check your audio, or confirm if it is already working.

The new wording makes it clear that playing a test sound is optional.

Scope

Update the Sound instruction text in the media preflight.
Preserve the existing audio confirmation behavior and browser audio activation mechanism.

Provide a more thorough analysis and identify the root cause.

Thank you for the feedback. I investigated the media preflight implementation further and identified the root cause.

1. The confirmation button is intentionally enabled

In web/interview.js, runAudioCheck() removes the initial aria-disabled attribute from the confirmation button:

nodes.audioHeard.removeAttribute("aria-disabled");
nodes.audioHeard.classList.remove("waiting");

The accompanying comment explains that the candidate is the only reliable output sensor, so confirmation is accepted whenever the candidate clicks rather than being gated on tone timing.

2. Confirmation does not depend on audio playback

The confirmOutput() handler sets outputConfirmed = true without checking whether the test tone or test voice has been played.

Both pointerdown and click events invoke this handler.

3. Browser audio activation is handled separately

The unblockOutput() function creates or resumes an AudioContext in response to a user gesture.

The source comment explicitly explains that candidates who skip the test tone must still be able to hear the interviewer.

This indicates that allowing direct confirmation is an intentional part of the current implementation.

4. The UI reflects the confirmation state

After outputConfirmed becomes true, refresh() updates the preflight state, and paintPreflight() displays the Sound status as "Confirmed".

Conclusion

The root cause is the current design of the preflight flow: audio output readiness relies on explicit user confirmation without requiring a playback test.

The remaining concern is a UX inconsistency: the interface instructs users to play a test sound and confirm that they heard it, while allowing confirmation without attempting playback.

Would you prefer to preserve the existing behavior, or would requiring a playback attempt before confirmation be a worthwhile improvement?

If a change is desired, I would be happy to implement it while preserving browser audio activation and adding a browser regression test.

investigated the media preflight implementation further and identified the root cause.

Update the GitHub issue descriptions accordingly.

@ChenYingHan1121

@ChenYingHan1121 Not accepted as proposed. The comment at web/interview.js:1316-1318 records the decision this would reverse: the candidate is the only reliable output sensor, so confirmation is accepted on their click. A test playback that started proves nothing more. It says nothing about Jim's audio reaching the device routeAudioOutput (web/audio-output.js:82) routes it to, nothing about Meet tab audio reaching the remote listener, and with autoplay blocked it takes away the click that recovers output today.

If the preflight instructions read as if playing the test is required, narrow this issue to that wording: quote the current text and say what it should say instead. Make that change by editing the description, not by filing again.

@ChenYingHan1121

@ChenYingHan1121 The edited body is accepted as scoped: wording only, with confirmOutput and the click-to-confirm behavior left as they are. The text lives in two places that must stay identical: the initial markup at web/interview.html:546 and paintPreflight at web/interview.js:1252, which rewrites it on every refresh. Change both, and keep the lowercase start, since it continues the bold "Sound" label mid-sentence: "play a test sound to check your audio, or confirm if it is already working." Add a browser test that the unconfirmed text paintPreflight writes matches the markup, so the two cannot drift. PR #411 edits the same two files, so rebase on whichever merges first. End the pull request with Closes #359.

@ChenYingHan1121

@ChenYingHan1121 On 2026-10-22 this was accepted as a wording-only change in both web/interview.html and paintPreflight. Is the pull request still coming? Please reply here by 2026-11-05, either way. If it is, a link to the branch is enough. If we hear nothing by then, I will remove the assignment so someone else can take it; the issue stays open.

Thank you for the clarification and guidance. I've decided not to continue working on this issue for now, so please feel free to unassign me and make it available to other contributors.

I appreciate your time and feedback!

I would like to take this, within the scope accepted on 2026-10-22: the wording only, changed in both web/interview.html and paintPreflight in web/interview.js to "play a test sound to check your audio, or confirm if it is already working.", with confirmOutput and click-to-confirm left as they are, plus a browser test that the unconfirmed text paintPreflight writes matches the markup. #411 has merged, so the change starts from current main. One question on scope: while output is the remaining step, the status line shows mediaReadiness's message from web/audio-check.js:127, "Play the test tone or voice and confirm you heard it.", which reads as required in the same way. Should it change in this pull request too, or stay as it is? Please assign this issue to me.

@lakekenny

@lakekenny Thanks for taking this. The scope accepted on 2026-10-22 stands: wording only, with confirmOutput and click-to-confirm left as they are.

Yes, change the output message in mediaReadiness (web/audio-check.js:127) in this pull request too. It tells the candidate the same thing as the two places you are already editing, and left alone it would contradict them. Use "Play the test tone or voice to check your audio, or confirm if it is already working." It starts with a capital because it stands alone as the status line.

Extend the browser test so that, when output is the remaining step, the status line shows this text. Leave the other messages in mediaReadiness as they are. End the pull request with Closes #359.

Navigation Menu

Repository navigation

Audio output can be confirmed without playing a test sound #359

Problem

Root Cause Analysis

Proposed Change

Scope

Conclusion

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Audio output can be confirmed without playing a test sound #359

Description

Problem

Root Cause Analysis

Proposed Change

Scope

Activity

jserv commented on Oct 18, 2026

ChenYingHan1121 commented on Oct 19, 2026

Conclusion

jserv commented on Oct 19, 2026

jserv commented on Oct 21, 2026

jserv commented on Oct 22, 2026

jserv commented on Oct 29, 2026

ChenYingHan1121 commented on Oct 30, 2026

lakekenny commented on Oct 30, 2026

jserv commented on Oct 30, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions