Windows system sounds play normally, but a browser video remains silent. Raising the main volume does nothing.
This situation does not necessarily indicate a broken speaker or driver. The application may have its own muted volume setting or may be sending audio to another output.
A useful diagnosis follows the sound path in a controlled order: the content, the application, Windows routing, and the intended listening device.
Establish a working comparison
Start with two known sources: one that produces sound and one that does not.
Record the applications involved and the device where sound should be heard. “The browser is silent through the USB headset” is more informative than “the computer has no audio.”
Keep the comparison simple. Use a familiar local file or a known working system sound alongside the affected application.
Do not change drivers, cables, and several settings simultaneously. That makes it difficult to identify which part of the path caused the problem.
Inspect the application’s mixer entry
Microsoft’s guidance for working system sounds but silent apps directs users to Settings, System, Sound, and Volume mixer.
Under Apps, check whether the affected application is muted and whether its slider is set appropriately. Microsoft also notes that an application can use an output different from the system default.
Inspect both controls.
A visible volume slider does not establish that sound is being sent to the headset you are wearing. It may be associated with a monitor, another audio interface, or a previously selected device.
Keep the application producing sound while checking its entry.
Distinguish output from input
Sound settings contain both playback and recording devices.
ASUS’s Windows guidance describes Output as the destination for sound, such as speakers or a headset, and Input as the source, such as a microphone. It also documents separate application volume controls in Volume Mixer.
This distinction matters in meeting applications.
A microphone test can succeed while incoming voices remain inaudible. Conversely, hearing other participants does not demonstrate that the correct microphone is selected.
Test the direction that is failing. For playback problems, begin with the output path.
Check the application’s own controls
Next, inspect the affected application for its own mute button, playback level, or device selection.
A browser tab, media player, or meeting interface may expose another control relevant to the current content. Check the actual session rather than relying only on a global preference remembered from an earlier call.
For a hypothetical docked laptop, write down the intended arrangement: meetings through a headset, media through speakers.
If that separation is intentional, preserve it. If it happened accidentally, simplify the routing and verify the result before rebuilding a more complex setup.
Retest after a connection change
Once sound works, reproduce the situation that originally caused confusion.
Disconnect and reconnect the relevant accessory, reopen the application, or return to the ordinary docked arrangement. Observe whether the selected destination remains appropriate.
If the problem persists after volume and routing checks, record those findings before moving to Microsoft’s further troubleshooting steps for services or drivers.
A precise record prevents repeated advice to “turn the volume up” when that has already been ruled out.
Successful audio troubleshooting ends with sound arriving at the intended device under normal working conditions—not merely with a setting that looks correct.
Sources: Sources: Microsoft: App audio troubleshooting · ASUS: Sound settings and Volume Mixer
