No sound on your computer almost always means the audio signal is being lost at one of four checkpoints: the wrong output device is selected, a digital volume or mute control is closed, a driver or audio service has crashed, or the physical output path (cable, jack, speaker, or headphone) has failed. The operating system routes sound to a device it believes is active. When that belief is wrong, the speakers stay silent even though playback continues normally. Work through the chain in signal order and you will find the break in minutes, not hours.
The audio signal chain and where it breaks
Think of computer audio as a pipeline with discrete stages. A media application decodes a file into raw audio samples. The operating system's audio engine mixes those samples with sounds from other apps. A kernel-level driver hands the mixed stream to the audio hardware. The hardware converts digital samples to an analog voltage through a digital-to-analog converter, or DAC. That voltage drives a speaker, headphone, or external amplifier.
A failure at any stage produces the same symptom: silence. This is why "no sound" has dozens of causes that look identical to the user. The diagnostic skill is isolating the stage, and the fastest way is to test the pipeline from both ends.
Start at the source. Play a known-good file in a different app. If a browser video is silent but a local music player works, the fault sits in the browser's output routing or its own volume. If everything is silent, the problem is system-wide and lives at the OS, driver, or hardware layer.
Then test the endpoint. Plug headphones into the same jack and play the same file. If headphones work but speakers do not, the fault is downstream of the DAC: a cable, a powered-speaker switch, or an amplifier. If headphones are also silent, the break is upstream, inside the computer.
This bidirectional test eliminates half the possible causes before you open a single settings menu. Professionals call it a half-split search, and it works because each test cuts the remaining search space roughly in half.
Quantifying the silence: levels, thresholds, and what "muted" really means
Digital audio volume is not a single number. Windows and macOS maintain a master volume per output device, a per-application volume, and often a hardware or amplifier gain stage. Each is a multiplier. A master at 20 percent and an app at 30 percent yields an effective 6 percent, which sounds nearly silent on laptop speakers.
The decibel scale makes this concrete. Halving perceived loudness is roughly a 10 dB drop. Each additional 10 dB of attenuation cuts acoustic power by a factor of 10. A muted channel is negative infinity, not zero, because the multiplier is zero. Many users set an app to "1 percent" believing it is low but audible; at 1 percent on a quiet laptop speaker, output can fall below the noise floor of a typical room.
Mute states compound too. A headphone jack with a physical mute switch, a monitor with its own volume knob at zero, and an OS master at 50 percent can each independently silence the chain. The OS has no idea the monitor's knob is down; it only knows it sent a signal.
Digital silence is also produced by sample-rate mismatch. If an app requests 44.1 kHz and the device is locked to 48 kHz, most modern drivers resample transparently. Some older or buggy drivers instead output silence or a stream of zeros. This is rare but real, and it explains the frustrating case where sound returns after a reboot and vanishes again when a specific app opens.
One professional caveat: a device can report "active" to the operating system while producing no output. Status indicators describe software state, not acoustic truth. Never trust the checkmark alone; trust your ears after a test tone.
Timeline of a typical audio failure
| Time frame | What happens | Typical symptom | Where to look |
|---|---|---|---|
| Instant, after an update | Driver or service state resets | Sound worked yesterday, silent after reboot | Audio service, default device |
| Instant, after plugging in | Jack detection reroutes output | Laptop speakers go silent on headphone insert | Output device selection |
| Minutes to hours | App or OS volume drifts | Gradually quieter, then silent | Per-app and master volume |
| After sleep or wake | Driver fails to reinitialize | Silence until reboot | Driver restart, power settings |
| After a hardware change | Device enumeration changes | Wrong default device selected | Sound settings, device list |
| Weeks, gradual | Speaker or cable degradation | Crackling, then dropout | Physical cable, speaker |
| Sudden, permanent | DAC or amplifier failure | No output on any device | Hardware service |
The timeline matters because it maps the symptom to a stage. An instant failure after an update points to software state. A gradual decline points to physical hardware. A failure tied to sleep points to driver power management.
Edge cases that mimic a dead sound card
Bluetooth introduces its own failure modes. A headset can connect in "hands-free" profile, which is designed for calls and uses a low-quality codec that some apps cannot route music through. The result is silence in the music app while the call app works. Disconnecting and reconnecting, or removing the hands-free profile, restores normal output.
HDMI and DisplayPort carry audio to monitors and TVs. If a monitor is connected but powered off, or the input is switched, the OS may still route audio to it. The computer plays, the monitor is dark, and no sound emerges. The fix is selecting the correct output or disabling the unused HDMI audio endpoint.
Virtual audio devices are a frequent culprit. Streaming software, conferencing apps, and screen recorders install virtual cables that can capture the default output. If a virtual device becomes the default, real speakers receive nothing. The audio is not lost; it is being recorded by software the user forgot was running.
USB headsets and docking stations add enumeration complexity. A dock that reconnects after sleep can leave the OS pointing at a stale endpoint. The device appears in the list but no longer maps to physical hardware. Unplugging and replugging forces re-enumeration.
Red-flag warnings: If you hear a repeating beep pattern at boot, stop and check hardware, not software. If sound fails only in one app, do not reinstall drivers; check that app's audio settings first. If a USB device causes crackling before silence, suspect power delivery or a failing cable. If the failure began after liquid exposure, do not power on repeatedly; seek service.
Misconceptions that waste diagnostic time
The most common misconception is that reinstalling audio drivers fixes everything. Drivers matter, but the default-device and volume-layer problems outnumber driver faults in practice. Reinstalling drivers also rarely resets per-app volume, so the original problem can persist through a full reinstall.
A second misconception is that "no sound" and "no audio device" are the same fault. They are not. A missing device is an enumeration or driver problem. A present device with silence is a routing or volume problem. The settings screens look similar but the fixes diverge sharply.
A third is trusting the volume icon. The taskbar icon reflects the master device, not the app's output, and not the physical amplifier. Users turn the icon up while an app remains muted or a speaker remains off.
The counterintuitive detail: sometimes the fix is to make the problem worse. Forcing the OS to re-enumerate hardware by disabling and re-enabling the audio device, or by unplugging and replugging, rebuilds the endpoint. This works because it clears stale software state that no settings menu exposes.
A professional caveat: audio can be present and inaudible because of ultrasonic or infrasonic content, or because the file itself is silent. Test with a known tone, not a favorite track, before concluding the hardware is dead.
Practical actions in signal order
Work from source to speaker, testing after each step.
Confirm playback is progressing. Check the player's timeline and level meter. A paused or buffering player produces silence regardless of audio settings. Select the correct output device. Open the OS sound settings, confirm the intended device is the default, and use the test button. Do not rely on the taskbar icon alone. Unmute and raise every layer. Set master to 50 percent, app volume to 100 percent, and any physical speaker or monitor knob to a known-good position. Run the half-split test. Plug in headphones. If they work, inspect the speaker path. If they fail, inspect the OS and driver path. Restart the audio service or the machine. On Windows, restarting the Windows Audio service clears most transient failures. On macOS, a restart reinitializes Core Audio. Force re-enumeration. Disable and re-enable the audio device, or unplug and replug USB and HDMI connections. This rebuilds the endpoint. Update or roll back the driver only after the steps above fail. Match the driver to the hardware vendor, not a generic package.
Define success before you start. Success means a test tone plays audibly from the intended speaker at a comfortable level and the same tone plays from headphones when plugged in. If both pass, the pipeline is healthy. If only one passes, you have localized the fault to a single stage.
For persistent failures, capture evidence: the exact device name, the OS version, whether the failure follows sleep or updates, and whether other outputs work. This turns a vague complaint into a reproducible case a technician can solve quickly.
Limits of what software can fix
Software cannot repair a blown speaker, a broken jack, a failed DAC, or a severed cable. If headphones work and speakers do not across multiple cables and sources, the speaker or amplifier is the suspect. If no output works on any device and a reboot does not help, hardware service is the appropriate path.
No diagnostic guide can identify a specific failing component remotely. This article explains mechanisms and a testing order; it does not replace hands-on hardware inspection. Do not open a power supply or attempt repairs that require disassembly unless you are qualified.