How to Manage Guest Settings in Streamlabs Talk Studio

To manage guest settings in Streamlabs Talk Studio, open Settings in the studio and choose the participant options that match what you want to control: identity, status cues, audio announcements, or screen-share presentation. Settings change how participants appear or receive feedback; they do not put a guest on the live canvas. After a guest joins, you still need to select Show on stream.

A useful way to avoid confusion is to separate the invitation workflow from participant presentation. The host invites and admits a guest, then adjusts the settings that affect the studio or audience. A guest can be waiting in the queue without their microphone being heard on stream.

Open participant settings and invite a guest

Open the Talk Studio studio and select Settings. Streamlabs documents Shift+G as a shortcut for reaching Settings; if it does not respond in your current browser or keyboard layout, use the on-screen control instead. The interface may change, so look for the Settings control in the studio rather than relying only on a remembered screen position. The Participant Settings help article describes the available presentation controls.

Settings and guest admission are separate jobs. To invite someone, choose Add Guest, then copy or email the invitation link and send it with any instructions the guest needs. The guest opens the link, provides a display name, and selects their speaker, microphone, and camera options during onboarding. Streamlabs says invitation links change for each invitation unless the permanent-link option is enabled; check the current studio controls if you intend to reuse a link.

After the guest connects, they appear in the queue. Select Show on stream to place them in the editor. Joining the studio is not the same as appearing on stream: until the host makes that change, the guest’s microphone is not heard on the broadcast. This is worth checking before assuming that a muted indicator or a failed audio device is the cause of silence.

If you are preparing a channel built around a fixed video loop rather than a live conversation, keep the two workflows distinct. A Talk Studio guest is a participant in a live production; an unattended recorded loop has different operating needs. For the latter, see how to keep a YouTube live stream running while your laptop is off. For a mixed format, decide which part of the programme needs a person on camera and when before you send invitations.

Change a guest name and avatar

Use the identity controls when a participant’s label or image should be different from the default. The host can change their displayed name and avatar in Settings, while the guest supplies a display name in their onboarding flow. These are presentation details: they help viewers and other participants recognise who is speaking, but they do not change a guest’s camera, microphone, or place in the queue.

Before going live, agree on the name the guest should use. A short name or role can be easier to read in a compact video layout than a full introduction. If a guest joins under an unsuitable label, do not assume changing a general studio setting will alter every guest’s submitted name; check which participant the control applies to and what the preview shows.

An avatar is useful when the camera is off or a participant is represented by an image, but it is not a substitute for checking the live scene. Review the editor after applying identity changes. Confirm that the name is legible against the video and that it does not obscure a lower-third, caption, or important part of a shared presentation.

For a devotional channel, for example, a guest joining a discussion after a recorded service might be better identified by their familiar name than by a long title that fills the label area. For an interview or local update, a role can help viewers distinguish a presenter from a guest. Choose a label that is accurate and agreed with the participant; keep personal details off screen unless they are intended for the audience.

Control names and audio indicators

Name tags and audio status answer different questions. A name tag identifies a participant; an audio-status cue can show whether that participant is muted. Choose the former when viewers need context and the latter when the host or production needs a quick indication of microphone state. Neither control repairs an audio connection or changes whether a queued guest has been put on stream.

The settings include options for showing participant names and placing them at the bottom, as well as rounding video-feed corners. Treat these as layout choices and check them in the actual scene. A bottom-positioned label may compete with captions or on-screen text, while rounded corners may suit a clean interview layout but trim the visual edge of a guest’s feed. The preview is a better guide than assuming one arrangement works for every scene.

Audio status is also not the same as audible sound. A participant may appear unmuted yet have the wrong input selected, or may be correctly configured but still be waiting in the queue. Check the guest’s chosen microphone, the studio status, and whether Show on stream has been selected before changing unrelated presentation settings.

The result depends on the audience. Name tags are part of the displayed scene, whereas a status cue is primarily useful as a prompt for the host and participants to notice a state. Check the preview and, where practical, confirm with the guest what they can see. Do not assume every indicator is visible to viewers: Streamlabs describes the connection-quality indicators, for instance, as guest-visible rather than viewer-facing.

Set muted-mic and join announcements

A muted-microphone warning is intended to draw attention when a participant speaks while muted. It is a cue, not a control that unmutes the guest or guarantees the correct microphone is selected. If someone is speaking but no sound reaches the production, ask them to check the selected input and browser permission as well as looking at the warning.

Text-to-speech on join serves a different purpose. When enabled, it audibly announces that a guest has joined. This can be useful for a host who is presenting alone and might not notice a new participant in the queue, but it may interrupt a quiet segment or a carefully timed introduction. Consider the programme’s tone and whether the host is already watching the queue before leaving the announcement enabled.

These cues are most useful when their jobs are clear. The muted-mic warning helps a participant notice a possible speaking problem; the join announcement alerts the host to a new arrival. Neither is an admission step. The host still chooses when a guest should be shown on stream, and the guest’s microphone is not heard on stream while they remain only in the queue.

If you are hosting a conversation alongside a continuous channel, plan transitions rather than leaving the audience to infer what has happened. For example, tell viewers that an interview is about to begin, admit the guest, check their audio, and then introduce them. If the main output is a recorded ambience programme, an unexpected join announcement can be more disruptive than useful. A guide to creating an always-on sleep music stream on YouTube may help you think through the difference between a continuous listening experience and a scheduled guest segment.

