Audio: no sound, wrong output, microphone problems, and driver oddities

Sound on Windows travels through a short chain, and each link can fail independently. Understanding the chain is what turns "audio is broken" into "the driver isn't reaching the endpoint," which is something you can act on.

It starts at the source — an app, a game, a video call — which hands its audio data to the audio driver, the software that translates that data into something your physical hardware understands. The driver then sends it to an endpoint: the specific output you've chosen (your speakers, a pair of headphones, a TV over HDMI, a Bluetooth device). A separate but related path handles capture: your microphone sends input through the same driver to whichever recording device is selected. All of this is coordinated behind the scenes by a couple of Windows services that most people never think about until they stop working.

The practical consequence: when audio misbehaves, you're dealing with one of these links, not with "audio" as a whole. The diagram below shows the path, and the table shows what each link does and how it typically fails. Keep this mental model while you read — every guide that follows is about one link in this chain.

Not sure which of the twenty guides you need? Filter by the kind of problem you're seeing, then jump straight to it. Each card links to the full guide below.

"Nothing plays, from anywhere" is the most common audio report — and the one most often caused by the simplest things. Because the cause can be anywhere from a single setting to a failing driver, the reliable approach is a short, fixed checklist worked top to bottom, not random clicking. Stop the moment sound returns and you'll know exactly what fixed it.

The value of a fixed order is that the cheap, harmless checks come first. A muted channel, the wrong default device, or a service that quietly stopped are all fixable in under a minute and can't make anything worse. Only once those are ruled out should you move toward the things that change configuration (a driver, a service restart), because by then you've eliminated a whole class of causes and any change you do make is more likely to be the real fix.

Two clarifications before you start. First, confirm the difference between "no sound" and "very quiet" — a master or app volume sitting at a couple of percent reads as silence to most people, so check the actual level, not just the mute state. Second, make sure your test source actually has audio; a muted video or a podcast with an intro of silence will look identical to a dead sound card. Work the checklist below; it's the same one the rest of this guide assumes you've done.

Verify: play a known-good source (a video with sound, or the Windows "test" sound in the Sound control panel). You should hear it from the device you expect, at a level that's clearly audible — not just present.

The sound plays, but from the wrong place — your laptop's speakers instead of your headphones, or a TV over HDMI instead of your monitor-less desktop. When sound "goes to the wrong device," it's almost never broken; Windows is simply playing to a default endpoint that isn't the one you want.

Windows plays to a default playback device, and that default can be set to anything in your device list. The quick fix is to change the selection: on Windows 11, the device name sits right next to the volume slider in the system tray — click it and pick the device you want. On Windows 10 (or for the full list), press Win + R and run mmsys.cpl to open the classic Sound window, then under the Playback tab select the correct device and click Set Default.

There's a second selection people overlook: the default communication device. Windows can automatically switch to a different output when it detects a "communication" like a video call. If your sound jumps to another device the moment you join a call, that's the setting at work — you can change what Windows does under Sound → Communications. Selecting the device you want as both the default and the default communication device stops most "wrong device" surprises.

Verify: the intended device produces the sound, and — the part people skip — it stays there after a reboot and after joining a call. If it reverts, the communication-device or auto-switch setting is the real cause, not the one-off selection.

Everything plays except one specific program. This is the classic "my browser has sound but my game is silent" situation, and it's almost always the Windows Volume Mixer: each running app gets its own volume channel, and the silent one is usually muted or turned all the way down while the master stays fine.

To open it, right-click the speaker icon in the taskbar and choose Open Volume Mixer (or run sndvol). You'll see a column per running app. Find the silent one, un-mute it, and raise its level. One catch: the mixer only shows apps that are running right now, so open the silent app first, then look for its column. If you don't see it, the app may be routing audio in a way the mixer doesn't list, which points to the app's own settings.

There's a related layer worth knowing. Some applications choose their output device independently of the system default — many games have a per-app output option, and some apps send audio to a specific endpoint. If the mixer shows the app at full volume but it's still silent, open the app's audio settings and check which output it's using. A full-volume mixer channel plus a wrong in-app output is the most common "the mixer looks fine but there's still no sound" case.

Verify: that specific app now makes sound at a normal level while the master and the other apps are unchanged. If the whole system is silent, this isn't your problem — go back to guide 01.

