If a screen recording is silent, distinguish three possibilities: no audio source was connected, a connected source supplied silence, or the file contains audio but the player is not playing it. A working picture or an enabled microphone does not prove that the app's internal sound was captured.
On September 29, 2026, we generated a test picture and two tones in Chrome 154 on Windows and recorded five conditions. We used Toolit's actual recording and mixing code, native browser encoding, and decoded the output audio. This is a controlled input-path test, not a test of the real sharing picker, system audio, or microphone hardware.
Make three distinctions before repeating the recording
Requesting screen audio does not ensure that a source supplies it.
One connected audio track supplied silence and its measured output signal was zero.
Check both screen sound and narration rather than relying on an input meter alone.
A connected audio track can still store silence
A track is the browser's path for audio data. No track and a connected track supplying silence are different states with different remedies. A and B below are identifiable synthetic tones, not captured voices or actual system sound.
| Condition | Connected inputs | Audio paths into recording | Signal found in output |
|---|---|---|---|
| Screen audio requested, no input track | None | 0 tracks | No decoded audio* |
| Screen track connected, silent input | Screen | 1 track | Silent: measured signal 0 |
| Screen-source test tone A only | Screen | 1 track | A detected |
| Microphone-source test tone B only | Microphone | 1 track | B detected |
| Screen A and microphone B together | Screen + Microphone | 1 track | A + B detected |
- *The first condition had zero audio tracks before recording and no audio codec in its output MIME. An audio-only decoding attempt produced EncodingError. In this case that does not show a damaged video or failed recording.
- The silent condition had one track and decoded successfully, but signal magnitude in the measured interval was exactly zero. A connection label alone cannot rule out silence.
- The mixed result had one output audio path with both tones detected. Counting output tracks does not tell you which source was recorded.
Include screen audio and Share tab audio are separate steps
The recorder's screen-audio setting requests sound. What it receives also depends on the surface selected in the browser picker and whether audio sharing was enabled. MDN documents that a getDisplayMedia request with audio: true may still return no audio track.
For sound from a web page, check the intended tab and Share tab audio first. Window and entire-screen audio depend on the browser and OS. If the picker offers no audio option, a higher picture resolution or a different extension will not supply it. Consider narration alone or a dedicated recorder allowed by your organization.
- Reference pageMDN: screen sharing and optional audio tracks
Narration can be present while screen sound is missing
The B-only condition retained the microphone-role tone even with a missing-screen-audio warning. A-only retained screen-role sound without narration. In a real demonstration, hearing your own voice does not prove that the tab's video sound was included.
A microphone can pick up speakers indirectly along with room echo and noise. Use headphones when directly combining screen audio and narration, and check each input separately. Toolit's live preview is muted to avoid feeding sound back through speakers; input meters are supporting checks rather than proof about the file.
Quieter mixed audio is not necessarily missing audio
Tone A measured about 0.2000 alone and 0.0999 in the mix; B measured about 0.1500 alone and 0.0749 in the mix. Both remained present. This agrees with Toolit's current half-gain per source, which leaves headroom when two sources are added. These are signal-component magnitudes, not perceived-loudness scores.
This mix does not automatically balance narration against loud music. Lower the original app's music level or adjust microphone position and compare a short trial. Other recorders need not use the same gain policy.
Match the next check to the symptom
For an existing file, first check the player's mute setting, volume, and output device. If it behaves the same in another player, inspect inputs before the next recording. Before recording, check the selected surface, actual connections, input meters, and a ten-second saved sample in that order.
| Symptom | Check first | Next action |
|---|---|---|
| Screen audio not connected | Selected surface and audio-sharing option | Cancel and select the intended tab with audio sharing |
| Connected but meter does not move | Source playback, microphone mute, input device | Supply a test sound and one sentence |
| Only voice or only tab sound remains | Both connections and their actual signals | Test each source separately before combining |
| Meter moved but saved file sounds silent | Player mute, volume, output device | Check the downloaded file in another player |
| New files remain silent in other apps too | Device, permissions, browser settings, sharing support | Try an allowed recording environment rather than just lowering resolution |
- Read related articleTen-second trial checklist for a work demonstration
Scope: real system sound and microphone hardware are separate checks
Inputs were intentionally absent or silent, so this test does not estimate the probability of real audio-sharing failures. Results cover one Windows/Chrome setup, short generated pictures, and simple tones—not an empirical screen/window/tab support table, mobile compatibility survey, or company-policy test.
We inspected an interval in the first channel, not every moment of a long recording. File size also depends on picture content and settings; it was not used to diagnose silence. Before an irreplaceable meeting or lecture, test actual screen sound and voice on the same device and surface and reopen the downloaded file.
Test conditions and reproduction
Two distinguishable tones stood in for screen and microphone sources
- 1
We generated a 320×180 picture at 15fps. Tone A at 440Hz represented screen audio and tone B at 660Hz represented microphone audio. Their input amplitudes were 0.2 and 0.15. No real screen or microphone permission was requested.
- 2
Each condition recorded for about four seconds: no audio track, a connected silent track, A only, B only, and A+B. Synthetic inputs fed the production preparation, mixing, recording, and finalization code in lib/screen-recording.mjs. Two inputs used the current 0.5 gain per source.
- 3
All five results were MP4 in this browser. We decoded outputs with audio and measured the first channel for one second starting at 0.5 seconds. A tone component above 0.01 counted as detected.
- 4
Each condition ran once. This is not a human listening test, real meeting-app check, OS support survey, microphone-permission test, or echo-cancellation benchmark. The local reproducible fixture is tests/browser/screen-recorder-audio.html, with instructions and raw observations retained.
Raw reproducibility records (JSON)
The main results are explained above. These raw records contain processing conditions and file hashes. Opening a link displays JSON text, not an illustrated article.
Official documentation used for this analysis
Check both the connection and the saved result
The five conditions distinguished missing audio, connected silence, one recorded source, and mixed sources. Recording completion or a connection label alone does not verify that the required sound was saved.
Check screen and microphone inputs separately, then play a ten-second trial. Renaming a file or making a GIF cannot add sound that was never captured. Select and record again or use a supported environment according to the actual cause.