음성 채팅방은 순수 오디오 방식으로 온라인 인터랙티브 소셜을 하는 가상 공간을 의미합니다.방 내에는 일반적으로 여러 개의 마이크가 설치되어 있습니다. 스트리머와 마이크로 연결된 청취자들이 마이크에서 체팅을 나누고 다른 청취자들은 방에 들어가서 청취할 수 있습니다. 유형이 다른 방은 마이크 설치 수량과 최대 수용 가능 청취자 인원수이 다릅니다. RTC Engine는 최대 50명이 동시에 마이크에서 채팅할 수 있도록 지원하며 마이크의 연결/해제를 원활하게 전환하며 음성 채팅 지연 시간이 300ms 미만입니다. 변성, 분위기 음향, 리버브 등 다양한 오디오 효과를 지원하여 음성 채팅 체험을 더욱 풍부하게 합니다. Chat과 결합하여 공개 채팅, 개인 채팅, 그룹 채팅, 좋아요, 선물 보내기 등 다양한 메시지 인터랙티브 형태를 지원하여 우수한 채팅 체험을 만들어줍니다.
구현 방안
일반적으로 완전한 음성 채팅방 시나리오를 구현하려면 여러 기능 모듈이 필요합니다.방 관리, 마이크 관리, 오디오 스트림 관리, 클라우드 레코딩 등 있습니다.각 기능 모듈의 주요 작업 및 기능 포인트는 아래 표와 같습니다.
기능 모듈
주요 업무 및 기능 포인트
방 관리
방 목록, 방 생성, 방 입장, 방 나가기, 방 파기
마이크 관리
마이크 자동 사용, 마이크 사용 초청, 마이크 끄기, 마이크의 사용 강제 끄기, 마이크 금언, 마이크 잠금, 마이크 이동
오디오 스트림 관리
푸시-풀 스트림 아키텍처 솔루션, 실시간 스트림 구독 모드
클라우드 레코딩
RTC Engine 클라우드 레코딩
음성 채팅방 시나리오의 전체 업무 아키텍처는 아래 그림과 같습니다. 방주인이 음성 채팅방을 생성하면 사용자는 관심 있는 방을 선택해서 입장할 수 있습니다. 방에 입장한 사용자는 마이크를 켜고 사용할 수 있으며 스트리머와 채팅할 수 있으며 규정 준수를 위해 방 내 음성 내용은 녹음되어 심사됩니다.
방 관리
방 관리 모듈은 주로 방 목록 유지 관리를 담당하며 주요 기능은 다음과 같습니다.
방 생성: 사용자가 업무 시스템에 로그인한 후 방을 생성할 수 있으며 방 생성 후 방 목록에 추가 작업이 이루어집니다.
방 입장: 사용자는 기존 방에 입장할 수 있으며, 방 입장 후 해당 방 인원 목록에 추가 작업이 이루어집니다.
방 나가기: 사용자는 현재 방에서 나갈 수 있으며, 방 나간 후 해당 방 인원 목록에서 삭제 작업이 이루어집니다.
방 파기: 모든 사용자가 방에서 나간 후 방을 파기해야 하며, 방 파기 후 방 목록에서 삭제 작업이 이루어집니다.
솔루션 아키텍처
전체 방 관리의 아키텍처에서는 주로 세 가지 모듈의 방 관리가 포함됩니다.
업무 측 방 관리: 주로 방 목록의 유지 및 관리를 위해 사용되며 예를 들어 업무 방의 속성과 상태를 동기화하는 것입니다. 기능으로는 방 목록 조회, 방 입장 및 퇴장, 방 생성 및 파기가 있습니다.
채팅 그룹 관리: 주로 방 멤버 목록, 시그널링의 송부및 수신, 메시지 인터랙티브에 사용되며 예를 들어 마이크 사용 신청의 허락/거부, 마이크 사용 초청/취소, 마이크 무음/해제, 마이크 사용 금지/해제 등이 있습니다.또한 그룹 차원으로 구분되어 있으며 그룹 생성, 그룹 가입, 그룹 퇴장, 그룹 파기 등의 기능이 있습니다.
RTC Engine 방 관리: 주로 오디오 스트림의 인터랙티브와 전송을 위해 사용되며 예를 들어 스트리머/청취자의 음성/음악의 송부및 수신등 있습니다. 또한 방 차원으로 구분되며 RTC Engine 방 입장 및 퇴장 기능이 있습니다.
구체적인 구현
방 관리에서 서로 다른 사용자 역할은 각자의 권한 및 구현 프로세스를 가집니다. 음성 채팅방에서는 주로 방주인과 청취자 두 가지 역할이 존재하며 역할 설명 및 차이점은 아래 표를 참조하십시오.
역할
설명
차이점
방주인
방의 최고 권한을 가진 소유자는 방을 생성하거나 파기할 수 있습니다.
역할은 반드시 스트리머여야 합니다.
업무 룸/채팅 그룹/RTC 룸의 생성 또는 폐기
청취자
방의 참여자도 마이크를 켜서 사용하여 스트리머가 될 수 있습니다.
역할은 청취자/스트리머일 수 있습니다.
방 입장및 퇴장
구현 프로세스
방주인
1. 방 목록 가져오기
2. 업무 인터페이스를 통해 해당 방을 생성합니다.
3. Chat 그룹을 생성합니다.
4. 업무 방/Chat 방/RTC 방에 들어가서 다른 사람들과 인터랙티브합시다
5. Chat 그룹/RTC 방/업무 방에서 나갑니다.
6. Chat 그룹을 파기합니다.
청취자
1. 방 목록 가져오기
2. 업무 방/Chat 그룹/RTC 방에 들어가서 다른 사람들과 인터랙티브합시다
3. Chat 그룹/RTC 방/업무 방에서 나갑니다.
마이크 관리
음성 채팅방의 마이크는 일반적으로 순서가 정해져 있고 제한적입니다. 예를 들어 방 내의 청취자가 마이크를 사용하려면 방주인의 동의를 받아 순서대로 마이크를 사용합니다. 방 내 마이크 수는 일반적으로 10개를 넘지 않습니다. 마이크 관리는 주로 업무 시나리오에 따라 방 내 마이크 수를 정의하고 현재 방의 모든 마이크 상태를 관리하는 역할을 합니다. 마이크 관리에 자동 마이크 사용, 마이크 사용 초청, 자동 마이크 끄기, 마이크의 사용 강제 끄기, 마이크 금언, 마이크 잠금, 마이크 이동 등 기능이 포함됩니다
사용자가 방에 입장한 후, 빈 상태의 마이크가 있을 때만 사용자가 마이크 사용을 신청할 수 있습니다.
방주인이 사용자의 마이크 사용 신청을 허락한 후, 마이크 상태를 비어 있지 않음으로 수정해야 합니다.
사용자가 스트리밍을 중지하고 마이크의 사용을 끈 후, 마이크 상태를 재설정해야 합니다.
방주인은 마이크 잠금, 마이크 사용 초청, 강제로 마이크 끄기, 마이크 금언 등의 권한을 가집니다.
솔루션 아키텍처
아래에서는 RTC Engine과 Chat을 결합하여 마이크 관리의 솔루션 아키텍처를 구성합니다. 전체 방 관리 아키텍처에서 방주인은 최고의 권한을 가지며 마이크 사용 초청/강제로 마이크 끄기/마이크 무음및 해제/마이크 금언및 해제를 할 수 있습니다. 청취자들은 마이크의 사용을 신청을 통해 스트리머가 되어 방 내 다른 스트리머들과 인터랙티브할 수 있습니다.
구체적인 구현
마이크 관리에서 서로 다른 사용자 역할은 각자의 권한 및 구현 프로세스를 가지며, 주로 방주인과 청취자 두 가지 역할이 존재합니다. 역할 설명 및 차이점은 아래 표를 참조하십시오.
역할
설명
차이점
방주인
방주인은 마이크 관리의 최고 권한자이고 모든 마이크를 관리합니다. 방주인이 방을 나가면 모든 마이크가 자동으로 해산됩니다.
역할은 반드시 스트리머여야 합니다.
방 입장 시 자동으로 마이크에 연결됩니다
마이크 신청의 수락/거절
마이크 사용의 초청/ 마이크 끄기
마이크 무음/해제
마이크 사용 금지/해제
청취자
방 내 마이크에 연결된 참여자는 마이크를 켜서 사용하여 인터랙티브할 수 있습니다.
역할은 청취자/방송자일 수 있습니다.
마이크 사용/끄기 초청
구현 프로세스
방주인
1. 스트리머가 방 홀에 들어가면 방 목록을 가져옵니다.
2. 스트리머가 방주인으로 방을 생성하고 방에 입장합니다.
3. 방주인은 그룹 속성에 의해 마이크 순위 목록을 받고 자동으로 마이크 켜서 사용합니다
4. 청취자가 마이크 켜서 사용합니다.마이크 사용한 후 마이크에 연결중의 다른 사용자와 인터랙티브할 수 있습니다. 청취자가 마이크 사용하는 방식은 두 가지 있습니다. 청취자가 직접 마이크 사용의 신청을 하고 방주인이 동의하고 나서 사용하는 것과 방주인이 청취자를 직접 초청하고 청취자가 동의한 후 사용하는 것입니다.
5. 청취자가 마이크 끄고 사용을 중지합니다. 마이크 끄고 사용을 중지하는 방식은 두 가지 있습니다.청취자가 직접 마이크 끄고 사용을 중지하는 방식과 방주인이 청취자의 마이크 사용을 강제로 끄는 방식입니다.
6. 방주인이 방에서 나가고 방을 파기합니다(방이 해산되고 모든 사용자가 강제로 마이크의 사용이 중단되어 방을 나갑니다).
청취자
1. 청취자가 방 홀에 들어가서 방 목록을 가져옵니다.
2. 청취자가 방을 선택하고 방에 들어갑니다.
3. 청취자는 그룹 속성에 의해서 마이크 순위 목록을 받습니다.
4. 청취자가 마이크 사용의 신청을 하고 방주인이 동의한 후 청취자는 마이크에 연결된 다른 사용자와 인터랙티브할 수 있습니다
5. 청취자가 마이크 끄고 사용을 중지하고 방을 나갑니다.
오디오 스트림 관리
음성 채팅 인터랙티브 시나리오는 일반적으로 RTC 스트림 접근 방식을 선택하며, 접근이 간단하고 빠르며 실시간 인터랙티브의 낮은 지연 특성을 체험할 수 있습니다. 아래 그림과 같이 마이크 사용중의 사용자와 마이크 사용하지 않는 청취자 두 가지 역할로 실시간 음성 채팅의 푸시 및 풀 스트림 아키텍처 솔루션을 보여줍니다.
방 내 실시간 스트림 구독을 위해 RTC Engine은 자동 구독과 수동 구독 두 가지 모드를 제공합니다.
자동 구독: 사용자가 방에 들어가면 해당 방의 오디오 및 비디오 스트림을 즉시 수신하며 오디오는 자동으로 재생되고 비디오는 자동으로 디코딩됩니다.
수동 구독: 사용자가 방에 들어간 후 startRemoteView를 수동으로 호출하여 비디오 스트림 구독 및 디코딩을 시작시키고, muteRemoteAudio를 수동으로 호출하여 오디오 재생을 시작시켜야 합니다.
대부분의 시나리오에서 RTC Engine은 자동 구독 모드를 기본으로 사용하며 사용자가 방에 입장하면 방의 모든 스트리머의 오디오 및 비디오 스트림을 구독하여 더 나은 '즉시 시작 체험'을 제공합니다. 반면, 수동 구독 모드는 더 나은 유연성과 맞춤 설정이 가능하며 사용자가 선택적으로 오디오 및 비디오 스트림을 구독할 수 있습니다.
설명:
자동 구독 모드는 수동 구독 모드에 비해 복잡한 미디어 스트림 구독 관리가 필요 없으며 음성 채팅 시나리오에서는 특별한 요구 사항이 없는 경우 자동 구독 모드를 사용하는 것이 좋습니다.
클라우드 레코딩
RTC Engine 최신 업그레이드된 클라우드 레코딩은 RTC Engine 내부의 실시간 레코딩 클러스터를 사용하여 오디오 및 비디오를 레코딩하며, 더 완전하고 통일된 레코딩 체험을 제공합니다.
싱글 스트림 레코딩: RTC Engine의 클라우드 레코딩 기능을 통해 방 안의 각 사용자의 오디오 스트림을 개별 파일로 레코딩할 수 있습니다.
혼합 스트림 레코딩: 동일한 방의 오디오 미디어 스트림을 하나의 파일로 혼합하여 레코딩합니다.
유령 마이크는 또 폭발 마이크나 블랙 마이크라고도 하며 마이크에 있지 않은 사용자가 말할 수 있고 다른 사용자가 해당 마이크의 사용자의 목소리를 들을 수 있는 현상을 말합니다. 유령 마이크 현상이 발생하는 근본적인 원인은 업무의 마이크 상태와 RTC Engine의 사용자 역할 상태가 일치하지 않기 때문입니다. 이 문제가 발생하는 데는 다음과 같은 몇 가지 가능한 원인이 있습니다.
청취자가 마이크 끄고 사용을 중지하여 마이크 리스트가 업데이트되었지만 마이크 정보 콜백이 도달하지 않거나 차단되어 청취자의 로컬에서 RTC Engine의 관객 역할 전환 및 마이크 종료 작업이 실행되지 않아, 마이크에 있지 않아도 여전히 발언할 수 있는 상태가 됩니다.
청취자가 마이크 끄고 사용을 중지하여 마이크 리스트가 업데이트되었지만 마이크 정보 콜백을 받은 후 청취자의 로컬에서 RTC Engine의 관객 역할 전환 인터페이스 호출이 실패하여 마이크에 있지 않아도 여전히 발언할 수 있는 상태가 됩니다.
App이 무차별 대입 공격을 당해 UserSig가 해커에게 탈취되었고, 이로 인해 해커가 스트리머 역할로 RTC Engine 방에 침입해 자유롭게 발언할 수 있었습니다.
유령 마이크의 감지 및 처리
유령 마이크를 감지함으로써 능동적으로 식별하고 신속하게 처리할 수 있습니다. 여기서는 실시간 스트리머 목록 비교및 감지를 하는 서버 측의 감지 솔루션을 권장합니다.
솔루션 원리: 음성 채팅방 시나리오에서 사용자 역할은 스트리머와 시청자로 구분되며 스트리머 역할만 로컬 오디오를 업로드할 수 있습니다. 따라서 업무 마이크 목록과 RTC Engine 역할 목록을 비교하여 유령 마이크를 감지할 수 있습니다. RTC Engine은 서버 측의 방 및 미디어 이벤트 콜백을 제공하며, 방 입장, 역할 전환, 방 퇴장 등의 이벤트를 모니터링하여 현재 방의 실시간 스트리머 목록을 유지할 수 있습니다. 그런 다음 RTC Engine 실시간 스트리머 목록과 업무 전체 마이크 목록을 비교하면 유령 마이크를 쉽게 감지하고 식별할 수 있으며, 이후 방에서 나가게 시키거나 금언등 조치를 취할 수 있습니다.
1. RTC Engine 콘솔은 콜백 정보를 자체 구성할 수 있도록 지원하며, 구성이 완료되면 이벤트 콜백 알림을 받을 수 있습니다. 자세한 내용은 콜백 구성을 참조하십시오.
2. 콜백 이벤트 패킷을 수신하고 파싱하며 103/104/105 이벤트를 주시하여 현재 방의 실시간 온라인 스트리머 역할 사용자 목록을 통계합니다. 자세한 내용은 콜백 이벤트을 참조하십시오.
103
104
105
{
"EventGroupId":1, #방 이벤트 그룹
"EventType":103, #방 입장 이벤트
"CallbackTs":1687679847972, #콜백 시간, 단위 밀리초
"EventInfo":{
"RoomId":"123456", #방 번호
"EventTs":1687679847, #이벤트 발생 시간, 단위 초
"EventMsTs":1687679847899, #이벤트 발생 시간, 단위 밀리초
"UserId":"1a99b0a9", #사용자 이름
"Role":20, #사용자 역할 20:스트리머; 21:시청자
"TerminalType":2, #터미널 유형
"UserType":3, #사용자 유형
"Reason":1 #구체적인 사유
}
}
{
"EventGroupId":1, #방 이벤트 그룹
"EventType":104, #방 퇴장 이벤트”
"CallbackTs":1687679847972, #콜백 시간, 단위 밀리초
"EventInfo":{
"RoomId":"123456", #방 번호
"EventTs":1687679847, #이벤트 발생 시간, 단위 초
"EventMsTs":1687679847899, #이벤트 발생 시간, 단위 밀리초
"UserId":"1a99b0a9", #사용자 이름
"Role":20, #사용자 역할 20:스트리머; 21:시청자
"Reason":1 #구체적인 사유
}
}
{
"EventGroupId":1, #방 이벤트 그룹
"EventType":105, #역할 전환 이벤트
"CallbackTs":1687679847972, #콜백 시간, 단위 밀리초
"EventInfo":{
"RoomId":"123456", #방 번호
"EventTs":1687679847, #이벤트 발생 시간, 단위 초
"EventMsTs":1687679847899, #이벤트 발생 시간, 단위 밀리초
"UserId":"1a99b0a9", #사용자 이름
"Role":20, #사용자 역할 20:스트리머; 21:시청자
}
}
주의:
105-역할 전환 이벤트은 사용자가 방에 입장한 후 역할 변경 시에만 트리거되므로, 103-방 입장 이벤트의 초기 역할 정보를 기반으로 사용자 역할 목록을 보완하고 104-방 퇴장 이벤트를 통해 사용자 역할 목록을 삭제하여 유지 관리되는 방 사용자 역할 목록을 더 정확하게 만들어야 합니다.
3. 일정한 빈도로 각 방의 업무 마이크 목록과 RTC Engine 실시간 스트리머 목록을 순환적으로 비교하여 유령 마이크를 식별하고 채팅 금지 또는 방에서 나가게 시킴을 합니다.
마이크 연결/해제 시 끊김 방지 솔루션
문제 설명
모바일 기기 시스템 메커니즘의 차이로 인해 Android와 iOS는 음성 채팅 시나리오에서 마이크 연결/해제 시의 동작이 일치하지 않습니다. iOS 단말에서는 마이크 연결/해제 시 잠시적인 오디오 끊김이 발생할 수 있습니다.
원인 분석
이는 iOS 시스템 오디오 메커니즘과 관련이 있습니다. startLocalAudio 및 stopLocalAudio 작업은 마이크 장치 권한을 획득하고 릴리스하며, SDK의 오디오 재수집으로 인해 AVAudioSession이 오디오 드라이버를 재시작시켜 마이크를 켜고 끌 때 오디오가 잠시 끊기는 현상이 발생합니다.
솔루션
RTC Engine의 일반적인 마이크 연결/해제 시나리오의 타이밍은 아래 그림과 같으며, 역할을 전환하는 동시에 로컬 오디오의 수집 및 발행을 시작하거나 중지합니다. 이 시나리오는 Android에서 정상적으로 사용할 수 있습니다.
iOS에서는 마이크를 끄고 사용을 중지하는 작업에서 stopLocalAudio를 호출하여 오디오 수집을 중단하고 마이크 권한을 해제하지 않아도 시청자의 역할를 전환하는 것만으로 푸시 스트림을 중지할 수 있어 마이크 켜고 끌 때 끊김 현상을 피할 수 있습니다.
주의:
마이크 켜고 끌 때 끊김 방지 솔루션에서 마이크를 끄고 사용을 중지하는 작업에서 stopLocalAudio를 호출하지 않으면 시스템이 계속 마이크 수집 상태를 유지하여 사용자 오해를 일으킬 수 있습니다.
오디오 구성의 최적화 사례
오디오 구성에서 오디오 음질과 볼륨 유형은 서로 다른 개념입니다. RTC Engine에서 오디오 음질은 로컬 오디오 수집 및 게시를 시작할 때 startLocalAudio(TRTCAudioQuality)를 설정하거나 setAudioQuality(TRTCAudioQuality)를 통해 개별적으로 음질릏 설정할 수 있습니다. 볼륨 유형은 방 입장 시나리오와 오디오 음질 설정 등 다양한 요소의 조합에 의해 결정되며, 또한 setSystemVolumeType(TRTCSystemVolumeType)를 통해 특정 볼륨 유형을 강제로 지정할 수도 있습니다.
오디오 음질 구성의 최적화 사례
RTC Engine SDK는 현재 다양한 수직 시나리오에서 오디오 음질에 대한 차별화된 요구를 충족하기 위해 세 가지 신중하게 조정된 오디오 음질 모드를 제공합니다.
오디오 음질 모드
오디오 음질 열거 값
오디오 음질의 매개변수
오디오 음질의 설명
인간 음성 모드
TRTCAudioQualitySpeech
샘플링 레이트: 16k; 모노;
인코딩 비트레이트: 16kbps
네트워크 저항성이 강해서 약한 네트워크 환경에서도 원활한 흐름을 유지하며, 온라인 회의나 음성 통화 등 인간 음성 커뮤니케이션이 주가 되는 애플리케이션 시나리오에 적합합니다.
기본 모드
TRTCAudioQualityDefault
샘플링 레이트: 48k; 모노;
인코딩 비트레이트: 50kbps
SDK 기본 모드는 음악 복원도가 인간 음성 모드보다 우수하며 전송 데이터량이 음악 모드보다 훨씬 적어서 다양한 시나리오에 적합합니다.
음악 모드
TRTCAudioQualityMusic
샘플링 레이트: 48k; 풀 밴드 스테레오;
인코딩 비트레이트: 128kbps
이 모드에서 오디오 전송 데이터량이 매우 커서 음악 신호가 모든 주파수 대역에서 고음질의 디테일 복원도를 보장하며, 고음질 음악 전송이 필요한 시나리오에 적합합니다.
위 표를 통해서 인간음성 모드에서 음악 모드로 음질 효과가 점차 높아지지만 오디오 전송 데이터량이 점차 늘어납니다.
음성 채팅방 시나리오에서 순수 인간 음성 커뮤니케이션은 인간음성 모드를 선택하는 것이 좋으며, 네트워크 조건에서 더 나은 유연성을 얻을 수 있기 때문입니다.
좋은 오디오 디테일 복원도를 얻기 위해 배경 음악 재생이 필요한 음성 채팅방은 기본 모드 또는 음악 모드를 선택하는 것을 권장합니다
하행 시청자의 네트워크 대역폭 부담을 고려하여 원활한 체험을 보장하기 위해, 10명 이상의 마이크 사용자가 있는 업무 시나리오에서는 음악 모드의 사용을 신중하게 고려해야 합니다.
설명:
RTC Engine 오디오 음질은 동적 조정을 지원하며 스트리밍 과정에서 setAudioQuality(TRTCAudioQuality)를 호출하여 오디오 음질을 동적으로 조정할 수 있습니다.
볼륨 유형 구성의 최적화 사례
RTC Engine SDK는 현재 다양한 시나리오에서 볼륨 유형에 대한 차별화된 요구를 충족하기 위해 세 가지 시스템 볼륨 유형 제어 모드를 제공합니다.
볼륨 유형 모드
볼륨 유형 모드의 열거 값
볼륨 유형 모드의 설명
전체 통화 볼륨
TRTCSystemVolumeTypeVOIP
이 방안의 장점은 사용자가 마이크를 켜고 끌 때 오디오 모듈이 작업 모드를 전환할 필요 없이 원활하게 마이크를 켜고 끌 수 있어서 사용자가 자주 마이크를 켜고 끄는 애플리케이션 시나리오에 적합합니다. 방에 입장할 때 선택한 시나리오가 TRTCAppSceneVideoCall 또는 TRTCAppSceneAudioCall인 경우 SDK가 자동으로 이 모드를 사용합니다.
자동 전환 모드
TRTCSystemVolumeTypeAuto
"마이크 켜면 통화하고, 마이크 끄면 미디어로 전환"이라고도 하며 스트리머가 마이크를 켤 때는 통화 볼륨을 사용하고 시청자가 마이크를 끄고 사용하지 않으면 미디어 볼륨을 사용하는 방식으로 온라인 라이브방송 시나리오에 적합합니다. 방에 입장할 때 선택한 시나리오가 TRTCAppSceneLIVE 또는 TRTCAppSceneVoiceChatRoom인 경우 SDK가 자동으로 이 모드를 사용합니다.
전체 미디어 볼륨
TRTCSystemVolumeTypeMedia
통화 시 미디어 볼륨만 사용하며 음질 요구 사항이 까다로운 음악 시나리오에 적합합니다. 사용자 대부분이 외부 장치(예: 외장 사운드 카드)를 사용하는 경우 이 모드를 사용할 수 있습니다.
통화 시나리오에서는 기본 전체 통화 볼륨을 사용하는 것을 권장하며, 이 경우 오디오 모드 전환이 필요 없습니다.
음성 채팅방 시나리오에서 순수 음성 커뮤니케이션은 기본 자동 전환 모드(마이크 켜면 통화하고 마이크 끄면 미디어로 전환)를 선택하는 것이 좋습니다.
배경 음악을 재생해야 하는 음성 채팅방은 전체 미디어 볼륨을 설정하면 사용자가 마이크를 켜고 끌 때 원격 음악의 끊김 및 볼륨 급변을 방지할 수 있습니다.
설명:
특정 볼륨 유형을 지정하려면 방 입장 후 스트리밍 전에 setSystemVolumeType을 한 번 호출하는 것이 좋으며, 마이크를 켜고 끌 때 호출하지 마십시오.
통화 음량은 휴대폰 자체의 AEC 기능을 사용할 수 있으며 블루투스 이어폰의 마이크를 통한 음성 수신도 지원됩니다. 단점은 음질이 별로입니다.
미디어 음량은 휴대폰 자체의 AEC 기능을 사용할 수 없으며 블루투스 이어폰의 마이크를 통한 음성 수신도 지원되지 않습니다. 하지만 더 나은 음악 재생 효과를 제공합니다.
단일 스트림 음량 크기의 평가
음성 채팅방 시나리오에서 일부 고객은 대역폭을 줄여 비용을 절감하기 위해 마이크 사용자가 RTC 단일 스트림을 푸시하고 시청자가 방 내의 혼합 스트림을 풀링하는 방식을 선택합니다. 그러나 음성 채팅방 시나리오에서는 일반적으로 마이크 사용자의 음량 크기에 따라 UI에 "음파 그래프" 또는 "볼륨 바"와 같은 해당 피드백을 표시해야 합니다. 단일 오디오 스트림의 음량 크기 평가 피드백 기능은 RTC Engine 방 내에서 쉽게 구현할 수 있지만, 순수 오디오 혼합 스트림에서 구현하려면 몇 가지 특별한 방법이 필요합니다. 아래에서는 두 가지 솔루션의 구체적인 구현 방법을 각각 소개하겠습니다.
RTC 방 내 단일 스트림 음량의 평가
단계1: 볼륨 크기 알림의 활성화
enableAudioVolumeEvaluation 인터페이스를 통해 음량 크기 콜백을 활성화하고 선택적으로 로컬 인간음성 감지 기능을 켭니다. 이 기능을 활성화하면 SDK는 onUserVoiceVolume 콜백에서 로컬 사용자와 원격 스트리밍 사용자의 음량 크기, 최대 음량 값 및 로컬 인간음성 감지 결과를 피드백합니다.
주의:
RTC Engine SDK 10.2및 그의 이상 버전에서는 로컬 인간음성 감지 기능이 추가되었으며, 활성화한 후TRTCVolumeInfo.vad에서 로컬 인간음성 감지 결과를 표시합니다(스트리머 역할이어야 함). muteLocalAudio 및 setAudioCaptureVolume(0) 작업은 인간음성 감지 결과에 영향을 주지 않아 사용자에게 마이크 켜기를 알리기에 편리합니다.
단계 2: 볼륨 크기 콜백의 모니터링
TRTCCloudListener에서 onUserVoiceVolume 콜백을 모니터링하며 콜백에서 로컬 사용자와 원격 스트리밍 사용자의 볼륨 크기 및 원격 최대 볼륨 값을 피드백합니다. 볼륨 크기에 따라 UI에서 해당하는 음파 표시를 할 수 있습니다.
순수 오디오및 혼합 스트림 음량의 구현 프로세스는 위 그림과 같습니다. 마이크 사용중의 스트리머는 음량 크기 콜백을 모니터링하고 로컬 음량과 원격 음량을 판단해야 하며, 로컬 음량 값 및 사용자 정보를 SEI 메시지 형태로 오디오 스트림에 삽입한 후 혼합 스트림을 거쳐 마이크 미사용중의 시청자에게 전달합니다. 혹은 방주인 한 명이 모든 마이크 사용중의 스트리머의 콜백 음량 값을 SEI 방식으로 전송할 수도 있습니다. 아래 그림은 전체 프로세스의 타이밍 다이어그램을 보여줍니다:
주의:
혼합 스트림 전환 CDN을 통해 SEI를 전달해야 하는 경우:
입장 시나리오에서는 반드시 LIVE를 선택해야 하고 순수 음성 입장 시나리오를 선택해서는 안 됩니다. 그렇지 않으면 SEI 메시지가 전달되지 않습니다.
혼합 스트림 인터페이스가 setMixTranscodingConfig를 사용하는 경우, 혼합 스트림 모드는 PureAudio 순수 오디오 모드를 선택할 수 없습니다.
혼합 스트림 인터페이스가 startPublishMediaStream를 사용하는 경우, 미디어 스트림 트랜스코딩 구성 매개변수에 TRTCVideoLayout 매개변수를 반드시 포함해야 합니다.
아래 그림과 같이, 시청자 측에서 혼합 스트림을 풀링하여 분석된 SEI 메시지에는 해당 발화자의 음량 크기가 표시됩니다.
시나리오 플레이
음성 채팅방 시나리오에서 방주인과 몇 명의 마이크 사용자는 음성으로 온라인에서 인터랙티브하며, 일부 시청자는 발언은 할 수 없으며 청취만 가능할 수도 있습니다. 선물 증정과 채팅 메시지를 통해 인터랙티브할 수 있습니다. 일반적으로 동일한 취향을 가진 사용자들이 시청하고 인터랙티브할 수 있도록 다양한 방 테마를 설정하며, 일반적인 테마로는 FM 라디오, 노래방 채팅, 게임 인터랙티브, 경기 생방송 등이 있습니다.
FM 라디오 방
스트리머가 단독으로 생방송을 진행하거나 몇 명의 게스트와 함께 방송하는 방식입니다. 배경 음악과 음향 효과를 재생하는 동시에, 시청자들은 선물을 보내고 마이크를 켜서 음성 인터랙티브에 참여할 수 있습니다.
이 시나리오는 일반적으로 시청자 수가 많습니다. RTC Engine 은 단일 방에서 동일 시점에 최대 10만 명을 지원할 수 있으며, 스트리머가 RTC 스트림을 푸시하고 시청자가 RTC 단일 스트림을 풀하는 방식을 채택하는 것에 적합합니다.
설명:
이 시나리오의 추천: 스트리머가 RTC 스트림을 푸시/풀하고 시청자가 CDN 혼합 스트림을 풀하는 방안입니다.
KTV 음성 채팅방
일반적으로 한 명의 관리자가 있으며, 노래 신청, 댓글, 노래 맞추기, 노래 이어부르기 등을 할 수 있습니다. 주로 다인 연맥과 다인 론맥 두 가지 모드로 나뉩니다. 다인 연맥은 한 사람이 메인 보컬을 맡고 다른 사용자는 들으면서 말할 수 있지만 메인 보컬은 다른 사용자들의 목소리를 들을 수 없습니다. 방의 청취자들은 모든 소리를 들을 수 있습니다. 다인 론맥 모드는 노래 신청 후 한 사람이 한 구절씩 부르고, 부르기가 끝나면 자동으로 다음 사람에게 차례가 넘어갑니다. 다른 사용자들은 대기 시간 동안에 듣기만 할 수 있으며 댓글로 소통할 수 있지만 음성 채팅은 할 수 없습니다.
온라인 노래방 시나리오는 지연 동기화에 대한 요구 사항이 높으며, 시청자가 언제든지 마이크 켜서 노래를 같이 부르려는 요구가 있으므로, 마이크 사용중의 스트리머가 RTC 스트림을 푸시/풀하고 시청자가 RTC 혼합 스트림을 풀하는 솔루션에 적합합니다. 여기서는 혼합 스트림 봇이 혼합 스트림 명령을 시작하고 혼합 스트림을 RTC Engine 룸으로 다시 푸시하여 시청자들이 스트림을 풀어 볼 수 있도록 해야 합니다.
설명:
이 시나리오의 추천: 스트리머가 RTC 스트림을 푸시/풀하고 시청자가 RTC 혼합 스트림을 풀하는 방안입니다.
KTV 음성 채팅방 구현의 구체적인 기술 세부 사항 및 주의 사항에 대해서는 온라인 노래방 시나리오 솔루션을 참조하십시오.
인터랙티브 게임룸
늑대인간 게임, 시나리오 게임, PIA 연기, 진실말 게임, 그림 맞추기 등 시나리오에서는 게임 진행에 따라 방을 생성하고 게임 진행 상황에 따라 말하는 플레이어의 권한을 제어하여 순서대로 발언합니다.
인터랙티브 게임 시나리오는 일반적으로 참여 인원이 제한적이며, 자주 마이크를 켜고 끄며 게임에 참여하려는 요구가 있어서 스트리머가 RTC 스트림을 푸시/풀하고 시청자가 RTC 단일 스트림을 풀하는 일반적인 방안에 적합합니다. 게임 참여자는 언제든지 마이크를 켜고 발언하거나 마이크를 끌 수 있으며, 캐릭터가 사망되면 강제로 마이크를 끄고 시청만 하거나 방을 나갑니다.
설명:
이 시나리오의 추천: 스트리머가 RTC 스트림을 푸시/풀하고 시청자가 RTC 단일 스트림을 풀하는 방안입니다.
인터랙티브 게임룸은 일반적으로 로컬 게임 음향 효과 재생을 포함하며, AEC 처리 및 볼륨 유형 선택에 주의해야 합니다.
