Why Isn't My Sound Working on My Computer? A Layer-by-Layer Diagnosis Guide

Your sound is probably failing at one of four points: the app's own output setting, the operating system's default device selection, the audio driver or audio service, or the physical connection and speakers. Because computers route audio through a chain of software and hardware stages, a single broken link anywhere in that chain silences everything downstream. The fastest fix is to identify which link failed rather than reinstalling drivers at random. This guide walks the full signal path, shows what each failure looks like, and gives you thresholds for deciding when to repair, replace, or stop troubleshooting.

The signal chain from app to speaker cone

Digital audio on a computer is a pipeline, and sound only emerges if every stage passes signal. An application generates audio samples and hands them to the operating system's audio mixer. On Windows, that mixer is part of the audio service and the Windows Audio Device Graph Isolation process; on macOS, it is Core Audio. The mixer combines streams from all apps and sends the result to a driver. The driver translates the stream into a format the audio hardware understands—typically PCM samples at a set rate and bit depth. The hardware converts digital samples to an analog voltage through a digital-to-analog converter, amplifies that voltage, and drives the speaker or headphone driver.

Each handoff has its own failure mode. An app can be muted inside its own volume slider. The mixer can route audio to the wrong endpoint, such as an HDMI monitor that is powered off. A driver can crash or hold a stale format, and the audio service can stop running entirely. The hardware chain can break at a cable, a jack, or a dead amplifier.

The key mental model: the volume icon in your taskbar reflects only one stage of this chain. It can show 100 percent while the actual blockage sits three stages away. That is why "the volume is up" is not evidence that audio should be audible.

One level deeper, the format negotiation matters. Modern systems default to 48 kHz sample rate for shared-mode audio, though 44.1 kHz remains common for music playback. If an app requests a format the endpoint does not advertise—say, a higher bit depth or an exclusive-mode stream—the driver may refuse the stream silently. Windows shows this as an app that appears to play but produces nothing, and macOS can behave the same way when an aggregate device is misconfigured.

How often each layer is the actual culprit

Audio failures cluster heavily at the endpoints and the device selection layer, not inside the driver itself. In practical support terms, the distribution looks roughly like this: wrong output device selected, muted app or system stream, or a disconnected jack account for the majority of "no sound" reports. Driver and service faults come next, and true hardware failure is the smallest bucket.

A useful anchor: the 3.5 mm audio jack has been a standard on consumer computers for decades, and its mechanical design—a sleeve, ring, and tip carrying ground, left, and right channels—has not changed in any way that affects troubleshooting. What has changed is that many laptops now ship with a single combo jack that handles both headphones and headsets, and plugging a three-pole headphone plug into a four-pole combo jack can leave the microphone contact floating. The audio still plays, but headset detection logic may misclassify the device. That single mechanical detail explains a surprising share of "my headphones work everywhere except this laptop" complaints.

Quantify the diagnostic value of observation. If sound works in one app but not another, the fault is above the mixer—in the app or its output routing. If no app produces sound but the system chime plays at boot, the fault is in the user session, not the hardware. If the boot chime is also absent, the fault is in firmware, the audio codec, or the speaker path. Each observation cuts the search space roughly in half, which is why a two-minute test sequence beats an hour of driver reinstalls.

Edge cases that mimic hardware failure

Bluetooth audio introduces its own layer stack, and it fails differently from wired audio. A Bluetooth headset can connect for calls and media separately, and on some systems the two profiles are distinct endpoints. If the headset is connected but the system has selected the hands-free telephony profile, media playback can route to a low-quality or silent path. Disconnecting and re-pairing forces the profile negotiation to restart, which resolves a large share of these cases.

USB audio devices add another negotiation step. A USB headset or DAC enumerates as a separate audio endpoint, and the operating system may keep the old default device after the USB device is removed. When the device returns, it may not reclaim the default role. The result is audio playing to a device that is not physically present—silent to you, but the system believes it is working.

Monitor audio over HDMI or DisplayPort is the most common invisible sink. Many monitors and televisions advertise audio endpoints even when their speakers are muted, powered off, or absent. Windows will happily route the default stream to that endpoint. The fix is not a driver repair but a device-selection change, and the same trap appears on macOS with displays that support audio.

Virtual audio devices are a fourth edge case. Streaming software, meeting apps, and some games install virtual cables and loopback devices. These appear as legitimate endpoints and can become the default after an update. Audio then flows into a virtual device that is not connected to any physical output. Checking the device list for unfamiliar names is a fast way to spot this.

A counterintuitive professional caveat: reinstalling the audio driver rarely fixes a misrouted endpoint, and it can reset custom format settings that were working. Support scripts often recommend it because it is easy to script, not because it addresses the common fault. Diagnose the layer first, then repair only that layer.

