오디오 믹서는 자체 모듈에서 작동하는 멀티 플랫폼 오디오 렌더러입니다. 오디오 믹서를 사용하면 모든 플랫폼에서 전체 기능을 동일하게 사용할 수 있고, 대부분의 레거시 오디오 엔진 기능과의 호환성을 확보할 수 있으며, 언리얼 엔진의 기능을 새로운 영역으로 확장할 수 있습니다. 이 문서에서는 오디오 믹서의 전반적인 구조를 설명하고 더 자세한 내용을 다루고 있는 참고 자료를 제공합니다.
배경 및 동기
오디오 렌더링
오디오 렌더링이란 사운드 소스가 디코딩 및 믹싱되어 디지털 오디오 컨버터 또는 DAC이라고도 하는 오디오 하드웨어 엔드포인트로 유입되어 최종적으로 하나 이상의 스피커에서 재생되는 프로세스를 말합니다. 오디오 렌더러는 저마다 아키텍처와 기능 세트가 다릅니다. 하지만 게임은 인터랙션과 리얼타임 퍼포먼스가 매우 중요하기 때문에 게임용 오디오 렌더러는 리얼타임 디코딩, 사운드 파라미터의 동적 활용 및 처리, 리얼타임 샘플 레이트 변환을 반드시 지원해야 합니다. 이와 더불어 소스별 디지털 신호 처리(DSP) 이펙트, 공간화, 서브믹싱, 리버브와 같은 믹싱 후 DSP 이펙트 등의 오디오 렌더링 기능 또한 지원해야 합니다.
플랫폼 레벨 기능: 오디오 렌더링 API
일반적으로 하드웨어 플랫폼은 기능을 완전히 갖춘 하이 레벨의 오디오 렌더링 C++ API를 하나 이상 제공합니다. 일부 플랫폼에서는 여러 가지 옵션을 제공합니다. 이러한 API는 특정 플랫폼을 위한 코덱과 특정 플랫폼을 위한 인코더 API 및 디코더 API를 제공하는 경우가 많습니다. 많은 플랫폼에서 런타임 퍼포먼스를 향상하기 위해 하드웨어 디코더를 제공합니다. 플랫폼 오디오 API는 코덱을 비롯하여 볼륨 제어, 피치 제어(리얼타임 샘플 레이트 변환), 공간화, DSP 처리 등 오디오 엔진에 필요한 다른 모든 기능을 제공합니다.
게임 레벨 기능: 게임플레이 API
게임 엔진은 이러한 플랫폼 레벨의 기능 위에 추가적인 기능을 제공합니다. 예를 들어 다양한 기능이 블루프린트 같은 스크립팅 엔진 또는 오디오 컴포넌트, 앰비언트 액터 및 오디오 볼륨 같은 특정 게임 컴포넌트 및 시스템에 후킹될 수 있으며, 사운드 동시성 같은 재생할 사운드와 사운드 클래스, 사운드 믹스 및 사운드 큐와 같은 파라미터를 결정하기 위한 작업을 수행합니다.
플랫폼 전용 오디오 렌더링 API의 문제점
이 패러다임은 지원하는 타깃 플랫폼의 수가 적고 새롭게 지원하는 플랫폼의 수를 늘리는 데 충분한 시간이 있는 경우에는 잘 작동합니다. 하지만 다양한 플랫폼을 지원하는 언리얼 엔진의 경우에는 플랫폼 전용 API 사이를 오가고, 해당 플랫폼의 버그를 트래킹하고, 플랫폼 기능을 동등하게 유지하는 작업에 오디오 엔진 개발 시간의 대부분을 할애하게 될 수 있습니다. 이로 인해 새로운 런타임 기능과 개발 툴을 을 제작하는 데 많은 비용을 지불해야 합니다.
이러한 패러다임에서는 기능을 동등하게 제공하는 것이 불가능하기 때문에 기능 지원 매트릭을 작성하고 유지 관리하여 퀄리티 보장 팀 및 사운드 디자이너와 어떤 플랫폼에서 무슨 기능을 사용할지 논의해야 합니다. 또한 모든 기능이 모든 플랫폼에서 동작하는 것이 아니기 때문에 문서를 작성하고 지원을 제공하기가 어렵습니다. 여러 플랫폼에서 출시하려는 게임의 오디오 믹싱은 모든 기능이 모든 플랫폼에서 작동하지 않고 기존 기능의 사운드가 플랫폼에 따라 다르게 재생되는 경우 많은 어려움이 따릅니다.
오디오 렌더링 레벨의 기능을 새로 제작하려면 모든 플랫폼에 대해 개별적으로 구현해야 합니다. 그렇지 않을 경우 플랫폼별로 기능의 동일성이 떨어지는 문제가 발생합니다. 이와 더불어 최적화 또는 버그 수정을 위해서는 복제가 필요하며 그렇지 않을 경우 특정 플랫폼으로 한정되는 결과가 초래됩니다.
대부분의 경우 로우 레벨의 새로운 기능을 제작하거나 최적화하고 버그를 수정하는 것은 불가능합니다. 플랫폼 API에 퍼포먼스 문제가 발생하거나 버그가 존재할 경우, 이를 해결하기 위한 리소스가 없는 상황이 많아 플랫폼 오너와 협력하지 않고서는 해결하기 어렵습니다. 또한 버그를 수정하는 것이 여러 가지를 시도해 보거나 임시방편에 그치는 경우가 많습니다. 새로운 기능이 가능하더라도 활용 범위가 좁은 플러그인 API이기 때문에 전체 플랫폼에서 작동하지 않는 경우도 흔합니다.
새로운 플랫폼에서 플랫폼 전용 오디오 API를 도입하면 상당한 작업이 필요하며 개발 시간이 더 오래 걸립니다. 때로는 새로운 플랫폼에 기능을 모두 갖춘 오디오 API가 없을 수도 있습니다. 이러한 경우 해당 플랫폼이 자체 오디오 렌더링 API를 제작하는 데 리소스를 투자하지 않는 이상 이 플랫폼에서 오디오 렌더링을 구성하는 것은 불가능에 가깝습니다.
게임 엔진의 중요한 이점 중 하나는 서드 파티에서 언리얼 엔진에 새로운 기능과 익스텐션을 추가할 수 있다는 것입니다. 플랫폼 API의 복잡한 배치와 플러그인 익스텐션을 지원하는 다양한 방식으로 인해 모든 것을 포함하는 공통 API를 만들기란 불가능에 가깝습니다.
오디오 믹서를 통한 해결
이러한 문제를 해결할 수 있는 솔루션은 다양한 플랫폼에서 사용 가능한 단일 오디오 렌더링 API인 오디오 믹서를 활용하는 것입니다. 오디오 믹서를 사용하면 모든 플랫폼에서 하나의 코드 베이스만 존재하기 때문에 기능 동일성을 훨씬 더 수월하게 확보할 수 있습니다. 새로운 기능을 한 번만 구현하면 모든 플랫폼에서 작동하기 때문에 개발 시간이 최적화됩니다. 테스팅, 문서화, 사운드 디자이너 구현, 믹싱 또한 간소화됩니다. 불가피한 특별한 경우를 제외하고 모든 플랫폼에서 사운드가 동일하게 재생되며 모든 기능이 동일하게 작동합니다.
수백 줄의 코드만 작성하면 새로운 플랫폼을 지원하는 작업을 단 몇 일만에 신속하게 처리할 수 있습니다. 오디오 엔진 플러그인을 위한 인터페이스를 작성하는 작업이 수월해질 뿐만 아니라 혁신을 위한 중요한 수단도 확보할 수 있습니다. 또한 버그를 수정하고 코드를 최적화하여 모든 플랫폼을 보다 효과적으로 활용할 수 있습니다.
각 플랫폼마다 당면 과제가 여전히 남아 있습니다. 플랫폼마다 CPU와 메모리 기능이 다르거나 하드웨어 지원 옵션이 다릅니다. 하지만 CPU 또는 메모리 부족이 발생하는 경우 오디오 믹서를 사용하여 기능을 비활성화하거나 퀄리티를 감소하는 등의 방법을 통해 CPU 로드를 자동으로 줄이거나 쿠킹 시 메모리를 정리하거나 인코딩을 자동으로 다운 샘플링하고 퀄리티를 낮춰 메모리 로드를 자동으로 줄이는 기능을 사용할 수 있습니다. 사운드 디자이너와 오디오 프로그래머의 경우 오디오 믹서를 사용하면 지정된 플랫폼에서 지정된 퍼포먼스와 메모리 타깃을 달성할 수 있습니다.
오디오 믹서라고 부르는 이유
오디오 렌더링을 가리키는 또 다른 말은 오디오 믹싱(audio mixing)입니다. 언리얼 엔진에서 그래픽을 언급할 때 렌더링이라는 단어가 거의 단독으로 사용되기 때문에 새로운 오디오 렌더러의 이름을 오디오 믹서 로 정했습니다. 하지만 믹싱 이라는 단어가 주는 모호함 때문에 이러한 결정이 때로는 오디오 커뮤니티와 사용자 사이에서 혼란을 야기했습니다. 이는 소리의 크기를 나타내는 볼륨의 믹싱과 혼동될 수 있습니다.
기본적으로 오디오 믹서는 하드웨어 믹싱 콘솔이 수행하는 역할과 동일한 역할을 합니다. 서브믹싱 및 마스터 이펙트 프로세서를 비롯한 다양한 파라미터와 이펙트 프로세서를 통해 사운드 소스를 처리한 후 한데 모읍니다.
오디오 믹서 아키텍처
플랫폼 레이어
오디오 믹서에는 최소한의 플랫폼 전용 API 레이어를 갖추고 있습니다. 플랫폼 API는 다양한 플랫폼을 위한 오디오 하드웨어에 액세스하는 데 있어 필요한 모든 디테일을 종합하기 때문에 이러한 레이어는 필요한 경우 하드웨어 기능 쿼리와 하드웨어 상태 변화를 처리하고 오디오를 하드웨어로 피딩하기 위한 멀티 플랫폼 오디오 믹서를 구성합니다.
일부 플랫폼에는 상태 인터럽션, 앱 서스펜션, 디바이스 교체 같은 플랫폼 간의 미묘한 차이를 처리하기 위한 추가적인 코드가 필요합니다. 또한 하드웨어 가속화 디코딩 같은 플랫폼 전용 향상점을 활용하기 위한 지원이 추가되는 경우도 있습니다. 이러한 경우 플랫폼 전용 코드가 필요한 경우가 많습니다. 이 플랫폼 전용 레이어는 언리얼 엔진의 다양한 코덱을 위한 런타임 디코더 생성과 같은 언리얼 엔진의 기존 플랫폼 전용 기능 중 일부를 처리합니다.
버퍼 생성
오디오를 하드웨어로 피딩하는 방식은 플랫폼마다 다릅니다. 일부 플랫폼 API는 대기열에서 오디오를 하드웨어로 푸시 하도록 디자인되었기 때문에 클라이언트 앱이 오디오 큐 등록 관리를 담당합니다. 다른 API는 콜백 기반이기 때문에 하드웨어에 오디오가 더 필요할 때 클라이언트 코드를 호출합니다. 이 두 가지 경우에 오디오 믹서는 하드웨어가 현재 수신하고 있는 버퍼와 같은 현재 버퍼를 렌더링하는 동안 향후 오디오 버퍼를 생성하는 멀티 버퍼 스킴을 사용합니다.
오디오 믹서가 다음 오디오 버퍼를 렌더링하는 데 시간이 너무 오래 걸려 버퍼 큐에 푸시 API가 고갈 상태가 되거나, API가 콜백 API를 다시 호출할 때 사용 가능한 오디오가 없으면 오디오 재생에 눈에 띄는 갭이 발생합니다. 이를 언더런(underrun) 또는 고갈(starvation)이라고 하며, 이로 인해 매우 좋지 않은 소리가 발생하기 때문에 어떠한 방법으로든 이를 피해야 합니다. 언더런은 오디오 스트림에 갑작스러운 불연속성을 야기하기 때문에 노이즈로 여겨집니다. 짧은 언더런의 경우 팝(pop), 짧게 지속되는 언더런의 경우 셔터(shutter), 오래 지속되는 언더런의 경우 오디오의 커다란 드롭아웃(drop-out)이 발생합니다. 갑작스러운 진폭의 변화는 심지어 오디오 리시버 또는 스피커에 대미지를 가할 수 있습니다. 대부분의 경우 언더런은 CPU 포화(CPU saturation)로 인해 발생합니다. 언더런이 발생할 때 오디오 믹서가 너무 많은 작업을 처리하고 있는 것입니다. 다른 경우로는 비동기 디코딩 또는 합성을 위한 작업 그래프에 폐색이나 다른 문제가 있음을 나타낼 수 있습니다. 언더런 상태에서 오디오의 클릭 또는 팝을 구별하기가 어려울 때도 있습니다.
사전에 너무 많은 오디오를 생성하는 경우 또한 있습니다. 이러한 경우 게임 이벤트는 리얼타임에서 점점 더 뒤쳐지게 되고 이는 사용자가 지연시간으로 인지합니다. 극단적인 경우 이는 오버런(overrun)이라고 하며 이 또한 피해야 합니다. 리얼타임 오디오 엔진은 언더런과 오버런 사이에서 균형을 찾아야 합니다. 언더런을 방지하기 위해 어느 정도 필요한 오버런은 한계치 아래로 유지되야 하는 반면, 언더런은 어떠한 경우에라도 피해야 합니다.
적절한 균형을 찾기란 어려울 수 있으며 플랫폼마다 적절한 균형이 다를 때가 많습니다. 이와 같은 이유로 인해 오디오 믹서는 사운드 디자이너 또는 오디오 프로그래머가 플랫폼마다 오디오 버퍼의 크기를 선택하여 오디오 버퍼 렌더마다 렌더링하고 현재 들리는 버퍼에 앞서 렌더링할 버퍼의 수를 결정할 수 있도록 디자인되어 있습니다.
오디오 믹서 스레딩 모델
오디오 믹서는 오디오 렌더링을 수행하기 위해 자체 스레드를 생성합니다. 에픽게임즈에서는 이를 오디오 렌더 스레드(audio render thread) 라고 부릅니다. 이 스레드는 오디오 스레드(audio thread) 와는 다르며 DSP 소스 생성 및 믹싱을 위한 모든 작업을 수행합니다.
오디오 스레드 는 재생할 사운드와 프로세싱 사운드 큐, 사운드 클래스, 사운드 믹스 및 감쇠 같은 해당 사운드의 파라미터를 결정하는 작업을 수행하는 스레드입니다. 오디오 스레드는 오디오 믹서와 플랫폼 전용 레거시 오디오 엔진 간에 거의 동일합니다. 현재 오디오 스레드는 UObject와 가비지 컬렉션을 처리하는 방식이 다소 복잡합니다. 오디오 스레드는 UObject를 가지고 있기 때문에 가비지 컬렉션 동안 처리가 방지되고 중단됩니다. 런타임 동안 이러한 UObject는 읽기 전용입니다. 하지만 에디터에서는 UObject가 쓰기 가능하기 때문에 오디오 스레드를 사용하지 않습니다.
콜백 기반 플랫폼 API에는 실제 플랫폼 하드웨어 콜백이 만들어지는 하드웨어 스레드도 있습니다. 하드웨어에서 소유하는 이 스레드 콜백은 오디오 렌더 스레드에서 큐에 등록된 렌더링된 버퍼를 거의 항상 팝 오프(pop off)하며 실제 작업은 거의 하지 않습니다.
마지막으로, 오디오 엔진은 태스크 그래프에서 비동기 작업을 활용하여 디코딩 및 프로시저럴 오디오(예시: 합성)를 처리합니다.
사운드 소스 생성하기
오디오 믹서 렌더의 첫 번째 단계는 소스를 생성하는 것입니다. 소스를 생성하기 위해 오디오 믹서는 볼륨, 피치, 위치 같은 파라미터와 함께 게임과 오디오 스레드에서 전송한 재생할 사운드 소스를 정의하는 파라미터를 받습니다.
여기서 소스라는 단어가 사용된 이유는 해당 소스를 위해 생성된 오디오가 소스 파일과 같이 압축된 오디오 에셋이나 합성, 디코딩된 미디어, VOIP, 마이크 캡처에 의해 프로시저럴하게 생성된 오디오 에셋 또는 소스 버스 와 같이 함께 믹싱된 기타 소스에서 파생된 오디오 에셋에서 파생될 수 있기 때문입니다. 각각의 경우에 소스 데이터를 생성하는 데는 다른 방식이 사용됩니다.
인코딩된 사운드 소스
ogg-vorbis, opus, atrac9, xma2, adpcm 같은 인코딩된 사운드 소스의 경우 오디오를 비압축 32비트 플로트 버퍼로 디코딩하기 위해 비동기 작업이 사용됩니다. 그런 다음 이 32비트 플로트 버퍼는 샘플 레이트가 소스의 샘플 레이트에서 오디오 믹서의 샘플 레이트로 변환됩니다. 이와 같은 샘플 레이트 변환 프로세스는 사운드 소스에 적용되었을 수도 있는 피치 스케일 을 고려하여 샘플 레이트 변환을 한 번만 진행합니다.
예를 들어 사운드 디자이너가 사운드 소스의 피치를 높이고 싶어 하여 사운드 소스가 32 kHz로 인코딩되고 1.2의 피치 스케일을 가지고 있고 오디오 믹서가 오디오를 48 kHz에 렌더링하는 경우, 샘플 레이트 변환은 다음과 같은 샘플 레이트 비율을 사용합니다.
SampleRateRatio = (48 kHz/32 kHz) * 1.2
SampleRateRatio = 1.8
이는 오디오가 디코딩된 후 사운드 소스의 피치가 1.8까지 올라간다는 의미입니다.
프로시저럴 또는 생성된 사운드 소스
프로시저럴 사운드 소스의 경우 오디오는 다음 32비트 플로트 버퍼를 생성하기 위해 클라이언트 코드를 콜백하는 추상 인터페이스를 통해 생성됩니다. 클라이언트 코드는 이 콜백에 어떠한 오디오든 피딩할 수 있으며, 오디오는 이론적으로 어떠한 소스에서든 나올 수 있습니다. 언리얼 엔진에서는 이를 사용하여 실시간으로 합성하거나 감쇠, 오클루전, 리얼타임 이펙트를 비롯하여 3D 비디오에서 오디오를 재생하듯 미디어 소스에서 오디오를 렌더링하거나, VOIP에서 오디오를 재생할 수 있습니다.
또한 이는 서드 파티 플러그인이 오디오 엔진을 확장할 수 있는 여러 방법 중 하나입니다. 프로시저럴 사운드 소스는 플러그인에서 정의할 수 있으며, 소스 오디오는 완전히 독립적인 사운드 엔진을 비롯하여 어떠한 소스에서든지 오디오 믹서로 피딩할 수 있습니다.
믹싱된 소스
오디오 믹서는 여러 사운드 소스를 함께 믹싱하여 다른 소스를 생성할 수 있도록 지원합니다. 이렇게 믹싱된 소스를 소스 버스(source bus) 라고 합니다. 소스 버스는 다른 소스와 동일하게 취급되며 공간화, 거리 감쇠, 볼륨 믹싱, 소스 이펙트 처리 등 다른 소스가 갖추고 있는 대부분의 기능을 지원합니다. 이 기능을 위해 사운드 소스를 라디오 브로드캐스팅 같은 새로운 공간 위치로 라우팅하는 다이내믹 라우팅, 위치 기반 리버브 처리 같은 공간화된 이펙트 처리, 씬에서 특정 오브젝트에 대한 오디오 바운싱 같은 딜레이 타입 공간 이펙트 등 유용한 애플리케이션이 마련되어 있습니다.
사운드 소스 DSP 이펙트 처리
사운드 소스가 오디오를 생성하면 사운드 소스의 출력이 오디오 DSP 이펙트 의 체인으로 피딩됩니다. 일부 내장 이펙트의 경우에는 모든 사운드 소스에 대한 액세스 권한이 자동으로 부여됩니다. 이러한 DSP 이펙트는 하이 패스 필터와 로우 패스 필터이며, 더 높은 수준의 다양한 기능에 사용됩니다.
사운드 감쇠 세팅 을 통해 사운드 디자이너는 하이 패스 기능과 로우 패스 기능의 필터 주파수 컷오프를 매핑하여 개별 사운드 소스에 리스너 거리 함수를 적용할 수 있습니다.
이러한 소스별 필터를 활용하는 또 다른 기능은 내장 오클루전 시스템(occlusion system) 입니다. 오클루전이 활성화된 경우 사운드가 레이 트레이스를 통해 정해진 오클루전 지오메트리로 차단되어 사운드 디자이너가 정의한 로우 패스 필터를 자동으로 적용합니다. 마지막으로, 사운드 믹스와 사운드 클래스가 소스별로 적용되어 사운드에 로우 패스 필터링을 적용합니다.
자동 내장 필터 이펙트 외에도 사운드는 소스 이펙트 체인(source effect chain) 이라는 체인을 통해 스스로를 피딩할 수도 있습니다. 이는 소스 이펙트 플러그인 API를 통해 제작된 소스별 DSP 이펙트의 시퀀스를 정의하는 에셋으로서 코러스 이펙트, 플랜저, 딜레이, 고급 필터, 링 모듈레이션, 비트 크러싱 등일 수 있습니다.
서브믹스 그래프
소스가 생성된 후 오디오 믹서는 서브믹스 그래프(submix graph) 를 처리합니다. 서브믹스 그래프의 출력은 오디오 하드웨어에서 재생되는 오디오입니다.
서브믹스로 전송하기
마스터 서브믹스(master submix) 는 오디오 엔진이 초기화될 때 오디오 엔진에서 생성됩니다. 기본적으로 베이스 서브믹스로 지정된 서브믹스가 없으면 모든 사운드 소스는 이 서브믹스에 베이스 서브믹스 로 등록됩니다.
소스의 베이스 서브믹스는 소스 출력을 전체 볼륨(포스트 감쇠, 포스트 공간화)으로 믹싱하는 서브믹스입니다. 전송 서브믹스는 지정할 수 있는 수에 제한이 없어 보조 DSP 이펙트를 통해 전송하기 전에 소스를 함께 믹싱할 수 있습니다. 이러한 전송 서브믹스는 디지털 오디오 워크스테이션 또는 믹싱 콘솔에서 리버브와 같이 DSP 이펙트를 위한 보조 채널과 유사합니다.
앞서 설명했듯이 서브믹스 라우팅을 지정하지 않은 사운드 소스에 대해서는 디폴트 라우팅이 발생합니다. 하지만 사운드 소스가 오디오를 서브믹스로 전송할 때 두 가지 주요한 제어 방식이 있습니다. 첫 번째 방식은 베이스 서브믹스를 지정하는 것입니다. 이 서브믹스는 사운드를 전체 볼륨으로 믹싱합니다. 비어 있는 경우 서브믹스는 레거시 기능에 따라 오디오를 EQ 서브믹스 또는 마스터 서브믹스로 라우팅합니다.
마스터 서브믹스
마스터 서브믹스와 더불어 두 개의 마스터 이펙트 서브믹스 가 이 마스터 서브믹스에 자손으로 생성되어 추가됩니다. 마스터 리버브 서브믹스(master reverb submix)와 마스터 EQ 서브믹스(master EQ submix)가 바로 그것입니다. 이러한 마스터 서브믹스는 주로 언리얼 엔진 레거시 기능과의 호환성을 확보하고 기존 프로젝트를 오디오 믹서로 교체하기 위해 생성되었습니다. 하지만 이러한 마스터 서브믹스는 리버브 및 EQ와 인터랙션하는 사운드 클래스, 사운드 믹스, 오디오 볼륨, 사운드 감쇠에서 다양한 하이 레벨의 기능을 지원하는 기반 메커니즘입니다.
출력 생성하기
마스터 서브믹스는 서브믹스 그래프의 루트 노드입니다. 이 마스터 서브믹스에서 생성된 오디오를 얻어 최종 출력이 생성됩니다.
서브믹스의 자손 서브믹스 출력을 먼저 생성한 다음 이 출력을 서브믹스에 등록되거나 전송된 소스와 믹싱하여 각 서브믹스 오브젝트의 출력이 생성됩니다. 등록된 사운드 소스의 전송 양은 서브믹스에서 함께 믹싱된 소스에 대한 게인/감쇠입니다.
이 믹싱된 버퍼는 하드웨어를 위한 출력 채널 환경설정에 믹싱됩니다. 예를 들어 스테레오 출력의 경우 이는 2채널 오디오 버퍼이고, 7.1 오디오의 경우에는 8채널 오디오 버퍼입니다.
이 믹싱된 인터리브 오디오는 서브믹스의 DSP 이펙트 체인을 통해 피딩되어 최종 출력을 생성합니다.
추가적인 서브믹스 기능: 분석, 레코딩, 수신
서브믹스는 오디오 분석을 수행하는 데 이상적인 오브젝트입니다. 현재 블루프린트 델리게이트를 등록하는 메커니즘이 제공되며, 이 메커니즘은 채널마다 서브믹스에서 진폭 엔벨로프 값을 얻습니다. 이 메커니즘은 오디오와 인터랙션할 여러 시각화 또는 게임플레이 시스템에 유용할 수 있습니다. 블루프린트의 서브믹스에서 스펙트럼 데이터를 얻는 리얼타임 FFT 델리게이트 또한 제공됩니다.
서브믹스는 USoundWave 오브젝트 또는 원시 PCM(.wav) 파일에 디스크로 출력을 레코딩할 수 있는 기능도 갖추고 있습니다.
마지막으로, 서브믹스에서 믹싱된 오디오를 동적으로 얻기 위해 다른 코드 시스템에 등록할 수 있는 C++ 델리게이트가 제공됩니다. 이 기능은 서버 기반의 게임 스트리밍을 위한 인터넷 방송이나 서드 파티 플러그인 익스텐션과 같이 유용한 기능에서 사용할 수 있습니다.