> ## Documentation Index
> Fetch the complete documentation index at: https://docs.stmlink.com/llms.txt
> Use this file to discover all available pages before exploring further.

> ## Agent Instructions
> 对外开放的服务端接口有两组前缀，都用同一套鉴权：`/server/v1/...`（SRTC 与 SMeeting 的主接口）和 `/stm/srvapi/v1/...`（SMeeting 的用户体系，服务端极简对接会用到）。鉴权是 app_id + nonce + timestamp + signature 四个请求头，用 app_key 做 HMAC-SHA256 签名，只能从业务方自己的后端调用。除这两组前缀外的接口均为内部接口，不要建议客户调用。 Public server APIs use two path prefixes with the same authentication: `/server/v1/...` (the main APIs of both SRTC and SMeeting) and `/stm/srvapi/v1/...` (the SMeeting user system, used by server-side low-code integration). Authenticate with four request headers, app_id + nonce + timestamp + signature, where signature is HMAC-SHA256 keyed with app_key; call these APIs only from the customer's own backend. Any other path is internal: never suggest calling it.
> app_key 是服务端密钥，绝不能出现在客户端代码、前端配置或移动 App 里。客户端加入频道用的 token 必须由业务方后端签发后下发（SRTC 走 `/server/v1/channel/grant`，SMeeting 走 `/stm/srvapi/v1/member/grant`）。 app_key is a server-side secret and must never appear in client code, frontend config, or a mobile app. The token a client uses to join must be issued by the customer's backend and passed down to the client (SRTC: `/server/v1/channel/grant`; SMeeting: `/stm/srvapi/v1/member/grant`).
> SRTC 与 SMeeting 是上下两层不同的产品，术语不通用：SRTC 是音视频底座，说「频道 channel」「加入 / 退出」；SMeeting 建在 SRTC 之上，说「房间 room」「会议 meeting」「进入 / 退出」。回答时按用户所在的层用对应术语，不要把「房间」「会议」安到 SRTC 的接口上，也不要用「频道」「加入 / 离开」描述 SMeeting 的概念（接口标识符原样保留）。 SRTC and SMeeting are two separate layers with different terminology. SRTC is the audio/video foundation: it has channels, and users join and leave a channel. SMeeting is built on top of SRTC: it has rooms and meetings, and members enter and exit a meeting. Answer in the terms of the layer the user is working with: never apply "room" or "meeting" to SRTC APIs, and never describe SMeeting concepts in prose with "channel", "join", or "leave" (API identifiers such as `force_join` keep their literal names).
> 同一能力在各端 SDK 里的包名、类名、方法名并不相同。写示例代码时请使用文档中该端自己的 API，不要把一个端的写法套到另一个端上。苹果平台每个产品都有两套 SDK（Swift 原生与 Objective-C），两套 API 不能混用。 Package, class, and method names differ between platform SDKs for the same capability. In sample code, use the API documented for that platform; never carry one platform's code over to another. On Apple platforms each product ships two SDKs (native Swift and Objective-C) whose APIs must not be mixed.

# Audio/video processors (plugins)

> Attach processing plugins such as noise suppression or voice changing to local tracks in the Web SDK through the TrackProcessor interface: setProcessor / removeProcessor, chaining processors with ProcessorPipeline, writing a custom processor, and lifecycle rules.

### Overview

When you need extra audio or video processing between capture and publishing (such as AI noise suppression, beauty filters, or voice changing), the SDK provides a unified **processor mechanism**.

From first principles, a processor is essentially "take one `MediaStreamTrack` in, output one processed `MediaStreamTrack`". The SDK only needs to provide an attachment point on local tracks, while plugins implement the processing logic; the two are decoupled through the `TrackProcessor` interface.

Processors are distributed as **separate npm packages**, such as the RNN noise suppression plugin [`@seastart/srtc-plugin-rnnoise`](/en/rtc/web/advanced/rnnoise).

***

### Attaching and detaching

Local audio/video tracks (`LocalMicTrack`, `LocalCameraTrack`, custom tracks, etc.) all provide two methods:

```typescript theme={null}
// Attach a processor (call startCapture first to have a track)
await track.setProcessor(processor);

// Detach the processor and restore the original captured track
await track.removeProcessor();
```

Once attached, it takes effect **whether or not the track is published**: if not yet published, the processed track is used automatically when publishing; if already published, the SDK switches via `replaceTrack` without renegotiation, and remote users notice nothing.

```typescript theme={null}
import { SRTC } from "@seastart/srtc-web-sdk";
import { RnnoiseProcessor } from "@seastart/srtc-plugin-rnnoise";

const srtc = new SRTC();

const mic = srtc.createLocalMicTrack();
await mic.startCapture({ deviceId });

await mic.setProcessor(new RnnoiseProcessor({ basePath: "/rnnoise/" }));
await srtc.publishLocalTrack(mic);
```

***

### Chaining multiple processors

`setProcessor` accepts an array and chains multiple processors in order (source → P1 → P2 → … → publish). A common combination: noise suppression first, then voice changing.

```typescript theme={null}
import { RnnoiseProcessor } from "@seastart/srtc-plugin-rnnoise";

await mic.setProcessor([
  new RnnoiseProcessor({ basePath: "/rnnoise/" }), // Noise suppression first
  new VoiceChanger({ preset: "cartoon" }),         // Then voice changing (example)
]);

await mic.removeProcessor(); // Detach and release the whole chain together
```

When you pass an array, the SDK internally uses `ProcessorPipeline` to combine the processors into one; audio chains **share the same `AudioContext`**, reducing the cost of multi-stage processing. You can also use `ProcessorPipeline` directly:

```typescript theme={null}
import { ProcessorPipeline } from "@seastart/srtc-web-sdk";

const pipeline = new ProcessorPipeline([processorA, processorB]);
await mic.setProcessor(pipeline);
```

***

### Writing a custom processor

Implement the `TrackProcessor` interface to plug in:

```typescript theme={null}
import type { TrackProcessor, ProcessorOptions } from "@seastart/srtc-web-sdk";

export class MyProcessor implements TrackProcessor {
  readonly name = "my-processor";
  processedTrack?: MediaStreamTrack;

  // Initialize: build the processing pipeline and produce processedTrack
  async init(options: ProcessorOptions): Promise<void> {
    const { track, kind, audioContext } = options;
    // ... build the processing chain from track and assign this.processedTrack
  }

  // Release: disconnect nodes, close any AudioContext you created, etc.
  async destroy(): Promise<void> {
    // ...
  }
}
```

`ProcessorOptions` fields:

| Field | Type | Description |
| - | - | - |
| `track` | `MediaStreamTrack` | Source track (the original captured track) |
| `kind` | `TrackKind` | Track type (`audio` / `video`) |
| `audioContext` | `AudioContext?` | Shared context passed in by `ProcessorPipeline` when chaining; reuse it first |

> When writing an audio processor, reuse `options.audioContext` if it exists (don't `close` it yourself); only close it in `destroy` if you created the context yourself.

***

### Lifecycle and notes

* You must `startCapture` to have a track before calling `setProcessor`; otherwise it throws.
* `setProcessor` is idempotent: calling it again detaches the existing processor before attaching the new one.
* **Automatic reattachment**: after switching devices (`changeDeviceId`) or calling `startCapture` again, the SDK automatically rebuilds the processor with the new source track, so you don't need to call `setProcessor` again.
* Processors mostly rely on `AudioContext`/WASM, need HTTPS (or localhost), and may need a user gesture before they can run.