How to check audio drivers
Confirm that Windows or Mac sound drivers are listed and error-free, and see what that check does not prove before a call.
The short answer
Checking audio drivers means confirming that your computer has working software for your sound hardware: speakers, headphones, a headset, or a microphone. On Windows, that is a status check in Device Manager and Sound settings. On a Mac, built-in microphones and speakers are handled by the system audio stack; you confirm the device is listed and selected, and you look for a separate vendor driver only when an external interface requires one.
A driver check is not a rehearsal for a video call. A device can appear healthy while a browser still lacks microphone permission, a meeting app is pointed at the wrong input, or your voice is too quiet, noisy, or unclear for other people. Playback (what you hear) and capture (what the microphone records) are separate paths; checking one does not check the other.
What “checking the driver” can mean
The phrase covers two different jobs. A status check is reading the device’s name, driver version, and error state, and confirming it is enabled. A signal check is hearing a test sound or watching an input meter move when you speak. The signal check uses the driver, but it also depends on mute, volume, the cable, and which app has the device. Treat those as stacked tests, not as one result.
Before you start
Connect the headset, USB microphone, or audio interface you intend to use and wait a few seconds for the system to enumerate it. If several sound devices are plugged in, match the product name so you inspect the right entry. You need access to system settings; you do not need a meeting in progress. If a call app already has exclusive control of the device, the device may be missing from other lists until that app releases it.
Check on Windows
- Open Device Manager: search for it from the taskbar, or right-click the Start button and choose Device Manager.
- Expand Sound, video and game controllers. Expand Audio inputs and outputs if that category is shown.
- Find the playback device and the recording device you plan to use. A yellow warning, a question mark, or a disabled arrow points to a missing, failed, or disabled driver.
- Open the device’s Properties. On the General tab, read the device status. On the Driver tab, note the provider, date, and version so you can identify the software bound to that hardware.
- Open Settings, then System, then Sound. Confirm the same input and output devices appear, are enabled, and can be set as the system defaults.
- If a classic Sound control panel is offered from that page, use the Playback and Recording tabs to see which device is the default the system will use unless an app overrides it.
Check on a Mac
- Open System Settings and select Sound.
- Under Output, select the speakers or headphones you will use. Under Input, select the microphone or headset microphone.
- Speak at a normal distance and watch the input level indicator. Movement means the capture path is passing a signal. A listed device with a still meter more often points to mute, gain, a hardware mute switch, a cable, or an app holding the device than to a missing built-in driver.
- Play any local sound through the selected output and confirm you hear it. That confirms the playback path, not a meeting app’s speaker choice.
- Open Audio MIDI Setup when you need format details such as sample rate and channel count, which matter for some external interfaces.
- Install a manufacturer audio package only when that interface’s own documentation says macOS requires one. Built-in Mac microphones and speakers use the system audio stack rather than a separately named third-party driver.
Phones, Chromebooks, and Linux
Phones, tablets, and many Chromebooks do not expose a driver list the way Windows does. The practical equivalent is that the microphone and speaker appear in system sound settings, they are not muted, and a system-level check such as a voice memo or an input meter shows activity. On Linux, confirm the card is visible to the desktop sound server, that the intended device is selected, and that it is not muted. A device that never appears after you plug it in is the usual sign of a recognition or driver problem; a device that appears but stays silent is often mute, routing, or permission instead.
How you know it worked
The driver check has worked when the intended input and output are listed, you can select them, Windows reports no current driver error if you are on Windows, and you can read a driver version or see that the system itself owns built-in audio. Add a signal check only if you also need call readiness: the input meter moves when you speak, and you can hear playback. Those extra checks still do not measure whether speech is intelligible to someone else on a call. No microphone percentage or decibel target is specified for this setup; a moving meter is evidence of input activity, not of a correct call level.
| Check | What it establishes | What it leaves untested |
| Device listed in Device Manager or Sound settings | The operating system has associated the hardware with a driver or the system audio stack | Call-app device choice, browser permission, speech quality |
| No warning icon; device status reports it is working | Windows is not currently flagging a driver error | Dropouts, wrong format, exclusive-mode conflicts, later failures |
| Driver provider, date, and version are visible | You can identify which software is bound to the device | Whether a newer vendor package would fix a problem |
| Input meter moves when you speak | The capture path is delivering some signal (input activity) | Intelligible voice, correct loudness, noise, echo |
| You hear a local test sound | The playback path is delivering some signal | Meeting-app output routing and headset fit |
| Site or app microphone permission is on | That app may use the mic | Driver health, physical mute, and whether the sound is usable |
Next steps and limits
If the driver listing is clean and you still have call problems, move to routing and permissions rather than repeating the same Device Manager view. Camera access is a separate permission and does not diagnose speakers or microphones. Physical room backgrounds, virtual call effects, and edited photo backgrounds are unrelated to audio drivers.
- If Windows shows an error, record the current driver version first, then use the Driver tab to update, re-enable, or roll back.
- If a USB microphone or headset is missing, try another port and a cable meant for data, not charge-only.
- If drivers look healthy but a browser call is silent, check that site’s microphone permission and the in-call device menu.
- Do a short recording or a live call if you need to judge whether speech is intelligible; a driver listing cannot show that.