Hello. Is it possible to determine if the local user is speaking, even if he is muted? I wanted to improve the case when the user starts speaking, but he is muted, so I can alert him to unmute himself. i am using native ios library

Thanks for reaching out, Ilija. I'm an AI assistant and I'm here to help. Give me a moment while I research this topic.

1. currently on 2.6.1 2. this is the block of code how i mute: private let captureOptions = AudioCaptureOptions(echoCancellation: true, autoGainControl: false, noiseSuppression: false, highpassFilter: false, typingNoiseDetection: false) try await room.localParticipant.setMicrophone(enabled: !microphoneMuted, captureOptions: captureOptions) 3. the biggest criteria is that the microphone usage be reported as "not used". i dont want for user to be muted but the ios microphone usage indicator to be turned on 4. you can count i dont override audiosessions 5. i dont need the voice activity, just the detetion that soudn has been made from a muted user

Thanks — this is very helpful context. I’m responding to your goal of detecting when a local user speaks while muted, without turning on iOS’s microphone usage indicator. Short answer: You cannot detect actual microphone input without activating the microphone. Because you call

room.localParticipant.setMicrophone(enabled: ...)

which disables capture at the SDK level, iOS will not provide audio samples to your app while the microphone usage indicator is off. That means detecting real user speech from the device mic while the mic indicator remains "not used" is not possible. What you can do instead (options that respect your requirement to keep the mic indicator off or minimize its visibility): • If you want to keep the mic indicator OFF (no microphone access): ◦ You cannot observe real microphone audio. Instead, use indirect signals to guess the user is speaking: ▪︎ Monitor UI/UX cues: if the user taps push-to-talk or tries to unmute repeatedly, prompt them. ▪︎ Use speech events from remote participants (e.g., if other clients send a message that they hear the user) — this requires cooperation from other participants. ▪︎ Ask the user to explicitly allow a test/unmute action when you want to check audio. • If you will accept temporarily enabling the microphone (mic indicator ON) for local detection: ◦ Enable capture locally while keeping the track disabled for sending (capture-but-not-send). Then analyze captured audio locally for activity and only send when user un-mutes. Notes based on your setup: ▪︎ In your code you call

setMicrophone(enabled:)

. When you set enabled = false the SDK stops capture entirely (so no samples are available). To capture locally while not sending, you need to keep capture enabled but prevent the audio track from being published/sent. ▪︎ Implementation approaches: 1. Create a local audio track for capture and keep it un-published or unpublished while muted, but run voice-activity detection or RMS checking on captured samples locally. This will turn on the microphone indicator while capture runs. 2. Keep the audio track published but set its

enabled

property to

false

to mute send while capture and local analysis continue — however in your current code

setMicrophone(enabled:)

appears to stop capture when disabled, so you’ll need to manage the track lifecycle manually rather than relying on that wrapper. ▪︎ Tradeoff: iOS will show the microphone usage indicator while capture is active. Given your specific constraint that the microphone indicator must remain "not used", the only factual option is to rely on non-microphone signals (UX cues, remote participant feedback, explicit user action). If you are willing to accept the microphone indicator being visible briefly, I can provide sample iOS code showing how to: 1. Create a local audio track and keep capture running while not sending audio. 2. Tap or access audio levels / run a simple RMS threshold to detect speech locally. 3. Keep the UI prompt logic to ask the user to unmute. Which of these would you prefer? • Keep mic indicator always off and use indirect signals (I’ll outline UX patterns), or • Allow temporary mic access and I’ll provide a code example for local-level detection with LiveKit iOS (version 2.6.1) showing how to capture but not send audio and detect activity.