バージョン

    その他のドキュメント

menu_open
Wwise SDK 2018.1.11
Audiokinetic ストリームマネージャ初期化設定

Default Streaming Manager Information

この章は、高レベルストリームマネージャのAPIのデフォルト実装に特化したものです。

ストリームマネージャの初期化設定と AK::StreamMgr::Create() メソッドは、Audiokineticの実装に固有のもので、AK::StreamMgr::Create() で定義されています。

以下は、ストリームマネージャデフォルト実装の初期化設定に関する説明です。 実際のゲーム制作時には、I/Oとメモリリソースを最大限に活用するために、これらの設定を必要に応じて微調整する必要があります。

ストリームマネージャ設定

AkStreamMgrSettings 構造体は、ストリームマネージャ全体に必要な設定を定義します。各サブセクションに示されているデフォルト値は、AK::StreamMgr::GetDefaultSettings() により返される値です。これらのデフォルト値は、ご使用のシステムに適切でないかもしれません。最適値を選ぶ際には、I/Oのヒント、トラブルシューティングと最適化 に記載されている情報が有益です。

メモリサイズ

AkStreamMgrSettings::uMemorySize は、ストリームマネージャが、それ自体とその小オブジェクトのために作成するメモリプールのサイズを指定します:小オブジェクトは、ストリーミングデバイス、ストリームオブジェクト、保留中の転送オブジェクト、ストリームバッファへの参照、プロファイラストリーム名、延期されたファイルオープンコマンドなどのことです。つまり、各ストリーミングデバイスごとに(AkDeviceSettings::uIOMemorySize により指定される)固有のプールを持つ自動ストリーム用の I/O メモリを除くすべてです。メモリサイズは、再生することができるストリーム数を制限しないよう、可能な限り最小の値である必要があります。Wwise の Advanced Profiler ビューの Memory タブを使用して、(Stream Manager プール内の)小ストリーミングオブジェクトのメモリ使用状況を評価することができます。

このプールから要求されるメモリのほとんどは、ストリーミングデバイスが作成される時に割り当てられます。基本的に実行時の割り当ては、ストリームオブジェクト自体、それらのプロファイル名(デバックおよびプロファイル構成のみ)、そして該当する場合は、延期されたファイルオープンを処理するのに必要な一時的構造(streamingmanager_lowlevel_location_deferred_open 参照)で構成されています。

デフォルト:64 KB

ストリーミングデバイス設定

AkDeviceSettings 構造体は、AK::CreateDevice() で作成される各ドライブに必要な設定を定義します。各サブセクションに示されているデフォルト値は AK::StreamMgr::GetDefaultDeviceSettings() に返される値です。これらのデフォルト値は、ご使用のシステムに適切でないかもしれません。

I/Oメモリサイズ

AkDeviceSettings::uIOMemorySize は、デバイスの自動ストリーミング用に予約されているメモリの合計サイズです。デバイスは、自動ストリームI/Oデータが書き込まれる特別なメモリプールを作成します。自動ストリームを使用する予定がない場合は、ゼロを指定してください。ただし、サウンドエンジンは、ストリーミングされたオーディオファイルの再生に自動ストリームを使用することにご注意ください。AkDeviceSettings::pIOMemory、AkDeviceSettings::uIOMemoryAlignment と AkDeviceSettings::ePoolAttributes は、プール作成メソッド AK::MemoryMgr::CreatePool() に直接渡される追加のパラメータです。

デフォルト:

  • AkDeviceSettings::pIOMemory:NULL (メモリプールはデバイスによって割り当てられる)
  • AkDeviceSettings::uIOMemorySize:2 MB
  • AkDeviceSettings::uIOMemoryAlignment:4 (Windowsプラットフォーム固有)
  • AkDeviceSettings::ePoolAttributes:AkMalloc (Windowsプラットフォーム固有)

粒度

粒度(Granularity)は、AkDeviceSettings::uGranularity によって指定されます。これは、標準ストリーム(スライス操作)または自動ストリーム(単一のストリームバッファサイズ)のいずれから送信されるかにかかわらず、低レベル I/O に送信される標準的な要求サイズを定義します。自動ストリームは、利用可能なメモリに応じてバッファ変数番号を使用します。自動ストリーミングで利用可能なバッファ総数は、以下と等しくなります:
AkDeviceSettings::uIOMemorySize / AkDeviceSettings::uGranularity。

Tip: メモリ不足による枯渇を避けるためには、ストリームは少なくともダブルバッファでなければなりません。従って、I/O メモリサイズ設定は少なくとも次のようにする必要があります:
2 * uGranularity * nominal_number_of_streams
ストリームごとに必要な実際のバッファ数は動的であり、ストリームのヒューリスティックとデバイスのターゲットバッファ長に依存することに注意してください (AkDeviceSettings::fTargetAutoStmBufferLengthを参照)。ニーズに合わせて必要とされる I/O メモリサイズを決定する適切な方法は、最悪の場合に全ストリームが必要とするスループットの合計を計算し、これを fTargetAutoStmBufferLength で掛けることです。実際には、大きな値からはじめ、Wwise プロファイラでゲームをプロファイルし、Streaming Devices タブで I/O 使用のために報告されたピーク値を使用するほうが簡単です。

デフォルト:16 KB

スケジューラタイプ

