My sound isn't working

Windows audio has four layers, and “no sound” is what all four of them sound like when they fail: the master volume and mute, the selected output device, the per-app levels in the volume mixer, and underneath all of it the audio driver and the Windows Audio service. The working order is top-down, because each layer is a ten-second check and each one clears a real share of cases. Before you start, note two facts: whether it's every app or one (one app exits you to the one-app guide — the system path is fine), and what changed immediately before (a new monitor, a dock, a Bluetooth device, an update — the update guide starts from that timing).

The sequence. Master volume and mute — the speaker icon in the taskbar; on Windows 11 the full settings live under Settings → System → Sound, on Windows 10 under the same Settings area plus the classic Sound control panel (the labels and layout differ between the two, so follow your version's wording rather than a screenshot). The output device — the selector next to the volume icon; this is the single most common “no sound” cause on this page, because a monitor's HDMI input, a dock, or a Bluetooth device can be the selected output while you're listening to speakers. The mixer — click the volume icon to open the per-app list, where each running app has its own slider and mute; one app pinned at zero looks exactly like a system failure from inside that app. The built-in troubleshooter — Settings → System → Sound → Troubleshoot: it runs automatically, changes nothing without telling you, and is worth one run before you go deeper. The services — if nothing above moved it, the Windows Audio service may be the layer (see the command chip below); if it shows “not running,” starting it is the fix, and if it keeps stopping, that points at the driver. Drivers — the last software step, in its own guide: check and repair the audio driver.

Windows-specific causes worth knowing, because they don't look like typical sound problems: a communications app running can lower or mute everything else by design (Windows has a setting for this in the Sound control panel's Communications tab — the one-app guide covers it); a newly plugged-in display or dock can silently take over as the default output; and a fresh sign-in or profile can reset your device defaults. What to expect at each step: the first three checks either fix it or take seconds to clear; the troubleshooter tells you what it found; the services check is pass/fail. If all of them are clean and the silence holds, you're at the driver or the hardware — the driver guide and the when-to-stop section are the next reads, in that order.

The macOS surface, and where things live — with one honest version note: older macOS versions call it “System Preferences → Sound,” newer ones (Ventura and later) call it “System Settings → Sound”; the controls are the same, the name changed. Two things sit above everything else: the speaker icon in the menu bar (it shows volume and mute — a slashed speaker icon is the classic silent Mac, and clicking it is a two-second fix), and the Output list inside Sound settings, which shows every device macOS can play through: Built-in Output, external displays, Bluetooth devices, and USB audio. The selection in that list is the destination, exactly like Windows — and external displays are the usual impostor, because HDMI and DisplayPort carry audio and a connected monitor can become the default even when it has no speakers.

The sequence. Menu-bar volume — unmute, raise the level. Output list — select Built-in Output (or your speakers/headphones); if a display's name is selected and you're hearing nothing, that's your answer, and unplugging the display or reselecting restores sound. Per-app audio — macOS 13 and later shows a per-app volume list in the sound menu (older versions don't have it, on which an app-specific silence is more likely to live inside the app itself); check the silent app's slider and mute there. Bluetooth — if you're using Bluetooth headphones, the device must be selected in Output; the Bluetooth guide covers the profile and pairing layers. Application-specific — one app silent while others play is the one-app case; the app's own audio settings are the first stop. Restart — macOS audio wedges (a stuck session, a stuck route) clear on a full restart more often than people expect, and it's the cheapest remaining step. What to expect: a wrong-output case fixes itself the moment you reselect; a per-app case is one slider; a wedge case is gone after the restart.

The failure paths, so you know where to exit. If sound broke right after a macOS update and the settings are all correct, the update guide has the macOS branch — reboot first, then Bluetooth re-pair if that's your output, and treat a full system restore as a last resort, not a troubleshooting step. If the display keeps stealing the audio every time you plug it in, the permanent fix is reselecting Built-in Output after connecting (macOS remembers your last choice per connection state, so the habit sticks). And the honest difference from Windows: macOS doesn't expose audio services or driver management the way Windows does — for built-in audio, the realistic levers are the settings above, a restart, and the OS update itself. If every output is silent after all of that, you're at the hardware line — the when-to-stop section is the next read.

