> ## 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.

# Device management

> Use DeviceManager in the SRTC Swift SDK to enumerate cameras and audio devices, switch devices, and handle hot-plugging and interruption recovery. For output routing control on iOS, see the Audio routing page.

### Overview

The Swift SDK abstracts device management into `DeviceManager.shared`, so you don't have to piece together platform differences from scratch for device enumeration, hot-plug monitoring, and audio session interruption handling.

Common needs include:

* Enumerating cameras, microphones, and speakers
* Letting the user switch devices manually
* Monitoring device plug and unplug events
* Recovering after an interruption on iOS such as an incoming call or Siri

***

### Enumerate devices

#### Enumerate cameras

```swift theme={null}
let cameras = DeviceManager.shared.cameras()
```

#### macOS: enumerate microphones and speakers

```swift theme={null}
let microphones = DeviceManager.shared.microphones()
let speakers = DeviceManager.shared.speakers()
```

#### iOS: enumerate audio input ports

```swift theme={null}
let inputs = DeviceManager.shared.audioInputs()
```

This returns the **input ports** currently available to `AVAudioSession` (built-in microphone, Bluetooth, wired headset, and so on).

> iOS doesn't have the independent output device model of desktop systems, so this list **doesn't include the speaker**. "Whether sound comes out of the speaker or the receiver" is a separate mechanism—see [Audio routing](/en/rtc/swift/advanced/audio-routing).

#### Generic query

If you want to build a single device-picker UI layer, you can also use:

```swift theme={null}
let allDevices = DeviceManager.shared.getDevices()
let camerasOnly = DeviceManager.shared.getDevices(kind: .videoInput)
```

***

### Switch cameras

For an existing `LocalCameraTrack`, you can switch to a specific device directly:

```swift theme={null}
try await cameraTrack.changeDeviceId(deviceId)
```

To switch between the front and back cameras on iOS, use:

```swift theme={null}
try await cameraTrack.switchCamera()
```

The key point: the switch happens inside the track object, so you don't need to create a new `LocalCameraTrack`.

***

### Switch microphones or audio routes

#### macOS

```swift theme={null}
try micTrack.changeDeviceId(deviceId)
```

#### iOS

```swift theme={null}
try micTrack.changeDeviceId(deviceId)
```

The call looks the same, but the meaning differs:

* macOS: switches the input device
* iOS: switches the **input port** (`AVAudioSession.setPreferredInput`); `deviceId` comes from `audioInputs()`

<Warning>
  On iOS this method only handles input. It **can't be used to switch between the speaker and the receiver**, and it doesn't accept values like `"speaker"`. For output, use `AudioRouteSession.shared.setAudioRoute(_:)`—see [Audio routing](/en/rtc/swift/advanced/audio-routing).

  Also, this path doesn't take part in the audio routing module's fallback policy, and the switch isn't recorded as an "explicit user choice".
</Warning>

***

### Switch speakers on macOS

On macOS, output device switching goes through `DeviceManager`:

```swift theme={null}
try DeviceManager.shared.setOutputDevice(deviceId)
```

This is separate from microphone switching because the output device isn't bound to `LocalMicTrack`; it's bound to the output path of the underlying audio module.

***

### Monitor device changes

Register a listener through `DeviceManagerDelegate`:

```swift theme={null}
final class DeviceState: DeviceManagerDelegate {
    init() {
        DeviceManager.shared.delegates.add(delegate: self)
    }

    func deviceManager(_ manager: DeviceManager, didAddDevice device: DeviceInfo) {
        print("device added:", device.name)
    }

    func deviceManager(_ manager: DeviceManager, didRemoveDevice device: DeviceInfo) {
        print("device removed:", device.name)
    }
}
```

Recommended approach:

* In the callback, only refresh the local device list state
* Have the UI layer update its dropdown or picker automatically based on the new device list

***

### Automatic recovery built into the SDK

The Swift SDK already handles several common recovery cases internally:

* When the camera in use is unplugged, it tries to switch to an available camera
* On macOS, when the microphone in use is unplugged, it tries to switch back to the default input
* On iOS, after the audio session is interrupted by an incoming call or similar, it recovers when conditions allow (including waiting for the system call to end and retrying on failure—see [Audio routing](/en/rtc/swift/advanced/audio-routing))
* On iOS, camera capture can recover when the app returns to the foreground after going to the background

This means you usually don't need to build a full set of fault-tolerance logic yourself, but we still recommend that you:

* Show error messages to the user
* Refresh the UI after the device list changes
* Don't cache stale `deviceId` values

***

### Recommended approach in your app

Recommended approach:

* Call `refreshDeviceList()` when the page initializes
* Save the currently selected `deviceId`
* After a device change, if the original `deviceId` no longer exists, fall back to the default device automatically

This matters because in hot-plug scenarios, "an old device ID still lingering in local state" is the root cause of many switching failures.