다음은 Stream Manager 기본 구현의 초기화 설정에 대한 설명입니다. I/O와 메모리 리소스를 최대한 활용하기 위해 어느 시점에서는 자신의 게임에 맞는 설정으로 변경해야할 것입니다.

Stream Manager 설정

AkStreamMgrSettings 구조체는 전체 Stream Manager에 적용할 설정을 정의합니다. 각 세부 항목에 나와 있는 기본 값은 AK::StreamMgr::GetDefaultSettings() 에 의해 반환된 값입니다. 사용자의 시스템에는 이 기본 값이 적합하지 않을 수 있습니다. I/O 도움말, 문제 해결 및 최적화 에 나온 정보를 참고하면 최적값을 선택하는 데 도움이 될 것입니다.

스트리밍 장치 설정

AkDeviceSettings 구조체는 각 장치에 필요한 설정을 정의하며, AK::CreateDevice() 로 생성됩니다. 각 세부 항목에 나와 있는 기본 값은 AK::StreamMgr::GetDefaultDeviceSettings() 에 의해 반환된 값입니다. 사용자의 시스템에는 이 기본 값이 적합하지 않을 수 있습니다.

I/O 메모리 크기

AkDeviceSettings::uIOMemorySize 는 장치의 자동 스트리밍에 예약된 메모리의 전체 크기입니다. 이 장치는 자동 스트림 I/O 데이터가 작성되는 특수 메모리 풀을 생성합니다. 자동 스트림을 사용하지 않는 경우, 0으로 지정하세요. 그러나 사운드 엔진은 스트리밍된 오디오 파일을 재생할 때 자동 스트림을 사용한다는 점에 유의하세요. AkDeviceSettings::pIOMemory 와 AkDeviceSettings::uIOMemoryAlignment, AkDeviceSettings::ePoolAttributes 는 풀 생성 메소드, 즉 AK::MemoryMgr::CreatePool() 로 직접 전달되는 추가 매개 변수입니다.

기본값:

• AkDeviceSettings::pIOMemory: NULL (메모리 풀이 장치별로 할당됨)
• AkDeviceSettings::uIOMemorySize: 2 MB
• AkDeviceSettings::uIOMemoryAlignment: 4 (Windows 플랫폼 전용)
• AkDeviceSettings::ePoolAttributes: AkMalloc (Windows 플랫폼 전용)

세분성

세분성은 AkDeviceSettings::uGranularity 로 지정됩니다. 이는 Low-Level I/O로 전송된 표준 요청 크기가 표준 스트림(조각 작업)에서 전송되는지 자동 스트림(단일 스트림 버퍼 크기)에서 전송되는지를 정의합니다. 자동 스트림은 사용 가능한 메모리에 따라 버퍼 개수 변수를 사용합니다. 자동 스트리밍에 사용할 수 있는 버퍼의 총 개수는 다음과 같습니다.
AkDeviceSettings::uIOMemorySize / AkDeviceSettings::uGranularity.

작은 정보: 메모리 고갈을 방지하려면 스트림이 최소한 이중 버퍼여야 합니다. 따라서 I/O 메모리 크기는 최소한 다음으로 설정돼야 합니다. 2 * uGranularity * nominal_number_of_streams 스트림별로 필요한 버퍼의 실제 개수는 동적이며, 스트림 휴리스틱과 장치의 대상 버퍼 길이에 따라 다릅니다 (AkDeviceSettings::fTargetAutoStmBufferLength 참고). 자신에게 맞는 I/O 메모리 크기를 결정하는 올바른 방법은 최악의 상황에서 모든 스트림에 필요한 총량을 계산해 fTargetAutoStmBufferLength로 곱하는 것입니다. 실제로 큰 값에서 시작한 다음 Wwise 프로파일러로 자신의 게임을 프로파일링한 후 Streaming Devices 탭에서 I/O 사용량으로 보고되는 최고값을 사용하는 것이 쉽습니다.

기본값: 16 KB

I/O 스레드 속성

