Identify input and output separately
Open the meeting application's audio settings and read the selected microphone name. The speaker selection is a different control. Hearing the call through headphones does not prove that speech is being captured by the headset microphone. Choose both devices deliberately rather than relying on an ambiguous default entry.
Use the application's microphone meter or supported test-call function. Speak at your ordinary level and check that the intended microphone responds. If there are several similar names, disconnect an optional device temporarily when safe and observe which entry disappears. Do not tap or scrape the microphone loudly as the first test.
Check mute and permission
Inspect the headset's physical mute control, any inline control and the application's mute state. Some devices indicate hardware mute separately from the meeting interface. If no meter responds, check system microphone permissions and browser-site permission for a web meeting. A work policy may restrict access and should be handled by the administrator.
Position the microphone according to its maker's guidance, away from direct breath and rubbing clothing. Record a short harmless sample where the software permits it and listen back. A moving meter confirms input, but the recording reveals whether the voice is clear, too quiet or distorted.
Keep the selection stable
After the test, reconnect any required accessories and verify the selection again. Some applications follow the system default when a device appears or disappears. Learn whether your software remembers an explicit device or switches automatically.
If others still cannot hear you, distinguish between no input locally and a problem only inside the call. Report the selected device, connection type and test result. Avoid raising every gain control to maximum at once; that can introduce distortion while leaving the original wrong-device selection unchanged. Make one adjustment and listen to the result.
