SYSTEM vs MIC vs BOTH for Interpreter Workflows

SYSTEM: capture a supported shared source

SYSTEM is intended for audio supplied by a Chrome-supported tab, window, or screen selected in the browser's share picker. It is often the right starting point when the remote party is speaking through a browser-based OPI or VRI platform and the interpreter wants captions for that remote audio.

The interpreter must select the correct surface and enable shared audio when Chrome offers that option. Some windows expose video but no audio track, some desktop applications cannot be shared as expected, and protected content may refuse capture. A visible screen selection is not proof that sound is reaching the session.

Practical checklist

• Select the exact tab, window, or screen that contains the remote audio
• Enable Chrome's shared-audio option when it is available
• Play a non-sensitive test phrase from that source
• Confirm the audio indicator responds before the assignment
• Stop and choose again if the selected surface has no live audio track

MIC: capture a nearby speaker or approved microphone

MIC uses an approved microphone after Chrome grants permission. It can support an in-room speaker, a telephone played through an external speaker, or the interpreter's own voice when that is the intended reference. Headset choice and microphone direction strongly affect what it can hear.

A microphone is usually a poor substitute for direct system audio when it is listening to a laptop speaker across the desk. Room echo, keyboard noise, ventilation, competing voices, and automatic gain control can all reduce usefulness. Place and test the microphone for the actual acoustic setup rather than assuming permission equals quality.

BOTH: combine supported system and microphone paths

BOTH can create one mono processing stream from a supported shared source and a microphone. It may help when the interpreter wants a visual reference for both the remote caller and a local participant, or when the interpreter needs to inspect both sides during a controlled practice session.

Combining sources introduces tradeoffs. One side may be much louder, speaker playback may enter the microphone and create an echo-like duplicate, and overlapping turns are harder to separate. BOTH should be chosen because the workflow needs both paths, not because more audio automatically produces better captions.

Match the mode to the actual call topology

Draw a simple path: remote speaker to call platform to output device; local speaker to microphone; interpreter to headset or microphone. Then identify which point the browser can access. For a browser OPI call heard through a headset, SYSTEM may capture the remote party while MIC captures only the interpreter. For an in-room encounter, MIC may be the only relevant path.

VRI adds screen-space and device considerations but follows the same principle. The video platform may run in a browser tab or desktop application, and the interpreter still needs to know whether shared audio exists. Keep the video participants and platform controls visible; the caption panel should not displace critical visual context.

Test permission denial and missing-track behavior

A safe setup check includes failure paths. Deny the share or microphone prompt during a non-confidential test and confirm that no live provider session begins. Select a surface without shared audio and confirm that the workspace reports the problem instead of silently using another source.

The product should not fall back from SYSTEM to MIC, or from BOTH to one side, without making the change clear. Silent fallback can make the interpreter believe the remote party is being captioned when the tool is actually hearing room audio.

Control levels, echo, and competing devices

If one source dominates, reduce the loud path at the operating-system or platform level and retest. Avoid placing a microphone next to an open speaker when the same call is already captured through SYSTEM. A wired headset often provides a more stable separation between remote audio and local speech.

Close unused call tabs, disconnect unneeded microphones, and check the browser's selected input. Device names can change after reconnecting a USB headset or switching Bluetooth profiles. A quick harmless sentence from each intended speaker is more reliable than relying on yesterday's setting.

Use the smallest mode that solves the problem

Capturing fewer sources makes troubleshooting simpler and can reduce unnecessary processing. If only the remote browser tab is relevant, choose SYSTEM. If only an in-room speaker is relevant, choose MIC. Choose BOTH when the assignment and platform rules permit it and the combined reference has a clear purpose.

Regardless of mode, tell affected parties and follow the client's rules where required. A live tool that does not keep a conversation archive can still transmit audio to a speech provider while the feature runs. Review that data flow before using real conversation content.

How INTRCO presents the three modes

INTRCO keeps SYSTEM, MIC, and BOTH as explicit Start choices in the interpreter workspace and Chrome side panel. SYSTEM uses Chrome's selected shared surface, MIC uses an approved microphone, and BOTH combines supported shared and microphone tracks into one live-processing stream.

Availability depends on Chrome, the operating system, and the selected surface. INTRCO does not promise capture from every platform or silently substitute a different source. Test the path before work, use only the mode you need, and stop the session when the live reference is no longer required.