Kitに関わる全てのnodeのスーパークラスです。あなたがBMediaNodeから直接派生クラスを作成することは決してありません。その代りに、BMediaNodeから順に派生したシステムインターフェイスクラスの一つから派生させることができます。(BBufferProducerやBBufferConsumerなど)の使用方法の詳細については、それぞれの文書をご覧下さい。Classes"の16ページ目を見て下さい。(複数の継承を使用する際に要求される)仮想継承の動作に癖があるため、あなたはBMediaNodeのコンストラクタをあなたのノードのコンストラクタ中で呼び出さなければならないでしょう。Inheritance"の21ページ目をご覧下さい。アプリケーションは、nodeのメンバ関数を直接呼び出してはいけません。portを通してnodeに送ります。Node()、及びRelease()を直接呼び出すことができます。する場合は、そのnodeが破棄された後にそれらを呼び出さないように気をつけて下さい。nodeのメンバ関数をそのnodeの外部から直接呼び出すと、呼び出されたnodeの調整に関わっている一連の関数が動作しなくなる結果となります。悪くすれば、デッドロックが生じるでしょう。あなたがそれを行うのに安全な方法が見つかったと考えても、それを行わないで下さい。Nodeは、時間に対して高度に敏感な創造物です。その作業を行う上でもっとも微細な遅延が、メディアの再生や録音の品質に激烈な問題を引き起こしうるのです。普段はユーザにとって非常に大きな利益となる仮想記憶は、メディアを処理する作業に対して支障となりえます。時間に対する配慮が不完全な仮想記憶へのヒットは、メディアのパフォーマンスを破壊する原因になりえます。リアルタイムなメモリ割り当てとロック機能は、仮想記憶システムがnodeのメモリをディスクにキャッシュしてしまうことを防ぐため、nodeをロックダウンする方法を提供します。これはnodeがそれ自身またはそのメモリがスワップファイルから取り出される間停止しなければならないという状態を回避します。performanceアプリケーションを用いて設定することができます。典型的には、nodeはmalloc()及びfree()の代りに、リアルタイムなメモリ割り当てを使用すべきです。rtm_alloc()はB_MEDIA_REALTIME_ALLOCATORフラグがセットされれば自動的にメモリのロックを扱うので、あなたのnodeはそのことについて思い悩む必要はありません。加えて、もしあなたが書いたnodeのタイプと一致したリアルタイムのフラグがセットされていた場合、あなたのnodeはまた自分のスレッドのスタックをロックダウンするためにmedia_init_realtime_thread()を呼び出します。適切に書かれたnodeは、リアルタイムフラグをチェックせず、常にmedia_init_realtime_thread()を呼び出します。対応したフラグがセットされていなければ、この機能はB_MEDIA_REALTIME_DISABLEDを返すからです。あなたは単にエラーを無視し、先へ進むことができます。...もしadd-onやライブラリからのnodeがリアルタイムパフォーマンスを要求するなら、media_init_realtime_image()関数をメモリ上のイメージをロックダウンするために使用することができます。そのイメージがmalloc()を使用すると、そのイメージはロックされたメモリを割り当てられないということを銘記して下さい。これは制御不能となります。イメージがそれ自身をロックダウンすることは、さらにパフォーマンスを低下させます。(*)標準的なBeOSシステムのライブラリは、Be社の責任範囲です。それらがロックされるのに適当であれば、それらはあなたのためにロックされます。あなた自身でそれらをロックしないで下さい。libmedia.soとlibroot.soの両方に於て、media_init_realtime_image()が呼ばれます。Connection二つのnode間の接続を確立するには、複数の段階を踏みます。nodeは、接続が確立する前に両者のサポートするデータフォーマットについて合意する必要があります。input)が受け入れるフォーマットに関して、できる限り柔軟である必要があります。GetNextInput()からあなたのnodeが返すフォーマットは、交渉プロセスの開始点として使用されるでしょう。多くのワイルドカードをサポートすれば、その分いいでしょう。他のnodeと自分のnodeとの間に接続を確立したいアプリケーションは、そのnodeの入力と他方のnodeからの出力のフォーマットを決定し、その後、フォーマットとともにBMediaRoster::Connect()を呼び出します。rosterはあなたのnodeの出力に接続されたnodeの中でBBufferProducer::ProposeFormat()を呼び出します。producerは、ワイルドカードをもっとも特殊化されたフォーマットを形成することで特殊化します。それは、残されたどのワイルドカードもproducerにとって互換性を失わずに特化されることが保証されていなければなりません。結果として得られたフォーマットは、いくつかのワイルドカードを残しています(あるいは、もしproducerが非常に選り好みの激しいものであれば、まったくないかもしれません)。nodeのBBufferConsumer::AcceptFormat()呼び出しに渡します。この関数は、残されたワイルドカードを特殊化し、このフォーマットを返すために実装されるはずのもので、特殊なフォーマットが記述されます。このフォーマットは接続を確立するために使用されます。*name)派生したクラスのコンストラクタから呼び出して下さい。このカウントはAcquire()呼び出しが発行されるたびにインクリメントされ、Release()が呼び出されるたびにデクリメントされます。参照カウントが0になった時、nodeは削除されます。serverがそれを使って何をしているかを確実に知っている訳ではない以上、あなたはBMediaNodeを決して削除してはいけません。serverはnodeの参照カウントを維持し、それが使われなくなった時、自動的に削除します。*Release(void)Acquire()は、nodeの参照カウントをインクリメントした後、nodeへのポインタを返します。Release()は、その参照カウントをデクリメントし、nodeを開放します。カウントがゼロになれば、nodeは削除され、NULLが返されます。なければ、nodeのポインタが返されます。普段はアプリケーションの中からnodeのメンバ関数を呼び出せませんが、もしnodeが(add-onの中というより)アプリケーション自身のサブクラスであれば、Acquire()およびRelease()は直接呼び出すことができます。kind)nodeによってサポートされたkindのセットに、kindを追加します。これは、システムにそのnodeがサポートするように実装されたnodeのインターフェイスのタイプがなにか知らせます。(BBufferProducerプロトコルをnodeが実装していることを示す)B_BUFFER_PRODUCER及び(音声デジタル化入力機器などの物理入力を実装していることを示す)B_PHYSICAL_INPUTを含めた値を取ることができます。一般的に言って、この関数を呼び出す必要はありません。typeのフラグをセットするために自動的にAddNodeKind()を呼び出します。AddNodeKind()を呼び出す必要があるのは、物理デバイスまたはミキサーを実装した場合だけであり、そういう場合はB_PHYSICAL_INPUT、B_PHYSICAL_OUTPUTまたはB_SYSTEM_MIXERフラグを追加する必要があります。0この関数は、nodeのインスタンスを作成するBMediaAddOnへのポインタを返すよう実装されます。nodeが(add-on中よりむしろ)アプリケーション中で生きていれば、NULLを返します。nodeがadd-on中にあれば、outInternalIDはadd-on中のnodeの内部的なIDを内包するように変更されます。B_OK)nodeは与えられたcookieと時間を記憶するためにAddTimer()関数を実装します。toPerformanceTime時間に到達したとき、nodeは、記録されたtoPerformanceTime値をnotifyPoint引数として渡し、一致したcookieの値とともにTimerExpired()を呼び出します。AddTimer()は、全く問題なければB_OKを返すよう実装されます。なければ、適切なエラーコードを返します。0nodeが要求を監視するnodeのポートのport_idを返します。portを返すよう実装されなければなりません。*node)DeleteHook()関数は、BMediaNodeオブジェクトを削除するために呼び出されます。this;または、関数の継承された原形を通して呼び出します。nodeが問題なく削除されたなら、B_OKを返して下さい。なければ、適切なエラーコードを返して下さい。inMaxCount)あなたのnodeのアトリビュートをもって(inMaxCount個のアトリビュートを格納する空間を持つ)配列outAttributesを満たすために実装される関数です。問題がなければB_OKを返し、そうでなければ適切なエラーコードを返して下さい。size)もしあなたのnodeが、それ自身またはそれの派生したインターフェイスが理解できないメッセージを受け取ったなら、この関数に沿ったメッセージを理解し、受け渡して下さい。それはどうにかしてその問題を扱うのに功を奏するでしょう。HandleMessage()関数に受け取られる全ての引数はHandleBadMessage()を通じて直接渡されます。size)制御ポートから受け取ったメッセージが与えられると、この関数はメッセージを適切なBMediaNodeのフック関数にディスパッチします。そのメッセージがフック関数に一致しなければ、B_ERRORが返されます。nodeを実装する際は、常にあなたのnodeのHandleMessage()実装を通じてBMediaNode::HandleMessage()を呼び出す必要があります。あなたのnodeがBBufferProducerとBBufferConsumerの両方から派生しているとすると、あなたはBBufferProducer::HandleMessage()とBBufferConsumer::HandleMessage()を呼び出した後、BMediaNode::HandleMessage()を呼び出すべきです。}BMediaNode::HandleBadMessage()は、もしHandleMessage()の実装が一つもそのメッセージを受け入れなかった場合に呼び出されるということに留意して下さい。0x60000000と0x7FFFFFFFの間のcodeの値はアプリケーションによる利用が可能です。Kitによる利用のために予約されており、典型的にはあなたのnodeにおける特定の仮想フック関数に対応します。あなたがcodeの値を特殊なフックのために知る必要があるという理由を示せるなら、あなたはdevsupport@be.comに電子メールを送り、我々がその情報を共有してもよいとあなたに同意するるかどうかを知ることができます。codeの値をリバースエンジニアリングしないで下さい。あなたが本当にそれを知りたければ、我々に尋ねて下さい。なければ、我々は特定のコードが変更されるべきでないと知ることができないでしょう。一般的に、その必要がある場合でも、特定の値を信頼するのは悪い考えです。そのメッセージはディスパッチされました。そのメッセージはディスパッチ不能でした。フック関数に合致しなかったからです。constメディアサーバーによってnodeに割り当てられたedia_node_idを返します。nodeがまだ登録されていなければ結果は0となり、もしnodeの登録を企図している間にエラーが生じたなら結果は負の値になります。constnodeに実装されているインターフェイスが何か示すビットマスクを返します。有効なインターフェイスにどんな種類があるかについては181ページの"node_kind"をご覧下さい。constnodeの名前を特定する可読性の文字列を返します。このポインタはあなたがnodeをRelease()するまでの間だけ有効であり、その後にはなにもない場所を示すようになります。tagの値を作成して返します。rosterを経由してこのnodeにアクセスする際に使用されるmedia_node構造体を返します。Serverは、nodeが登録された後にこのフック関数を呼び出します。requestを使用し終わった時(バッファがもはや流れていない時)、この関数を呼び出します。notificationを待っていれば、それが通達されます。これは、オフライン(レンダリング)モードで動作しているアプリケーションに、nodeが実際に作業を完了した際、知らせます。あなたのnodeがBBufferProducerであれば、下流のconsumerはあなたのnodeが(自動的にであっても)停止したことをBBufferConsumer::ProducerDataStatus(B_PRODUCER_STOPPED)の呼び出しによって知らせます。これは特にB_OFFLINEモードで動作しうるnodeにとって重要です。Serverと交信できないか、他のnodeと交信できない時に生じます。Preroll(void)このフック関数は、もしnodeの呼び出しであるBMediaRoster::PrerollNode()をアプリケーションが使用したら、Start()メッセージがあなたのnodeに届く前に呼び出されます。これは、メディアが開始された時に出来るだけ速く反応できるように、nodeにそのメディアへの準備を行う機会を与えます。NULL)whichErrorによって特定されるエラーコードを、このnodeから通知を受け取るものに伝達します(BMediaRoster::StartWatching()及びBMediaRoster::StopWatching()をご覧下さい)。infoがNULLでなければ、それはエラー通知メッセージの規範となるメッセージとして使用されます。このエラー報告はエラーなしに送信されました。メッセージを送信することができませんでした。&info)この関数は、nodeによって発行された要求が完了したときには必ず呼び出されます。info構造体には要求の結果が記述されています。info構造体のchange_tagフィールドによって、完了した要求が識別されます。この値は、その要求を開始した関数に渡されるのと同じものです。あなたが幸せなら、B_OKが返され、そうでなければ適切なエラーコードが返されます。mode)RunMode()は、nodeの現在のrun_mode設定を返します。modeを変更するよう要求したときに呼び出されます。182ページの""run_mode"もご覧下さい。performanceTime)このフック関数は、BMediaRosterの呼び出しによってnodeが指定のmediaTimeをseek(検索)するよう求めた時に呼び出されます。nodeが検索処理を開始した時間を表すperformanceTimeは、将来実装されます。stop及びseek要求のそれぞれについて、少なくとも一つのキューを要求されます。アプリケーションが、あなたのnodeの処理進行をモニタすることなしにstartとstop時間を確立できるように、です。これら3つのキューの実際の大きさは、あなた次第です。指定された時間がくると、その要求は満たされるでしょう。mediaTimeが0の時は、メディアデータの最初を示します。sourceに従属するよう要求された時に呼び出されます。scale)で処理する必要のある修正がなんであれ、そのためにこの関数を追加します。TimeSource()は、そのnodeが現在従属しているBTimeSourceへのポインタを返します。sourceが使用され、それが返されるものとなります。TimeSource()によって返されるBTimeSourceオブジェクトは、次のHandleMessage()が呼び出されるまでの間のみ有効です。その結果、もしあなたのnodeが一つ以上のスレッドで動作している場合、あなたはTimeSource()呼び出しを(返されたオブジェクトと同じように)HandleMessage()呼び出しによって順番に並べる必要があります。このことは、もしあなたが推奨される手段に準じていれば、問題になりません。portの監視を行えばよいのです。performanceTime)このフック関数は、nodeがBMediaRosterへの要求で開始されるときに呼び出されます。nodeが動作を開始した時間を示す指定のperformanceTimeは、将来実装されます。stop及びseek要求のそれぞれについて最低一つのキューを要求されるため、アプリケーションは、例えばstart及びstop時間を、あなたのnodeの進行を監視することなく確立できます。これら3つのキューの実際の大きさは、あなた次第です。指定された時間がくると、その要求は満たされるでしょう。immediate)このフック関数は、nodeがBMediaRosterへの要求により停止させられる時に呼び出されます。nodeが停止した時間を示す指定されたperformanceTimeは、将来実装されます。immediateが真であれば、あなたのnodeはperformanceTimeの値を無視し、同期的に演奏を停止します。Stop()が返ったとき、あなたは下流のconsumerから受け取ったBBufferに書込まないことを約束しており、また再びStart()が呼び出されるまで、更にバッファを送らないことを約束します。stop及びseek要求のそれぞれについて最低一つのキューを要求されるため、アプリケーションは、例えばstart及びstop時間を、あなたのnodeの進行を監視することなく確立できます。これら3つのキューの実際の大きさは、あなた次第です。指定された時間がくると、その要求は満たされるでしょう。nodeは、それが停止した時に持っている全てのバッファを再利用します。timeの進行に突然のジャンプがあって(seek動作経由で)別の所に移されたときに呼び出されます。timeに発生します。nodeは、深刻などもりや失敗や演奏の加速が生じないように、この変化に対する準備をすることで呼び出しに反応するべきです。適切な手段が、演奏の質に対する影響を最小限にするために講じられるべきです。音声の一部分がスムーズに繰り返したりスキップされたりできるように、です。TimeWarp()を実装する時は、BMediaNode::TimeWarp()を他の全てのinheritされたTimeWarp()の形を通して呼び出します。timeか、あるいは制御ポートからメッセージを受け取るまで待ちます。flagsは現在使用されておらず、0でなければなりません。メッセージを受け取ったら、適切なHandleMessage()呼び出しが行われます。nodeのクラス派生を与えられて:BMediaNode::HandleMessage()は常に最初に呼ばれます。nodeがBBufferProducerから派生しており、メッセージがまだ処理されていなければ、BBufferProducer::HandleMessage()が呼ばれます。nodeがBBufferConsumerから派生しており、メッセージがまだ処理されていなければ、BBufferConsumer::HandleMessage()が呼ばれます。nodeがBFileInterfaceから派生しており、メッセージがまだ処理されていなければ、BFileInterface::HandleMessage()が呼ばれます。nodeがBControllableから派生しており、メッセージがまだ処理されていなければ、BControllable::HandleMessage()が呼ばれます。nodeがBTimeSourceから派生しており、メッセージがまだ処理されていなければ、BTimeSource::HandleMessage()が呼ばれます。メッセージがまだ処理されていなければ、もっとも元になるインターフェイスのHandleMessage()関数が呼ばれます。メッセージがまだ処理されていなければ、HandleBadMessage()が呼ばれます。これが終了すれば、WaitForMessage()が返ります。お分かりのように、これは受け取ったメッセージを処理する作業の大部分を扱うために、あなたの制御ポートから呼び出すことが出来ます。与えられた時間期限の間に発生します。メッセージを受け取らないままwaitUntilの時間に達した場合に発生します。nodeがStart()要求に失敗。nodeがStop()に失敗。nodeのrun_modeが設定できなかった。warp要求を実行できなかった。nodeがPreroll()要求に失敗。sourceが変更できなかった。nodeが全体的に苦悩している。node_error型は、nodeが、nodeを監視するよう登録されたBMessengerに通知できるエラーを定義しています。このフレーバーはBBufferProducerを実装しています。このフレーバーはBBufferConsumerを実装しています。このフレーバーはBTimeSourceを実装しています。このフレーバーはBControllableを実装しています。このフレーバーはBFileInterfaceを実装しています。このフレーバーはBEntryInterfaceを実装しています(R4では使用不可)。このフレーバーは、(インプットジャックのような)物理的な入力部位を表現します。このフレーバーは(ラインアウトのような)物理的な出力部位を表現します。このフレーバーはシステムミキサーを表現します。特定のフレーバーにサポートされたnodeの型を定義しています。フレーバーはnodeの一つ以上の型を実装できるため、ビットの論理和を使ってこれらの値を組み合わせることが出来ます。演奏に遅れがあったり速すぎたりしても、データを正確に保持する。これは典型的にはディスクにレンダリングする際に使用される。時刻を刻印されたバッファは、現実世界からそれらを取り込んだnodeから受け取られている。これらのバッファはタイムスタンプが過去であることを保証されている(それらはいつも「遅れて」いる)。演奏が遅れはじめたら、追いつくよう努力する。delayを増加させることでバッファはそれらが必要とするより時間を使わずに運ばれる。演奏が遅れはじめたら、データをスキップする。run_mode型は、もし演奏速度が要求されている速度から逸脱したら、どうやってnodeがうまく処理するかを示す。B_OFFLINEofflineモード(B_OFFLINE)にある場合は、nodeは特定の時間でバッファの処理することを心配する必要はありません。timeはBTimeSourceよりもバッファのタイムスタンプから導かれます。事実、あなたはnodeがofflineモードにある間、nodeの処理スレッドを低い優先度に設定するためset_thread_priority()を呼び出そうと考えるでしょう。これはソフトウェアがディスクにメディアをレンダリングするのに効果的な手法となり、ユーザが背後でレンダリングしている間も作業を続けられるようにします。B_RECORDINGrecordingモード(B_RECORDING)は、データが物理的な入力装置からサンプリングされている時に使用されます。これらの装置は常にタイムスタンプが過去のバッファを供給します。(バッファはそれがサンプリングされた時刻をスタンプされます。R127.1を動作させるでしょうし、この本は哀しいほど時代遅れになっているでしょう)B_RECORDINGモードの使用は、タイムスタンプが過去になるだろう他のnodeに警告するのに有用です。B_DECREASE_PRECISIONB_DECREASE_PRECISIONモードでは、nodeは遅延が生じた場合、普通よりも速くメディアデータのバッファを演奏することで追いつくように企図します。音声の場合これはより高いサンプリングレートで再生することを意味します。映像では、フレームレートを一時的に増加させます。measurement)を増やし、メディアストリーム上のあなたのnodeの上流にあるすべてのnodeのLateNoticeReceived()関数呼び出しを送信します。timeよりも早くそれぞれのバッファを生成するよう試するため、バッファが目的地に到着するのに、より多くの時間ができます。このモードは、スループットが大幅に遅れるデータストリームの補正を意図しています。メディアデータがネットワーク越しに流れているなら、バッファ(latency)をさらに追加することでトラフィックの変動に対応することが求められます。B_DROP_DATAB_DROP_DATAにあるときは、もし遅延が生じれば、nodeは単純にバッファをスキップします。timeで可能なかぎり多くのバッファの再生を保持するためにしなければならないことを全て無視すべきであるということに注意して下さい。reserved..。