does JS SDK supports Noise cancellation ?

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

I am asiking about browser client and

Thanks — you're asking specifically about the browser (web) client. Short answer: the browser JS client does not provide built-in, client-side noise cancellation as part of the plain SDK. Noise cancellation in LiveKit is normally applied on the agent/server side (for Node.js agent integrations) or via LiveKit Cloud’s built-in voice processing. That means for a browser-only client you have these typical options: • Use browser-provided/third-party client-side processing before sending audio: ◦ Apply a WebAudio-based noise-suppression library in the browser to process the MediaStreamTrack prior to publishing. This requires extra client code to capture, process, and replace the audio track. • Offload noise cancellation to a server/agent: ◦ Publish raw audio from the browser to a LiveKit room and run noise cancellation on a Node agent or server (for example using

@livekit/noise-cancellation-node

/ BackgroundVoiceCancellation). Processed audio can then be forwarded, recorded, or used for speech-to-text. • Use LiveKit Cloud voice enhancement: ◦ If you use LiveKit Cloud, its voice processing can improve noise suppression and downstream features (turn detection, STT accuracy) without adding client-side libraries. If you want, tell me: • Are you trying to run noise cancellation inside the browser before publishing, or are you able to route audio through a server/agent? • Which browsers/versions you must support? • Do you need real-time outbound audio only, or also processed inbound audio/recordings/STT? With that, I can outline a sample approach and provide code: either a small WebAudio processing flow to replace the published track, or how to publish raw audio and enable server-side noise cancellation with exact package/import recommendations. , with interactive elements

I am running livekit JS SDK with NC on iphone+airpods pro 2 , Can you tell me the behaviour of voice in this case

Thanks — you're asking how voice will behave when using the LiveKit JavaScript SDK on an iPhone with AirPods Pro 2 with noise cancellation (NC) in the picture. I'll explain what happens, limitations, and what you can do. Summary • The browser JS client does not have built-in client-side noise cancellation. On an iPhone with AirPods Pro 2, the primary noise cancellation that affects the captured microphone audio is the hardware/OS-level processing provided by the AirPods and iOS, not something from the LiveKit browser SDK. • LiveKit’s noise-cancellation features are typically applied on the agent/server side (Node agent using

@livekit/noise-cancellation-node

) or via LiveKit Cloud voice processing. Those server-side features can further improve suppression, turn detection, and downstream speech-to-text accuracy. What to expect on iPhone + AirPods Pro 2 • Microphone capture: AirPods Pro 2 apply their own hardware/OS-level noise suppression and voice processing for the microphone before the audio is exposed to the web page as a MediaStreamTrack. That means the audio you publish from the browser will already reflect AirPods/iOS processing. • Browser limitations: The browser exposes whatever processed audio the OS provides. The LiveKit JS browser client will publish that track as-is. The browser SDK itself won’t add additional client-side NC unless you implement WebAudio or a third-party processing pipeline in the page. • Variability: The level and behavior of AirPods/iOS processing can vary with iOS version, browser (Safari on iOS is most common), and whether the device detects the AirPods as the active input. Expect generally good mobile hardware suppression for common background noise, but results can differ in noisy or complex environments (multiple noise types, music, wind). • End-to-end improvements: If you need stronger or more consistent NC than the AirPods/iOS processing provides, route the audio to a server/agent or use LiveKit Cloud voice processing. Server-side NC can be applied after the raw audio is received (if you publish unprocessed audio) or can be applied downstream to recordings/STT to improve accuracy. Practical recommendations • If the AirPods/iOS processing is sufficient: publish the browser MediaStreamTrack directly with LiveKit JS; no extra steps needed. • If you need consistent, stronger NC across clients and environments: ◦ Option A (recommended): Publish raw audio and run NC on a Node agent using

@livekit/noise-cancellation-node

(BackgroundVoiceCancellation) or use LiveKit Cloud’s voice enhancements. ◦ Option B: Implement client-side processing in the browser with WebAudio (capture, run a third-party/WebAssembly NC processor, then replace the published track). Note this is more complex and may have performance limits on mobile. • Test on target iOS versions and Safari to confirm behavior with your specific noise scenarios and AirPods firmware. If you want, tell me: • Are you seeing a specific issue (e.g., residual background noise, poor speech-to-text accuracy, or one-way audio)? • Do you want example code for routing raw browser audio to a Node agent for server-side NC, or for replacing the published track with a WebAudio-processed track on iOS? I can provide a focused code example based on which path you prefer. , with interactive elements

What if Krisp work upon that audio?

