通常实现一个完整的在线 K 歌场景，需要涉及多个功能模块：房间管理、麦位管理、点歌管理、K 歌管理等。每个功能模块下的关键动作及功能点如下表所示。接下来会逐个介绍各个功能模块，通过介绍可以对搭建K歌房所需的功能有个完整的认知。
房间管理 | 麦位管理 | 点歌管理 | K歌管理 |
房间列表 | 上/下麦 | 歌单展示 | 唱歌玩法 |
创建房间 | 麦位控制 | 搜索歌曲 | 切歌 |
加入房间 | 锁麦位 | 点歌 | 人声音量调节 |
退出房间 | 邀请上麦 | 歌曲置顶 | 混响/声效 |
销毁房间 | 麦位禁言 | 已点列表 | 歌词同步 |
房主创建 K 歌房，用户可以选择感兴趣的歌房加入。进入房间后用户可以上麦参与互动，上麦后可以和房主语音互动。当然，用户也可以选择直接上麦参与合唱，这是两种不同的 K 歌玩法。在线 K 歌场景整体的业务流程如下图所示。
房间管理
房间管理是主要负责对房间列表的维护。主要包含的功能：创建房间、加入房间、销毁房间、退出房间。而且 K 歌房间有区别于普通房间，需要有单独的 K 歌房间标识符，以启动相关的组件管理：点歌管理、K 歌管理等功能。
创建房间：用户登录业务系统后，可以创建房间，创建房间后房间列表要做新增操作。
销毁房间：所有用户退出房间后，需要销毁房间，销毁房间后房间列表要做删除操作。
说明：
房间管理是实现在线K歌的必要模块，但并非主要功能模块，具体实现可以结合业务系统和 TRTC SDK，详见语聊房场景接入方案。
麦位管理
歌房内的麦位一般都是有序且有限的。麦位管理主要负责根据业务场景定义房间内的麦位数量，以及当前房间所有麦位的状态管理。麦位管理主要包含的功能：上/下麦、锁麦位、邀请上麦、麦位禁言等。
用户进入房间后，只有空闲状态的麦位才可以申请上麦。
房主同意用户上麦后，需要修改麦位状态为非空闲状态。
用户停止推流下麦后，需要重置麦位状态。
房主有权锁定麦位、邀请上麦、强制下麦、麦上禁言等。
说明：
麦位管理是实现在线K歌的必要模块，但并非主要功能模块，具体实现可以结合业务系统和 IM SDK，详见语聊房场景接入方案。
点歌管理
基本介绍
点歌管理属于在线 K 歌场景比较重要的一环，主要包含的功能：歌单展示、搜索歌曲、点歌和排麦、已点列表。而且每个 K 歌房间要有一个维护已点歌曲列表和自动排麦功能，都是需要业务后台来实现，而歌单展示、搜索歌曲需要结合 音速达直播音乐版权引擎（Yinsuda Authorized Music for Live Streaming）实现。
实现流程
整个点歌管理中，主要涉及业务端 App、业务后台、音速达后台，其中各自的职能分别为：
业务端 App：
调用点歌接口上报歌曲信息.
调用切歌接口通知业务后台更新已点歌单列表.
调用演唱确认接口通知业务后台。
业务后台：
维护已点歌单列表。
下发通知告诉业务端 App 更新当前已点歌曲列表。
音速达后台：
提供 获取直播互动曲目详情 的接口（播放playToken、歌词下载URL）。
提供 搜索直播互动歌曲 的接口。
K 歌管理
K 歌系统主要包含功能：唱歌玩法、开始/停止/切歌、人声音量调节、混响/声效、歌词同步。下面我们将通过演唱和实时合唱两种典型的 K 歌玩法来详细介绍 K 歌管理模块的实现流程。
演唱
主要是多人互动的KTV场景下，主播上麦后，才可以进行点歌，主播点歌成功后，会统一在点歌台展示，主播选择开始演唱。
（1）方案架构
在整体方案上，主要是用到的音速达SDK，实现歌曲下载，音速达后台，获取歌曲 playToken 和歌词下载地址；用到的 TRTC SDK，来实现演唱者人声的推流、歌曲的播放以及推流。整体的方案架构如下：
（2）具体实现
在演唱的场景，会区分不同角色有不同的实现流程，分为演唱者、观众 2种角色。
角色 | 描述 | 区别 |
演唱者 | KTV 房间的演唱者，是房间的房主点歌以后演变而来的，房主创建房间后自动上麦点歌并演唱，退房后房间自动解散，已点歌曲自动清空 | 角色必须为主播 上行音视频（无视频上行黑帧） 播放 BGM 发送 SEI 信息（发送歌词信息） 点歌 |
观众 | KTV 房间的观众，播放演唱者的流 | 角色为观众，亦可上麦成为主播 下行音视频流 接收 SEI 信息（接收歌词信息） |
不同角色的基本实现流程如下：
房主创建并加入 TRTC 的房间，自动上麦后点歌成为演唱者。
点歌后进行歌曲/歌词的下载，然后通过播放 BGM 接口播放歌曲。
演唱者没有带视频上行的话，需要开启视频上行。
通过 SEI 信息同步所有人的歌词进度。
演唱者在唱歌过程中可以随时切歌，并重新开始对歌曲/歌词进行下载，下载完成后进行演唱。
房主退房后将解散 TRTC 房间。
观众加入 TRTC 的房间。
监听房间歌曲变化，并加载歌词。
拉取演唱者的流。
解析演唱者发送的 SEI 信息，并同步歌词。
主要是要监听歌曲的 SEI 信息，更新对应的歌曲控件。
（3）API 调用时序
不同角色的 API 时序调用如下：
房主 | 观众 |
 |  |