"Speakers not working" is a hardware-and-settings problem wearing a software costume. Before you assume the speakers are dead, rule out the three usual suspects in order: they're muted or low in the mixer, they're not the selected output, or (for external speakers) the physical connection is loose or in the wrong jack.

For external speakers, the connection matters more than people think. A speaker plugged into the wrong port, a 3.5mm plug that isn't fully seated, or a powered speaker that's actually switched off will all read as "no sound" while Windows thinks everything is perfectly fine. The single most useful test is to plug those same speakers into a phone: if they play there, the speakers are fine and the problem is in your PC's settings or driver; if they don't play anywhere, the speakers themselves are the issue and no amount of Windows tweaking will help.

For built-in laptop speakers, the story shifts. There's no cable to check, so the cause is more often the driver or a "communications" behavior that mutes the built-in speakers when a call is active. Confirm the output is set to "Speakers" (not "Headphones" or a connected monitor), make sure no app has triggered a mute, and if it's still silent with everything correct, the driver is the next suspect (guide 15).

1. Confirm power and connection — external speakers powered on, plug fully seated, correct jack.
2. Test the speakers on another device — separates a dead speaker from a Windows problem.
3. Check the mixer and master — unmuted, at a real level (guide 03).
4. Check the output selection — "Speakers" is the selected device (guide 02).
5. Check the driver — Device Manager warning, or the driver is outdated (guides 15–17).

Verify: the speakers produce sound from multiple sources. If they fail on another device too, the hardware is at fault; if they only fail on this PC, it's a settings or driver issue you can still fix.

You plug in headphones and expect the sound to move, but it keeps coming from the speakers. When Windows (or the audio driver) should switch the output on plug-in and doesn't, it's usually one of three things: the detection didn't fire, the driver isn't set to auto-switch, or the wrong device simply remains selected.

Start physically. Make sure the plug is fully seated in the correct port. On many laptops the headphone and microphone share a single combined jack, and a partially inserted plug can register as microphone-only or not at all — reseat it firmly and you'll often hear the click that triggers the switch. If the device has separate jacks, confirm the headphones are in the headphone/line-out port and not the microphone port.

If it still won't switch, select the headphones manually from the output device list (guide 02) — some systems need the "Headphones" endpoint explicitly chosen even after you plug in. And if you have a real audio chip (Realtek, for example), its control applet usually has a "front panel jack" or "auto-detect" option; a disabled auto-detect is a very common cause of exactly this symptom. The fix is to re-enable detection or simply pick the headphone device by hand.

Verify: plugging in now routes sound to the headphones, and unplugging returns it to the speakers. If the switch works both ways, it's fixed; if it only works when you select manually, re-enable the driver's auto-detect so you stop having to.