ストリーミングデバイススケジューラのタイプは、AkDeviceSettings::uSchedulerTypeFlags に依存します。これは、低レベル I/O でハンドシェークモードを決定します。AK_SCHEDULER_BLOCKING フラグで作成されたストリーミングデバイスは、同期ハンドシェークを使用して AK::StreamMgr::IAkIOHookBlocking で動作します。AK_SCHEDULER_DEFERRED_LINED_UP フラグで作成されたストリーミングデバイスは、非同期ハンドシェークを使用して AK::StreamMgr::IAkIOHookDeferred で動作します。高レベルスケジューラに関する議論は、高レベルデバイスの特異性 を参照してください。

Caution: AK_SCHEDULER_BLOCKING デバイスで遅延 I/O フックを使用、またその逆は、ランタイムクラッシュを引き起こします。

デフォルト:AK_SCHEDULER_BLOCKING

I/O スレッドのプロパティ

すべての高レベルデバイスは、独立したスレッドを使用して、"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.(ミリ秒)

同時 I/O 転送の最大値

AkDeviceSettings::uMaxConcurrentIO は、非同期の低レベルデバイスのみに関与するものです(AK_SCHEDULER_DEFERRED_LINED_UP スケジューラフラグ)。これは、ストリーミングデバイスが、任意の時点で例レベル I/O に同時送出できる低レベル I/O転送の最大量です。I/O スレッドはリミットに達すると、ターゲット以下でバッファリングされたストリームがある場合でも、低レベル I/O へのリクエスト送出を停止します。この値を使用して、保留中の転送を追跡するために必要な構造体のスタティック配列を安全に割り当てることができます。

Tip: 1 を指定した場合は、同期デバイス(AK_SCHEDULER_BLOCKING スケジューラフラグ)の場合と同じ動作を取得します。これは、ご使用の I/O マネージャが非同期 API を公開している場合に便利です。

このパラメータに大きな値を使用したいかもしれませんが、これには欠点があります。ストリーミングデバイスのスケジューラは、検査時における各ストリームの状態に応じて低レベルリクエストを送出します。スケジューラにたくさんのリクエストを送信させ、これらのリクエストを低レベルI/Oに長時間残しておくと、その間に状況が変化する可能性があります。例えば、ストリーミングサウンドが停止したり、ルーピングが停止します。このような場合には、これらの転送がキャンセルされ I/O データが受信時にフラッシュされます。これにより、大量の帯域幅が浪費される可能性があります。

大量の同時リクエストは、スループットがリクエスト量と直線的でないデバイスとのみ使用されなければなりません。例えば、一部の DMA コントローラは、大量の転送を処理するようプログラムされていますが、いつ処理が完了するかは、プログラムされた転送量と無関係であることがほとんどです。

デフォルト:8(AK_SCHEDULER_BLOCKING schedulers スケジューラに無視されます)。

最大キャッシュ比率

AkDeviceSettings::fMaxCacheRatio は、データキャッシュが有効になるかどうかを指定します:値が1より大きいと、キャッシュが有効になります。

ストリーミングデバイスは、ストリーミングプールへのデータキャッシュをサポートします。I/O 操作がメモリブロックに対して実行される場合、ファイルのメタデータがこれにアタッチされます。同一のストリームまたは同一ストリームの別のインスタンスが、だいたい同じ位置で同じファイルに対応するデータブロックを必要とする場合は、このデータブロックは直接使用され、低レベル I/O からの転送を避けることができます。

デバイスが作成される時に重要なデータ構造が(ストリームマネージャのメモリプールから)事前に割り当てられることを知っておく必要があります。これは、ランタイム時におけるメモリ不足により、I/O スレッドが優先度の高いスレッドをスピンせず、ゲームのパフォーマンスに悲惨な結果がもたらされる可能性があるためです。

ストリームデータキャッシュを使用すると、メモリブロック1つに対して複数のリファレンスが存在する可能性があります。メモリブロックへのリファレンスは、事前割り当てされた重要なデータ構造の一例です。

AkDeviceSettings::fMaxCacheRatio は、メモリブロック数対比でのリファレンス数を指定します。AkDeviceSettings::fMaxCacheRatio が1の場合は、メモリブロック1つに対して1つのリファレンスが存在するため、データのキャッシングは実行されません。特定のデバイスに対してキャッシングが必要ない場合、AkDeviceSettings::fMaxCacheRatio を1のままにしておく必要があります。この設定によって、データのルックアップが完全にスキップされます。

AkDeviceSettings::fMaxCacheRatio を2に設定すると、メモリブロック数の2倍のリファレンスが存在することになり、キャッシングが実行されます。この設定で作成すると、ストリーミングデバイスのストリーミングマネージャプール内におけるメモリフットプリントが少し大きめになります。このキャッシュ比率がニーズに十分対応しているかどうかを判別するには、Wwise Profiler を使用してゲームをプロファイルします。Profiler の Streaming Devices タブにある Caching Available カラムの値は、余分なリファレンスがどのぐらい残っているかを示します。これが0になると、デバイスは事前割り当てされたリファレンス量を尊重する必要があるためキャッシングは発生しません。この時点では、有効なデータがストリーミングキャッシュに存在していても、新しいストリーミングバッファが低レベルI/Oから補充されます。従って、プロファイリングセッション中に Caching Available が頻繁に 0 近くまで低下することに気づいた場合には、データキャッシュ機能の使用を最適化するために、AkDeviceSettings::fMaxCacheRatio を2以上に上げることを検討してください。

デフォルト:1 (キャッシング無効)。


このページはお役に立ちましたか?

サポートは必要ですか?

ご質問や問題、ご不明点はございますか?お気軽にお問い合わせください。

サポートページをご確認ください

あなたのプロジェクトについて教えてください。ご不明な点はありませんか。

プロジェクトを登録していただくことで、ご利用開始のサポートをいたします。

Wwiseからはじめよう