The timing clue that changes the diagnosis. “It worked before the update and not since” converts an open search into a bounded one: the update is the suspect, and an audio-relevant update did one of a short list of things — pushed a new audio driver, reset the default output device, changed how the audio controller powers down, or (on a managed machine) applied a policy. Each of those has a specific undo, and each undo is cheaper than a fresh diagnosis from scratch. The first job is to confirm the timing honestly — when was the last time sound worked, and what installed since (Windows Update history; macOS's Software Update list) — because a “broke after an update” that was already flaky before it sends you down the wrong path, and the normal ladder applies instead.

The sequence, cheapest undo first. All apps or one? — if only one app is silent, it's not really an update story; exit to the one-app guide. The default device — an update (or a re-detection of your hardware) can flip the default output; check the output list first, because it's the cheapest possible fix and the most common actual one. A full reboot — not sleep, not restart-to-sleep: a driver update sometimes needs a cold boot to settle, and a wedged audio service clears the same way. Driver rollback — if the update pushed a new audio driver, Device Manager → your sound device → Driver → Roll Back Driver is the most direct undo available (the button only appears when a previous version is on the machine; the driver guide walks it). Uninstalling the update itself — Windows Update → Update history → Uninstall updates: a real, reversible undo, but it takes the whole update back (security updates included, until they re-apply), so it's the last move, not the first. What to expect: a device-reselection or reboot fix is immediate; a rollback or uninstall fix comes after the reboot it requires.

The managed-machine branch, and the red-herring check. On a work or school Mac or PC, an organizational update can change audio-related settings you can't safely touch — a routing policy, a disabled output, a managed Bluetooth restriction — and the fix is IT, not a setting you should be editing; working around an organizational policy is not a repair. The macOS branch of the undo list is shorter and worth stating plainly: macOS doesn't offer easy uninstallation of a point update, so the realistic levers are the reboot, a Bluetooth re-pair (if that's your output), a driver-level rollback where one exists, and — as a last resort, not a troubleshooting step — restoring the system. And the red-herring check that closes the guide: if the honest timing check doesn't hold, or the fault returns with the next update, the update was a trigger on top of a weaker cause (a marginal jack, an aging dock, a failing Bluetooth device), and the Bluetooth, headphones, or laptop guide is where the real cause gets named.

Laptops add a hardware layer desktops don't have, and it sits above every software setting: a dedicated mute key or a Function-key combination (often with a small LED), the headphone jack that's meant to switch the output when you plug in, and — for anyone who uses one — a docking station, which has its own audio chip and becomes a separate output that frequently steals the default. “No speaker sound” on a laptop is therefore four different problems wearing one description: a hardware mute, a jack that thinks headphones are still connected, a dock that's playing, or an actual speaker fault. The guide below separates them, in the order they actually occur.

The sequence. The mute key first — look for a speaker icon with a slash on the function row or a dedicated key; press it once and watch for an on-screen indicator, and check for an LED (a lit mute LED means the laptop was muted at the hardware level and no software setting would have reached it; key layouts vary by manufacturer, so if there's no obvious key, the laptop's quick-reference or the audio utility it shipped with is the map). Unplug everything — dock, headphones, USB-C adapters — and test the built-in speakers alone; a partially seated headphone plug or a dock can hold the output on a device that isn't playing. The output list — with everything unplugged, select the built-in speakers explicitly; a dock user will see the dock as its own device, and that's the one to change. The hardware-versus-software split — play a test tone through the OS itself (the speaker test in the Sound control panel on Windows; any system sound on macOS): if the OS's own test tone is silent, the fault is in the hardware path or the driver, and the driver guide plus the when-to-stop section are next; if the test tone plays but apps are silent, it's a software routing matter and the Windows guide (or Mac guide) applies.

The failure paths, by case. A dock user whose sound “moved” when docking: the dock is the default output — select the built-in speakers (or the dock's output, deliberately) and it's resolved; if the dock's own audio is the dead end, the dock is the component, not the laptop. A headphone jack that crackles or that leaves the speakers muted after unplugging: a worn jack or a stuck detection state — a reboot clears the detection; the crackle persists, and it's a hardware repair decision. And the case that matters most: test tone silent, all software checks clean, and the laptop was recently dropped or exposed to liquid — that's internal speaker or audio-path damage, and the escalation section is the next read, not another round of settings. If Bluetooth is involved at any point, the Bluetooth guide takes over from here.

Wired headphones change the circuit in a way nothing else does: the jack is a physical switch. Plug them in and the operating system is supposed to detect the connection and move the output from the speakers to the headphones — and when that detection fails (a worn jack, a plug that's a millimeter short, an adapter in the middle), the audio keeps going to the speakers and the headphones are perfectly healthy but perfectly silent. There's a second, subtler version of the same problem: your headphones are also paired as a Bluetooth device, so the output is the Bluetooth connection — not the wire — and “plugging them in” changed nothing at all. Both cases look identical from the chair, which is why the sequence below checks what the system thinks is plugged in before it blames anything.

The sequence. Seat the plug fully — all the way in, and on laptops that have two jacks, try the other one. Check what the OS sees — open the output list: it should flip to “Headphones” the moment they're in. If it flipped and you still hear nothing, the suspect is the cable, the contact, or the headphones themselves — and the isolation test is two minutes: the same headphones on another phone or laptop. If it didn't flip, the suspect is detection: try a different cable or a different adapter (a USB-C-to-jack adapter is its own failure point, and a charge-only USB-C cable carries no audio at all — the same lesson as the USB guide's cable rule), or a different jack. Per-application output — if most apps play but one doesn't, that app may still be pinned to the old output; the one-app guide is the fix, and browsers and call apps are the usual offenders. The correct playback device, explicitly — select “Headphones” by name even if it “looks” selected, because a greyed-out or duplicate entry is its own clue.

The failure paths, which are cleaner here than almost anywhere on this page. Headphones silent on every device you try → the headphones or the cable, not the computer — stop, and it's a replacement question. Works in one jack but not the other → the jack (a laptop repair line, or a USB-C adapter workaround in the meantime). Crackle that follows the headphones to another computer → the cable's contact. Crackle that stays on this computer → the jack or the path. And the USB-C headphone note, because it's the modern version of the classic: USB-C headphones need a data-capable connection — a charge-only cable or a charge-only port will power a chargeable headset and pass no audio, which is exactly the “connected but silent” state this guide exists for. If your headphones are Bluetooth-first rather than wired, the Bluetooth guide is the more useful read.

The distinction that resolves most Bluetooth audio cases: a Bluetooth connection and an audio output are two separate things. The headphones can be paired, connected, in range, and fully charged while the audio is routed to a different output — and “connected but silent” is a routing problem, not a link problem, which is why the first fix is the output selector, not a re-pair. There's a second layer that surprises people: Bluetooth audio runs on profiles. The stereo profile (A2DP — music and video, high quality) and the voice profile (HFP — calls, mono, low quality) are different modes of the same connection, and your device switches between them when a call starts or ends. Sometimes it switches back cleanly; sometimes it doesn't, and the headphones sit “connected” on a profile that isn't carrying what you're playing. The table below is the whole of that layer.

The sequence, in the order it catches the most cases. Connection state — Bluetooth settings: is it “Connected” (with a battery reading, on most systems), or merely “Paired”? Paired-but-not-connected plays nothing, and connecting is the fix. Output selection — the device must be the selected output; on Windows the device can appear as two entries (a stereo one and a “Hands-free” one), and picking the stereo entry is itself a fix. What mode you're in — if audio is playing in mono at call quality, the connection is on the voice profile; the fix is the next step. Disconnect and reconnect — toggle Bluetooth off and on (or airplane mode for ten seconds); this resets the profile negotiation and is far cheaper than a re-pair, which is why it comes first. Battery — a Bluetooth device at one percent may refuse to connect or cut audio outright; it's a silly check that clears real cases. Remove and re-pair — forget the device on the computer (and on the headphones, per their manual), then pair from scratch; this is the last software step, and it clears a wedged pairing that reconnects can't. What to expect: a routing case fixes on selection; a profile case fixes on reconnect; a pairing case fixes on re-pair.

The failure paths, and one honest note. If re-pairing plus a different Bluetooth device test both point at your headphones (they're silent on other computers too), it's the headphones, not the stack. If no Bluetooth device works on this computer while wired audio is fine, the fault is the computer's Bluetooth radio or its driver — and since a Bluetooth adapter is itself a USB-level device, the USB guide's controller thinking plus the driver guide are the tools, with the escalation section as the end state. The latency note people keep hitting: Bluetooth audio lags behind video by a fraction of a second, and in the voice profile it's more noticeable — that's expected behavior of the technology, not a fault, and it's one more reason to sit on the stereo profile for media. If your headphones are wired, the headphone guide is the parallel read.

Device-level absence is a different problem from silence: the output is missing from the list entirely (or listed as disabled), and that localizes the fault to detection — a driver state, a disabled entry, a cable or port, or the hardware. On Windows the distinction is visible and useful: the Sound control panel's Playback tab has a “Show disabled devices” option, and a device that appears only after you tick it is a settings problem with a one-click fix (Enable Device), while a device that's absent in both views is a detection problem that goes to drivers and hardware. On macOS the Output list is simpler — no disabled state to speak of — so absence there goes straight to the driver/USB/dock layer. The table below maps each device type to where it should appear and what “missing” means for it.

The sequence by type. Built-in — open the Sound control panel with the disabled-devices view on: if the speakers appear disabled, enable them (done); if they're absent with a warning on the audio device in Device Manager, the driver guide is the fix (rollback first, then a clean reinstall and reboot); if they're absent with no warning and a driver reinstall doesn't bring them back, you're at the hardware line. USB audio — it's a USB device before it's an audio device: a different port and cable first (the USB guide's path logic applies directly), a powered hub if the device draws power, and the device on another machine to clear it. HDMI/DisplayPort — the display has to support audio on that input, and the connection has to carry it (some adapters pass video and not audio); test with a different display or cable before suspecting the computer. Bluetooth — “not detected” in the audio list is normal until the device is actually connected; the Bluetooth guide owns that path. Dock — reseat the dock's connection, test the dock on another machine, and test your audio without the dock; whichever swap changes the result names the component.

The hardware line, stated plainly. A built-in speaker set that's missing from the system entirely — after the disabled-devices check, after a driver rollback or reinstall and reboot, with no recent drop or spill to explain it — is the audio path on the board, and that's a repair decision, not a settings one; the when-to-stop section is the next read. A USB speaker that's absent on every machine you try it on is the speaker. And the one impostor to rule out before any of the above: a “missing” device that reappears after a reboot or a re-plug is a marginal connection (a jack, a cable, a dock contact), and the fix is the reseat that's already working — note it, because it will come back.

YouTube adds its own layers on top of the system's, and they're worth checking before you touch system settings — because “YouTube is silent” is very often not a sound problem at all. Three of them, cheapest first: the player's own volume (the slider in the player's corner — it's separate from the system volume and can be at zero while everything else plays), the tab mute (Chrome and Edge show a small speaker icon on the tab itself; a muted tab is the single most common cause of “YouTube has no sound” and looks nothing like a system fault from inside the video), and the browser's autoplay behavior (browsers can hold a page's audio until you've interacted with it — a video that loads in a new tab without a click may start silent by policy, with a “sound is off” indicator in the player). None of these require a single system setting to be wrong.

The sequence, in that order. Player volume — drag the slider; the icon shows the level, and a slashed icon means the player itself is muted. The tab icon — click the tab's speaker icon if it's showing a slash; that's the whole fix in the muted-tab case. The “sound is off” chip — if the player shows it, click it to enable sound for the page; that's the autoplay-policy case. The system, quickly — master volume and the selected output (twenty seconds; if YouTube is your only audio and the output has drifted to a monitor or a Bluetooth device, this is your fix). Another video — if one specific video is silent while others play, the problem is that video's audio track or its source, not your machine; there's nothing to fix. Another browser — the isolation test: if the same video plays with sound in a different browser, the first browser's profile or an extension is in scope, and the Chrome guide (or the browser's equivalent) is next. What to expect: a muted-tab or player-volume case resolves in the first two steps; a browser case resolves on the incognito or second-browser test.

The failure paths, which are unusually clean for a browser problem. All videos silent in one browser, system audio fine → the browser: the Chrome guide if that's the one, or the one-app guide's per-app volume check (the OS can mute one application specifically, and browsers are frequent victims of it). All apps silent, not just YouTube → it was never a YouTube problem; the Windows or Mac guide is the real destination, and YouTube was just the app you happened to be in. And the site-settings corner case: a browser's per-site settings can carry a media or sound preference for youtube.com specifically (visible in the site info on the address bar) — worth one look if the video plays muted in one browser profile and not another, and the one-app guide has the exact places to look.

Chrome-specific silence has a short list of real causes, and the list is shorter than people assume: the tab or site mute (the speaker icon on the tab, or the site's own sound setting — right-click the tab for the mute-site option, or the site info on the address bar for the setting), the autoplay policy (the “sound is off” state a page can load in, enabled by one click), the operating system's per-app volume (Windows' mixer can have Chrome's own slider at zero while every other app plays — the OS doesn't know Chrome is a browser, only that it's an app), and extensions (audio-routing and some ad-blocking extensions can interfere with media playback — rarer than the first three, but real, and the reason the incognito test exists). A full browser restart and a profile reset sit at the end of the list, not the beginning.

The sequence. Tab and site mute — the tab's speaker icon first (one click), then the site's sound setting if the icon isn't there. The “sound is off” chip — click it in the player; that's the autoplay case and it's a one-click fix. The OS per-app volume — Windows: the volume icon → mixer → Chrome's slider and mute; macOS 13+: the per-app list in the sound menu. This one is worth checking before any in-browser work, because a zeroed OS slider makes every in-browser check look meaningless. Incognito — open the same page in an incognito window: extensions are disabled there by default, so sound working in incognito but not in a normal window names an extension; the follow-up is disabling extensions in your normal window (in half-groups is faster than one-by-one when you have many). Full restart — closing Chrome's windows doesn't quit it; use the proper quit (File → Quit, or the app menu) so the audio session actually tears down. Reset, last — Chrome's reset option (Settings → Reset) restores defaults and clears extensions while keeping bookmarks; it's a “use caution” step — it changes your setup — and it's the end of the line for browser-side causes.

The failure paths. Sound works in a different browser → it's Chrome's profile or an extension, and the incognito result tells you which; the YouTube guide is the parallel read when the silence is video-specific. Sound is silent in every browser → it's not Chrome; the OS per-app volume was the likely culprit if only browsers were affected, or the system path itself if everything is — the one-app and Windows guides take over. And the honest scoping note: Chrome doesn't have a hidden “audio off” master switch that people think it does — if the tab, the site, the OS slider, and incognito are all clean and the silence holds across sites, the problem is upstream of the browser, and staying in Chrome's settings past that point is where hours get lost.

Call apps add their own audio layer on top of the operating system's, and it overrides the system default: the app has its own speaker (and microphone) selection, and whatever it's pointing at is where the call's audio goes — even if the rest of the system is set up correctly. Two confusions dominate reported “call audio” problems, and they're opposites: “you can't hear me” is the microphone side (out of scope here, but worth naming so it's not misdiagnosed as a speaker problem), and “I can't hear you” is the speaker side — which is what this guide covers. The fastest isolation tool in the category is the app's built-in test: Zoom's pre-join audio test (and the equivalent test-speaker option in the audio settings of most call apps) plays a tone through whatever speaker the app is using. If the test tone is silent, the device or the OS is the problem; if the test tone plays and the call is silent, the problem is the call or the other side — and you can stop troubleshooting your machine with confidence.

The sequence. The in-app speaker selection — the arrow next to the speaker icon: pick the device you're actually listening on, then run the test speaker. A call app pinned to a device that's no longer connected (a Bluetooth headset that went to sleep, a dock that got unplugged) is the classic “silent call” with everything else fine. The OS level — with the app set to the system default (if that option exists), the output list and master volume apply directly; the Windows or Mac guide's first three checks are the OS half of this. The per-app volume — the OS can mute the call app specifically (Windows mixer / macOS per-app audio); a zeroed slider for the app explains a silent call with a working system, and the one-app guide is the reference. One accuracy note on “permissions”: operating systems don't gate an app's playback the way they gate its microphone — there's no “allow sound” permission to find; the per-app volume slider is the real lever, and looking for a permission that doesn't exist is a common time-sink. Bluetooth — if you're on Bluetooth in the call, the connection drops to the mono voice profile by design (the Bluetooth guide's table): audio changes, quality drops, and some setups don't switch back cleanly — running the call on wired speakers once tells you whether the Bluetooth path is the variable.

Common call-audio mistakes, because they're so frequent: expecting low latency from Bluetooth while watching video (the lag is the technology, not a fault); a dock or headset connecting mid-call and flipping the default out from under the app (the in-app selection is the fix, and re-selecting after the change); and the microphone/speaker inversion — the caller is told “you're muted” and reports “no sound” when the actual state is that their mic is muted and everyone else's audio is fine. The failure paths: test tone silent with the app's device selected → the system or the device (the OS guides, then the not-detected guide if the device has vanished); test tone fine, call silent → the call itself or the remote side, and the productive next step is asking the other party to run their own test; every app fine except the call app, test tone included → the app's audio session, and a full quit-and-restart of the app (not just closing the window) is the first fix, with the app's reinstall as the end of the line.

The isolation that changes the whole diagnosis: if app A plays and app B doesn't, the system's audio path is demonstrably working — the mixer, the driver, the output, the hardware. The fault is in how app B's audio is being handled, and there are exactly three mechanisms for that. Per-app volume: the operating system keeps a separate level (and mute) for each running app — Windows shows it in the volume mixer (click the volume icon), macOS 13 and later shows it in the per-app list in the sound menu — and app B's slider at zero, or its mute on, produces precisely this symptom. Per-app output routing: some apps pick their own output device independent of the system default — call apps, audio workstations, games, and a few others — and app B may be pinned to a device that isn't playing (a disconnected Bluetooth headset, a monitor without speakers). The app's own settings: internal volume, mute, and device selection that live inside app B — browsers mute individual tabs and sites, and the YouTube and Chrome guides are the browser version of exactly this.

The sequence, in the order it resolves. The per-app volume — open the mixer (or the macOS per-app list) and find app B: is its slider at zero, or is its mute engaged? This is the most common cause and a five-second fix. Note the shape of the symptom: in the per-app-volume case, app B is silent everywhere — every site, every video — while app A is fine, which distinguishes it from a tab mute (silent on one site, fine on the next). The app's own audio settings — device selection and in-app volume, if app B has them; for a browser, the tab/site mute and the player volume come first (Chrome guide); for a call app, the in-app speaker selection (Zoom guide). The Windows communications setting — the one that bites specifically when the “working app” is a call app: Windows can lower or fully mute other applications while a communications app is active, by a setting in the Sound control panel's Communications tab. If the silence only happens while a call is running, that setting is the first thing to look at — and setting it to “Do nothing” is a reversible, well-documented change. Restart app B — a wedged audio session (an app that opened its output before a device change, a crash-recovered media pipeline) clears on a full quit and relaunch; it's the cheapest remaining step and it clears a real share of cases.

The failure paths, which end the category cleanly. App B is silent on another computer too, with the same per-app checks clean → app B itself (its build, its media codecs, its settings) — the fix is the app, not the machine. The per-app slider was the cause → done, and the habit to keep is glancing at the mixer before any deeper work, because a zeroed per-app slider is the cheapest “no sound” there is. And the escalation that closes the loop: if app B is a browser and the per-app, tab, and site layers are all clean, the Chrome guide's incognito test is the next move (it separates an extension from the profile); if app B is the only thing affected and every layer is clean on this machine and another, the app is the component — and “the app” is a legitimate end state, not a failure of the diagnosis.

The specific state: the volume is up, the icon says unmuted, activity levels are moving, and nothing is heard. It feels like the worst version of the problem — the computer is doing everything right and producing nothing — but it's actually the most localizing state on this page, because it proves the audio is going somewhere. The sound is being sent to the selected output, and the selected output is a device you're not monitoring: a monitor's HDMI input (a display with no speakers is a dead end that still “plays”), a dock with no audio wired to it, a Bluetooth device that's connected but not on your head, or — on multi-monitor setups — a second display. The silence isn't in the level; it's in the destination. The table below is the list of dead ends, because the list is short and the fixes are all the same move.

The sequence. The output list, first and only — what is actually selected? If it's anything other than the device you're listening to, select that device and listen: in the dead-end cases, sound returns the moment you do, and that's the whole fix. The per-app mixer, second — “shows sound” can come from other apps while the app you're testing has its own slider at zero; check the specific app's level in the mixer (the one-app guide is the full version). Bluetooth routing, third — if a Bluetooth device is selected and you're not wearing it, that explains both the “active” indicator and the silence; the Bluetooth guide covers the profile layer if the quality is wrong too. The hardware test, last — with the built-in speakers explicitly selected and a test tone playing (the OS's own test, not an app's): if the tone is silent on the speakers but plays through headphones in the same machine, the speaker hardware or its amplifier is the suspect — a laptop's internal speakers failing is a real and not-rare end state, and the when-to-stop section is where it's handled. What to expect: a destination case fixes on reselection, immediately and verifiably; a hardware case announces itself with the test tone.

The failure paths, and the one to not rush. If reselecting every output in turn produces silence everywhere — including headphones and a USB audio device if you have one — the problem has moved upstream of the output: the audio engine (driver or services — the Windows guide's lower half and the driver guide) or the machine's audio path itself. That's the transition from “shows sound but silent” to the system-level guides, and it's the right transition — this guide's job was to prove the destination was the problem or rule it out, and the test tone is the evidence either way. The one thing not to do in this state is start buying or swapping hardware: the destination dead-ends above account for most “active but silent” reports, and a spare pair of headphones (usually already owned) separates the remaining cases for free.

When the driver is the suspect — and how to know it is. A driver is the least common cause of “no sound” and the most time-consuming, which is why it sits last in the ladder: the settings-level checks (volume, output, mixer) clear the majority of cases in minutes. The signs that the driver is actually in scope: a warning icon on the audio device in Device Manager (a Code 28 or 43, the same codes the USB guide decodes); sound that broke immediately after a driver or OS update (the update guide hands you off here); or a device that was present and is now missing after a reboot, with the services running and the settings correct. A driver problem usually follows a change; a settings problem doesn't — that's the test that decides whether this guide is open in the first place.

The sequence, Windows first (macOS branch below), using only legitimate sources. Find the device — Device Manager → “Sound, video and game controllers” (and “System devices” for a controller-level entry): read the warning and its code before doing anything — a Code 43 is the device reporting a fault, which tilts the diagnosis toward hardware; a Code 28 is a missing driver component, which is squarely fixable. Update — Properties → Driver → Update Driver → Search automatically: this lets Windows Update supply the driver, and for most machines Windows Update is the driver source (Intel, Realtek and the like publish their audio drivers through it). Roll back — if an update pushed a new driver version and broke sound, Roll Back Driver is the most direct undo available, and it's reversible (you can re-apply the newer version later); try it before a reinstall whenever the button is present. Reinstall — Uninstall device, then restart: Windows reinstalls the audio driver automatically at boot, and a wedged driver state clears on the reinstall better than any amount of clicking Update. Audio is gone for the duration of the operation — that's expected, not a new problem. The manufacturer's page — for laptops especially, the OEM's support page (matched to the exact model) is the right source, because laptop audio drivers carry the function-key mixer behavior; for desktops, the motherboard maker's page. And the source rule, stated once and meant absolutely: no third-party “driver updater” packages. The audio driver stack is maintained by Windows Update and the hardware maker, the updaters are a well-known source of new problems, and nothing in this page requires one.

The macOS branch, honestly scoped: macOS doesn't expose user-facing driver management for built-in audio the way Windows does — there's no Device Manager equivalent, and the built-in audio “driver” is part of the operating system. The realistic levers, in order: a full reboot (macOS audio wedges clear on one more often than the statistics suggest), a Bluetooth re-pair if that's the affected output (the Bluetooth guide), and the OS update itself as the maintenance path. USB and Bluetooth audio devices on a Mac are usually class-compliant and need no driver at all — a missing USB audio device on macOS is a cable/port/device problem (the USB guide's path logic) before it's anything else. The failure path that closes both branches: a driver rollback and a clean reinstall that don't restore the device, with no warning code to explain it — the device layer is the suspect, and the not-detected guide plus the when-to-stop section are the next two reads, in that order.