Permission does not select a microphone
An application is allowed to use the microphone, yet your voice is absent from the call. Permission and input selection answer different questions. Permission allows access; device selection determines which input is used. A laptop with a webcam, headset and dock can present several similarly named choices.
Begin with the physical controls. Is the connector seated, is the wireless device charged, and is a switch on the cable or microphone muted? Some headsets mute when their boom is raised. Check the particular model's operation before repeatedly altering software settings. A visible mute light can be more informative than another trip through a privacy menu.
Divide the signal path
Open Windows Sound settings and select the intended input. Speak a short sentence from your normal position and observe the input indicator or use the offered test. If a signal arrives there, that portion of the path is working. If not, concentrate first on the device, connection and operating system rather than on the meeting service.
Then review microphone access in the privacy and security settings. The individual controls available depend on the application type and Windows version. Allow the access you actually need. Organisational policy can govern a managed computer; a locked control is a reason to contact the responsible team, not to run an unfamiliar script intended to bypass the restriction.
Browsers add another permission layer
A browser-based meeting also needs permission for the particular website. Inspect the site settings for the address actually in use. Permission granted to another service or another browser profile does not resolve this case. After changing it, you may need to reload the page or reopen the meeting for the application to request the device again.
Next, explicitly choose the desired microphone inside the meeting application. Do not rely solely on an entry called Default after connecting or disconnecting equipment. Use a preview, recording test or test-call feature where the service provides one. This helps establish that the headset is active rather than the laptop microphone sitting farther away on the desk.
Use a short recording for comparison
A local test recording can help when the input meter moves but clarity remains uncertain. Say two sentences in your normal position and listen through a known working output. Do not record confidential conversation for this purpose. If the recording is clear while the other participant hears interruptions during a call, the connection or meeting application’s processing becomes a more useful next area to inspect.
Adjust noise suppression and automatic level controls deliberately. They can help, but their behaviour varies with microphone, surroundings and application. Filters running in both manufacturer software and the meeting application make comparison harder. Record the active combination and change one setting at a time. Judge the result by intelligible speech rather than by how quiet a meter looks during a pause.
Aim for clear input, not a maximum meter
Adjust the input level using an ordinary sentence. A meter constantly at its maximum can indicate clipping; it is not automatically better than a moderate level. Keep your distance consistent during comparisons. Changing your speaking volume, position and the control simultaneously makes each adjustment's contribution unclear.
If Windows shows a clean input but one application fails, record that application's name, version and selected input. If every application fails, describe the connection and device model. This distinction avoids repeatedly checking the wrong layer. Reinstalling every audio driver is a poor first move while a single incorrectly selected input could still explain the entire observation. A brief, ordered test can usually produce a much more precise support question.
