You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hex 0.7.3 records silence with a multichannel USB input interface (Scarlett 2i2 4th Gen), even though the UI enters recording mode normally. The red pill appears, but the input meter does not react and the resulting audio file is silent.
This looks related to the 0.7.2+ capture-engine changes, but it is a different failure mode than the earlier double-tap-lock race: it affects normal shortcut-triggered recording on this interface, not just double-tap lock.
Repro
Use Hex 0.7.3 on macOS 26.3
Select Scarlett 2i2 4th Gen as the input device in Hex
Leave Super Fast mode disabled
Start recording with the normal hotkey / modifier-only shortcut
Speak into the interface
Stop recording
Actual
The recording UI starts
The level indicator does not react
Transcription is empty or effectively empty
The capture files produced by Hex are silent
Observed locally on 0.7.3:
Hex logs show the capture-engine path being used (Capture engine armed, Capture engine first buffer)
The generated hex-capture-*.wav files are flat silence (mean_volume: -91.0 dB, max_volume: -91.0 dB)
Expected
Hex should capture real microphone audio from the selected Scarlett input, the same way older builds did.
Why this looks like a Hex bug
The interface and mic path are fine outside Hex:
Ableton records from the same Scarlett input normally
A direct ffmpeg capture from the Scarlett input produces non-silent audio
A plain AVAudioRecorder test on the same machine and device also produces non-silent audio
The regression split is also very clear:
0.7.3: broken, shortcut recording goes through capture engine and produces silent WAVs on this device
0.6.10: works immediately on the same machine, same Scarlett input, same hotkey/settings
After downgrading to 0.6.10, the next Hex recording produced a normal non-silent file (mean_volume: -46.9 dB, max_volume: -29.6 dB).
Notes
The Scarlett enumerates as a multichannel input device on this machine
From local source inspection, newer Hex builds appear intended to prefer recorder fallback for multichannel inputs, but the 0.7.3 release build here still took the capture-engine path
This may be a multichannel-device-specific regression in the 0.7.x recording pipeline
Summary
Hex 0.7.3 records silence with a multichannel USB input interface (Scarlett 2i2 4th Gen), even though the UI enters recording mode normally. The red pill appears, but the input meter does not react and the resulting audio file is silent.
This looks related to the 0.7.2+ capture-engine changes, but it is a different failure mode than the earlier double-tap-lock race: it affects normal shortcut-triggered recording on this interface, not just double-tap lock.
Repro
Scarlett 2i2 4th Genas the input device in HexActual
Observed locally on 0.7.3:
Capture engine armed,Capture engine first buffer)hex-capture-*.wavfiles are flat silence (mean_volume: -91.0 dB,max_volume: -91.0 dB)Expected
Hex should capture real microphone audio from the selected Scarlett input, the same way older builds did.
Why this looks like a Hex bug
The interface and mic path are fine outside Hex:
ffmpegcapture from the Scarlett input produces non-silent audioAVAudioRecordertest on the same machine and device also produces non-silent audioThe regression split is also very clear:
0.7.3: broken, shortcut recording goes through capture engine and produces silent WAVs on this device0.6.10: works immediately on the same machine, same Scarlett input, same hotkey/settingsAfter downgrading to 0.6.10, the next Hex recording produced a normal non-silent file (
mean_volume: -46.9 dB,max_volume: -29.6 dB).Notes
Environment