2011-12-28 6 views
0

私たちはiPad用のドラムコンピュータアプリを作りました。ステージ上や寝室でのライブミュージックと一緒に遊ぶことができます。設定は非常に基本的です。ボタンの1つを押すと、対応するサンプルが再生されます。すべてはかなりスムーズに動作しますが、残念ながら、指を置いた瞬間からサウンドを再生するまでの間に、小さな(迷惑ですが)レイテンシがあるようです。私はレイテンシー(耳による)の量を測定しようとしましたが、それは0.05〜0.1秒のようです。iPad drumcomputer touch-> audio latency

オーディオ再生は、AudioToolboxフレームワーク(拡張オーディオファイルサービス、オーディオユニット)を使用して実装されています。サウンドは、デバイスに保存されているファイルからストリーミングされ、異なるサウンドバンク間のロード時間を防ぎます。サンプルは生のwav形式(リニアPCM、16ビットのリトルエンディアン符号付き整数、2チャンネル、44100 Hz)です。これは理解できる範囲で処理するのが最も速くなければなりません(mp3のようなものとは対照的です)。

私は、ボタンの押下(UIButtonタッチイベント)とサンプルの最初のフレームのミキサーへの送達(再生コールバックによる)の間の時間を測定しました。それはかなり安定しており、0.02秒から0.03秒の間である。私にとってこれはかなり速いようですが、それは十分に速くないかもしれません。

これは問題になるのでしょうか、それともタッチイベントの配信が遅れるようなことがありますか?

UPDATE:

私は、サンプルのロードを書き換えてきた、ティルによって示唆されるように。これらはすべてメモリにプリロードされるため、ディスクIOはもはや問題になりません。その上に私はエコー効果のためにかなりmemcpyをやっていました。私はそれを無効にして、後でそれをリンクリストのような解決策で修正します。

これにより待ち時間が短縮されますが、ボタンを押したまま再生すると、0.005〜0.02秒(0.02秒)の値が測定されます。これはまだ目立つ。私はこれが再生のコールバックのバッファサイズ(現在は1024バイト)に起因する可能性があると考えています。

これを行う方法に関するアイデアはありますか? kAudioUnitProperty_MaximumFramesPerSliceを設定しても動作しないようです。

+0

ストリーミングファイルが問題だと思います。現在のモバイルデバイスのファイルシステムを使用しているときは、速度(またはその欠如)を過小評価してはなりません。メモリから直接プリロードして再生してみてください。 – Till

答えて

1

Iは、(0.005、バッファ時間を設定することによりAudio Session Cookbook

NSTimeInterval preferredBufferDuration = 0.005; 
[audioSession setPreferredIOBufferDuration:preferredBufferDuration error:&audioSessionError]; 

if (audioSessionError != nil) 
{ 
    NSLog (@"Error setting preferred buffer duration."); 
    return; 
} 

に述べたように、アプリケーションが唯一の256のバイトを供給しなければならない、好適なハードウェアI/Oバッファ時間を指定することにより、待ち時間の問題を解決各サイクルで44Khzで)。これは(明らかに)レイテンシを0.02から0.005に減らしますが、オーディオはより速いレートで生成する必要があります。

iPad 2は、ディスクからIOを読み込んだ場合でも、この速度に完全に対応できます。第1世代のiPadは、不幸にも(ディスクIOの有無にかかわらず)十分に高速ではありませんので、私は2つを区別し、パフォーマンスを向上させるためにiPad 1にもう少しレイテンシを与える方法を見つけることができることを願っています。

1

TimeProfiler(Apple Documentation on Instruments)テンプレートでInstrumentsを使用すると、どのメソッドを実行するかが正確にわかります。実行中は、「コールツリーの反転」オプションのチェックを外し、「システムライブラリを隠す」をチェックしてください。

+0

インストゥルメントがこの機能を内蔵していることを認識しませんでした。これは間違いなく問題を解決するのに役立ちます。 –