모든 상위 레벨 장치는 'AK::IOThread'를 호출한 Low-Level I/O 로 전송 요청을 게시할 때 별도 스레드를 사용합니다. AkDeviceSettings::threadProperties 를 이용해 이 스레드의 속성을 지정할 수 있습니다. AkThreadProperties 는 SDK/include/AK/Tools/{Platform name}/AkPlatformFuncs.h에서 각 플랫폼에 대해 정의됩니다. 이 메소드는 일반적으로 스레드 우선 순위와 프로세서를 지정합니다.

작은 정보: I/O 스케줄러 스레드는 CPU를 많이 사용하지 않기 때문에 평균 이상의 우선 순위를 가져야 합니다. I/O 스케줄러 스레드는 대부분의 경우 스트림 작동을 기다리거나 디스크 제어 장치를 기다립니다. 그러나 작업을 선택해 이를 Low-Level I/O로 발송할 때는, 저장 장치 처리량을 최대화하기 위해 가능한 빠르게 처리해야 합니다.

기본값: 기본 플랫폼별 스레드 속성 (AKPLATFORM::AkGetDefaultThreadProperties()에 의해 반환)으로, AK_THREAD_PRIORITY_ABOVE_NORMAL (AkPlatformFuncs.h에서 정의)과 동일한 우선 순위.

대상 버퍼링 길이

AkDeviceSettings::fTargetAutoStmBufferLength 는 장치의 I/O 스케줄러를 위한 휴리스틱입니다. 이는 자동 스트림에만 적용됩니다. 스트림별 가장 적합한 버퍼링 시간을 밀리세컨드 단위로 지정합니다. Stream Manager는 버퍼링 길이에 도달할 때까지 주어진 스트림에 대해 I/O를 실행합니다. 시간 값은 스트림의 처리량 휴리스틱을 사용해 버퍼 크기로 해석됩니다. 예를 들어, 44.1 kHz로 샘플링된 16 비트 스테레오 사운드는 172.3 KB/s의 처리량을 필요로 합니다. 만약 대상 버퍼 길이가 380 ms로 설정된 경우, 이 스트림의 대상 버퍼 크기는 약 64 KB가 됩니다. 버퍼링이 많을수록 스트림은 자원이 고갈될 확률이 낮아집니다. 반면 I/O 스케줄러의 처리량은 더 많아지고 CPU를 더 많이 사용하게 되며, 스트리밍 I/O 풀에서 더 많은 메모리를 사용합니다. 최적의 값은 하위-레벨 저장 장치 대역폭과 스트리밍이 사용할 수 있는 메모리 양에 의해 좌우됩니다. 빠른 장치는 적은 버퍼링 길이를 사용하며, 반대로 느린 장치나 처리량의 표준 편차가 큰 장치는 (탐색 등의 이유로) 큰 값을 사용합니다. 모든 자동 스트림이 대상 버퍼링 길이에 도달한 경우, 그리고 지연 표준 스트리밍 작업이 없는 경우, I/O 스케줄러는 idle 상태가 됩니다.

작은 정보: 최적의 대상 버퍼링 길이는 자신의 하위 레벨 장치가 데이터를 보내는 시간에 비례합니다. 적절한 사용 환경에서 충분한 I/O 메모리 크기로 Wwise Profiler에서 음원 고갈 알림이 뜨지 않을 때까지 최대한 낮은 값을 지정하도록 해보세요. 이 작업을 거치면 I/O 메모리 크기를 최대 사용 값까지 줄일 수 있습니다.

기본값: 380 ms.

동시 I/O 전송 최대 개수

AkDeviceSettings::uMaxConcurrentIO concerns asynchronous low-level devices only. 어떤 시점이든 스트리밍 장치가 하위 레벨 I/O로 동시에 게시할 수 있는 하위 레벨 I/O 전송의 최대 개수입니다. 한계에 도달하면, 대상 이하로 버퍼링 되는 스트림이 있다 하더라도 I/O 스레드가 하위 레벨 I/O로 발송하던 요청을 중단하게 됩니다. 이 값을 이용해 지연된 전송을 추적해야 하는 구조체의 정적 배열을 안전하게 할당할 수 있습니다.

