Permission is not source selection
Allowing a website to use a microphone does not by itself establish that the intended microphone is active. A laptop can have built-in, USB, headset and other input sources. Browser capture requests and the application's selection determine the actual track. Treat permission, selected input and audible result as separate checks before an important authorised recording.
Use the recording application's documented input selector and the operating system's normal controls. Note the actual device label. The word default may follow a system preference that changes when hardware is connected, so it is less informative than identifying the source used for the session. Do not grant unrelated websites microphone access to investigate one recorder.
A hypothetical desk recording
Suppose a creator connects a USB microphone but the browser application continues using the laptop microphone. Its meter moves and a preview has sound, so the creator assumes the new microphone is working. A short spoken test played back through headphones can reveal that the recording still captures the room from the laptop. The meter established signal presence, not source identity.
Select the intended input through the supported application workflow and repeat the same short test. Keep output volume comfortable and avoid creating feedback. If a communication application is also using the headset microphone, note that arrangement separately. Simultaneously changing input, Bluetooth mode and output makes the comparison difficult to interpret.
Inspect actual settings when developing the tool
For developers, MediaStreamTrack.getSettings reports current track properties, distinct from the constraints originally requested. Supported fields and context vary. A request for a preferred source is not a substitute for checking the result and presenting useful device information to the user. Handle missing or unavailable devices explicitly rather than silently implying the preferred input was retained.
Do not expose raw device identifiers publicly as a diagnostic shortcut. An origin's device identifiers are technical references, not meaningful microphone names for a reader. Provide a clear, accessible selection interface and a short test route. A user should not need to inspect JavaScript objects to know which microphone their own recording application is using.
Recheck after hardware changes
Before the full session, confirm the source after reconnecting a headset, changing a dock or returning from sleep. Then record and replay a small nonprivate passage. Check intelligibility, level and unwanted room sound as well as the presence of a signal. This is preparation, not a claim that the application will never change state later.
If reporting a failure, include the intended input, actual selected label, permission state and observed sample result. Keep private speech out of public attachments. The useful outcome is a verified capture path for the intended task, with microphone access and source selection understood separately from playback speakers and network streaming.
Questions answered
Does a moving input meter prove the intended microphone is selected?
No. It proves signal activity. Check the selected source and replay a short authorised test.
Are requested browser constraints the same as actual track settings?
No. The current track settings describe the selected result; capabilities and context can affect which requested preferences are met.
Sources & further reading
Official references for the subjects discussed. Service terms and device software can change.