Test playback and recording after an update

Test the intended task, not only the driver version

A driver version shown in Device Manager confirms only that Windows is using a particular driver. Verification should check the route the person needs: internal speakers, an HDMI display, USB headphones, Bluetooth playback, or microphone recording. Playback and recording use different endpoints, so test them separately.

Begin at a low volume. This is especially important after an update because an output selection or level may have changed. Keep the connection used during the original problem in place; moving from a dock to a direct port changes more than one variable.

Check output selection and playback

Open Settings > System > Sound. Under Output, choose the device you actually expect to hear. Open its properties and use the Test control when it is available, then play a familiar local sound. Check that the device is not muted and that the volume control for the application is not set low. If a display is selected, verify it has speakers or an audio receiver attached.

Expected result: sound is heard from the selected physical device at the expected level. Note the exact result rather than simply “audio works”; for example, “speakers work, but HDMI has no sound.” That distinction narrows a later check.

1. Select the desired output in Sound settings and confirm its volume is audible but modest.
2. Use its Test control if shown, then play a known audio item.
3. Switch deliberately to one other listed output only when comparing paths, and note where sound appears.
4. Return to the required output before testing the application that originally showed the symptom.

Check microphone selection and access

In Sound settings, select the intended device under Input and use the input test if available. Make a short recording or use the application’s meter. A moving input meter is useful evidence that Windows receives sound, but it does not prove every application has permission to use the microphone.

For an app that cannot record while Windows sees input, open Settings > Privacy & security > Microphone. Microsoft documents separate controls for microphone access and for allowing apps to access the microphone. Check the relevant control and the application’s own input selection; do not grant access to unrelated applications merely to test the driver.

Expected result: the chosen microphone responds in Windows and in the intended application. A Bluetooth headset can behave differently when its microphone is active because Bluetooth audio profiles and capabilities affect available sound modes; that is not automatically a failed audio-driver installation.

When comparing before and after, use the same file, connection, and application if possible. A browser tab, conferencing app, or game can retain a previously selected device until it is reopened. Reopen only the affected application after the Windows endpoint test, then select the intended device inside that application if it provides its own audio settings.

If the expected result does not occur

If sound appears only on a different endpoint, correct the output choice and inspect the connection before changing software again. For USB equipment, check power and a direct port when appropriate. For Bluetooth, confirm connection and pairing. For display audio, verify the display’s speaker or receiver setup. These checks address common alternative causes without guessing at a driver.

If playback or recording stopped immediately after a known driver update, compare the current Driver tab with your saved note and see whether Roll Back Driver is available. If Windows shows a warning icon, the update failed, or no endpoint appears, use the official package documentation or device support channel. Persistent failure with suitable cables and another known-good audio path may require hardware diagnosis rather than more installations.

Frequently Asked Questions