Hatena::Groupiphone-dev

Ni chicha, ni limona - 平均から抜けられない僕

2009-06-09

[iPhone][OpenAL] OpenALで音を鳴らした時の遅延時間を調べてみた 23:20  [iPhone][OpenAL] OpenALで音を鳴らした時の遅延時間を調べてみた - Ni chicha, ni limona - 平均から抜けられない僕 を含むブックマーク はてなブックマーク -  [iPhone][OpenAL] OpenALで音を鳴らした時の遅延時間を調べてみた - Ni chicha, ni limona - 平均から抜けられない僕  [iPhone][OpenAL] OpenALで音を鳴らした時の遅延時間を調べてみた - Ni chicha, ni limona - 平均から抜けられない僕 のブックマークコメント

iPhoneで音周りを扱おうとすると、


 「OpenALは遅延が小さいよ」

 「サウンドやるなら最低OpenAL使わないとね」


なんていう声が聞こえてくるわけですが、実際のところどれくらいの負荷がかかっているかよく分かっていません。ひょっとしたらそんなことはないかもしれないのです。

そこで『再生から処理が戻ってくるまでの時間』という視点で調べてみることにしました。


ソースコードは以下のとおり。

	NSDate *from = [NSDate date];
	alSourcePlay(alSourceID); // ここをコメントアウトした場合も計測する。
	NSLog(@"elapsed time:%f",[from timeIntervalSinceNow]);

これだと負値が出てしまいますが、そこはスルーしておきます。


なお音声ファイルに使ったのは16bits/monoral/22.05kHz/caf形式のファイルです。たぶん、皆さんが一番使っているタイプのフォーマットではないかと勝手に思っています。


結果

以下のとおりでした。

どう受け取るかという点では、予想していたよりも1桁速かったのが嬉しい誤算。


デバイス遅延(サウンド再生)遅延(NSDateとNSLog()だけ)
Device200-500μsec50-60μsec
Simulator約50μsec10μsec以下

だけど・・・、うーん、ちょっとSimulator*1は速すぎるかな、と。シミュレータはパフォーマンステストには全然使えないことが分かりました。

まとめ

  • OpenALのサウンド再生では、処理復帰までに200-500μsecの遅延がかかる。
    • 思っていたよりもOpenALの処理復帰は速い
  • NSDateやNSLogもぼちぼち時間がかかる原因にはなっている
    • リリース前に消しておけるようにしておくことも重要

あと、初回の再生だけ少し時間がかかっていたのを念のために書いておきます。

*1iMac Core2Duo 2.0GHz