Red flag: audio works only after a reboot, then fails again within minutes—suspect a service crash or a device that re-enumerates. Red flag: crackling or popping before silence—suspect buffer underruns, a failing cable, or a power delivery problem, not a mute. Red flag: one channel only—suspect a partially inserted plug, a broken jack contact, or a balance setting. Red flag: silence after an operating system update—suspect a driver or format mismatch introduced by the update. Red flag: silence in one app only, with system sounds intact—suspect the app's own output device or exclusive-mode setting.

Why "it worked yesterday" is a different problem

Audio that fails suddenly without any user action usually points to a state change rather than a broken component. The three most common state changes are: an update replaced or reset the audio driver, a device was connected or disconnected and the default endpoint changed, and a service stopped or crashed.

Driver updates are the classic trigger. A new driver may advertise a different set of supported formats, and an app pinned to a now-unsupported format can fail silently. The same update can reset the default sample rate, which matters if the app uses exclusive mode and expects a specific rate. Windows audio enhancements, a layer of processing between the mixer and the driver, can also be reset and cause silence on some codecs.

Device changes are the second trigger. Plugging in a headset, a monitor, or a USB device can change the default endpoint depending on the operating system's auto-switching rules. Those rules are configurable, and they are often the hidden cause when audio "moves" to a device the user did not intend.

Service crashes are the third. The Windows audio service can be configured to restart automatically, which is why a reboot fixes some cases temporarily. If the service is set to manual or disabled by a management tool, it will not restart and the symptom looks like total failure. macOS has an equivalent daemon, and a corrupted preference file can prevent it from starting.

Mapping the time course helps separate transient from persistent faults. A fault that appears immediately after a change is likely a state problem. A fault that develops gradually—crackling worsening over weeks—is more likely a physical or thermal problem. A fault that is intermittent with no pattern is often a loose connection or a marginal power supply to a powered speaker.

Decision thresholds: when to repair, replace, or stop

Practical repair decisions need thresholds, because endless troubleshooting has a cost. Use the following rules of thumb to bound your effort.

First, isolate the software layer with a boot-level test. Play a system sound that does not depend on your user session—the startup chime, a firmware test tone, or a diagnostic tone in the firmware setup utility. If that tone is audible, the hardware chain is intact and you can restrict further work to software. If it is not, the fault is in firmware, the codec, the amplifier, or the speaker, and software tools cannot fix it.

Second, isolate the endpoint with a known-good alternate. Plug headphones directly into the computer's jack and test. If headphones work, the internal speakers or their amplifier path are suspect; if they do not, the fault is upstream in the mixer or driver. Swap the cable if the endpoint is external, because cable failure is common and a replacement costs a few dollars.

Third, isolate the app. Test the same media in a second player. If only one app is silent, reset that app's audio output settings and check whether it is set to exclusive mode. No hardware work is warranted at this point.

Fourth, use the operating system's built-in troubleshooter or audio diagnostic as a last software step, not a first one. These tools can restart the service and reset defaults, which is useful, but they do not reason about the layer structure and can mask the real cause by changing state.

Fifth, apply a cost threshold to hardware replacement. Internal laptop speakers are usually a module or a soldered assembly; replacement requires disassembly and can cost more than an inexpensive USB headset that bypasses the internal path entirely. If the goal is working audio rather than restored internal speakers, a USB or Bluetooth headset is often the cheaper fix, at a typical cost of USD 20 to USD 60 for a basic model. Choose repair only when the internal speaker path itself matters—for portability or for a device where USB ports are scarce.

Sixth, set a time box. If two hours of structured layer testing has not identified the failing stage, the marginal value of more testing drops sharply. At that point, the rational move is a known-good external audio device to restore function, followed by a professional diagnostic if the internal hardware still matters.

What the limits of self-diagnosis look like

Self-diagnosis has real boundaries. Software cannot reliably distinguish a failed amplifier from a failed speaker cone, because both present as silence at the same endpoint. It cannot measure whether the codec is receiving power, whether a solder joint has cracked, or whether a capacitor has aged. Those require a multimeter, a known-good replacement part, or a service manual with test points.

The other limit is that some failures are systemic rather than local. A failing power supply can cause audio dropouts under load while every audio-specific test passes at idle. Thermal throttling can cause the audio subsystem to reset when the machine is hot. A failing motherboard can present as intermittent audio failure that moves between endpoints. These cases resist layer-by-layer testing because the audio path is not the actual fault.

The practical conclusion: layer testing is highly effective for the majority of failures, and it tells you quickly when you have left its domain. When the boot-level tone is silent, when a known-good external device also fails, or when the symptom correlates with heat or load, stop software troubleshooting and move to hardware service or replacement.

Quick reference: fault layers and their signatures

Timeline: what a structured diagnosis looks like

The single most useful habit is to record what changed immediately before the failure. A new update, a new device, a moved cable—each narrows the layer faster than any generic checklist. Sound failures are almost always traceable to a specific stage, and the stage is usually identifiable within the first five minutes of structured testing. The rest of the work is applying the right repair to the layer you found, not to every layer at once.