- 고정 기능 하드웨어 블록(XMA, Sample Rate Convertor(SRC), 이퀄라이저 및 컴프레션, 필터 볼륨)을 사용하여 일반적으로 사용되는 오디오 함수를 효율적으로 수행합니다
- 이러한 블록을 제어하는 프로그래머블 임베디드 Audio Control Processor(ACP)를 제공합니다
- 시스템 메모리에 액세스하기 위한 Direct Memory Access(DMA) 프로세스
- 믹스 버퍼 라고 하는 특별한 내부 메모리 믹스 버퍼는 한 오디오 프레임 분량의 데이터를 저장하는 메모리 블록입니다. SHAPE 하드웨어는 일반적으로 하나 또는 두 개의 믹스 버퍼에서 읽고 출력 믹스 버퍼에 씁니다. XMA 디코딩과 DMA 및 SRC 블록과 같이 이 일반 프로세스에는 몇 가지 예외가 있습니다.
XAudio2와 오디오 미들웨어는 SHAPE 구성요소를 암묵적으로 구현합니다. 하지만 플로우그래프를 구성하면 XBOX One 콘솔의 오디오 가속 기능에 대한 최대의 유연성과 액세스를 제공합니다.
이 항목에서는 SHAPE 하드웨어와 함수 블록에 대한 개요를 제공합니다.
- 제어 흐름
- DMA
- XMA
- PCM
- Sample Rate Convertor(SRC) 블록
- 이퀄라이제이션 및 컴프레션
- 필터/볼륨 블록(FLTVOL)
- 믹스 버퍼
- 오버플로, 크기, 포화
- SHAPE 큐
- 프로그래밍 고려사항
제어 흐름
다음은 오디오 처리의 일반적인 제어 흐름입니다.- 압축된 XMA 오디오 데이터 파일이 메인 시스템 메모리로 로드됩니다.
- XMA 디코더 블록이 XMA 데이터의 일부를 Pulse Code Modulation(PCM) 데이터로 디코드합니다. 출력은 시스템 메모리의 XMA 디코드 버퍼에 저장됩니다.
- SRC 블록이 XMA 디코드 버퍼에서 PCM 샘플을 읽고 필요한 샘플 레이트 변환 및 피치 시프팅을 수행합니다. 이를 통해 임의의 샘플링 레이트의 오디오 데이터를 SHAPE 가속기 블록으로 가져올 수 있습니다. SRC 블록은 48KHz의 고정 레이트로 실행되는 오디오 데이터를 내부 믹스 버퍼로 출력합니다.
- 이제 추가 SHAPE 처리와 임시 믹스 버퍼로부터의 읽기 및 쓰기가 수행됩니다. 처리는 ACP에 의해 제어되며, ACP 자체는 이 문서 세트에서 설명하는 ACP API를 통해 애플리케이션에 의해 구동됩니다. 처리에는 이퀄라이제이션, 컴프레션, 필터 스케일링, 볼륨 스케일링이 포함됩니다.
- 마지막 단계인 Speaker Output Accumulation 에서는 스피커 믹스 버퍼가 재생을 위해 여러 사운드 소스에서 샘플을 수집하고 믹스합니다. 선택적 글로벌 오디오 효과가 이 단계에서 처리될 수 있습니다.
- 압축된 XMA 오디오 데이터 파일이 메인 시스템 메모리로 로드됩니다.
- XMA 디코더 블록이 XMA 데이터의 일부를 PCM 데이터로 디코드하며, 출력을 시스템 메모리의 XMA 디코드 버퍼에 저장합니다.
- SRC 블록이 XMA 디코드 버퍼에서 PCM 샘플을 읽고 필요한 샘플 레이트 변환 및 피치 시프팅을 수행합니다. 이를 통해 임의의 샘플링 레이트의 오디오 데이터를 SHAPE 가속기 블록으로 가져올 수 있습니다. SRC 블록은 48KHz의 고정 레이트로 실행되는 오디오 데이터를 내부 믹스 버퍼로 출력합니다.
- 이 단계에서 프로세스 흐름이 분기됩니다. DMA 시스템은 하나 이상의 믹스 버퍼를 메인 시스템 메모리로 전송하는 데 사용됩니다.
- 애플리케이션 CPU는 메인 메모리의 버퍼에 필요한 신호 처리를 수행합니다.
- DMA 시스템은 메인 메모리 버퍼의 처리된 오디오 데이터를 임시 믹스 버퍼로 전송하는 데 사용됩니다. 이 단계 이후 프로세스는 앞서 설명한 것과 동일합니다.
- 이제 추가 SHAPE 처리와 임시 믹스 버퍼로부터의 읽기 및 쓰기가 수행됩니다. 처리는 ACP에 의해 제어되며, ACP 자체는 이 문서 세트에서 설명하는 ACP API를 통해 애플리케이션에 의해 구동됩니다. 처리에는 이퀄라이제이션, 컴프레션, 필터 스케일링, 볼륨 스케일링이 포함됩니다.
- 마지막 단계인 Speaker Output Accumulation에서는 스피커 믹스 버퍼가 재생을 위해 여러 사운드 소스에서 샘플을 수집하고 믹스합니다. 선택적 글로벌 오디오 효과가 이 단계에서 처리될 수 있습니다.
DMA
Direct Memory Access(DMA) 시스템은 float에서 integer로, integer에서 float로의 자동 변환 기능과 함께 읽기/쓰기 기능을 지원합니다. DMA 시스템은 128 샘플 블록의 디인터리브된 샘플을 포함하는 순환 버퍼를 사용합니다. DMA 프로세서를 통해 SHAPE 엔진은 추가 처리를 위해 믹스 버퍼에서 메인 시스템 메모리로 데이터를 전송하고, 메인 시스템 메모리에서 믹스 버퍼로 데이터를 검색할 수 있습니다. DMA는 블록 단위로 수행됩니다. 한 번에 한 오디오 프레임 분량의 데이터가 전송됩니다. 블록 인터리브 데이터를 지원하기 위해 스킵 값은 샘플을 읽거나 쓸 때 (기본 주소에서) 건너뛸 시스템 메모리 내의 오디오 프레임 블록 수를 지정합니다. 이 때문에 다채널 스트림은 채널당 하나의 DMA 컨텍스트가 필요합니다. 오디오 데이터 샘플은 항상 32비트 값으로 읽고 쓰이며, 정수 또는 float 형식으로, DMA 컨텍스트FloatConvert 플래그에 지정된 대로입니다. 데이터 대역폭을 줄이기 위해 DMA의 방향(읽기 또는 쓰기)은 DMA 컨텍스트가 아닌 DMA 명령에 지정됩니다. DMA 엔진은 신호 처리는 하지 않지만 float를 integer로, integer를 float로 변환할 수 있습니다. 이를 통해 애플리케이션 CPU가 부동 소수점 형식으로 데이터 샘플을 처리할 수 있습니다.
DMA 버퍼의 크기를 계산하려면 다음 공식을 사용하십시오.
XMA
XMA 형식은 가변 비트 레이트와 압축으로 모노, 스테레오, 인터리브된 다채널 사운드를 지원합니다. XBOX 360 XMA 구현에 비해 클록 레이트 증가(예를 들어 피치 시프팅 기능이 40% 개선됨) 및 보이스 수 320개에서 512개로 증가를 포함해 여러 개선이 이루어졌습니다. XMA 디코더 블록은 메인 메모리의 XMA 데이터 일부를 디코드하고 PCM 데이터를 메인 메모리의 XMA 디코드 버퍼로 반환합니다. XMA 디코더 블록은 다른 SHAPE 구성요소와의 인터페이싱을 위한 사소한 상태 관련 개선을 제외하고 XBOX 360 XMA 디코더 블록과 동일합니다. XMA 디코더 레지스터 블록은 각 보이스에 대한 디코드된 출력과 관련된 상태 정보로 증강되었습니다. XMA 컨텍스트당 5비트가 PCM 출력 버퍼에서 소비되지 않은 채로 남아 있는 오디오 데이터의 양을 지정합니다. 이러한 레지스터는 XMA 디코더 블록 내부에 구현됩니다. 이를 통해 메인 메모리를 읽지 않고도 SRC용 컨텍스트를 잠글 만큼 충분한 샘플이 있는지 판단하는 데 항상 사용할 수 있습니다.xWMA는 SHAPE에서 지원되지 않지만
XAudio2를 사용하여 지원됩니다.PCM
Linear Pulse Code Modulation(PCM)은 48KHz에서 최대 7.1 서라운드 사운드를 지원합니다. 사용자의 사운드 시스템이 5.1 서라운드 사운드 또는 스테레오 등인 경우 ACP는 다운믹스합니다. S/PDIF 출력이 지원됩니다. 또한 16비트 모노 또는 스테레오 정수, 32비트 모노 float, 32비트 모노 정수(24비트 왼쪽 정렬 또는 하위 8비트가 마스크된 32비트)를 포함하는 선형 및 순환 PCM 버퍼도 지원됩니다.Sample Rate Convertor(SRC) 블록
SRC 블록은 정수 기반 샘플 레이트 변환을 수행하고 출력 데이터를 믹스 버퍼에 씁니다. SRC는 일반적으로 악기 에뮬레이션, 입력 샘플을 소스보다 한 옥타브 낮거나 높게 변환하는 데, 그리고 도플러 및 기타 효과에 사용됩니다. 시스템 메모리에서 SRC 블록은 32비트 부동 소수점 PCM 데이터 또는 16비트, 24비트, 32비트 고정 소수점 데이터를 읽습니다. 입력 데이터로는 XMA 하드웨어 디코더의 출력이나 소프트웨어에 의해 유지되는 데이터를 받을 수 있습니다. XMA 디코더와 밀접하게 통합되어 있으므로 SRC 블록은 XMA 디코드 버퍼에 있는 디코드된 PCM 데이터 샘플 수가 메인 메모리를 읽지 않고도 오디오 프레임의 샘플을 생성하고 완성하기에 충분한지 판단할 수 있습니다. SRC는 모노 또는 스테레오 모드로 작동합니다. PCM 데이터는 메모리에서 읽혀지고 샘플 레이트 변환을 위해 공통 24비트 고정 소수점 형식으로 변환됩니다. 출력은 모드에 따라 하나 또는 두 개의 믹스 버퍼에 기록됩니다. 스테레오 데이터는 16비트 데이터의 인터리브 스트림으로 메모리에 저장됩니다. 왼쪽 채널은 각 32비트 워드의 최하위 16비트에 있고, 오른쪽 채널은 최상위 16비트에 있습니다. 또한 스테레오 모드에서는 PCM 데이터가 읽혀지고 동시에 디인터리브됩니다. 왼쪽 채널 데이터(샘플 0,2,4,6…)가 처리되어 한 믹스 버퍼로 출력됩니다. 오른쪽 채널 데이터(샘플 1,3,5,7…)는 두 번째 믹스 버퍼에 기록됩니다. 그림 3은 샘플 레이트 변환 모드를 보여줍니다. 그림 3. 샘플 레이트 변환 모드. SRC 블록에 대한 입력은 384KHz에서 엡실론을 뺀 값을 초과하지 않는 어떤 샘플링 레이트에서도 가능합니다. 하지만 출력은 48KHz의 일정한 레이트가 됩니다. 엡실론은 요청된 정수 값과 하드웨어에서 사용되는 부동 소수점 값 사이의 작은 차이입니다. SHAPE는 오디오 프레임당 최대 512개의 SRC 채널(모노와 스테레오의 어떤 조합이든)을 처리할 수 있습니다. SRC는 선형 및 폴리페이즈 보간, 모노 및 스테레오, 그리고 1:16 또는 4옥타브 다운에서 3.99:1 또는 거의 2옥타브 업까지의 리샘플링 범위를 지원합니다.이퀄라이제이션 및 컴프레션
컴프레서는 입력 레벨을 모니터링하고 동적 게인 값을 만들어 신호의 동적 범위를 제한합니다. 그런 다음 컴프레서는 이 게인 값을 신호의 승수로 사용하여 현재 입력 신호 레벨에 따라 적절히 스케일링합니다. 즉, 컴프레서는 입력 신호를 지속적으로 모니터링하고 스스로 조정하는 자동 볼륨 컨트롤입니다. 컴프레서는 특정 임계값을 초과하는 신호에만 작동합니다. 임계값 이하의 신호는 변경 없이 통과합니다. 임계값은 EQComp 컨텍스트 데이터의 일부로 애플리케이션에 의해 설정됩니다. 컨텍스트의 프로그래머블 컨트롤은 컴프레션 또는 익스팬션을 수행하는 데 사용됩니다. 컴프레서는 들어오는 레벨과 나가는 레벨 사이의 비율을 지정하는 매개변수에 따라 사운드 데이터를 변경합니다. 이 비율은 들어오는 신호가 임계값을 초과할 경우 수행할 감쇠의 정도를 나타냅니다. 예:- 2:1에서 임계값보다 2dB 초과할 때마다 컴프레서는 임계값 위 1dB를 출력합니다.
- 1:1에서 컴프레서는 사실상 꺼진 상태입니다.
attack과 release 매개변수는 컴프레서가 얼마나 빨리 활성화되는지, 즉 임계값을 초과하는 사운드를 비율로 지정된 양만큼 완전히 감쇠시키는 데 얼마나 걸리는지를 지정합니다. Attack과 release는 밀리초로 지정되며, 임계값을 초과하거나 그 아래로 떨어지는 신호에 대응하여 컴프레서가 출력 게인을 얼마나 빠르게 변화시킬지에 해당합니다. 이러한 조정은 선형이거나 로그 기반일 수 있습니다.
다음 다이어그램(그림 5)은 입력이 attack으로 지정된 시간 동안 임계값을 초과하기 전까지는 원하는 출력 레벨이 달성되지 않는 방법을 보여줍니다. 이 다이어그램은 또한 release로 지정된 시간 동안 입력이 임계값 아래에 있을 때만 입력과 출력이 유니티로 돌아가는 방법을 보여줍니다.
그림 5. attack/release 타이밍.
그런 다음 입력은 현재 출력 게인에 곱해집니다. 그 첫 번째 곱셈이 실제 컴프레션을 수행합니다 - 즉, 입력 진폭에 따라 시간에 따라 변하는 함수로 신호를 스케일링합니다.
마지막 단계인 추가 게인 스케일링이 있습니다. 메이크업 게인 은 애플리케이션에 의해 설정되는 변경되지 않는 값입니다. 컴프레션, 특히 낮은 임계값에서 컴프레션은 상대적으로 낮은 게인의 신호를 초래할 수 있으므로, 메이크업 게인은 신호를 사용 가능한 범위로 되돌리는 데 사용됩니다.
컴프레서의 또 다른 매개변수는 RMS입니다. 노멀 모드에서 입력 레벨은 즉각적이며 모든 샘플에 대해 계산됩니다. RMS 모드에서는 이전 128 샘플에 대한 이동 평균(RMS 값의 근사)이 유지됩니다. 이동 평균은 현재 입력 샘플의 절대 레벨 대신 입력 레벨로 사용됩니다.
EQ/Compressor-Expander 블록은 직렬로 두 개의 별도 처리 유닛을 포함합니다: 3밴드 프로그래머블 이퀄라이저와 다이내믹 레인지 컴프레서(그림 6). 이 블록은 사운드의 주파수와 다이내믹 레인지를 제어하는 데 사용되며, 하나 또는 두 개의 믹스 버퍼에서 입력을 받습니다.
- 하나의 입력은 처리될 오디오 신호입니다.
- sidechain 이라고 하는 두 번째 입력은 오디오 컴프레션을 결정하는 데 사용되는 선택적 컨트롤 신호입니다.
- 노멀 모드(그림 7)에서는 믹스 버퍼로부터 단일 오디오 입력이 있습니다. 입력은 이퀄라이저를 통과한 후 컴프레서에 의해 처리되고 믹스 버퍼로 출력됩니다. 그림 7. 노멀 모드.
- 인터널 모드(그림 8)에서는 입력 신호가 컴프레서의 오디오 입력으로 직접 공급되고 분할되어 이퀄라이저로 전송됩니다. 이퀄라이저에서 컴프레서의 사이드체인 입력으로 전송됩니다. 그림 8. 인터널 모드.
- 익스터널 모드(그림 9)에서는 두 개의 별도 믹스 버퍼로부터 두 개의 별도 입력 신호가 사용됩니다. 입력 신호는 이퀄라이저와 컴프레션 블록의 오디오 입력을 통과합니다. 사이드체인 입력 신호는 컴프레서의 사이드체인 입력으로 직접 공급됩니다. 그림 9. 익스터널 모드.
필터/볼륨 블록(FLTVOL)
FLTVOL은 다음과 같은 용도로 사용됩니다:- 객체 주변을 우회하거나 통과하는 사운드의 폐색을 모델링
- 사운드가 도착하는 방향을 모델링하기 위해 여러 스피커로 사운드 에너지를 분배
f와 q 매개변수는 SHAPE 블록 외부의 소프트웨어에 의해 계산됩니다. 계수가 업데이트되면 한 오디오 프레임에 걸쳐 새 값으로 램프됩니다. 컨트롤 비트는 FLTVOL 블록의 최종 출력으로 사용할 출력(band reject, High-pass, Band-pass, Low-pass)을 결정하는 데 사용됩니다.
각 채널 또는 스트림에 대한 컨텍스트 데이터는 시스템 메모리에 저장됩니다. 성능은 2560개의 48KHz 동시 스트림으로 제한되지만(즉 SHAPE는 오디오 프레임당 최대 2560개의 FLTVOL 컨텍스트를 처리할 수 있음), 스트림 재사용의 시나리오를 단순화하기 위해 메모리에서 주소 지정 가능한 컨텍스트 수는 더 많습니다.
필터링 동작은 XAudio2와 동일하도록 설계되었습니다.
믹스 버퍼
믹스 버퍼는 세 가지 주요 목적을 가집니다.- 믹스 버퍼는 시스템(또는 개별 플레이어)의 각 스피커 출력에 대한 최종 믹싱 대상 역할을 합니다. 각 사운드가 처리되면 그에 이어지는 출력이 이 버퍼에 믹싱됩니다.
- 믹스 버퍼는 오디오 데이터의 버퍼가 하드웨어 블록 간에 전달될 때 임시 저장 위치 역할을 합니다.
- DMA 엔진과 함께 믹스 버퍼는 SHAPE 하드웨어 및 오디오 서브시스템에서 메인 시스템으로, 그리고 메인 시스템 메모리에서 SHAPE 하드웨어 및 오디오 서브시스템으로 데이터를 전달하는 메커니즘 역할을 합니다.
오버플로, 크기, 포화
타이틀 오디오 엔진에서 헤드룸 관리는 매우 어려울 수 있습니다. 이 때문에 각 SHAPE 블록은 신호 오버헤드 및 게인과 관련된 상태를 유지합니다. SRC를 제외한 각 블록은 처리 중 내부 포화가 발생했는지 여부를 나타내는 플래그를 유지합니다. 내부 포화 플래그 외에도, 각 하드웨어 블록은 하드웨어 블록의 출력 크기를 나타내는 두 개의 4비트 숫자도 유지합니다. 크기는 오디오 프레임 동안의 피크 출력을 결정하고 피크의 절대값의 리딩 제로를 계산하여 계산됩니다. 하나의 4비트 숫자는 지속적 피크 크기로 유지되고, 다른 하나는 매 오디오 프레임마다 하드웨어에 의해 리셋됩니다. 각 개별 하드웨어 블록의 피크 크기를 모니터링하는 것 외에도, 믹스 버퍼의 피크 크기도 유지됩니다. 하드웨어 블록의 출력이 믹스 버퍼에 추가될 때, 피크 크기는 같은 방식으로 - 리딩 제로를 계산하여 - 계산됩니다. 각 하드웨어 블록 상태는 추가적인 4비트 피크 크기 값 쌍을 유지합니다. 이 값들은 하드웨어 블록의 출력이 믹스 버퍼로 누적된 후 믹스 버퍼의 피크 크기를 나타냅니다. 하나의 4비트 숫자는 진행 중인 지속적 피크 크기를 나타냅니다. 다른 하나는 매 오디오 프레임마다 업데이트됩니다. 피크 크기 값은 표시되는 것이 믹스 버퍼 상태임에도 불구하고 SHAPE 블록의 컨텍스트에 저장됩니다. 피크 크기는 다음 표에 따라 인코딩됩니다(ShapeHardwareContexts.h 파일에 코딩됨).
오버헤드 관리를 돕고 오버플로 및 포화를 피하기 위해, 세밀한 게인 설정 외에도, 출력 믹스 버퍼로의 누적 전에 하드웨어 블록의 출력에 대해 0에서 7비트의 오른쪽 시프트가 수행될 수 있습니다. 이는 각 SHAPE 하드웨어 블록의 컨텍스트에 지정됩니다.
SHAPE 큐
SHAPE 오디오 프로세서는 시스템 하드웨어와 앱 하드웨어 인터록을 줄이는 데 도움이 되는 두 개의 큐를 관리합니다.- Command and Control Queue(CCQ)는 SHAPE 오디오 프로세서가 언제든지 - 일반적으로 현재 오디오 프레임의 처리를 완료할 때 - 실행할 명령 시리즈를 제공하는 데 사용됩니다. SHAPE 실행 목록은 매 오디오 프레임 출력마다 한 번 읽힙니다. 하지만 CCQ는 한 번만 읽히고 실행됩니다. CCQ는 CPU가 SHAPE 하드웨어와의 하드웨어 인터록을 요구하지 않고 오디오 프레임 경계에서 블록 컨텍스트 데이터를 업데이트할 수 있게 하는 메커니즘입니다. 이의 예로는 XMA 블록에 더 많은 비트 스트림 데이터 제공, 다양한 블록에 대한 컨텍스트 매개변수 업데이트, 새 실행 목록 가리키기 등이 있습니다. 이는 일반적으로 오디오 처리 플로우그래프가 변경될 때 수행됩니다.
- Status and Reporting Queue(SRQ)는 SHAPE 오디오 프로세서에 의해 실시간 응답이 필요하지 않은 다양한 이벤트를 CPU에 보고하는 데 사용됩니다. 예로는 비트 스트림 버퍼 소비 업데이트, 오류, 경고 및 플래그, 디버그 데이터, 성능 데이터, 상태 정보 등이 있습니다.
프로그래밍 고려사항
SHAPE 하드웨어에 직접 프로그래밍하는 것은IACPHAL 인터페이스를 통해 활성화됩니다. 하지만 SHAPE 하드웨어를 위한 오디오 데이터 준비 과정은 복잡합니다. 많은 유틸리티 메서드, 구조, 열거형이 제공됩니다. 이러한 유틸리티는 SHAPE 하드웨어를 제어하는 데 필요한 모든 또는 대부분의 메서드를 제공합니다. Microsoft Game Development Kit(GDK)는 특정 종류의 데이터를 처리하기 위해 코드를 수정해야 하는 드문 경우를 위해 이러한 유틸리티에 대한 소스 코드를 포함합니다.
프로젝트에 명시적으로 포함시켜야 하는 유일한 헤더 파일은 모든 유틸리티 헤더 파일을 참조하는 acphal.h 입니다. 모든 유틸리티 함수는 NO_SHAPE_CONTEXT_VALIDATION 매크로를 참조합니다. 이 매크로가 정의되면 모든 검증이 생략됩니다. 이는 최종 리테일 빌드에 유용합니다.
XAudio2 인스턴스와 SHAPE 및 XMA 리소스 공유에 대한 자세한 내용은 XAudio2Create 함수의 Remarks 섹션을 참고하십시오.
모든 유틸리티 메서드에 대한 자세한 내용은 ACP 개요를 참고하십시오.
영구적 및 비영구적 플로우그래프
플로우그래프를 영구적 또는 비영구적으로 처리되도록 제출할 수 있습니다. 영구적 플로우그래프는 처리되고 상주 상태로 남아 있어 읽기 및 쓰기 포인터가 진행되고 다른 컨텍스트 정보가 업데이트된 후 다음 프레임에서 처리를 반복합니다. 다음 시나리오 중 하나에 대해 영구적 플로우그래프를 사용하십시오.- 각 프레임을 재조립하는 데 상당한 양의 CPU 처리가 필요한 매우 복잡한 플로우그래프
- 오랜 기간 동안 동일한 보이스 수와 구성을 가진 매우 정적인 플로우그래프
- 보이스 토폴로지가 자주 변경됩니다.
- 타이틀의 오디오 소프트웨어 엔진의 처리 케이던스가 SHAPE 하드웨어에서 분리되어 있습니다. 즉, 2.667MS의 배수가 아닙니다.
- 실시간보다 빠르게 오디오 처리를 실행하려고 합니다. 가능해질 때마다 소비되도록 그래프를 제출하는 경우입니다.
이슈 디버깅
플로우그래프를 개발할 때 메시지에 등록하면 발생할 수 있는 모든 이슈를 디버그하는 데 도움이 됩니다. 특히 Connect의NumMessages 매개변수를 사용하십시오. 메시징 시스템은 잘못된 플로우그래프(ACP_FLOWGRAPH_TERMINATED_REASON_INVALID_GRAPH), 차단된 명령, 하드웨어 프레임 크기인 2.667MS가 허용하는 것보다 더 많은 처리를 수행하려 할 때 발생하는 프레임 아웃과 같은 다양한 문제에 대한 풍부한 피드백을 제공합니다. 타이틀을 출시하기 전에 각 제출된 플로우그래프에 대해 ACP_MESSAGE_TYPE_FLOWGRAPH_COMPLETED 메시지를 관찰하여 플로우그래프 처리가 일관되게 성공하는지 확인하십시오.
놓친 메시지
ACP 메시지를 사용하여 엔진 상태를 구동하는 경우, 그리고 많은 메시지를 처리하는 경우, 개발 중에 ACP_MESSAGE의droppedMessageCount 필드를 검사해야 합니다. 이 필드의 값이 0이 아니면 메시지 큐가 가득 차서 메시지를 버려야 했음을 나타냅니다. 이 시나리오에서는 큐를 더 빠르게 서비스하고 더 크게 만드는 것을 고려하십시오.
프레임 아웃
너무 많은 플로우그래프 처리 또는 잘못 구조화된 플로우그래프 처리와 같이 오디오 프레임 종료(2.667MS) 전에 플로우그래프가 완료되지 않을 수 있는 이유는 여러 가지입니다. 이 미완성 플로우그래프는 영구적 플로우그래프에 대해ACP_FLOWGRAPH_TERMINATED_TIME_EXCEEDED 메시지를 발생시키며, 이러한 영구적 플로우그래프는 미완성 상태가 됩니다. 반면, 비영구적 플로우그래프는 이러한 방식으로 제약되지 않으며 프레임을 넘나들며 완료될 때까지 실행됩니다.
차단된 명령
SRC 및 DMA 명령은 다음 표에 나타난 여러 시나리오에서 차단됨(ACP_MESSAGE_TYPE_SRC_BLOCKED, ACP_MESSAGE_TYPE_DMA_BLOCKED)으로 보고될 수 있습니다.
| 명령 유형| 차단 시나리오|
| --- | --- | --- | --- |
| XMA SRC| 관련 XMA 컨텍스트에 파서 오류가 있거나 소스 데이터가 없습니다. 오류는 SHAPE_XMA_ERROR_STATUS_READ_BUFFER_INVALID_VALIDBUFFER_CURRBUF_IS_0 | SHAPE_XMA_ERROR_STATUS_FRAME_CROSSES_BOUNDARY_INTO_INVALID_READ_BUFFER_VALIDBUFFER_CURRBUF_IS_0 | SHAPE_XMA_ERROR_STATUS_FRAME_CROSSES_BOTH_READ_BUFFER_BOUNDARIES입니다. XMA SRC는 디코드된 데이터 부족으로 인해 차단되지 않습니다.|
| PCM SRC| 관련 PCM 컨텍스트가 SHAPE_PCM_MODE_CIRCULAR이고 소스 데이터가 없습니다.|
| 읽기(믹스 버퍼에서 DMA)| DMA 버퍼가 가득 찼습니다.|
| 쓰기(믹스 버퍼로 DMA)| DMA 버퍼가 비어 있습니다.|
명령이 차단된 것으로 결정된 후(항목이 처리를 위해 SHAPE 큐에 추가되기 전과 런타임에 모두 발생함), 명령은 그래프에서 제거되며, 이는 오디오 드롭으로 이어질 수 있습니다. 개발 중에는 플로우그래프 처리 개선을 찾을 첫 번째 지점으로 차단된 명령을 사용하십시오. 또한 출시 전에 여러분 타이틀이 명령 차단을 완전히 방지하도록 하십시오.
오디오 버퍼가 충분히 크고 버퍼 크기와 관련된 정기적 간격으로 데이터가 스트리밍되도록 하여 DMA 명령의 차단을 방지할 수 있습니다. 예를 들어 한 번에 4개의 하드웨어 프레임을 스트리밍하는 경우, 하드웨어가 타이틀의 읽기 포인터보다 앞서 쓸 수 있도록 해당 프레임의 배수(적어도 8에서 더블 버퍼링됨)가 버퍼에 있는지 확인하십시오. 대신, 다음 플로우그래프를 제출하기 전에 버퍼를 비우도록 강제할 수 있습니다: 소비하고, DMA 읽기 포인터를 업데이트한 다음, 플로우그래프를 제출하십시오.
SRC 명령에는 세 가지 모드가 있습니다.
SHAPE_SRC_COMMAND_TYPE_START는 플로우그래프의 거의 모든 SRC 명령에 사용됩니다. 정상적인 처리를 수행하고 현재 플로우그래프에 이어 더 많은 오디오 데이터가 있을 것으로 예상하십시오.SHAPE_SRC_COMMAND_TYPE_STOP_IMMEDIATE는 소스 XMA 또는 PCM 데이터 처리를 즉시 중지하는 데 사용됩니다. SRC는 이 프레임에 대해 0으로 채워진 버퍼를 출력합니다.SHAPE_SRC_COMMAND_TYPE_STOP_END는 보이스의 마지막 패킷을 나타내는 데 사용됩니다.
STOP_END 또는 STOP_IMMEDIATE로 제출되지 않으면 SRC 명령이 완료되지 않아 활성 플로우그래프가 stall됩니다. 영구적 플로우그래프는 오디오 프레임 끝에서 종료되고, 비영구적 플로우그래프는 절대 완료되지 않습니다.
동기화 문제
컨텍스트 및 명령에 대한 SHAPE 하드웨어의 소비 관행을 준수하지 않으면 동기화 문제가 발생할 수 있습니다. 여러분 타이틀이 ACP가 할당한 메모리에 대한 전체 액세스를 유지하지만, 사용 중인 컨텍스트 구조를 수정하지 않도록 주의하십시오. SubmitCommand를 사용하여 특정 프레임에서, 다음 프레임의 시작에서, 또는 가능한 한 즉시 발생할 명령을 제출할 수 있습니다.”가능한 한 즉시” 시나리오는 여전히 타이틀 CPU 처리로부터 비동기적입니다. 컨텍스트가 중단 불가능한 작업의 중간에 있는 경우와 같이 일부 명령은 즉시 완료되지 않을 수 있습니다. 명령이 실제로 처리되었는지 확인하려면
ACP_MESSAGE_TYPE_COMMAND_COMPLETED를 기다리십시오.