Repository navigation
Recording captures only channel 1 of multichannel audio interfaces → silence when the mic is on input 2+ #165
Description
Summary
On a multichannel audio interface (Universal Audio Apollo, Focusrite, MOTU, etc.), Amical records near-silence if the microphone is on any input other than channel 1. Whisper then returns "no words detected", even though the interface, the mic, and all OS permissions are correct.
Environment
- macOS (Apple Silicon), Amical 1.9.x, Local / Whisper Medium
- Audio interface: Universal Audio Apollo Twin (2 preamps; front Hi-Z instrument = ch1, rear Mic 2 = ch2)
- Microphone (SM58) on rear input 2 → Core Audio channel 2
What happens
- Amical history shows repeated "no words detected".
- The recorded WAVs (
$TMPDIR/amical-audio/*.wav) are full length but ~-66 dBFS (digital silence). - Capturing the interface directly and measuring per channel shows the voice is on channel 2, while channel 1 is silent (it's the empty Hi-Z instrument input).
- Zoom / Google Meet / other dictation apps capture the voice fine (they take stereo / the correct channel).
Root cause
The recorder requests a mono stream:
getUserMedia({ audio: { channelCount: 1, sampleRate, echoCancellation: false, noiseSuppression: false, autoGainControl: false } })and the audio-recorder-processor AudioWorklet consumes only channel 0:
const channelData = input[0]; // channel 0 == interface channel 1With channelCount: 1, Chromium hands over only the device's first channel, so any mic on channel 2+ is dropped. (Confirmed empirically: the recorded audio is bit-for-bit the interface's silent channel 1, not a downmix.)
Impact
Anyone using a pro audio interface with the mic on an input other than #1 — an extremely common studio configuration — gets unusable, silent dictation with no error explaining why.
Suggested fix
Capture at least two channels and let the worklet pick the channel that carries signal (or expose a channel selector). A minimal, backward-compatible change:
channelCount: 1→channelCount: 2- worklet:
const channelData = input[0];→const channelData = input[1] || input[0];
The || input[0] keeps ordinary mono microphones working unchanged. A more complete fix could auto-select the loudest channel or add a UI channel picker. PR with the minimal version to follow.
Activity
haritabh-z01 commentedon Jul 15, 2026
Based on all my research media recorder should be already handling this.
Can you please share a mechanism to test this out @fututukamono (virtual mic or whatever mic you use etc)
fututukamono commentedon Jul 15, 2026
Sure — here's a self-contained repro plus the exact spot in the code.
Where it happens: the recorder calls
getUserMedia({ audio: { channelCount: 1, ... } })and theaudio-recorder-processorworklet reads onlyinput[0]. WithchannelCount: 1, Chromium hands over only the device's first channel (it does not downmix), so any input device whose mic sits on channel 2+ records that device's silent channel 1.Repro without a pro interface (virtual mic):
Real hardware (mine): UA Apollo Twin, SM58 on rear input 2 = Core Audio channel 2, front Hi-Z (ch1) empty. Amical's WAVs come out at ~-66 dBFS (digital silence) — bit-for-bit the interface's silent channel 1, not an attenuated downmix, which is what pins it to discrete channel-0 selection. Zoom/Meet capture fine (they take stereo).
Minimal fix (mono mics stay unchanged via the fallback):
Local patcher + full writeup: https://github.com/fututukamono/komochi — happy to open a PR with the minimal change, or a fuller version that auto-selects the channel carrying signal.
iibaranov-IG commentedon Sep 14, 2026
The fix is ready for hardware validation in PR #184: #184
@fututukamono, could you please test that build with the Apollo Twin selected, place the microphone or a test tone on input 2 while input 1 is silent, and confirm that the recorded WAV contains the signal and transcription works? If possible, please also repeat once with a mono microphone to confirm the fallback.
The automated reproduction now passes for a silent channel 1 plus active channel 2, maximum device channel expansion, preservation of the strongest channel without attenuation, mono input, and a device that rejects channel expansion. The full desktop test suite also passes. Physical Apollo validation remains the final check.