Skip to content

Require headphones before a session starts - #117

Merged
alpha5611331 merged 2 commits into
mainfrom
feat/headphone-notice
Aug 28, 2026
Merged

Require headphones before a session starts#117
alpha5611331 merged 2 commits into
mainfrom
feat/headphone-notice

Conversation

@alpha5611331

Copy link
Copy Markdown
Member

Closes #116. The cheap half of #111 - useful now, and still useful once the gate lands.

Why this is a correctness fix, not a recommendation

ch_0 is a loopback of the system's render endpoint, so on speakers the microphone hears the interviewer a fraction of a second after the loopback does. The echo lands as a recent Self final, and skipDueToRecentSelf in transcript.service.ts then suppresses the live suggestion for the question that was just asked. There is no error, no card, nothing in the panel. The duplicated transcript lines are the visible half; this is the half that costs the interview.

The dialog says that, rather than recommending headphones for "best results". A user who reads the second version and ignores it has made a reasonable decision on the information given.

What it does

Shown on Start, before the macOS permission gate and before doStart - on speakers the echo is already in the audio by the time the first question is asked. startAfterNotice holds everything from the permission gate onwards so the dialog can hand the start back without duplicating those checks.

Shown on every session until the user ticks "Do not show this again", which persists as headphoneNoticeAcknowledged. Opt-out rather than opt-in: whether the call is on speakers is a property of the machine and the meeting, not a setting, and it can change between sessions on the same install. The preference is written when the user goes through, not when they tick the box, so a tick followed by Cancel does not silence a warning they never acted on.

What it deliberately does not do

It does not try to detect headphones. enumerateDevices() reports what exists, not what the sound is coming out of, and a label match on "headset" is wrong in both directions - it clears a user whose headphones are plugged in but not selected, and nags one whose USB interface is named after a mixer. The user's answer is the only signal available, so it is asked for.

Checks

pnpm lint, both tsc configs, pnpm build and pnpm test:main pass locally. test/config-store.test.mjs gains a check that a store written before this key existed reads as "not acknowledged" rather than silenced - the migration backfill direction that matters here.

Note on merge order

Touches handleStartClick in control-panel/index.tsx, as does #115. Whichever lands second needs a one-hunk rebase there: the confirmation from #115 goes before this notice, so the order is check config -> ask to save the previous interview -> headphone notice -> permission gate -> start.

🤖 Generated with Claude Code

@gitar-bot

gitar-bot Bot commented Aug 28, 2026

Copy link
Copy Markdown

Gitar is working

Gitar

alpha5611331 and others added 2 commits August 27, 2026 22:33
`ch_0` is a loopback of the render endpoint, so on speakers the
microphone hears the interviewer too and the question lands as a recent
`Self` final. `skipDueToRecentSelf` then suppresses the live suggestion
for the question that was just asked, silently.

The notice is shown before every session until the user silences it, and
it names that failure rather than recommending headphones for "best
results". It sits ahead of the macOS permission gate and ahead of
`doStart`: on speakers the echo is in the audio before the first question.

Nothing in the renderer can detect the output route, so the dialog asks
rather than guesses. The preference is written when the user goes through,
not when they tick the box, so a tick followed by Cancel does not silence
a warning they never acted on.

Closes #116

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The dialog is mounted for the life of the control panel, so a tick that
was followed by Cancel survived and was waiting, already checked, the next
time it opened - silencing the warning on a click the user did not
knowingly make.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@alpha5611331
alpha5611331 force-pushed the feat/headphone-notice branch from 88ee7b4 to 4baaa5e Compare August 28, 2026 02:34
@alpha5611331
alpha5611331 merged commit 0191d9e into main Aug 28, 2026
1 check passed
@alpha5611331
alpha5611331 deleted the feat/headphone-notice branch August 28, 2026 02:36
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Nothing tells the user to wear headphones, and on speakers the app goes quiet

1 participant