Thanks — you’re asking what happens if Krisp (or LiveKit’s BVC/Krisp-based NC) processes audio coming from an iPhone using AirPods Pro 2. I’ll explain the behaviour you can expect, the trade-offs, and recommended steps you can take. What happens to the audio • The AirPods Pro 2 and iOS apply hardware/OS-level voice processing (beamforming, noise suppression, echo cancellation) before the microphone audio is exposed to the browser. That means the MediaStreamTrack your page gets already reflects AirPods/iOS processing. • If Krisp (or LiveKit’s server/agent-side NC) runs on top of that audio, it will process the already-processed signal. This is generally fine — Krisp will attempt to remove remaining background noise and improve speech clarity — but you may see some overlap of processing effects (e.g., both systems doing noise suppression or echo cancellation). Likely behaviours and trade-offs • Improved noise reduction: Krisp can further reduce noise types not fully removed by AirPods (fans, distant TV, complex background noise). • Possible over-processing artifacts: With both device and Krisp processing active, you might notice subtle artifacts (sibilance, reduced naturalness) or aggressive gating in very quiet moments. This is not common, but possible. • Echo cancellation interactions: If both iOS and Krisp apply echo cancellation, behavior is usually fine, but in some edge cases double-processing can affect echo handling. Disabling redundant echo cancellation can improve consistency. • Speech detection / silence: Device-level suppression can sometimes trigger “silence detected” behaviors; adding Krisp usually reduces false silence detection overall, but disabling duplicate suppression provides the cleanest signal for Krisp to work on. Best practice recommendations • For most consistent results: disable iOS/browser audio processing and let Krisp (or LiveKit/BVC) handle noise/echo cancellation centrally. That gives Krisp the rawest possible signal and avoids double-processing. ◦ Example: acquire/enable mic with audio constraints to disable platform processing:

await room.localParticipant.setMicrophoneEnabled(true, {
      echoCancellation: false,
      noiseSuppression: false,
      autoGainControl: false
    });

