2011-12-13 5 views
1

IPCの種類や、特定の状況(プロデューサ/コンシューマ、優先度&タイミングなど)。リアルタイムオーディオ/グラフィックスのスレッド間のキューイング/イベント通信

OpenGLとSDLグラフィックス、ALSAオーディオ(MIDI)、POSIX pthreads、および周辺機器ハードウェア用のカスタムライブラリを使用するC for Linux(Ubuntu)のリアルタイムオーディオ/グラフィックスアプリケーションに取り組んでいます。現在、周辺機器と通信するためのメインスレッドとスレッドがあります。メインスレッドは、メイングラフィック描画サイクルと、オーディオの録音/再生を制御するコード(またはより正確には、ループ録音/再生用に設定されたMIDIイベント)を組み合わせます。

メインスレッドは現在厳密にタイムアウトしていないので、オーディオを独自のスレッドに分割する必要があります(つまり、メインの描画サイクルは、1つのスレッドから描画される内容に応じて繰り返しを終了するのに常に同じ時間を要しません)。これにより、オーディオループの「再生」(MIDIイベントの発生)がタイミングが一定になるのを防ぐことができます。

オーディオスレッドは、録音/再生に一貫性があり、周辺機器ハンドラスレッドからトリガイベントを受信する必要があります(イベントを生成する複数の周辺スレッドがあることに注意してください)。再生タイミングがまったく妨げられるほど長く待ってください。周辺スレッドによって送信されたトリガイベントは、オーディオスレッドと同期する必要があるため、ユーザがノートの再生/録音をトリガするときに、適切なタイミングで再生されます(つまり、すぐに、ノートを再生するとき、記録ループ内の正しい位置に)記録する。

オーディオスレッドは、グラフィクススレッド(グラフィックススレッドはメインプログラムスレッドのままです)に「描画」イベントを送信します。グラフィックススレッドは、グラフィックスイベントがオーディオ再生と同期して表示されるように、イベント - グラフィックススレッドは、オーディオスレッドと同じくらい厳密にタイムアウトする必要はありません。

私は試してみたいことを人々が示唆するのに十分明確であることを望みます。私はあまりキューアルゴリズム、ブロック、ロック、mutexesなどに精通していないが、私は基本的な概念を理解しているので、どのような種類のキューやメッセージングアルゴリズムを私は見て、どのような例/実装Cそれは素晴らしいでしょう。どうもありがとう!

答えて

0

zeromqをご覧ください。これらのコンセプトの多くを単純化するのは本当に素晴らしい仕事です。本質的にあなたのために待ち行列を作る魔法のトランスポート層であり、さまざまなプロトコル(IPC、TCPなど)上のさまざまなトポロジに配置できます。また、WindowsとLinuxで素晴らしいドキュメンテーションと実行が可能です。重要な言語でクライアントlibがあります。

私はインチワームのような形のソケットと考えるのが好きです。

関連する問題