说明：
鉴于以上实现方案需要一定的技术门槛，而 TRTC 官网提供的TUIKaraoke 开源的音视频 UI 组件，可以通过在项目中集成 TUIKaraoke 组件，您只需要编写几行代码就可以为您的应用添加在线 K 歌场景，体验 K 歌、麦位管理、收发礼物、文字聊天等 TRTC 在 KTV 场景下的相关能力。
实时合唱
实时合唱是指各端在连麦的基础上，同时播放歌曲，然后上麦进行合唱。多人模式下合唱者之间都能听到彼此声音，几乎感受不到延迟，达到了真正意义上的实时合唱。
（1）方案架构
在媒体流方面，合唱者互相进行推拉流，同时会由一名主唱者推出音乐，其他合唱者在本地播放音乐，经过 NTP 进行时间同步。另外，歌曲和所有合唱者的声音都通过混流机器人进行混流处理形成一条流，并回推到 TRTC 房间，观众只需拉一条流即可听到各端同步的声音，完美实现多人合唱的效果。实时合唱方案架构如下图所示。
该方案的优点在于：
降低了端到端的时延。
提供了用户中途加入合唱的解决方案。
精准同步不同端之间的音乐、歌词、人声。
改善各端设备性能和本地时间不精准的情况，降低网络环境造成的时延影响。
说明：
根据业务需要，可以选择纯音频场景或音视频场景的实时合唱方案；若为纯音频场景则需要补黑帧以发送 SEI 消息用于歌词同步；
主唱需要使用子实例同时上行音乐及人声；其他合唱者仅互相拉取人声流，同时本地播放音乐；观众只需拉取一路混流；
图中展示的是 RTC 观看方案，混流机器人将合流回推至 RTC 房间；CDN 观看方案下，混流机器人将合流转推至直播 CDN，观众拉取 CDN 流观看。
（2）具体实现
我们可以将在线 K 歌房里的用户划分为三种角色：主唱、合唱和观众，如下表所示。
角色 | 描述 | 区别 |
主唱 | 主唱负责点歌和发送合唱信令，以及 SEI 的发送 | 角色为 Anchor 上行音乐和人声 点歌及发起合唱 混流回推 发送 SEI 消息 |
合唱 | 合唱者可以接收并处理合唱信令，麦上参与合唱 | 角色为 Anchor 上行人声 本地播放音乐 接收合唱 |
观众 | 进入歌房后，在麦下拉流的观众，也可上麦合唱 | 角色为 Audience 下行混流 接收 SEI 消息 申请上麦成为 Anchor |
不同角色的基本实现流程如下图所示：
主唱需要点播歌曲，发送合唱信令。
主唱创建子实例推送人声和音乐，并拉取其他合唱者的人声。
在推流后，主唱负责发起混流转推任务。
开唱后，播放音乐，通过播放进度回调同步歌词。
需要通过 SEI 发送歌曲进度，以便观众端同步歌词。
所有演唱者需要根据 NTP 校准本地歌曲播放进度。
合唱者推送一路人声流，拉麦上合唱用户的人声流。
合唱者需要监听并接收合唱信令，预加载音乐资源。
开唱后，本地播放音乐，合唱者通过播放进度回调同步歌词。
所有演唱者需要根据 NTP 校准本地歌曲播放进度。
拉混流收听合唱。
解析混流中 SEI 的歌曲进度信息，用于同步歌词；
上麦后停止拉混流，转为拉麦上人声流，同时开启合唱模式。
（3）API 调用时序
不同角色的 API 调用时序如下：
主唱 API 时序 | 合唱 API 时序 | 观众 API 时序 |
 |  |  |
说明：
鉴于以上实现方案需要一定的技术门槛，而 TRTC 官网提供的TUIKaraoke 开源的音视频 UI 组件，可以通过在项目中集成 TUIKaraoke 组件，您只需要编写几行代码就可以为您的应用添加实时合唱场景，体验 K 歌、麦位管理、收发礼物、文字聊天等 TRTC 在 KTV 场景下的相关能力。