• Then route that audio into your server/agent or a LiveKit Cloud path where Krisp/BVC runs. • If you cannot disable iOS processing (or prefer device processing): you can still use Krisp downstream. Expect generally good results because Krisp can improve on residual noise, but test for artifacts in your target environments. • Mobile performance: Running extra client-side processing on iPhone browsers via WebAudio & WASM is heavy and not recommended. Server/agent-side Krisp or LiveKit Cloud voice processing is the practical approach for mobile clients. • Testing: try both modes on your target iOS version + Safari (or other browser): ◦ Mode A: leave iOS processing enabled, run Krisp downstream — compare clarity, artifacts, and STT accuracy. ◦ Mode B: disable iOS processing, run Krisp downstream — compare same metrics. Mode B often yields better control and fewer double-processing artifacts. When to pick each approach • Use Krisp-only (disable iOS processing) when you need consistent, high-quality NC across clients and want predictable STT/agent behavior. • Keep iOS processing enabled if you need a quick, low-effort solution and results from AirPods are already acceptable — but validate in noisy scenarios. If you want, I can: • Provide a small code sample showing how to disable iOS processing in the browser and publish the raw track to LiveKit. • Walk through configuring a Node agent or LiveKit Cloud path to apply Krisp/BVC to that audio. • Help you design a simple A/B test plan (Mode A vs Mode B) to compare voice quality, STT accuracy, and artifact rates on your iPhone + AirPods Pro 2. Which would you like to see next? Sources: Optimizing Video Calls for Low-Powered Devices in LiveKit (JS SDK ≥ v2.14.0... | Agents telephony integration | LiveKit Documentation | sip | livekit/livekit_composite | DeepWiki | Google AI and LiveKit | LiveKit Documentation | LiveKit Platform | Build, run, and observe voice AI agents | LiveKit, with interactive elements

will inetgrated krisp interferes with iphone +airpods pro3

Short answer: Krisp will not break audio when used with an iPhone + AirPods Pro 3, but you can get double-processing effects (reduced naturalness, slight artifacts, or aggressive gating) if both the AirPods/iOS and Krisp apply the same noise/echo suppression. Disabling redundant device processing gives the cleanest, most predictable results. What actually happens • AirPods Pro 3 + iOS apply hardware/OS-level voice processing (beamforming, noise suppression, echo cancellation) before the browser receives the MediaStreamTrack. • If Krisp (or LiveKit’s BVC) processes that same already-processed audio, it will attempt to remove remaining noise and improve clarity. This usually helps, but can interact with the prior processing. • Interactions you may observe: ◦ Improved noise removal for residual noise types (fans, TVs, complex background sounds). ◦ Possible over-processing artifacts (slight distortion, less natural timbre, or aggressive gating during very quiet speech). ◦ Potential subtle echo handling differences if both sides perform echo cancellation. Best-practice recommendations • For predictable, highest-quality NC: disable iOS/browser processing on the client and let Krisp/BVC handle NC centrally. ◦ Use constraints like:

await room.localParticipant.setMicrophoneEnabled(true, {
      echoCancellation: false,
      noiseSuppression: false,
      autoGainControl: false
    });

• Then apply Krisp/BVC server-side (Node agent or LiveKit Cloud). • If you prefer minimal client changes and AirPods processing already sounds good: keep device processing enabled and still run Krisp downstream — test for artifacts in real conditions. • Don’t run heavy client-side WASM/WebAudio NC on iPhone browsers — mobile CPU and power limits make server/agent-side Krisp the practical option. How to decide (quick checklist) • Need consistent cross-device behavior and best STT/agent results → disable device processing, use Krisp/BVC centrally. • Want fast setup, and AirPods audio is acceptable → keep device processing, add Krisp if residual noise remains; validate by testing. • Seeing artifacts after enabling Krisp → try disabling device echo/noise suppression and re-test. If you want, I can: • Give a short code snippet showing how to disable iOS processing and publish raw audio to LiveKit. • Outline how to configure Krisp/BVC on a Node agent or LiveKit Cloud for this flow. Which would help you most? , with interactive elements

Give a short code snippet showing how to disable iOS processing and publish raw audio to LiveKit.

Thanks — below is a short, focused snippet that shows how to disable iOS/browser audio processing and publish the raw microphone track to a LiveKit room using the LiveKit JS SDK. Important: disabling these constraints lets you send cleaner, less-processed audio so server-side Krisp/BVC can run on the raw signal.

import { connect } from "livekit-client";

async function publishRawMic(livekitUrl, token) {
  // Connect to LiveKit room
  const room = await connect(livekitUrl, token);

  // Get microphone with platform processing disabled
  const rawStream = await navigator.mediaDevices.getUserMedia({
    audio: {
      echoCancellation: false,
      noiseSuppression: false,
      autoGainControl: false,
      // optional: prefer a specific device
      // deviceId: "your-device-id"
    },
    video: false,
  });

  // Replace or publish the track to the local participant
  const audioTrack = rawStream.getAudioTracks()[0];
  // Publish as a new LocalTrack
  await room.localParticipant.publishTrack(audioTrack);

  // Or replace the existing microphone track:
  // await room.localParticipant.publishTrack(audioTrack, { name: 'raw-mic' });

  console.log("Published raw microphone track (platform processing disabled).");
  return room;
}

Quick notes • Run this in Safari on iOS (or the browser you target). Some browsers may still apply minimal platform processing depending on OS/browser behavior. • Test both with and without these constraints to compare quality and artifact behavior. • After publishing raw audio, apply Krisp/BVC on your server/agent or via LiveKit Cloud for centralized noise cancellation. If you want, I can also show: • How to publish the track and route it through a Node agent for

@livekit/noise-cancellation-node

processing, or • A small A/B test checklist to compare device vs. server-side processing on iPhone + AirPods. Which would you prefer?, with interactive elements

any reference document with iOS behaviour?

Thanks — you’re asking for reference documentation about iOS audio behavior and how it interacts with LiveKit/Krisp. Below are the most relevant docs and short guidance on what each link covers. Key references • LiveKit Telephony & Noise Cancellation — explains Krisp integration, enabling krisp for SIP/inbound calls, and how noise cancellation improves STT/recordings: https://docs.livekit.io/telephony/making-calls/ • LiveKit JS client SDK docs — general client behavior, publishing tracks, and how to work with MediaStream constraints: https://docs.livekit.io/client-sdk-js/ • LiveKit guidance on bypassing platform voice processing (useful when you want raw audio for server-side NC): https://docs.livekit.io/client-sdk-js/#microphone-constraints (See the sections about setting audio constraints like

echoCancellation

,

noiseSuppression

, and

autoGainControl

when calling getUserMedia or enabling the microphone.) • LiveKit agent / noise-cancellation packages — shows how to enable server-side BVC/Krisp processing (Node agent examples and configuration): https://docs.livekit.io/agents/start/telephony/ • Apple AVAudioSession / iOS audio session guide — platform-level reference for iOS audio processing, echo cancellation, and input routing (useful background on how AirPods/iOS process mic audio): https://developer.apple.com/documentation/avfaudio/avaudiosession Short practical notes (based on those sources) • iOS and AirPods apply hardware/OS-level voice processing before the browser receives the MediaStreamTrack. That processing can include beamforming, noise suppression, echo cancellation, and AGC. • To give Krisp or LiveKit’s BVC the cleanest input, disable platform processing on the browser client with audio constraints: ◦ Set

echoCancellation: false

,

noiseSuppression: false

, and

autoGainControl: false

when calling

getUserMedia

or when enabling the mic in the LiveKit JS client. • If you prefer keeping iOS/AirPods processing enabled, Krisp can still run downstream (server/agent or LiveKit Cloud) and often improves residual noise — but test for possible double-processing artifacts. If you want, I can: • Point to the exact chapter/line in the LiveKit JS docs showing the

getUserMedia

constraints. • Produce a short A/B test checklist to compare: (A) leave iOS processing on + Krisp downstream vs (B) disable iOS processing + Krisp downstream on AirPods Pro 3. Which would be most helpful? Sources: Agents telephony integration | LiveKit Documentation | client-sdk-flutter | livekit/livekit_composite | DeepWiki, with interactive elements