작은 정보: If you specify 1, you get the same behavior as with a synchronous device, with asynchronous handshaking instead. 이는 자신의 I/O 관리자가 비동기 API만을 나타낼 경우 유용합니다. 이 매개 변수에 큰 값을 사용하고 싶겠지만, 여기에는 단점이 있습니다. 스트리밍 장치의 스케줄러는 요청들을 검사할 때 각 스트리밍의 상태에 따라 하위 레벨 요청을 발송합니다. 많은 요청을 전송하게 두고 하위 레벨 I/O에 오랫동안 남겨두면, 그 사이 상황이 바뀔 가능성이 많습니다. 예를 들어 스트리밍 사운드가 멈추거나 반복 재생을 중단할 수 있습니다. 이런 경우, 이들 전송은 취소되며 I/O 데이터가 받는 순간 지워집니다. 이는 대역폭을 크게 낭비할 수 있습니다. 많은 양의 동시 요청은, 요청의 양과 상관 없는 처리량을 지닌 장치에만 사용돼야 합니다. 예를 들어 일부 DMA 제어기는 많은 전송을 처리하도록 프로그래밍될 수 있지만, 전송을 완료한 순간은 프로그래밍 된 전송량과 거의 상관이 없습니다.

Default: 8.

스트림 캐시 사용하기

AkDeviceSettings::bUseStreamCache 는 데이터 캐싱을 활성화할지 안 할지를 결정합니다.

스트리밍 장치는 스트리밍 풀로의 데이터 캐싱을 지원합니다. 메모리 블록에 대해 I/O 작업이 실행될 때 파일 메타데이터가 연결됩니다. 동일한 스트림이나 동일한 스트림의 다른 인스턴스가 같은 파일에 해당되는 데이터 블록을 거의 같은 위치에 필요로 하는 경우, 이 데이터 블록은 직접 사용되어 하위 레벨 I/O로부터의 전송을 피하게 됩니다.

중요한 데이터 구조체는 장치가 생성될 때 사전에 할당된다는 점을 기억하세요 (Stream Manager 메모리 풀로부터 할당됨). 런타임에 메모리가 고갈되면 I/O 스레드가 아무 것도 없이 높은 우선 순위로 돌아가기 때문에 게임 성능에 치명적인 영향을 미칠 수 있습니다.

스트림 데이터 캐싱을 이용하면 주어진 메모리 블록에 대해 하나 이상의 레퍼런스가 있을 수 있습니다. 메모리 블록의 레퍼런스는 사전에 할당된 중요한 데이터 구조체 중 하나의 예제입니다.

AK::SoundEngine::PinEventInStreamCache() 를 호출하면 특정 이벤트의 미디어를 스트림 캐시에 고정해놓도록 요청할 수 있어, 필요할 때 지연 없이 바로 재생할 수 있습니다. AK::SoundEngine::PinEventInStreamCache() 가 호출될 때 데이터가 이미 캐시에 있지 않은 경우, 해당 데이터는 자동 스트림에서 낮은 우선 순위로 스트림 됩니다. 고정된 각 미디어 파일의 밀리세컨드 길이는 Wwise 저작 툴에서 프리패치 슬라이더를 이용해 커스터마이징할 수 있습니다. 데이터는 사용자가 AK::SoundEngine::UnpinEventInStreamCache() 를 호출해 미디어를 해제할 때까지 메모리에 유지됩니다.

AkDeviceSettings::bUseStreamCache 는 이미 디스크에서 스트림된 IO 버퍼를 장치가 재사용할 지 여부를 지정합니다. 이는 간단한 반복 재생 사운드를 스트리밍할 때 매우 유용합니다. 단점이 있다면, 메모리를 할당할 때 CPU에 작은 타격을 입는다는 점과 StreamManager 풀에서 메모리 사용 공간을 다소 차지한다는 점입니다.

기본값: false (캐시 비활성화).