Adjust speaker and connection indicators

Speaker indicators identify who is speaking, which can help a host follow a multi-person conversation when several feeds are visible. They are a visual aid, not a microphone selector. If the wrong person appears to be active or a participant’s voice is absent, verify the chosen input and the guest’s on-stream state rather than treating the indicator itself as an audio fix.

Talk Studio also offers connection-quality indicators described as visible to guests. This distinction matters: the indicator can help a guest recognise a connection issue, but it should not be presented as a status display for viewers. Ask the guest what they see and whether their audio or video is affected; then decide whether to continue, pause, or invite them to reconnect. The indicator alone does not establish the cause or promise that reconnection will work.

Keep the control’s audience in mind when setting expectations. A host may want a quick visual cue to follow the conversation, while a guest may need their own connection feedback. Those are different uses, and neither changes the underlying presentation state. If the guest is connected but still in the queue, select Show on stream when they are ready; if they are already on screen but cannot be heard, check their microphone selection and permissions.

For channels that also publish recorded material, it can help to plan a separate fallback scene or programme rather than expecting a participant indicator to solve every interruption. A continuous show built from recordings, such as a stream of recorded sermons for a church in Kerala, has a different continuity plan from a live guest interview. The useful choice depends on whether the conversation itself is the programme or one segment in a longer broadcast.

Screen-share controls affect what the host or guest sees, not whether the guest is admitted. Streamlabs documents an option for showing a screen share to the host themselves. If a shared screen appears recursively, like a hall of mirrors, disable Show screen share to self. This prevents the host’s self-view of the share from feeding back into the visible presentation; check the scene after changing it to ensure the audience sees the intended content.

Name position is a separate layout choice. Placing names at the bottom can make participant labels predictable, but it may overlap captions, slides, or other lower-screen graphics. Review a scene with the actual content you plan to share rather than a blank studio preview. Rounded video corners are another visual setting, and should be checked for cropping around text or important details at the edge of a feed.

If a guest will share their screen from a Mac, prepare permissions before the session. Streamlabs’ guidance says the browser needs Screen Recording access in macOS under System Settings > Privacy & Security > Screen Recording; the browser may need to be relaunched after access is granted. Ask a guest who plans to present to check this ahead of time, because permission changes during a live introduction add delay.

A screen share is not automatically suitable for every audience. Check that the guest is sharing the intended window or content, and that notifications or private material will not be exposed. For a channel that alternates between interviews and pre-recorded clips, set a simple hand-off: stop the share, verify the camera layout, then bring the next segment in. A guide to streaming gaming replays on YouTube Live with no downtime covers a different kind of continuity, but the principle is similar: know what viewers should see during a transition.

Resolve camera or microphone permission issues

A guest’s camera or microphone can remain unavailable if the browser has not been granted access, if the wrong device is selected, or if another application is using it. Begin with the guest’s onboarding screen: confirm the intended camera and microphone are selected, then check whether the browser shows a permission prompt or an error. The Streamlabs camera troubleshooting guide gives product-specific troubleshooting steps.

If access was denied, the guest may need to change the browser’s site permissions and reload or rejoin. The exact route varies by browser and operating system, so have them use the browser’s current permission controls rather than follow a path meant for a different device. Streamlabs recommends Chrome for guests on PC, Mac, and Android, and Safari on iOS. That recommendation is a useful starting point, not a guarantee that every camera or microphone will work in every setup.

Work through one cause at a time:

Confirm the guest has joined using the invitation and is visible in the studio queue.
Ask them to select the intended camera and microphone in the guest setup screen.
Check that the browser has camera and microphone permission for the Talk Studio page.
If a device is still missing, close other apps that may be using it, then reload or rejoin and select it again.
Once the guest is ready, choose Show on stream and check both the preview and audible output.

This sequence separates device access from admission. A guest can connect to the room and still have no usable camera, while a guest with working devices can remain queued and unheard until the host moves them to the stream. A permission change may help, but it cannot fix every hardware, browser, or network problem. If the issue persists, consult Streamlabs’ current troubleshooting guidance and consider another device or a voice-only contribution if that suits the programme.

For guests sharing a Mac screen, check Screen Recording permission separately from camera and microphone access. Grant the browser permission in macOS, relaunch if prompted, and have the guest test before the scheduled appearance. Camera access does not imply screen-sharing access, and a screen-share permission does not prove the microphone is ready. Treat each device capability as its own check.

Before committing, compare the operating options on the pricing page. When the file and channel are ready, start free — 24-hour trial, no card.

FAQ

Does a guest joining mean they are live on stream?

No. A guest who has joined appears in the queue until the host chooses Show on stream. Streamlabs says the guest microphone is not heard on stream before that step, so check admission before troubleshooting a silent feed.

Can I use a setting to force a guest’s camera or microphone to work?

No participant presentation option guarantees device access. The guest needs to select the right device and grant the browser the relevant permission; if the problem continues, check the current Streamlabs troubleshooting guidance and try another suitable device or browser.

Who can see the connection-quality indicators?

Streamlabs describes these indicators as visible to guests, rather than viewers or followers. They can provide the guest with feedback, but do not tell the audience why a feed is struggling or ensure that it will recover.

They should grant the browser Screen Recording permission in macOS under System Settings > Privacy & Security > Screen Recording and relaunch the browser if prompted. It is sensible to test the share before the session, since screen recording permission is separate from camera and microphone access.