Wwise SDK 2023.1.8
|
Default Streaming Manager Information ストリームマネージャの初期化設定と AK::StreamMgr::Create() メソッドは、Audiokineticの実装に固有のもので、AK::StreamMgr::Create() で定義されています。 |
以下は、ストリームマネージャデフォルト実装の初期化設定に関する説明です。 実際のゲーム制作時には、I/Oとメモリリソースを最大限に活用するために、これらの設定を必要に応じて微調整する必要があります。
AkStreamMgrSettings 構造体は、ストリームマネージャ全体に必要な設定を定義します。各サブセクションに示されているデフォルト値は、AK::StreamMgr::GetDefaultSettings() により返される値です。これらのデフォルト値は、ご使用のシステムに適切でないかもしれません。最適値を選ぶ際には、I/Oのヒント、トラブルシューティングと最適化 に記載されている情報が有益です。
AkDeviceSettings 構造体は、AK::CreateDevice() で作成される各ドライブに必要な設定を定義します。各サブセクションに示されているデフォルト値は AK::StreamMgr::GetDefaultDeviceSettings() に返される値です。これらのデフォルト値は、ご使用のシステムに適切でないかもしれません。
AkDeviceSettings::uIOMemorySize は、デバイスの自動ストリーミング用に予約されているメモリの合計サイズです。デバイスは、自動ストリームI/Oデータが書き込まれる特別なメモリプールを作成します。自動ストリームを使用する予定がない場合は、ゼロを指定してください。ただし、サウンドエンジンは、ストリーミングされたオーディオファイルの再生に自動ストリームを使用することにご注意ください。 AkDeviceSettings::pIOMemory 、AkDeviceSettings::uIOMemoryAlignment と AkDeviceSettings::ePoolAttributes は、プール作成メソッド AK::MemoryMgr::CreatePool() に直接渡される追加のパラメータです。
デフォルト:
粒度(Granularity)は、AkDeviceSettings::uGranularity によって指定されます。これは、標準ストリーム(スライス操作)または自動ストリーム(単一のストリームバッファサイズ)のいずれから送信されるかにかかわらず、低レベル I/O に送信される標準的な要求サイズを定義します。自動ストリームは、利用可能なメモリに応じてバッファ変数番号を使用します。自動ストリーミングで利用可能なバッファ総数は、以下と等しくなります:
AkDeviceSettings::uIOMemorySize / AkDeviceSettings::uGranularity。
Tip: メモリ不足による枯渇を避けるためには、ストリームは少なくともダブルバッファでなければなりません。従って、I/O メモリサイズ設定は少なくとも次のようにする必要があります: ストリームごとに必要な実際のバッファ数は動的であり、ストリームのヒューリスティックとデバイスのターゲットバッファ長に依存することに注意してください (AkDeviceSettings::fTargetAutoStmBufferLengthを参照)。ニーズに合わせて必要とされる I/O メモリサイズを決定する適切な方法は、最悪の場合に全ストリームが必要とするスループットの合計を計算し、これを fTargetAutoStmBufferLength で掛けることです。実際には、大きな値からはじめ、Wwise プロファイラでゲームをプロファイルし、Streaming Devices タブで I/O 使用のために報告されたピーク値を使用するほうが簡単です。 |
デフォルト:16 KB
すべての高レベルデバイスは、独立したスレッドを使用して、"AK::IOThread" と呼ばれる低レベル I/O への転送要求を送出します。AkDeviceSettings::threadProperties を使用して、このスレッドのプロパティを指定することができます。AkThreadProperties は、各プラットフォーム向けに SDK/include/AK/Tools/{Platform name}/AkPlatformFuncs.h で定義されます。通常、このメソッドはスレッド優先順位とプロセッサを指定します。
Tip: I/O スケジューラスレッドは CPU を多く使用しないので、優先度を標準より高くするべきです:これは、ストリームのサービスやディスクコントローラを待機している状態にあることがほとんどです。しかし、タスクを選択して低レベル I/O に送出する必要がある時にはこれを迅速に実行できるので、ストレージデバイスのスループットを最大限に高めることができます。 |
デフォルト:(AKPLATFORM::AkGetDefaultThreadProperties() によって返されるような)デフォルトプラットフォーム固有のスレッドプロパティ、(AkPlatformFuncs.h で定義される)AK_THREAD_PRIORITY_ABOVE_NORMAL に等しい優先度を持つ。
AkDeviceSettings::fTargetAutoStmBufferLength は、デバイスの I/O スケジューラのためのヒューリスティックです。これは、自動ストリームにのみ適用されます。到達されるべき理想的なバッファリング時間を、ストリームごとにミリ秒単位で指定します。ストリームマネージャは、このバッファ長が満たされるまで、該当ストリームの I/O を実行します。時間値は、ストリームのスループットヒューリスティックを使用してバッファサイズに変換されます。例えば、44.1 kHz でサンプリングした16ビットのステレオサウンドは、172.3 KB/s のスループットを必要とします。ターゲットバッファ長が380ミリ秒に設定されている場合、このストリームのターゲットバッファサイズは約64 Kb になります。より多くのバッファリングを使用すると、ストリーミングが枯渇する可能性も低くなります。一方、I/O スケジューラはビジー状態になりやすく、より多くのCPU、より多量のストリーミング I/O プール内メモリを使用します。最適値は、主に低レベルストレージデバイスの帯域幅とストリーミングに利用可能なメモリ量に依存します。高速デバイスはより小さいバッファ長を使用する必要があるのに対して、低速デバイスや、例えば、シークのためなどにスループットが大きな標準偏差を持つデバイスは、より大きな値を使用する必要があります。すべての自動ストリームがターゲットバッファ長に到達し、保留中の標準ストリーミング操作がない場合、I/O スケジューラはアイドル状態になります。
Tip: 理想的なターゲットバッファ長は、低レベルデバイスのデータ転送時間に比例します。ソース枯渇通知を Wwise プロファイラに表示させずに、可能な限り低い値を、合理的な条件下のもとで十分に大容量の I/O メモリサイズにて指定するようにしてください。これが完了すると、I/O メモリサイズを使用ピーク値に減らすことができます。 |
デフォルト:380 ms.(ミリ秒)
AkDeviceSettings::uMaxConcurrentIO concerns asynchronous low-level devices only. これは、ストリーミングデバイスが、任意の時点で例レベル I/O に同時送出できる低レベル I/O転送の最大量です。I/O スレッドはリミットに達すると、ターゲット以下でバッファリングされたストリームがある場合でも、低レベル I/O へのリクエスト送出を停止します。この値を使用して、保留中の転送を追跡するために必要な構造体のスタティック配列を安全に割り当てることができます。
Tip: 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 からの転送を避けることができます。
デバイスが作成される時に重要なデータ構造が(ストリームマネージャのメモリプールから)事前に割り当てられることを知っておく必要があります。これは、ランタイム時におけるメモリ不足により、I/O スレッドが優先度の高いスレッドをスピンせず、ゲームのパフォーマンスに悲惨な結果がもたらされる可能性があるためです。
ストリームデータキャッシュを使用すると、メモリブロック1つに対して複数のリファレンスが存在する可能性があります。メモリブロックへのリファレンスは、事前割り当てされた重要なデータ構造の一例です。
AK::SoundEngine::PinEventInStreamCache()
をコールすることで、ユーザーは、特定のイベントのメディアをストリームキャッシュ内に "ピン付け" するように要請でき、そうするとイベントの準備が整い、必要なときにゼロレイテンシで再生できます。 AK::SoundEngine::PinEventInStreamCache()
がコールされた際に、データがまだキャッシュになければ、データが低プライオリティの自動ストリームを通してストリームされます。ピン固定する各メディアの長さは、Wwiseオーサリングツール上のプリフェッチスライダーを使用してミリ秒単位でカスタマイズ可能です。データはメモリ上に残り、ユーザーが AK::SoundEngine::UnpinEventInStreamCache()
をコールしてメディアをリリースするまで、残ります。
AkDeviceSettings::bUseStreamCache は、デバイスが、既にディスクからストリーミングされたIOバッファの再利用を試みるべきかどうかを、指定します。小さなループサウンドをストリーミングするときなどに、特に便利です。欠点はメモリのアロケーション時にCPUが多少、消費されることと、StreamManagerプールでやや大きいメモリフットプリントが生じることです。
デフォルト: false(キャッシュ無効)。