HDMI carries audio as well as video, so a "monitor" or "TV" can show up as an audio output — often named after the display (a monitor's brand, or "NVIDIA High Definition Audio" / "AMD" for the graphics driver). Whether you want sound through a TV or want it off the TV entirely, this display endpoint is the thing to understand.

The two common problems are mirrors of each other. TV or monitor with no sound: the display's audio endpoint isn't the selected output (so Windows is still sending sound elsewhere), or the TV's own input volume is muted — remember the TV has its own volume separate from your PC's. Sound going to the monitor when you want your speakers: the display endpoint is the default; switch it back (guide 02). In both cases, first confirm the display actually appears in the output device list — if it's missing, the issue is the cable or the display's audio support, not a Windows setting.

Because HDMI audio is negotiated between the PC and the display, the physical link matters. A damaged or low-quality HDMI cable can carry video but drop the audio channel, and the TV must be set to the correct input with its volume up. If you have more than one HDMI port or cable, swapping them is a fast way to isolate a bad cable from a settings problem.

1. Confirm the display appears as an audio output device in the list.
2. Select it as the playback device (for TV audio).
3. Check the TV's own volume and input — it's separate from the PC.
4. Swap cable or HDMI port if the display endpoint is missing or flaky.

Verify: PC audio is audible through the TV or monitor at a reasonable level, with both the PC and the TV volumes up. For the "sound should NOT go to the monitor" case, verify the reverse: your speakers play and the display endpoint is no longer the default.

A Bluetooth device can show as "connected" and still produce no sound — because being paired isn't the same as being the selected audio output. The device is linked, but Windows may still be playing to your speakers, or the device may be offering an audio profile that doesn't match what you want.

First, select it. In the output device list, choose your Bluetooth headphones as the playback device — they may appear as "Name Stereo" or "Name Headset" (more on that below). If they don't appear in the list at all even though they're paired, the device is connected but not offering an audio endpoint; unpair and re-pair it, and make sure it's not already playing audio on another device it's also paired to.

The profile distinction is the part that surprises people. Bluetooth audio has two main modes: Stereo (A2DP) gives high-quality music playback but no microphone, and Headset (HFP/HSP) gives lower-quality audio but enables the mic for calls. A lot of "no audio" and "my Bluetooth mic doesn't work" problems are really a profile mismatch — the device is in the wrong mode for what you're trying to do.

If what you hear is crackling or dropouts rather than silence, that's usually range or interference, or the device switching profiles mid-session — keep it close to the PC and away from other 2.4GHz devices. Verify: audio plays through the Bluetooth device at the quality you expect, and (in headset mode) the microphone works in a test call.

The output device changes on its own — speakers one moment, a monitor or a Bluetooth device the next. When that happens, Windows is usually re-selecting a device automatically, most often triggered by a device connecting or disconnecting, or by a "communication" (a call) starting.

The usual culprit is the communications setting. Windows can lower or redirect audio when it thinks a call is happening. In the Sound settings under Communications, you control what happens: the default "let Windows adjust" can duck or move audio, and that's what feels like the output "switching" during a call. Change it to "do nothing" (or to a fixed volume reduction) and the mid-call jumps usually stop.

The other trigger is devices connecting. When a Bluetooth device or a monitor connects and Windows auto-selects it as the new default, the output visibly changes. The fix is to re-select the device you want and, where the setting exists, stop newly connected devices from overriding your choice. Unpairing a Bluetooth device you don't actually use removes a whole class of surprise switches, since it can no longer grab the default when it powers on nearby.

If the switching is erratic with no clear trigger — no call, no new device — that stops being a settings issue and points at a flaky driver or a failing connection (a loose Bluetooth link or a dodgy HDMI cable). That's when you move down to the driver guides (15–19) rather than keep adjusting selections.

Verify: the output stays on your chosen device through a test call and through a Bluetooth device connecting and disconnecting nearby. If it holds in both cases, it's fixed; if it only holds without the trigger, you've found which trigger to disable.

"Microphone not detected" means the input device doesn't appear at all — which is a different problem from "detected but silent" (guide 10). Here, Windows simply isn't listing the mic as an available input, so the cause is usually that it's disabled, not connected properly, or missing its driver.

Work it in this order. Physically: is it connected and powered? USB microphones need power, and a dead or under-powered USB mic won't register. On a laptop with a combined headphone/mic jack, the plug type must be correct or the mic half won't be detected (the same issue from guide 05). In settings: open Sound settings → Input and see if anything is listed at all. In Device Manager: run devmgmt.msc and look under "Audio inputs and outputs" — is the microphone present, enabled, and free of a warning triangle?

What you find in Device Manager is the key signal. If the device is there but disabled, right-click and enable it — that alone restores a lot of "missing" mics. If it has a warning, that's a driver problem and the answer lives in guides 15–19. If it's absent entirely, the hardware isn't being detected: reseat or reconnect it, try a different USB port, and test it on another machine to separate a dead mic from a Windows problem. A mic that's detected on a phone but not on your PC is almost certainly a Windows/driver issue, not a dead device.

Verify: the microphone now appears in the input list, and — the real test — its level meter moves when you speak. Appearance alone isn't enough; a mic that's listed but shows no level has a different problem (guide 10).

The mic is listed and even shows a level, but in a call no one can hear you (or they hear nothing at all). This is the "detected but silent" problem, and it has a short list of causes: the input is muted, its level is far too low, the wrong input device is selected, or — the most common — the app is using a different microphone than the one you set in Windows.

Check the level and mute first. In Sound settings → Input, there's a level slider and a mute control; make sure it's unmuted and the level is high enough that the meter moves clearly when you speak at normal volume. Then confirm the mic you actually want is the selected input device, not just present in the list.

Then check the app, because this is where most of these problems live. Call apps (Teams, Zoom, Discord, and browsers) each have their own microphone selection that overrides the system default. Open the app's audio settings and confirm it's pointing at the same mic you set in Windows. The "correct mic in Windows, wrong mic in the app" mismatch is one of the most frequent "no one can hear me" causes, and it's invisible if you only look at the system settings.

Finally, rule out permissions: an app without microphone permission behaves exactly like a dead mic (guide 12). Verify: record a short clip with the system's Voice Recorder (or a browser-based recorder) and play it back, or join a test call and confirm your voice comes through at a normal level. If the system recording is fine but the app is silent, the app's own mic selection is your remaining suspect.

Modern systems often list several input devices at once — a built-in laptop mic, a USB mic, a Bluetooth headset, a game controller's mic. When "the wrong mic" is being used, it's because the system or the app picked a different one than you intended. This guide is about making the right one the clear winner.

There are two levels to set, and both matter. The first is the Windows default input, set in Sound settings → Input. The second is each app's own choice, which can override the default (as guide 10 explains). Set the Windows default to your main microphone, and then check the specific apps you care about are actually using it. Fixing only the system default while the app points elsewhere will feel like it "didn't work."

How do you tell which device is which? Name them. In the Sound control panel (mmsys.cpl), each input device can be renamed, so "USB Mic" and "Microphone Array" become "Desk Mic" and "Laptop Mic." Then test each one by speaking and watching its level meter — the one whose meter moves when you talk into your intended mic is the right one. Once named, the right choice is obvious in both the system settings and every app.

Verify: the intended mic is the selected input system-wide and in the apps you use, and its level meter responds to your voice. When the same mic is the choice at both levels, "wrong mic" problems stop happening.

Windows controls microphone access per app through privacy permissions, and an app that "can't access the mic" is very often blocked here even though the hardware works perfectly. This is a permissions problem, not a hardware one — which is why the mic might record fine in one app and be completely silent in another.

There's a master switch and a set of per-app switches. In Settings → Privacy & security → Microphone, the top option ("Let apps access your microphone") is the master: if it's off, no app can use the mic at all. Below it is a list where each app has its own toggle. The fix is often just flipping the specific app's toggle from off to on — but the master must be on for any of them to matter.

Two extra settings trip people up. First, "Allow desktop apps to access your microphone" — if this is off, classic desktop programs (and some games) lose mic access even when the master and the per-app list look fine. Second, browsers have their own permission layer: a website you once blocked can't use the mic until you re-allow it in that site's permission settings (usually a lock/info icon in the address bar). So "the browser mic doesn't work" is often a per-site block, not a Windows problem.

Verify: the previously-silent app can now reach the mic — its settings no longer show access as denied, and a test recording (or a test call) confirms your voice comes through. If the app is allowed but still silent, the problem is back in level or device selection (guides 10 and 13).

The mic works, but it's too quiet, too loud, or it distorts. Input level is a balance, and unlike output volume — which just gets quieter or louder as you change it — an over-driven microphone produces clipping, a distortion that stays present even if you turn the playback volume down afterward. That's the tell that the problem is the input level, not the output.

Set the level by the meter, not by guesswork. Speak at your normal conversation volume and watch the input level meter in Sound settings → Input. You want it to reach a healthy range when you talk but not to peg at the maximum constantly. Adjust the slider until normal speech lands in the upper-middle of the meter without hitting the top — that's the sweet spot between "barely audible" and "clipping."

Two more levers matter here. "Microphone boost," available with some drivers, amplifies a weak mic — but it amplifies the noise along with the voice, which is a very common cause of the hiss covered in guide 14. Use it only if the mic is genuinely too quiet after a normal level. And don't forget the simplest one: a microphone that's "working" but muted reads as too quiet or silent. Check the mute state before you reach for the boost, because a muted-at-max mic and a healthy mic at the right level can look surprisingly similar at a glance.

Verify: your voice is clear at a normal level, the meter moves well without pegging, and there's no new hiss or distortion. If raising the level introduces noise, back off slightly or reduce the boost — clean-but-a-bit-quiet beats loud-but-hissy for anyone on the other end of a call.

"My mic sounds bad" is four different problems, and the fix depends on which one you're actually hearing. Echo is usually the mic picking up what's playing through the speakers. Static or hiss is usually a level, boost, or connection problem. Crackling is often a Bluetooth or sample-rate issue, a driver problem, or a loose connection. Distortion (clipping) is an over-driven input level. Naming the specific sound is half the fix.

Echo: if people hear their own voice come back, your microphone is capturing the output. Move the mic away from the speakers, or — better for calls — use a headset so the microphone and the speaker are physically separated, and enable the app's echo cancellation. A doubled or slightly-delayed echo can also be a driver or network timing issue rather than a physical one.

Static / hiss: lower the input level or turn off the microphone boost (guide 13), and check the connection — a loose 3.5mm plug or a failing USB mic is a classic hiss source. Crackling: on a Bluetooth device, try a different audio rate or move to a wired connection to confirm it's the wireless link; on a wired mic, a crackle that follows a specific action often points at a driver. Distortion: reduce the input level until the clipping stops (guide 13).

Verify: the specific artifact is gone at a normal speaking level, with the input level set per guide 13. Test in a real call, not just a local recording, because echo and network-related crackle often only appear over a live connection.

The audio driver is the software that talks to your sound hardware, and when it's outdated, crashed, or the wrong version, you get problems that no amount of settings changes will fix — silence, crackling, devices that appear and disappear, or a warning in Device Manager. Recognizing that the driver (not a setting) is the culprit is what saves you from tweaking sliders that were never the problem.

There are specific signals that it's the driver rather than a setting. A yellow warning triangle on the audio device in Device Manager. Audio that worked fine and then stopped right after a Windows update. Devices that appear and disappear on their own. Crackling that no level or connection change fixes. Or the audio service repeatedly restarting. If you've done the settings work from guides 1–14 and nothing moved, the driver is the next layer to examine.

To confirm and get the facts, open Device Manager (run devmgmt.msc), expand "Sound, video and game controllers" and "Audio inputs and outputs," and look for warnings. Note the driver name and date (right-click the device → Properties → Driver tab). A driver that's simply missing often shows up as a generic "High Definition Audio Device" with a warning, or under "Other devices" — a clear sign the correct driver isn't installed.

Verify: a driver fault is confirmed when a driver action (update, rollback, or reinstall — guides 16–17) resolves what the settings couldn't. If the warning clears and the audio behaves, you've identified the layer correctly.

An outdated or buggy driver is a real audio cause, and updating can fix it — but a bad "update" can also be the thing that breaks a working setup. The safe principle is to get the driver from the right source (Windows Update or the hardware vendor) rather than from a third-party "driver updater," which very frequently installs the wrong version and is itself a leading cause of broken audio.

The reliable sources, in order: Windows Update — it often already has the correct, tested driver for your hardware; the motherboard or laptop manufacturer's support page — search your exact model number for the audio driver; and, as a last resort, the audio chip vendor directly. The quickest path is in Device Manager: right-click the audio device → Update driver → Search automatically for drivers. Windows checks its catalog and installs a match if a better one exists.

Before you change anything, note the current driver's version and date (Device Manager → Properties → Driver tab). That single note is what lets you roll back if the new driver is worse — and it's the difference between a recoverable experiment and a puzzle. And resist the "driver booster" utilities: they're a source of new problems far more often than a solution, and they can't know your specific hardware the way the manufacturer or Windows Update can.

Verify: after the update, audio works correctly, the specific problem is gone, and no new issues appeared (missing devices, new crackling, lost features). Re-check the Device Manager entry shows the new version and no warning.

Sometimes the right move isn't to update the driver but to reset it — either rolling back to the previous version, or removing it and letting Windows reinstall a clean copy. These are the two "reset the driver" moves, and they're more reliable than any settings change when the driver itself is the problem.

Roll back is the least invasive. In Device Manager, open the audio device's Properties → Driver tab and click Roll Back Driver — if it's available. This restores the prior version, which is exactly what you want when an update caused the problem. The button only appears if a previous version exists, so if it's greyed out or missing, rollback isn't an option and you move to a reinstall.

Reinstall is the cleaner reset. In Device Manager, right-click the audio device → Uninstall device (you can tick the option to delete the driver software if it's offered), then restart the PC. On reboot, Windows reinstalls its default audio driver automatically. This clears a corrupted driver state that neither a setting nor a simple update will touch.

1. Note the current driver version and date (Driver tab).
2. Try Roll Back first if the button is available.
3. If not available or it didn't help, Uninstall the device.
4. Restart — Windows reinstalls the driver.
5. Verify the problem is gone and there's no warning triangle.

Verify: after the rollback or reinstall, the original problem is resolved and the device reports "working properly" in Device Manager. If the problem returns, the driver wasn't the root cause — look at the service (guide 18) or the hardware.

Windows audio is coordinated by background services — primarily Windows Audio (service name Audiosrv) and Windows Audio Endpoint Builder (AudioEndpointBuilder). If one of these stops or hangs, you can get no sound, missing devices, or a system that won't switch outputs — even though every visible setting looks correct. It's one of those layers you never think about until it fails.

To check, run services.msc and find the two services. Both should be Running with a startup type of Automatic (the Endpoint Builder is often "Automatic (Delayed Start)," which is normal). If one is stopped, start it. If it starts and immediately stops again, that's a deeper problem than a simple "it was off" — it's usually a driver or a system file issue, which is when guides 16–17 and a system-file check become the next step.

A careful restart can clear a hung service. Stopping and starting "Windows Audio" briefly cuts all audio for a few seconds while it recovers — sometimes that's all a stuck state needs. You can do it from the Services window, or from an elevated prompt. Just know what it does: it doesn't fix a broken driver, it only resets a hung service, so if the underlying cause is the driver, the problem will come right back.

Verify: both services are running, the audio problem is resolved, and — check again after a reboot — the services stay running. A service that won't hold is a sign the problem is a driver or system file, not the service itself.

When a device is failing, Device Manager shows a specific error code, and the code tells you the category of problem. A "Code 10" on an audio device is a generic "this device isn't functioning" that usually means a driver problem; a "Code 28" means the driver software is missing. Reading the code points you at the right fix instead of guessing between a driver, a service, and a dead device.

To read it: in Device Manager, select the audio device, open Properties, and look at the status line. "The device is working properly" is the good outcome. Anything else is a code and a message that names the category — missing driver, driver failure, or a hardware/ID problem. The table below covers the ones you'll actually see on audio devices.

The right response is usually a driver action — update, rollback, or reinstall from guide 17. If the code is specifically about a missing driver, get the correct one from guide 16. A Code 43 that persists after you've done all the driver work is the signal to suspect the hardware itself: the device may be failing, at which point the answer is repair or replacement rather than more software.

Verify: after the driver action, the device reports "working properly" and the audio it's supposed to provide actually works. The code clearing is necessary but not sufficient — the sound has to come back and stay back.

If you've worked through the settings and the common fixes without success, it's time to stop trying things and start isolating. The goal of this section is to turn "something's wrong with my audio" into a specific, actionable conclusion — "the audio driver is failing," "a third-party program is interfering," or "the physical output is dead." You get there by testing one layer at a time.

The isolation sequence works from the outside in. App vs system: does a known-good source (a video, a system test sound) play? If not, it's system-wide, not one app, and you can stop looking at individual programs. Output vs input: is it playback, capture, or both? That narrows which half of the system to focus on. Recent change: did a Windows update, a driver change, or new hardware line up with when the problem started? A clear "it broke on Tuesday after the update" is worth more than any amount of testing.

The key advanced test is the clean state. A clean boot starts Windows with only the minimum services and no third-party startup programs. If audio works in the clean state but not normally, a third-party program is the interference — and you can re-enable things in groups to find which. If audio still fails in the clean state, the problem is inside Windows itself or the hardware, which points at the driver (guides 16–19) or a physical fault. This single test is what separates "a program is the cause" from "the OS or hardware is the cause."

And know when to stop software work and blame hardware. If the driver is correct and current, the service is running and stable, the clean-state test still fails, and the same device fails on another machine, the output hardware is the problem. At that point, repair or replacement beats any further tweaking — and the systematic process just told you that definitively instead of leaving you guessing.

1. App vs system — test a known-good source; system-wide means stop checking individual apps.
2. Output vs input — decide which half of the system is affected.
3. Find the recent change — an update, driver, or new device that lines up with the start.
4. Run a clean-state test — isolates a third-party program from an OS/hardware cause.
5. Test the hardware elsewhere — a device that fails on another machine is a hardware fault.
6. State the conclusion — driver, interference, or hardware — and act on that one thing.

Verify: you can state a specific conclusion — which layer failed — rather than "I tried a bunch of things." A named cause is what makes the next action (a driver fix, removing a program, or replacing a device) the right one rather than another guess.

If you'd rather not read all twenty, pick the symptom that fits best and follow the suggested route. Each route points you at the right guide(s) for that specific situation.

Audio problems often connect to a few other areas of the library. These are the guides that naturally follow on from here.