JP4575528B2 - 標準クロック・メカニズムを用いて、多重データ・ストリームの処理の同期と異なる処理速度のマッチングを行う方法 - Google Patents

Description

【０００１】
【発明の属する技術分野】
本発明の分野は、発生クロックとレンダリング・クロックとの間のストリーム同期化およびレート整合といったように、マルチメディア・アプリケーションで起こるタイミング問題に関係する方法とコンピュータ・プログラム・プログラムに属するものである。また、本発明はソフトウェア・ドライバにおける標準化タイミング・メカニズムに関する。より具体的には、本発明は相互接続されたソフトウェア・ドライバなどの、複数のエンティティによって使用されるタイミングおよびクロック・メカニズムを標準化された方法で提供し、複数の処理されるデータ・ストリームが同期化され、異なるハードウェア・クロック間のレートが整合されるようにする方法およびコンピュータ・プログラム・プロダクトに関する。
【０００２】
【現在の技術状況】
ディジタル化サウンドやビデオ・データなどのマルチメディア・データを処理するとき、連続するメディア・サンプルのストリームを処理しているのが普通である。また、データ・ストリームは、規則またはタイムスタンプ情報のどちらかによってデータと関連づけられた時間インターバル情報ももっている。タイムスタンプ情報は、特定のサンプルをいつ処理すべきかを処理コンポーネントに知らせるものであるが、処理がタイムスタンプ間で特定のレートで進行するのを保証するためにトラッキング参照(tracking reference)としても使用されている。
【０００３】
処理が行われている期間に使用される時間インターバル情報を伝達するものとして、データ編成(data organization) 、フォーマット、および規定(convention)もある。例えば、３０フレーム／秒（ｆｐｓ）フォーマットと規定のビデオ・データ・ファイルは、処理コンポーネントがその規定とフォーマットを知っていれば、各サンプルが１／３０秒のインターバルで処理されるものと認識される。
【０００４】
メディア・ストリームを処理するときに起こる１つの問題は、２つまたはそれ以上のストリームを同期化してこれらが一緒にレンダリングされるようにすることである。例えば、サウンドトラックを表すオーディオ・ストリームと、それに付随するビデオ・データ・ストリームはコヒーレントなマルチメディア・プレゼンテーションが得られるように同期化する必要がある。
【０００５】
ある同期化方法では、ＰＣクロックのような物理クロックやハードウェア・クロックに基づく値をもつクロック・メカニズムを利用している。データ・ストリーム・プロセッサはこのクロック・メカニズムの値を照会してストリームの処理またはレンダリングを同期化することが可能になっている。同期化はハードウェア・クロックを基準にして行われるが、２つの異なるストリームは処理するイベントや遅延が各ストリームに対して独立に行われることがあるので、常に同期化されるとは限らない。
【０００６】
別の同期化方法では、ストリームが処理されている間、「マスタ」・データ・ストリーム上のプレゼンテーション・タイムスタンプ値に基づく時間値を提供するクロック・メカニズムを利用している。マスタ・ストリームが休止または停止されると、時間値はＰＣクロックのような物理クロックまたはハードウェア・クロックを基準にするように切り替わる。第２データまたはメディア・ストリームのプロセッサはこのクロック・メカニズムの値を照会(query) できるが、別の機能が用意されているので、クロック・メカニズムは物理クロック上の特定の時間に、あるいは、物理クロックに基づく一定のインターバル（例えば、１０ｍｓごと）に、プロセッサに通知するようになっている。
【０００７】
イベント通知は物理クロックに基づいているので、処理がマスタ・データまたはメディア・ストリームで休止または停止されたときでも、このようなイベントは引き続き起こる場合がある。通知は一時的に禁止することができるが、そうすると、余分の処理オーバヘッドが発生するという犠牲が伴い、処理コードがさらに複雑化することになる。通知が明示的に禁止されたときでも、通知が誤って行われるというタイミング上の問題が生じることがある。
【０００８】
メディアまたはデータ・ストリームを処理するとき起こるもう１つの問題は、メディア・ストリームに関連する異なるハードウェア・クロックのレートを整合するという問題である。あるハードウェア・クロックはメディア・ストリームのメディア・サンプルを生成し、タイムスタンプ情報を各サンプルと関連づけるときに使用されている。他方、全く別のハードウェア・クロックはメディア・ストリームをレンダリングするために使用されている。２つのハードウェア・クロックは見かけ上同じレートで動作しているように見えるが、物理クロック・レートが変動すると、処理に影響することになる。
【０００９】
ここでレート整合(rate matching) とは、物理クロックに起こる実際の周波数変動を補償する概念である。例えば、ライブ・オーディオのストリームがローカル・オーディオ・ハードウェア側でレンダリングするためにネットワーク接続から受信されるとき、ストリームの受信時のレートはローカル・オーディオ・ハードウェアが実際にストリームをレンダリングするときのレートに一致していない場合がある。このようなことが起こるのは、オーディオ・ハードウェア側のクリスタルが、ネットワーク接続の他端に置かれたオーディオ・ハードウェア側のクリスタルとは無関係であるためである。
【００１０】
場合によっては、ローカル・オーディオ・ハードウェア側で微調整を行うようにすると、ローカル側をソース側が発生している周波数に近づけることが可能な場合もある。しかし、すべてのオーディオ・ハードウェアがこれを可能にしているとは限らない。ハードウェアによっては、周波数解像度にある種の制約があるため調整の精度が制限されているものや、許容される調整量が制限されているものがある。
【００１１】
処理時の「ドリフト(drift) 」はこのレート差が原因で起こるため、ドリフト量を正確かつ迅速に判断するための方法が追求されている。さらに、ドリフトの補償は、大きな調整を低頻度で行なうよりも、小刻みに高頻度で行なうと最適化されるので、ドリフト補償がエンド・ユーザに気づかれることがなくなる。この気づかれやすい調整は、サウンド・データを「スキップする(skipping)」および／またはビデオ・データが「滑らかに動かなくなる(jerking) 」という形で現れる。
【００１２】
メディアまたはデータ・ストリームを処理するときに起こるさらに別の問題は、ある時間フレームを別の時間フレームに変換する問題である。この問題は、「スレーブ」・ストリームのプレゼンテーション時間がマスタ・ストリームの時間フレームに変換されるときの同期の間によく起こっている。エラー発生を最小限にしてこの変換を行なうための方法が探究されている。
【００１３】
マルチメディア環境では、ソフトウェア・ドライバを相互接続し、実行優先度が非常に高く、セキュリティ保護度が低いオペレーティング・システム・モードで実行され、多くの場合、ドライバが直接に操作する実際のハードウェアにアクセスできるソフトウェア・ドライバで処理を行なうようにすると好都合である。
多くのアプリケーションは、本明細書においてWindows NT用語で「カーネル・モード(kernel mode) 」と呼ばれる、この制約がゆるやかでパフォーマンス指向のモードで実行させると有利である。他の強固なオペレーティング・システムも機能的に同等のモードをもっている。このような相互接続ソフトウェア・ドライバの場合も、同じように複数のメディア・ストリームを同期化し、物理クロックのレートを整合する必要がある。
【００１４】
【発明が解決しようとする課題】
現在、本明細書で用いられているカーネル・モード・ドライバを容易に使用することができないプログラムの主要例の１つとして、ユーザがフィルタと呼ばれる、異なる処理ブロックを選択し、１つに接続してマルチメディア・データ・ストリームを連続的に操作できるようにするグラフ作成機能がある。データは、サウンドまたはビデオを表す一連のサンプルであるのが代表的であり、処理ブロックとしては、圧縮データのデコンプレション(decompression) 処理、特殊効果処理、CODEC 機能、データをアナログ信号にレンダリングすることなどがある。
【００１５】
このようなフィルタはユーザ・モードで置かれているのが代表的であるので、プログラムのグラフ作成部分は、フィルタのオペレーションを相互接続してその制御を行い、ユーザの入力と処理ブロックの配置替えに応答できるようになっている。マルチメディア・データ・ストリームはその性質上一貫性があり、大量のデータが生成されるので、パフォーマンスは重大な問題となっている。汎用オペレーティング・システムでは、ユーザ・モードとカーネル・モードとの間の受渡し／切替えを繰返し行うと、システム・パフォーマンスはある種のマルチメディア・アプリケーションが禁止されるほどに低下することがある。
【００１６】
カーネル・モード・フィルタの相互接続を標準化する方法が望まれているが、標準化クロック・メカニズムがあると、複数のマルチメディア・ストリームを同時に処理するとき起こる同期化の問題が解決しやすくなるという利点がある。さらに、このような標準化クロック・メカニズムはデータを送信し、異なる物理クロックを使用してデータをレンダリングするとき起こるレート整合問題も取り扱って、解決する必要がある。
【００１７】
本発明の目的は、各々が、関連する時間インターバル情報を有するデータ・サンプルからなる複数のデータ・ストリームの処理を同期化することである。
【００１８】
本発明の別の目的は、データ・ストリームがストリーム・データ・サンプルに表された発生側物理クロックと、ハードウェアの一部と関連づけられたレンダリング側物理クロックとによって発生された場合にデータ・ストリームの処理レートの整合を容易化することである。
【００１９】
さらに、本発明の目的は、相互接続されたカーネル・モード・ソフトウェア・ドライバのシステムで使用される標準化インタフェースをもつ有用なクロック・メカニズムを提供することである。
【００２０】
さらに、本発明の別の目的は、一方のクロック・メカニズム上の時間から他方のクロック・メカニズム情報の時間への変換を容易化することである。
【００２１】
本発明のその他の目的および利点は以下の説明に記載されているが、その一部はその説明から理解されるものと、本発明を実施することにより知得し得るものとがある。本発明の目的と利点は、請求の範囲に個々に記載されているインストリューメント(instrument)の手段および組合せにより実現し、得られるものである。
【００２２】
【課題を解決するための手段】
上記目的を達成するために、また本明細書に具現化され、広い意味で説明されている本発明によれば、標準化クロック・メカニズムを使用して複数のデータ・ストリームを同期化し、異なる処理レートを整合する方法とコンピュータ・プログラム・プロダクトが提供されている。クロック・メカニズムは種々の異なる方法で実現することが可能であるが、本明細書では、データ・ストリームの処理を効率化する相互接続可能なカーネル・モード・ドライバを中心にして説明されている。
【００２３】
本発明のクロック・メカニズムは３つの異なる時間値をもち、他のコンポーネントが利用できるようにする。これらの時間値を照会することも、クロック・メカニズムが一定の時間値に来たことに基づいて、または周期的インターバルで通知を送ることも可能である。
【００２４】
本発明のクロック・メカニズムで利用できる最初の時間値は位置時間値(positional time value)であり、これはデータ・ストリームに関連する時間インターバル情報に基づいており、処理されるデータ・ストリーム内の位置を反映している。第２の時間値はＰＣクロックやレンダリング・プロセッサ・クロックなどの実際のハードウェア・オシレータまたはクロックに基づく物理時間値である。最後に、第３の時間値は相関時間値(correlated time value) であり、これは位置時間値などの指定時間値(designated time value) をＰＣクロックなどの共通に利用可能なハードウェア・クロックに基づく参照時間値と共に提供する。
【００２５】
クロック・メカニズムをマスタ・クロックとしたときは、位置時間値は他のデータ・ストリームを処理する他の処理コンポーネントが同期をとるために使用することができる。位置時間値はデータ・ストリームの処理に基づいているので、基礎となるデータ・ストリームの処理が停止すると、クロックも停止する。さらに、タイミング・イベント通知も絶対時間を基準にして凍結されるが、位置時間値に対して完全にタイミングは合い続ける。このことは、「休止された」時間をトラッキング（追跡）したり、操作したり、あるいは気にしたりしないで済むという大きな利点がある。「スレーブ」・クロック・メカニズムとコンポーネントは位置時間値から得られる時間を基準にして処理を行う。
【００２６】
データ・ストリーム・レンダラまたは他のプロセッサに関連する基礎となるハードウェア・クロックの物理時間値は、処理されるデータ・ストリームのレートをレンダリング・プロセッサの処理レートと一致させるために使用できる。データ・ストリームは関連づけられている時間インターバル情報を有しているので、発生側プロセッサの処理レートは固有である。処理レートを確かめて、物理時間値に入っているレンダリング・プロセッサの実際の処理レートと比較することができる。これにより、処理レートの「ドリフト」を迅速かつ正確に判断できるので、レンダリングされたデータに目立った影響を与えることなく処理の調整を行うことができる。
【００２７】
最後に、相関時間値は他のクロック・メカニズムと処理コンポーネントが時間情報をある基準（basis）から別の基準へ変換するときの手段となるものである。共通ハードウェア・クロックは共通の参照（reference）として使用できるように、他のクロック・メカニズムまたはコンポーネントが利用できるようになっていなければならない。相関時間はアトミック・オペレーションとして返されるまたはアクセスされるので、発生する誤差は最小限であり、非累積的になっている。
【００２８】
相関時間はここで説明している実施の形態では２種類がサポートされ、どちらの場合も、ＰＣクロックを参照として使用している。一方はメディア時間を指定時間(designated time) として使用し、他方は物理時間を指定時間として使用している。本明細書では、相関時間が単独で使用されるときは、２種類の相関時間のどちらか、またはこの分野の当業者ならば自明である他の種類の相関時間を意味している。これらを区別する必要があるときは、相関メディア時間と相関物理時間の用語が使用され、それぞれの指定時間が共通参照と比較されるようになっている。
【００２９】
本発明の一実施の形態は、標準化された方法でカーネル・モード・ドライバを接続する一部として行われる。ある所定のドライバまたはフィルタは接続ポイントの「ピン・ファクトリ(pin factory) 」をサポートし、定義している。ピン・ファクトリは他のドライバ上の他のピン・インスタンスと相互接続される接続ピン・インスタンスをインスタンス生成するために使用され、ユーザ・モードのエージェントに頼らなくても、処理メッセージをドライバがカーネル・モードで連続的に処理できるようにする。
【００３０】
コンプライアント・ドライバ(compliant driver)を接続することを希望するサード・パーティ・エージェントはドライバに能力(cabability)があるかどうかを照会する。そのような能力としては、どの種類の接続ピン・インスタンスがインスタンス生成できるか、といったことがあり、この中には、処理されるデータのタイプ、データ・フォーマット、転送レート、転送媒体またはモード、接続ピン・インスタンスの入力または出力の性質などの関係特性が含まれる。照会されるものとして、ほかにも、必要なデータ・バッファ容量と、各接続ピン・ファクトリで利用できるバッファを割り当てる能力がある。
【００３１】
ユーザ・モードで実行されるのが代表的であるサード・パーティ・エージェントが１つまたは２つ以上のコンプライアント・ドライバの機能について照会したあと、そのエージェントは、複数のドライバを１つに「チェイニング」してデータがドライバ間で最適に処理されるようにする最良の接続特性を決定する。この決定ステップは、すべてのドライバ機能の照会を終えて、最適な接続基準が選択できるようになったあとで行われる。
【００３２】
各接続ピン・インスタンスごとに、サード・パーティ・エージェントはバッファ・アロケータ(buffer allocator)を特定のピン・インスタンスで作成する必要があるかどうかも判断する。この場合も、これはすべての異なるフィルタとピン・ファクトリの照会を終えたあとで行われ、そのあとで相互接続が行われる。
【００３３】
そのあと、サード・パーティ・エージェントは、各ドライバ上の接続ピン・ファクトリに基づいて接続ピン・インスタンスを作成することによってドライバを相互接続する。エージェントは接続ピン・インスタンス作成の一部としてデータ・フォーマットと接続フォーマットを指定する。ＮＴオペレーティング・システムの下で実装された実施の形態では、実際の接続ピン・インスタンスは「ファイル」へのハンドルを戻す作成入出力オペレーションによって作成される。作成入出力要求はドライバ・インスタンス・ハンドルと、接続ピン・インスタンスのデータ・フォーマットと接続フォーマットを示しているデータ構造への参照とを収めている。
【００３４】
さらに、以前に作成された接続ピン・インスタンス（例えば、入力ピンまたはＩＲＰ「シンク」・ピン）への参照は、他の接続ピン・インスタンス（例えば、出力ピンまたはＩＲＰ「ソース」・ピン）を作成する要求の中で指定され、接続ピン・インスタンス間の接続が行われるようにする。ソース・ピン・インスタンスがバッファ・アロケータをもつ入力ピン・インスタンスへの参照を使用して作成されると、バッファ・アロケータのソース・ピン・インスタンスと一緒に通知が行われ、データが既存バッファから新しいバッファに送り込まれるようにする。参照が示されていなければ、ソース・ピン・インスタンスは処理を終えた後、データを既存バッファに残しておく。
【００３５】
コンプライアント・ドライバを作成するためには、ドライバ開発者は、ユーザ・モードのエージェントが機能について照会し、ドライバ間の相互接続を行えるようにする、ある種の標準機能をサポートしている。Windows NTオペレーティング・システム上で構築されている、ある実施の形態では、これは、必要とする機能を実装している「集合(set) 」（つまり、プロパティ、メソッド、およびイベントの集合）の使用によって達成されている。
【００３６】
集合は、集合全体を特定するＧＵＩＤ(globally unique identifier)（グローバルにユニークな識別子）と、集合内の各機能エレメントのＲＵＩＤ(relatively unique identifier)（相対的にユニークな識別子、例えば、集合自体内で相対的な識別子）をもつものとして論理的に定義されている。各集合は１つまたは２つのＩＯＣＴＬｓ(IO Controls)(入出力コントロール）だけと関連づけられ、ＩＯＣＴＬは、集合の仕様と組み合わされて、ドライバとのすべてのインタラクションを制御する。
【００３７】
本実施の形態では、３タイプの集合が使用されている。つまり、プロパティ集合、メソッド集合、およびイベント集合である。プロパティ集合はサウンド・ボリューム、転送レートなどの、値または設定値をドライバ内で管理するために使用され、コールがプロパティ値を得ようとしているのか、および／またはプロパティ値を設定しようしているのかを示すフラグと一緒に単一のＩＯＣＴＬを使用する。メソッド集合は、メモリの割当て、バッファのフラッシング(flushing)などのように、ドライバが実行できるオペレーションを管理するために使用され、単一のＩＯＣＴＬを使用して特定のメソッドをコールする。イベント集合は、デバイス変更通知、データ・スターベーション(data starvation) 通知などのように、ドライバの処理に関連するイベントを管理するために使用され、２つのＩＯＣＴＬを使用する。１つは特定のイベントをイネーブル(enable)にするためのもので、もう１つは特定のイベントをディスエイブル(disable) にするためのものである。
【００３８】
集合を使用するには、入出力制御オペレーションは特定のＩＯＣＴＬと、集合のＧＵＩＤ、ＲＵＩＤをもつデータ構造への参照およびその他の必要なデータを使用して開始される。例えば、サウンド・カード・ドライバでボリューム・プロパティを設定する場合は、集合プロパティのＩＯＣＴＬを使用し、ボリューム設定値をもつプロパティ集合の適切なＧＵＩＤを指定し、その集合内の特定ＲＵＩＤがボリューム・プロパティを示していることを指示し、新しいボリューム設定値を含んでいる入出力制御オペレーションが行われることになる。
【００３９】
サポートされる集合について照会するには、ヌルＧＵＩＤが特定集合タイプの特定ＩＯＣＴＬ（例えば、プロパティ集合ＩＯＣＴＬ、メソッド集合ＩＯＣＴＬ、またはイベント・イネーブルＩＯＣＴＬ）で照会フラグと一緒に使用され、サポートされる集合ＧＵＩＤのリストが返される。ある集合内のサポートされたプロパティ、メソッド、またはイベントについて照会するには、集合ＧＵＩＤ、集合タイプＩＯＣＴＬ、および照会フラグが、サポートされたＲＵＩＤのリストを返すオペレーションと一緒に使用される。
【００４０】
汎用集合メカニズムを使用すると、コンプライアント・ドライバをサポートするために最小限の機能を実装することができるが、それでも拡張性は無制限である。集合は、特定の集合が実装されている限り、相互動作可能で、相互接続可能なドライバのシステムを作成するために、多数の異なるドライバ開発者によって独立してコーディングすることができる仕様書に定義することができる。さらに、この仕様書には、サポートする必要のある必須のプロパティ、メソッドおよびイベントを定義できるだけでなく、ドライバの機能と拡張機能に依存して実装できるオプションのプロパティ、メソッド、およびイベントも定義することができる。要求される基本的最小限の共通性のほかに、ドライバ開発者は独自の集合を定義し、その集合にＧＵＩＤを割当てることによって追加の機能を組み込むことも可能である。サポートされる機能（つまり、サポートされるＧＵＩＤとＲＵＩＤの照会を行うこと）を列挙できるようにすると、サード・パーティ制御エージェントなどの、呼出し側(caller)は期待を調整することも、基礎となるフィルタの機能に依存して適切な補償を行うこともできる。
【００４１】
位置時間値、物理時間値、相関位置時間値、および相関物理時間値をもつクロック・メカニズムの実施の形態は、コンプライアント接続ピン・インスタンス上に作成することができる。「ファイル」は、接続ピン・インスタンスを親として表しているファイル・オブジェクトのハンドルと、クロック・メカニズムのファイル・タイプを示すＧＵＩＤストリング値を指定して、入出力の特定のデバイス上でオープンされる。ハンドルはクロック・メカニズムを表すファイル・オブジェクトに返され、フィルタはそれぞれの時間値を提供するプロパティ集合を、このファイル・オブジェクトを通してサポートする。位置時間値はフィルタによって処理され、特定の接続ピン・インスタンスに渡されるデータ・ストリームに基づいている。物理時間は、ハードウェア・クロックまたは存在すればフィルタに関連するオシレータ、つまり、ＰＣクロックに基づいている。相関時間値はどちらも、ＰＣクロックが普及しているので、ＰＣクロックを参照値として使用しているのが代表的である。
【００４２】
クロック・メカニズムを「マスタ」として使用すると、他のクロック・メカニズムまたはコンポーネントを「スレーブ」にし、あるいはその時間トラッキングと同期させることができる。さらに、ＰＣクロックに基づくデフォルトの実装が用意されている。
【００４３】
本発明の上記およびその他の目的と特徴は以下の説明および請求の範囲に詳しく記載されている通りであるが、以下に説明する本発明を実施することによって知得することも可能である。
【００４４】
本発明の上記およびその他の利点と目的がどのようにして得られるかという方法を示すために、以下では、添付図面に図示されている具体的実施の形態を参照して、以上で簡単に説明してきた本発明を詳しく説明することにする。添付図面は本発明の代表的な実施の形態を示したにずぎず、従って、本発明の範囲を限定するものではないとの了解の下で、以下、添付図面を使用しながら本発明をもっと具体的にかつ詳しく記述し説明することにする。
【００４５】
【発明の実施の形態】
本明細書で用いられている「ユーザ・モード(user mode) 」という用語は、ユーザが書いたプログラムの大部分が実行されるときの、オペレーティング・システムにおける動作レベルのことである。ユーザ・モードの動作レベルはセキュリティ・レベルが最も高く、あるアプリケーション・プログラムまたはプロセスが別のアプリケーション・プログラムまたはプロセスに干渉するのを防止するために大量のオーバヘッドが消費されるのが代表的である。さらに、システム・リソースへのアクセスは特定のインタフェースを通して厳格に制御され、実行優先度は最低ではないとしても、最低優先度の１つであるのが一般である。
【００４６】
本明細書で用いられている「カーネル・モード(kernel mode) 」という用語はユーザ・モードの動作レベルよりも制約が非常に少ない、オペレーティング・システムにおける動作レベルのことである。カーネル・モードのプログラムまたはプロセスの例としては、ハードウェア・コンポーネントを制御するソフトウェア・ドライバ(software driver) を含む。代表例として、カーネル・モードのプログラムはパフォーマンスに影響されやすく、従って、動作上のオーバヘッドはユーザ・モードのプログラムよりも少なくなっている。さらに、ハードウェアや多くのシステム・リソースへのアクセスは無制約であるか、あるいはユーザ・モードのプログラムの場合よりも制約がはるかに少なくなっている。多くの場合、カーネル・モードで実行されるプログラム・コードは、規則(convention)に対するプログラマの規律正しさと準拠とを信頼して、システムが良好に動作するようにする（例えば、別のプログラムのアドレス空間を破壊しないようにする）。カーネル・モードを表わす別の用語として、「トラステッド(trusted) 」コードがある。
【００４７】
本明細書で用いられている「ドライバ(driver)」という用語はカーネル・モードで実行されるのが代表的である、ソフトウェア・ドライバ・プログラムのことである。ドライバという用語は、オペレーティング・システム上にロードされる実際の実行可能プログラムまたはある種の機能を分け与えるプログラム部分を意味する場合もある。ドライバは、多くの場合、ある形態のハードウェアと関連づけられているが、必ずしもそうである必要はない。
【００４８】
本明細書で用いられている「フィルタ(filter)」という用語はソフトウェア・ドライバ内に置かれている機能部分のことであり、この中には、ドライバ自体も含まれ、そこでは、接続ポイントがフィルタを通してデータを送信するために公開されている。例えば、ソフトウェア・ドライバはいくつかの異なるフィルタをサポートする場合もあれば、１つの単一機能をもっている場合もある。さらに、内部的には１つに接続され、外部的には入出力用に接続ポイントを公開している異なるドライバからの複数のフィルタは単一フィルタとして集合的に参照される場合もある。また、もっと総称的な意味では、フィルタという用語は、伸張(decompression) などのように、それがカーネル・モードで実行されるソフトウェア・ドライバ・フィルタで起こるか、ユーザ・モードで実行される別のプログラム・コードで起こるかに関係なく、実行されるオペレーションを意味する場合もある。
【００４９】
本明細書で用いられている「ドライバ・オブジェクト(driver object) 」という用語は、ソフトウェア・ドライバを管理し、これをシステム・リソースとして知らせるオペレーティング・システムによって定義されているオペレーティング・システムのエンティティのことである。
【００５０】
本明細書で用いられている「デバイス・オブジェクト(device object) 」という用語はシステムによって定義されたシステム・レベルのエンティティのことであり、これは利用が可能であるドライバの機能の一部をシステム・リソースとして知らせ、ドライバの機能と他のシステム・コンポーネントが利用できるかどうかを定義している。ドライバ・オブジェクトとデバイス・オブジェクトはどちらも、代表的にドライバ・ソフトウェアのロード時と初期化時に作成される。
【００５１】
本明細書で用いられている「ファイル・オブジェクト(file object) 」という用語は、デバイス・オブジェクトによって指定されたリソースの呼出しを管理するオペレーティング・システムのエンティティのことであり、これはオペレーティング・システムによって定義されている。ファイル・オブジェクトはドライバ・オブジェクトの使用状況に関するコンテキストを提供する。さらに、ファイル・オブジェクトは、以前のファイル・オブジェクトが新しいファイル・オブジェクトの作成時に「親」と指定されていれば、別のファイル・オブジェクトと階層的に関係づけることが可能である。ファイル・オブジェクトは、代表的にデータ・ストリーム上に操作するすべての入出力オペレーションの管理に使用される。
【００５２】
本明細書で用いられている「データ(data)」という用語は、相互接続されたカーネル・モードのフィルタを通して処理される一切の情報のことである。そのようなデータは、ビデオ、オーディオ、テキスト、ＭＩＤＩなどを表すメディア・データを含むが、他のアプリケーションの場合には制御情報やパラメータも含んでいる場合がある。例えば、カーネル・モード・フィルタ・グラフはプロセス制御オペレーションで使用されることがあるが、そこでは、異なるフィルタ間で受け渡しされる制御情報はマシン類をアクチュエートする制御信号を創り出すために使用されている。メディア処理システムの例が示されているが、他のアプリケーションも、本明細書に説明されている相互接続カーネル・モード・フィルタのシステムから、同じような方法で利点を得ることが可能である。
【００５３】
本明細書では、本発明の説明は、Microsoft(登録商標）社から提供されているWindows NT（商標）オペレーティング・システムのコンテキスト内で記載されている。さらに、本明細書に説明されている好適実施の形態を理解するためには、Windows NTの入出力アーキテクチャの知識が前提になっている。入出力システムおよび NT オペレーティング・システム全般について解説した好適書としては、Helen Custer著「Windows NTの内部(Inside Windows NT) 」(Microsoft Press発行）があるが、本書は引用により本明細書の一部を構成するものである。
【００５４】
ドライバおよびファイル・オブジェクト、デバイス・オブジェクト、ドライバ・オブジェクトなどのシステム・エンティティの以下の説明では、Windows NTオペレーティング・システム上でこれらがどのような働き方をするかが解説されているが、この分野の精通者ならば理解されるように、本発明は、類似のコンポーネントを持つ他のオペレーティング・システム上で実装することが可能であり、これらのオペレーティング・システムが同じ用語を使用しているかどうかとは無関係である。例えば、別のオペレーティング・システムがファイル・オブジェクトとして動作するエンティティを持っていれば、そのエンティティはその実際の名称に関係なく、ファイル・オブジェクトと解釈することができる。
【００５５】
まず、図１を参照して説明すると、図示のシステム例は、サウンド・データのストリームをディスク・ドライブから読み取り、そのサウンド・データをレンダリング(rendering) して、従来のモデルに従ってスピーカから聞こえるようにするものである。あるデータ量はハード・ドライブ２０にストアされるが、これはディジタル化されたサウンド・サンプルの形態でサウンドを表している。ほかにも、サウンド・データ・ストリームのソースとしては、電話回線を利用して送られてくるディジタル化情報、ネットワークや他の通信パケットからのディジタル化情報、この分野で公知の他のソースが考えられる。データ・ストリームはディジタル化サンプルから構成され、これらのサンプルはデータ・フォーマットと規則によって、または各サンプルに付加される明示的タイムスタンプ情報によってタイム・インターバル情報が関連づけられている。カーネル・モードのディスク・ドライバ２２はディスク・ドライブ・ハードウェア２０と相互作用し、ユーザ・モードのリーダ(reader)プログラム・コンポーネント２４の制御下に置かれている。制御エージェント(controlling agent) ２６はサウンド・データのレンダリングを行うために異なるコンポーネントを管理するが、動的グラフ作成機能(dynamic graph building capability) を備えている場合は、異なるソフトウェア・コンポーネントが動的に割当てられて、エンド・ユーザの指定に従ってカスタム・フィルタリングまたは他の処理経路を提供できるようにする。
【００５６】
リーダプログラム・コンポーネント２４はオペレーティング・システムの標準入出力制御インタフェースを使用してディスク・ドライバ２２と相互作用し、圧縮サウンド・データをディスク・ドライブ２０から読み取って、ユーザ・モード・プロセスのアドレス空間(address space) の一部としてユーザ・モードで割当てたバッファに入れる働きをする。次に、デコンプレッサ(decompressor)・コンポーネント２８は圧縮データを処理に適した伸張(decompressed)フォーマットに伸張する。図示のように、このステップ全体は、付随の低優先度の、プロセス動作(processbehavior)安全メカニズムを使用してユーザ・モードで実行される。
【００５７】
効果コンポーネント３０はデータに操作を加えて、ある種の特殊効果が得られるようにし、カーネル・モードで動作する附属の効果フィルタ３２をもっている。さらに、効果プロセッサ３４が存在する場合もあれば、効果フィルタ全体が実際のハードウェア・プロセッサをエミュレートするソフトウェアで動作する場合もある。効果フィルタ３２にアクセスするためには、効果コンポーネント３０はシステム入出力制御メカニズムを使用して、データと制御を効果フィルタ３２に転送する。この場合も、カーネル・モード／ユーザ・モード境界を交差して、この遷移が行われる。
【００５８】
効果フィルタ３２は効果プロセッサ３４を制御し、必要または望ましいとされる特殊効果がそのデータ上に作られるようにする。これは、効果コンポーネント３０から全データを効果フィルタ３２にコピーし、実際のシステム構成によっては、再度効果プロセッサ３４にもコピーすることにより行われる。多くのソフトウェア効果コンポーネントはハードウェア・プロセッサが関連づけられているが、他のコンポーネントは、ホスト・プロセッサ上で実行されるシステム・ソフトウェア内で完全に機能している。
【００５９】
効果コンポーネント３０の処理の完了時にコントロールとデータがユーザ・モードに戻されると、これは、次に、サウンド・レンダリング・コンポーネント３６に転送される。サウンド・レンダリング・コンポーネント３６はコントロールとデータをサウンド・レンダリング・ドライバ３８に転送し、これを受けてサウンド・レンダリング・ドライバは、処理され、フィルタリングされたデータをスピーカ４２からのサウンドとしてレンダリングするようにサウンド・カード４０を制御する。以上から容易に理解されるように、ユーザ・モードとカーネル・モード間の転送は多種類存在するために、サウンド・データのレンダリングを非効率化している。連続するサウンドまたはビデオ・ストリームのように、マルチメディア・データはタイミングに影響されやすい性質のため、これらの非効率性とコントロールの遷移を少なくすると共に、異なるバッファ間でなん度もデータをコピーすることを少なくすると、好都合である。
【００６０】
本明細書で用いられている本発明の一実施の形態は、Windows NTオペレーティング・システム・アーキテクチャ上で提供されるサービスから構成されている。
このサービスはシステムのユーザがアクセスする、いくつかの異なるソフトウェア・コンポーネントに分割されている。第１は、ユーザ・モードのＡＰＩであり、これは、接続ピン・インスタンスと、クロック・メカニズムやバッファ割当てメカニズムなどの特定の機能を表している他のファイル・オブジェクトとを作成するためのルーチンを含んでいる。ほかにも、もっと重要なものとして、ドライバ開発者が標準化アーキテクチャに従うドライバを作成するのを支援するルーチンとデータ構造が完備されている。システムに用意されているこれらの機能を利用すると、異なるドライバ開発者は特定のアーキテクチャに準拠して相互に相互作用するコンプライアント・ドライバを作成することができる。ユーザ・モード・エージェントはＮＴエグゼクティブおよび入出力マネージャのシステム・サービスと通信する、ユーザ・モードで実行中の環境サブシステムを通してコンプライアント・ドライバと通信する。これは、他のすべての入出力に対する同じ標準入出力メカニズムであり、好適実施の形態の本実装では、既存のシステム・サービスを可能な限り利用するようになっている。
【００６１】
本発明を利用する図１のシステムのアーキテクチャは図２に示すようになっている。制御エージェント４４は知らされているドライバに照会し、データ・フォーマットと接続フォーマットに従って相互接続を行い、レンダリングを完全にカーネル・モードで行うようにする。さらに、制御エージェント４４は重要なイベントの通知を受けるので、必要に応じて制御を行うことができる。このようなイベントの例としては、処理の終了、データ・スターベーション状態などを含む。
【００６２】
この構成では、サウンド・データは前述したように、ディスク・ドライバ４８によってディスク・ドライブ４６から読み取られる。リーダ・ドライバ５０はディスク・ドライバ４８を制御し、従来の使い方と同じようにＮＴ層(NT layered)入出力アーキテクチャに従ってディスク・ドライバ４８と「垂直方向」に関連づけられている。「垂直方向」と「水平方向」の用語は、ＮＴ層入出力アーキテクチャの一部として現在行われているドライバ接続（垂直方向）と、サード・パーティ制御エージェントによって動的に行われる相互接続カーネル・モード・ドライバに従う接続（水平方向）とを区別するために用いられている。
【００６３】
リーダ・ドライバ５０は以下で説明する接続メソッドに従ってデコンプレッサ５２とも「水平方向」に相互接続され、制御エージェント４４によって管理されている。デコンプレッサ５２は伸張をカーネル・モードで行ってから、データとコントロールを効果フィルタ５４に引き渡す。効果フィルタ５４は必要に応じて効果プロセッサ５６を利用して特殊効果を適用してからデータとコントロールをサウンド・レンダリング・ドライバ５８に引き渡し、このドライバ５８はサウンド・カード６０を制御し、データをスピーカ６２からのサウンドとしてレンダリングする。図２から理解されるように、処理をカーネル・モードのままにしておくと、ユーザ・モードとカーネル・モードとの間の複数の遷移がなくなり、処理をユーザ・モードで行うと通常起こるオーバヘッド量が減少するので、効率面の利点が得られる。
【００６４】
次に、図３を参照して説明する。図３は、本発明の一実施の形態に従う相互接続ソフトウェア・ドライバに関係するシステム・オブジェクトの階層的性質を示すロジック図である。ドライバ・オブジェクト６４は、メモリにロードされるときの、実行可能ソフトウェア・コード・イメージを表すために作成される。ソフトウェア・コード・イメージはドライバの機能全体を含んでおり、ドライバ・オブジェクト６４はシステムに置かれている場所、サポートされるドライバの種類などのイメージに関する情報を含んでいる。
【００６５】
制御エージェントによって独立にアクセスできる機能の各タイプ別に、デバイス・オブジェクト６６_a 〜６６_N が入出力ディレクトリ構造に作成され、これらのオブジェクトは利用可能で、ユーザ・モードのクライアントによってアクセスされる異なる機能を表している。これらは、フィルタまたは独立に利用できる他の機能部分を表しているのが代表的である。ドライバ・オブジェクト６４とデバイス・オブジェクト６６_a 〜６６_N は囲みボックス６８で示すように、ドライバ・コードのインストール時に作成される。
【００６６】
歴史的には、デバイス・オブジェクトは物理ハードウェアの各エレメントごとに存在する。しかるに、最新の入出力システムの柔軟性は、デバイス・オブジェクトが完全にソフトウェアで実装されたフィルタを表すことを可能にさせている。そのため、デバイス・オブジェクトは専らソフトウェアで実装されたフィルタの各インスタンスごとに作成することが容易になっている。従って、ソフトウェア・フィルタは、デバイス・オブジェクトで表された各インスタンスがデバイス・オブジェクトと１対１の対応関係をもつように実装することも、単一のデバイス・オブジェクトがより伝統的な手法に従い、各々がフィルタのクライアント・インスタンスを表している複数のファイル・オブジェクトを管理するように実装することも可能になっている。
【００６７】
デバイス・オブジェクト、図示の例では、デバイス・オブジェクト６６_a 上には、ファイル・オブジェクトが作成され、これはデバイス・オブジェクトで表された機能の独立インスタンスを表している。デバイス・オブジェクトはフィルタを表し、そのフィルタの複数のインスタンスを管理するのに対し、ファイル・オブジェクトは特定のエンティティによって使用される、そのフィルタの実際のインスタンスを表している。従って、ファイル・オブジェクト７０はデバイス・オブジェクト６６_a によって定義されたフィルタのインスタンスである。
【００６８】
フィルタを使用するには、制御エージェントまたは他のユーザ・モード・クライアントは入出力ディレクトリ構造内で利用可能なデバイス上でファイルをオープンする。適切なコンテキスト情報を収めているファイル・オブジェクトが作成され、そのファイルへのハンドルがユーザ・モード・クライアントに返される。
ファイル・オブジェクトは、作成時に「親」ファイル・オブジェクトを指定することによって階層的に関係づけることが可能であるが、ファイル・オブジェクトはすべてが同一デバイス・オブジェクトの子であるような、兄弟(sibling) 関係も持っている。
【００６９】
ファイル・オブジェクト内のコンテキスト情報は、ユーザ・モード・クライアントとの入出力インタフェースを管理する情報、ファイル・オブジェクトが表わしているエンティティの「状態(state) 」などからなっている。コンテキスト情報には、システムが必要とする情報があり、さらに、特殊な意味をもたせることができる、ユーザ定義可能エリアも含まれている。ユーザ定義可能エリアの使い方の例は、下述するバリデーション(validation)とＩＲＰルーチング(routing) ・メソッドのインプリメーテンションの説明個所に示されている。
【００７０】
接続ピン・インスタンスを提供するためには、フィルタ・インスタンスを表すファイル・オブジェクト７０が親として使用され、特定フィルタの接続ピン・インスタンスを表す子ファイル・オブジェクトが作成される。ファイル・オブジェクト７０は接続ピン・ファクトリの定義と可用性に関して照会されるのに対し、実際のファイル・オブジェクトは特定のファイル・オブジェクトを適切な情報コンテキストとして使用して、ピン・ファクトリの各インスタンスごとに作成され、接続ピン・インスタンスが有効に、かつ正しく作成されるようにする。例えば、ファイル・オブジェクト７２と７４はファイル・オブジェクト７０で表されたフィルタの接続ピン・インスタンスを表し、ファイル・オブジェクト７０と階層的に関係づけられている。それぞれファイル・オブジェクト７２と７４で表された接続ピン・インスタンスはフィルタ・インスタンス（ファイル・オブジェクト７０で表されている）に入ったあとで、そこから出るデータ・パスにすることができ、これは一連のチェイン・フィルタまたは他のドライバ機能を形成するときに他の接続ピン・インスタンスと接続するために使用できる。
【００７１】
ピン・インスタンスがフィルタ・インスタンスを表す別のファイル・オブジェクトと階層関係をもつファイル・オブジェクトで表されて、ピン・インスタンスのコンテキスト情報を提供するようにするのとまったく同じように、他のファイル・オブジェクトをピン・インスタンスと階層的に関係づけて他の機能を表すようにすると、正しいコンテキスト情報が得られるようになる。コンテキスト情報は、ピン・データ・フォーマット、通信タイプなどのように、作成時に使用される個々のパラメータに従って、あるピン・インスタンスを他のピン・インスタンスと区別するために必要である。
【００７２】
バッファ割当てメカニズム、タイミング・メカニズムなどのように、個別コンテキストかユーザ・モードのコントロールのどちらかをハンドルを通して要求する他の操作エンティティも、ファイル・オブジェクトで表すことができる。さらに、ファイル・オブジェクト（例えば、特定の接続ピン・インスタンスと関連づけられたバッファ割当てメカニズム）間の階層関係は、必要ならば、子ファイル・オブジェクトの作成時に親ファイル・オブジェクトを指定することにより確立することができる。これらの親子関係は、操作エンティティを表すファイル・オブジェクト間の関係と構造を決定するために存在する。さらに、特定タイプの「親」ファイル・オブジェクトはある種のタイプの「子」ファイル・オブジェクトだけを作ることができるので、以下で説明するように作成バリデーション・メカニズムが必要になる。この場合も、このようなファイル・オブジェクトは対応するハンドルがユーザ・モードで利用可能になっており、これらのハンドルはNtCreateFileなどのシステムＡＰＩコールを通してクライアントに返される。
【００７３】
ファイル・オブジェクトへのハンドルはカーネル・モード・ドライバと通信するために、制御エージェントなどのユーザ・モード・クライアントによって使用される。ファイル・オブジェクト、デバイス・オブジェクト、およびドライバ・オブジェクトの階層的チェインは、入出力サブシステムが階層関係をもつファイル・オブジェクトとデバイス・オブジェクトを通ってドライバ・オブジェクトまで戻り、実際のドライバ・コードに入るエントリ・ポイント(entry point) に到達することができるようにする。このようなエントリ・ポイントはソフトウェア・ドライバ・コードの中の機能を指す参照（例えば、ポインタ）になっている。
さらに、特定のファイル・オブジェクトと、ソフトウェア・ドライバ・コードへのエントリ・ポイントをもつドライバ・オブジェクトとの間のオブジェクト通路(pathway) 上にあるオブジェクトの各々は、入出力サブシステムがＩＲＰを作成するときに重要なコンテキスト情報のほかに、下述するルーチングおよびバリデーション・メカニズムに従ってＩＲＰを正しくルーチングするときに使用されるデータ構造への参照も提供する。
【００７４】
ファイル・オブジェクトと他のシステム・オブジェクトに対するハンドルはプロセス専用であり、ユーザ・モード・プロセスが基礎となるオブジェクトと通信するときの手段となる。注目すべきことは、ファイル・オブジェクトなどの、基礎となる単一システム・オブジェクトを参照するために複数のハンドルが作成できることである。このことは、複数のアプリケーションがファイル・オブジェクトで表されたピン・インスタンスに情報を供給できることを意味する。
【００７５】
異なるドライバを相互接続するとき重要となる情報エレメントの１つとして、デバイス・オブジェクト・スタックの深さ(depth) パラメータがある。これは特定のドライバ・オブジェクトのＩＲＰスタック・ロケーションを示している。このようにすると、入出力マネージャを使用して、相互接続されたドライバ間で単一のＩＲＰを使用し受け渡しできるので、ＩＲＰを別々に作成し、それを種々の相互接続ドライバ間で送信するよりもパフォーマンス向上を提供できることになる。別の方法として、各ドライバは適切な入出力マネージャのコールを通して、各連続通信ごとに新しいＩＲＰを作成し、各々の新ＩＲＰを相互接続されたドライバのチェイン上の次のドライバへ送信させることも可能である。
【００７６】
次に、図４〜図６を参照して説明する。図は、異なるタイプのファイル・オブジェクト作成のバリデーションと適切なハンドラへの入出力要求パケット（I/ORequest Packet：ＩＲＰ）のルーチングを可能にするシステム・ドライバ・オブジェクト、デバイス・オブジェクト、およびファイル・オブジェクトのエクステンションを示している。図４は、１つまたは２つ以上のフィルタまたは他のドライバ機能を実装している実行可能コードを表すドライバ・オブジェクト７６を示している。ドライバ・オブジェクト７６内では、Windows NTアーキテクチャはソフトウェア・ドライバ開発者が用意した作成ハンドラへの参照を要求している。この実施の形態によれば、マルチプレクシング・ディスパッチ機能(multiplexing dispatch function)７８は作成ハンドラとしてドライバ・オブジェクト７６から参照され、作成されるファイル・オブジェクトのタイプに応じて特定の作成ハンドラへメッセージをルーチングするために使用される。マルチプレクシング・ディスパッチ機能７８のオペレーションは図８に示すフローチャートを参照して以下で説明する。
【００７７】
同じように、ドライバ・オブジェクトからの他のハンドラはマルチプレクシング・ディスパッチ機能を示し、どのように実装するかに応じて、これらは同じ機能にすることが可能である。言い換えれば、以下で詳しく説明するように、各タイプの入出力ハンドラ参照（例えば、読取り、書込み、デバイス制御など）はデバイス・オブジェクト内のエクステンション・データとファイル・オブジェクト内のコンテキスト情報を使用して、メッセージを適切なハンドラへルーチングするマルチプレクシング・ディスパッチ機能を指している。バリデーション・テーブルを参照するデバイス・オブジェクト内のエクステンション・データは、作成オペレーションで親ファイル・オブジェクトの指定がないとき使用される。指定があれば、親ファイル・オブジェクトのコンテキスト情報は正しいバリデーション・テーブルを示している。
【００７８】
図５は、ドライバ開発者によって所望により利用でき、ドライバ専用情報を含んでいる特定のデバイス・エクステンション・エリア８２をもつデバイス・オブジェクト８０を示している。デバイス・オブジェクト８０のデバイス・エクステンション・エリア８２内の定義されたロケーションには、ファイル・タイプ・バリデーション・テーブル８４と呼ばれ、ファイル・オブジェクト・タイプ８６のストリング表現を含んでいるデータ構造への参照と、表現される各ファイル・タイプ別の関連する作成ハンドラ８８への参照が置かれている。作成マルチプレクシング・ディスパッチ機能はファイル・タイプ・バリデーション・テーブル８４を使用して、作成されるファイル・オブジェクト・タイプを検査し、そのあと、コントロールを適切な作成ハンドラへ引き渡す。これについては、以下の図８の説明個所で詳しく説明する。検査されるストリングはＩＲＰ作成要求に見出され、ユーザ・モードのNtCreateFile関数コールと共に使用されるファイル名ストリングから創られる。NtCreateFile関数コールは、ピン・インスタンスまたは他のメカニズムを作成するためにユーザ・モード関数セルの中で行われる。
【００７９】
図６は、ソフトウェア・ドライバ開発者が使用するために解放されているファイル・コンテキスト・エリア９２をもつファイル・オブジェクト９０を示している。参照はファイル・コンテキスト・エリア９２からＩＲＰディスパッチ・テーブル９４へ行われる。ＩＲＰ要求９６の異なるタイプは特定のハンドラ９８の参照と関連づけられ、適切なマルチプレクシング・ディスパッチ機能はこの情報を使用して正しいハンドラにアクセスする。正しい作成ハンドラを決定する場合には、ファイル・オブジェクト・タイプ・バリデーション・テーブル１００と呼ばれるデータ構造が参照され、そこには、ファイル・オブジェクト・タイプ１０２のストリング表現と、表現される各ファイル・タイプ別の関連する作成ハンドラへの参照１０４が入っている。子ファイル・オブジェクト（つまり、デバイス・オブジェクトではなく別のファイル・オブジェクトを親としてもつファイル・オブジェクト）の場合は、タイプはファイル・オブジェクト・タイプ１０２内のストリングと比較されるストリングで表されている。一致するものが見つかると、関連する作成ハンドラは、参照１０４のうち、一致したファイル・オブジェクト・タイプ・ストリングと関連づけられている参照を使用してアクセスされる。一致するものが見つからなければ、要求は無効であるので、エラー表示が出されることになる。
【００８０】
次に、図７を参照して説明すると、図は作成バリデーションとメカニズムをセットアップするためのインストレーション・プロシージャを示している。ステップ１０６で、インストール・プログラムは適切なマルチプレクシング・ディスパッチ機能への参照をドライバ・オブジェクトの中に作成する。図４に示すように、作成ハンドラは汎用マルチプレクシング・ディスパッチ機能７８を指している。同様に、ドライバ・オブジェクト７６の中の他のすべてのハンドラ参照は、特定ハンドラと密接な関係をもつ他の汎用(generic) マルチプレクシング・ディスパッチ機能を必要に応じて指している。別の方法として、各ハンドラ参照は同一マルチプレクシング・ディスパッチ機能を指すことも可能であり、その場合は、このディスパッチ機能はＩＲＰ要求を処理したあと、それを適切なハンドラへルーチングすることができる。この方法によるマルチプレクシング機能は異なる種類の要求（例えば、作成、書込みなど）を受け付ける必要があるため、複雑化することが避けられない。
【００８１】
次に、ステップ１０８で、ソフトウェア・ドライバ実行可能コードのインストールの一部として作成された各デバイス・オブジェクトは、図５に示すようにファイル・タイプ・バリデーション・テーブル８４を参照するように調整される。
最後に、ステップ１１０で、ＩＲＰ要求の処理は、適切なデバイス・オブジェクト８０から参照されたファイル・タイプ・バリデーション・テーブル８４を使用してマルチプレクシング・ディスパッチ機能から開始される。
【００８２】
ファイル・オブジェクトが作成されると、適切なＩＲＰディスパッチ・テーブル９４が作成され、必要ならば、インデックスされたファイル・オブジェクト・タイプ・バリデーション・テーブル１００と一緒に参照される。ファイル・オブジェクト・タイプ・バリデーション・テーブル１００の作成は、ファイル・オブジェクト・タイプに従って用意された作成ハンドラ内で行われる。データ構造が作成され、これはＩＲＰディスパッチ・テーブル９４とファイル・オブジェクト・タイプ・バリデーション・テーブル１００を表しており、それを指す参照は作成される特定のファイル・オブジェクト９０のファイル・コンテキスト・エリア９２と一緒に特定ロケーションにストアされる。
【００８３】
次に、図８を参照して説明すると、図は作成マルチプレクシング・ディスパッチ機能のオペレーションとそのバリデーション・メカニズムを示すフローチャートであり、そこには、システム・ドライバ・オブジェクト、デバイス・オブジェクト、およびファイル・オブジェクトから参照されるデータ構造との相互作用も示されている。ステップ１１２で、ユーザ・モード・プロセスはファイル・オブジェクトを作成する入出力要求を送信する。この入出力作成要求はNtCreateFileのシステムＡＰＩを呼び出すことによって行われる。ステップ１１４で、入出力マネージャはドライバ・オブジェクト７６内の参照に基づいてＩＲＰをマルチプレクシング・ディスパッチ機能７８に送信する（図４参照）。
【００８４】
マルチプレクシング・ディスパッチ機能７８が作成要求のＩＲＰを受け取ると、ステップ１１６でテストが行われ、親ファイル・オブジェクトがあるかどうかが判断される。この判断を行うために必要な情報はＩＲＰ自体の中にあるが、これはユーザ・モード・プロセスによって元来用意されたものである。ユーザ・モード・プロセスは「親」ファイル・オブジェクトを参照するハンドルを作成要求の一部として用意し、ＮＴシステムは「親」ファイル・オブジェクトへの正しい参照をもつＩＲＰを作成する。
【００８５】
親ファイル・オブジェクトがなければ、右へのブランチがとられ、マルチプレクシング・ディスパッチ機能７８は適切なデバイス・オブジェクト８０からのデバイス・エクステンション・エリア８２を使用して、ファイル・タイプ・バリデーション・テーブル８４をステップ１１８で参照する（図５参照）。ファイル・タイプ・バリデーション・テーブル８４を使用して、マルチプレクシング・ディスパッチ機能７８は要求の中のストリングをファイル・オブジェクト・タイプ８６のストリングと比較することによって、ステップ１２０でファイル・オブジェクト・タイプを検査する。
【００８６】
ステップ１２２でストリングが一致していると判断されると、適切な作成ハンドラがステップ１２４でアクセスされる。一致していなければ、作成要求はステップ１２８で拒否される。ステップ１２４でアクセスされた作成ハンドラはステップ１２６でファイル・オブジェクトを作成するか、あるいは作成させる。作成されたファイル・オブジェクトを使用して、適切な作成ハンドラは、以前に作成していたＩＲＰディスパッチ・テーブル９４を指すファイル・オブジェクト参照をファイル・コンテキスト・エリア９２の中に作成する。
【００８７】
再びステップ１１６に戻って、親ファイル・オブジェクトが存在するかどうかが判断される。親ファイル・オブジェクトが存在するとステップ１１６で判断され、それが作成要求に関連するＩＲＰに入っていれば、マルチプレクシング・ディスパッチ機能７８は親ファイル・オブジェクト９０からのファイル・コンテキスト・エリア９２を使用して、ステップ１３０でＩＲＰディスパッチ・テーブル９４を参照する（図６）。作成要求の場合は、マルチプレクシング・ディスパッチ機能７８はステップ１３２でファイル・オブジェクト・タイプ・バリデーション・テーブル１００を参照する。ファイル・オブジェクト・タイプ・バリデーション・テーブル１００を使用して、マルチプレクシング・ディスパッチ機能７８は、上記と同じように、要求の中のストリングをファイル・オブジェクト・タイプ１０２のストリングと比較することによってステップ１３３でファイル・オブジェクト・タイプを検査する。
【００８８】
ストリングが一致しているとステップ１３４で判断されると、適切な作成ハンドラがステップ１３８でアクセスされる。一致していなければ、作成要求はステップ１３６で拒否される。適切な作成ハンドラを使用して、ファイル・オブジェクトはステップ１４０で作成され、作成ハンドラは新しく作成されたファイル・オブジェクトの新しいＩＲＰディスパッチ・テーブル９４を作成し、新しく作成されたＩＲＰディスパッチ・テーブル９４を指す参照を新しく作成されたファイル・オブジェクト９０のファイル・コンテキスト・エリア９２の中にステップ１４２で作成する。注意すべきことは、親ファイル・オブジェクトおよび有効に作成された子ファイル・オブジェクトとの相互作用を説明するために、どちらの場合も、図６に示す同じファイル・オブジェクト構造が使用されていることである。どちらの場合も同じ構造が存在するが（新しいファイル・オブジェクトが作成されたあと）、これらはその使い方が異なり、含んでいる情報も異なっている。
【００８９】
接続ピン・インスタンスが作成されるといつでも、接続ピンＩＤが引き渡され、これはピン・インスタンスの作成を「サポート」するフィルタ内のピン・ファクトリを示している。この分野の精通者ならば理解されるように、接続ピンＩＤは、ファイル・オブジェクトが検査されるのとまったく同じように、バリデーション・テーブルでストリングとして検査することも可能であり、また、その実装方法もさまざまである。
【００９０】
異なるドライバ間の接続を行うためには、あるドライバがそのような相互接続をサポートしていることを確かめるための共通メカニズムが必要である。この共通メカニズムは、接続ピン・ファクトリ機能を含むフィルタ機能を明らかにすることを可能にするものでなければならない。さらに、この種のメカニズムは、ドライバ開発者の柔軟性を向上するように拡張可能であることも必要である。
【００９１】
コンプライアント・ドライバを定義し、機能を明らかにすることを可能にするために本実施の形態で選択されている１つのメカニズムは関連アイテムの「集合」と名づけられている。これは既存の入出力通信メカニズムと一緒に使用すると便利なメカニズムである。集合は集合全体を特定するＧＵＩＤ（グローバルにユニークな識別子）と集合内の各機能エレメントのＲＵＩＤ（相対的にユニークな識別子、例えば、集合自体内の相対的な識別子）を持つものとして論理的に定義されている。集合識別子および選択されたＲＵＩＤアイテムと一緒にオペレーションするために必要な他のデータ構造は、フィルタ・ハンドルをパラメータとして使用して入出力制御コールの一部として引き渡される。機能の完全なシステムを実装するためには、少数のＩＯＣＴＬを割当てるだけで十分である。実装されるとき、３つの異なる種類の集合がその機能に応じて確立されるので、必要になるＩＯＣＴＬは総計４個である。他の実装では、集合の使い方が異なる場合がある。特定のＩＯＣＴＬは、選択されたエレメント（ＲＵＩＤを使用する）をなんらかの方法で解釈または使用するように入出力制御のハンドラに通知する。さらに、制御フラグをＧＵＩＤおよびＲＵＩＤと一緒に渡して、制御情報をもっと詳しく指定することができる。
【００９２】
最初の集合タイプはプロパティ集合であり、これはドライバ内または関連ハードウェア上に置かれている値または設定値と一緒に使用される。そのような設定値の例としては、転送レート、ボリューム・レベル（音量）などがある。１つのＩＯＣＴＬがプロパティ集合と関連づけられ、制御フラグは'get' プロパティ・コマンドと'set' プロパティ・コマンドとを区別している。このようにすると、同じデータ構造を特定のプロパティを設定または取得するために使用でき、ドライバは必要なアクションを使用されたＩＯＣＴＬに基づいて決定することができる。正しいプロパティは、ユニークなＧＵＩＤとＲＵＩＤの組合せからなる集合識別子(set identifier)によって特定される。
【００９３】
メソッド集合は使用されるもう１つの集合タイプであり、これはドライバによって実行できるアクションの集合である。メソッド集合を特定するために必要なＩＯＣＴＬは１つだけであり、アクチュエートされる正しいメソッドは集合識別子のユニークなＧＵＩＤとＲＵＩＤの組合せによって特定される。メソッドはドライバを制御するために使用され、ドライバを使用するための初期化、バッファのクリアといった機能を含んでいる。
【００９４】
イベント集合は、デバイス変更通知、データ・スターベーション通知などのドライバ処理や、ユーザ・モード・アプリケーションで使用すると便利である集合によって定義された他の通知に関連するイベントを管理するために使用される。
２つのＩＯＣＴＬが使用され、１つは特定のイベントをイネーブルにするためのものであり、もう１つは特定のイベントをディスエーブルにするためのものである。ＲＵＩＤで識別された、与えられたイベントに必要なデータ構造は、イベントをイネーブルにするか、ディスエーブルにするかに関係なく共用することができる。
【００９５】
集合を使用するには、入出力制御オペレーションは特定のＩＯＣＴＬおよび集合ＧＵＩＤ、 ＲＵＩＤをもつデータ構造と他の必要なデータ（例えば、制御フラグ、データ構造など）を指す参照を使用して開始される。例えば、サウンド・カード・ドライバでボリューム・プロパティを設定することは、入出力制御オペレーションをプロパティ集合ＩＯＣＴＬ、集合プロパティ・オペレーションを示す制御フラグ、ボリューム設定値をもつプロパティ集合の適切なＧＵＩＤ、ボリューム・プロパティを示しているその集合内の特定ＲＵＩＤ、および新しいボリューム設定値を使用することを必然的に伴う。
【００９６】
サポートされる集合についてタイプ別に照会するには、ヌルＧＵＩＤとサポートされる集合の列挙を示す制御フラグとをもつ、特定の集合タイプのＩＯＣＴＬ（例えば、プロパティＩＯＣＴＬ、メソッドＩＯＣＴＬ、またはイベント・イネーブルＩＯＣＴＬ）が入出力コマンドの一部として出され、サポートされる集合ＧＵＩＤのリストが返される。ある集合内のサポートされるプロパティ、メソッドまたはイベントについて照会するには、集合ＧＵＩＤ、集合タイプＩＯＣＴＬ、ヌルＲＵＩＤ、およびサポートされるエレメントの列挙を示す制御フラグが入出力オペレーションと共に使用される。サポートされるＲＵＩＤのリストは入出力オペレーションの結果として返される。このリストから、サード・パーティ・エージェントは、実装されている集合のどのオプション・エレメント（もしある場合）がサポートされるかを判断することができる。
【００９７】
ＧＵＩＤでユニークに識別された集合の仕様書は、ドライバ開発者とサード・パーティ制御エージェントのどちらもが実装ガイドとして利用できるメカニズムをドキュメント化している。サード・パーティ開発者は、あるドライバの機能を照会に対する応答に基づいて知り、事前プログラムされた知識を抽象的集合定義に基づいて知ることになる。同様に、ドライバ開発者は、知った機能をどのようなサード・パーティ・エージェントに対して提供する集合または集合グループを実装するときのガイドとして抽象的集合定義を使用することができる。
【００９８】
ここで説明している接続機能を提供するためには、コンプライアント・ドライバはある種の集合をサポートしていなければならない。以下の表は、プロパティ集合フォーマットでサポートされ、本発明を実装するときに使用できるいくつかの重要な情報を示している。最初の表は、フィルタによって実装される接続ピン・ファクトリに関するプロパティに関し、２番目の表は、特定の接続ピン・ファクトリをテンプレートとして使用して作成される実際の接続ピン・インスタンスに関するプロパティを示している。
【００９９】
【表１】

【０１００】
【表２】

【０１０１】
【表３】

【０１０２】
【表４】

【０１０３】
【表５】

【０１０４】
【表６】

【０１０５】
上記の表は単なる例示であり、これに限定されるものではない、この分野の精通者ならば理解されるように、異なるドライバ間の接続を作成するためには多数の異なるプロパティとスキーマを実装することが可能である。１つの重要な要素は標準化係数(standardization factor)であり、異なるドライバ製造者または開発グループは同一のプロパティ集合を実装する能力をもっているので、相互接続できるドライバを作成できるようにすることである。
【０１０６】
もう１つの有用なプロパティ集合は、あるフィルタ上の入力と出力の接続ピン・ファクトリの内部関係に関するトポロジ情報を与える。この情報はあるフィルタ上の入力ピン・ファクトリおよび対応する出力ピン・ファクトリの関係だけでなく、入力と出力のピン・ファクトリの間でどのようなタイプの処理が行われるかも記載している。行われる処理の例としては、異なるデータ変換、データ伸張、エコー打消し(cancellation)などがある。このような情報は複数のフィルタを使用して仮定上の接続パスをトレースしてから実際の接続ピン・インスタンスおよび接続を作成する自動化フィルタ・グラフ作成機能で使用すると、便利である。基本的には、トポロジ情報はフィルタの内部構造を説明し、これをプロパティ集合メカニズムを通してサード・パーティ・制御エージェントからの照会に公開する。
【０１０７】
従って、コンプライアント・ドライバは指定されたプロパティ集合を実装しているものにすぎない。そのため、サード・パーティ制御エージェントは、あるプロパティ集合がサポートされていることが分かったとき、コンプライアント・フィルタに対し照会と設定を行うことができる。全体目標は、異なるフィルタを１つに接続してフィルタ・グラフを作る方法に関する十分な情報を得ることである。
【０１０８】
汎用集合メカニズムを使用すると、最小限の機能を実装してコンプライアント・ドライバのシステムをサポートできるが、その場合でも、拡張性は無制限である。集合は、特定の集合が実装されている限り、相互操作可能で相互接続可能なドライバのシステムを作成するために多数の異なるドライバ開発者によって独立にコーディングできる仕様書の中で定義することができる。さらに、この仕様書には、サポートしなければならない必須のプロパティ、メソッド、およびイベントを定義できるだけでなく、ドライバ機能と拡張機能に応じて実装できるオプションのプロパティ、メソッド、およびイベントも定義できる。最小限に要求される基本的共通性のほかに、ドライバ開発者は独自の集合を定義し、これらにＧＵＩＤを割当てることにより追加の機能を組み入れることも可能である。
【０１０９】
次に、図９および図１０を参照して説明する。図は２つのカーネル・モード・フィルタを接続するプロセスを図形化して示している。図９はロジック・ブロック説明図であり、そこでは各フィルタ・インスタンスと接続ピン・インスタンスはファイル・オブジェクトで表されている。図１０はファイル・オブジェクトおよび適切な接続を作成するときのステップを示すフローチャートである。
【０１１０】
ステップ１４４からスタートして、フィルタＡ１４６のインスタンスおよびフィルタＢ１４８のインスタンスはユーザ・モードのエージェントによって作成される。これらは特定のデバイスでファイルを作成する標準ファイル・システムＡＰＩを使用して作成される。フィルタＡ１４６とフィルタＢ１４８がコンプライアント・フィルタまたはドライバとなっているのは、これらが適切なプロパティ、メソッド、およびイベント集合を実装して接続ピン・インスタンスの作成をサポートし、サポートされる集合とそのフィルタ用に定義された接続ピン・ファクトリに関してそれぞれのフィルタの機能に照会するようになっているからである。
【０１１１】
サード・パーティ・制御エージェントは、ステップ１５０でフィルタＡ１４６とフィルタＢ１４８にそれぞれ照会し、利用可能な接続ピン・ファクトリおよびそれから作成できる接続ピン・インスタンスの属性を判断する。これらの属性には、前述したように、フィルタＡ１４６とフィルタＢ１４８のそれぞれのピン・ファクトリのタイプ別の接続フォーマットとデータ・フォーマットがある。照会は、以下で詳しく説明する集合ベース照会メカニズムを使用して行われる。
【０１１２】
上記情報の照会を終えると、サード・パーティ・制御エージェントは、以前に照会したデータ・フォーマットと接続フォーマットの範囲に基づいて最適接続フォーマットを決定する。この決定はステップ１５２で行われ、選択した接続パスの要求事項に応じて同じフィルタをサード・パーティのエージェント（サード・パーティ・制御エージェント）が異なった使い方をできるようにする。サード・パーティ・制御エージェントはデータ交差プロパティ(data intersection property)、トポロジ情報、および接続ピン・ファクトリを両方のフィルタで使用して、作成される実際のフィルタ・グラフに応じてデータ・フォーマットと接続配置の最良の選択方法を決定する。
【０１１３】
入力ピン・インスタンス１５４はステップ１５２で判断された最適検出情報を使用して、ステップ１５６でサード・パーティ・制御エージェントによって作成される。入力ピン・インスタンス１５４はファイル・オブジェクトであるので、ハンドルが作成プロセスから返されるが、これは入出力要求を入力ピン・インスタンス１５４へ送るために使用できる。さらに、入力ピン・インスタンス１５４の作成が有効性の検査をされているが、この作成には、図４〜図６、図７および図８を参照して前述したルーチングおよびバリデーション・メカニズムが使用される。
【０１１４】
接続を完成するために、出力ピン・インスタンス１５８は、以前に作成された入力ピン・インスタンス１５４のハンドルをNtCreateFileコールの中でパラメータとして使用してステップ１６０で作成される。出力ピン・インスタンス１５８がこのようにして作成される効果として、システム・ファイル管理機能と入出力管理機能を使用して内部ＩＲＰスタック構造が作成される。このスタック構造により、オリジナルの書込みコマンドは、さまざまな方法で接続された接続ピン・インスタンスとフィルタによって適当な順序で連続処理することが可能になるので、異なるフィルタ間の直接データ・フローが容易化される。これを行うためには、入力ピン・インスタンスを供給する関連出力ピン・インスタンスの前に入力ピン・インスタンスが作成されていることが必要である。
【０１１５】
デバイス・オブジェクトのスタック深さパラメータは、このドライバに送られるＩＲＰ用にスタック・ロケーションをいくつ作成するかを制御する。スタック深さパラメータは、デバイス・オブジェクトが初めて作られるときは１つであると想定されているが、複数のドライバが１つにチェイニングされているかどうかに応じて、あとで変更することも可能である。現システムでは、この変更は、必要ならば、出力ピン・インスタンスが初期「停止」状態から「取得」または他の状態に遷移するとき行われる。接続ピン・インスタンスの状態遷移はＩＲＰを正しく作成し、処理するための正しいスタック深さパラメータ情報を決定するメカニズムである。
【０１１６】
チェイニングされた接続ピン・インスタンス集合を正しく割当てるためには、接続ピン・インスタンスを特定の順序で停止状態から出るように遷移させる必要がある。つまり、最後の入力ピン・インスタンス（この例では、入力ピン・インスタンス１５４）から始まって、関連の（例えば、接続された）出力ピン・インスタンス（この例では、出力ピン・インスタンス１５８) まで連続的に逆方向に戻っていく必要がある。多数のフィルタが１つにチェイニングされていれば、最も深いフィルタまたはブリッジの入力ピン・インスタンスが遷移の開始ポイントであって、ブリッジまたはフィルタ上の初期出力ピン・インスタンスが設定されるまで逆方向に連続的に構築していかなければならない。言い換えれば、停止状態から出る遷移はチェインを逆昇るように行われ、各接続ピン・インスタンスが前の接続ピン・インスタンスの後で必要になるスタック・サイズを得るようにしなければならない。代表例として、必ずしもそうする必要はないが、接続ピン・インスタンスは停止状態から取得状態へ遷移するが、以下での説明の便宜上、取得状態への遷移はスタック深さパラメータの調整に関しては、停止状態から出る遷移と同じ目的を果たすようになっている。
【０１１７】
すべてのピン・インスタンスが取得状態になったあとは、ストリーム読取りと書込みをフィルタ・グラフに対して出すことができる。なお、注目すべきことは、ここで説明しているシステムが、関連する入力ピン・インスタンスと出力ピン・インスタンスとの接続をどの順序でも行うことができ、停止状態からの遷移だけはボトムアップ方式、つまり、最も深いものから先に行わなければならないことである。さらに、フィルタ・グラフは初期作成後に変更が行えるように再構成可能になっている。変更が行われるときは、状態遷移は停止状態にある接続ピン・インスタンスだけで行い、正しいスタック深さパラメータ情報が得られるようにする必要がある。
【０１１８】
フィルタ上に見出される接続ピン・ファクトリは、フィルタが特定フォーマットでデータを消費および／または作成できる場所を表している。例えば、特定の接続ピン・ファクトリは、１６ビットの４４キロヘルツＰＣＭオーディオや８ビットの２２キロヘルツＰＣＭオーディオなどの、いくつかの異なるデータ・フォーマットをサポートすることができる。前述したように、接続ピン・ファクトリやそのデータ・フォーマットなどの異なる機能については、適切なプロパティ集合メカニズムとシステム入出力機能を使用してフィルタから照会することができる。実際の接続ピン・インスタンスはピン・ファクトリから受信した情報に基づいて作成される。
【０１１９】
単一のストリーム書込みまたはストリーム読取りオペレーションがユーザ・モード・エージェントから出されると、接続されたフィルタを通してデータの連続処理が行われるストリーミング環境では、ＩＲＰ制御用の２つのメイン・メソッドがＮＴオペレーティング・システムのネーティブ機能の一部として使用することができる。第１のメソッドでは、個別ＩＲＰは各フィルタによって作成され、次のフィルタへ送られて処理され、このフィルタは新しいＩＲＰを作成し、チェインを下って次々と処理されていく。他のメソッドでは、単一のＩＲＰが使用され、入出力マネージャと相互作用するために用意された標準プロシージャを使用して連続フィルタ間で受け渡しされていく。チェイン上の各連続フィルタごとに新しいＩＲＰを作成していく第１のメソッドが使用される場合は、フィルタ間の相互接続順序が重要でないのは、フィルタはＩＲＰのデスティネーション(destination) だけを知っていればよく、入出力マネージャをコールしてＩＲＰを指定のフィルタへ送ることができるからである。ＩＲＰが再使用される場合に重要なことは、停止状態からの接続ピン・インスタンスの遷移が再使用ＩＲＰを受け取る最後のフィルタから始まるように行われ、再使用ＩＲＰを受け取る最初のフィルタまで、または処理のためにＩＲＰを作成したフィルタまで逆方向に処理していくことである。
【０１２０】
相互接続カーネル・モード・フィルタの本実施の形態と実装例は、ＩＲＰ共用を利用してドライバ開発の複雑さを軽減し、より堅牢なドライバが作成されることを可能にし、処理を効率化するという利点がある。「ボトムアップ」のピン・インスタンス状態遷移パスは、正しいスタック順序が連続ドライバによって処理されるＩＲＰに作成され、各ドライバ・オブジェクトが適切なスタック深さパラメータ集合をもつことを保証する。さらに、受信側入力ピン・インスタンスの現状態は、状態遷移シーケンスを正しくたどっていたかどうかを確かめるためにチェックされる。そのような理由から、特定の接続ピン・ファクトリの通信プロパティは起こり得るフロー方向を判断し、接続ピン・インスタンスの状態遷移を正しく分配する上で支援する。
【０１２１】
出力ピン・インスタンス（またはＩＲＰソース）を作成するとき、別のフィルタ上の入力ピン・インスタンス（またはＩＲＰシンク(sink)）を表すファイル・オブジェクトへの参照はNtCreateFileコールの一部として引き渡される。適切な作成ハンドラはマルチプレクシング・ディスパッチ機能とデバイス・オブジェクト／ファイル・オブジェクト階層を使用して、前述したように実行される。この作成ハンドラは入力ピン・インスタンスをもつフィルタ（例えば、図９のフィルタＢ１４８）のデバイス・オブジェクトを、入力接続ピン・インスタンス・ファイル・オブジェクト（例えば、入力ピン・インスタンス１５４）を通してアクセスすることができる。デバイス・オブジェクトから、前のスタック深さパラメータを読み取ることができ、出力ピン・インスタンスをもつフィルタのデバイス・オブジェクトのスタック深さパラメータが増加される。例えば、フィルタＡ１４６に関連するデバイス・オブジェクトは、図９に示す接続ではフィルタＢ１４８に関連するデバイス・オブジェクトのそれから増加されるスタック深さパラメータをもっている。これは停止状態から出る遷移のとき行われるのが通常であり、ＩＲＰは接続ピン・インスタンスが停止状態にある間はルーチングされない。
【０１２２】
フィルタがＩＲＰを処理するとき、その特定フィルタ用に指定された情報を含んでいる、ＩＲＰスタック内のどのスタック・フレームまたはロケーションをアクセスすべきかを、関連デバイス・オブジェクトのスタック深さパラメータを参照するか、あるいはそれを使用することによって知る。さらに、現フィルタは、デバイス・オブジェクトのスタック深さパラメータを減らして次のフィルタのＩＲＰスタック・ロケーションに位置づけることによって、処理チェイン上の次のフィルタ用のＩＲＰを準備する。
【０１２３】
フィルタ・コードはＩＲＰスタック内の次のロケーションを準備し、入出力マネージャをコールしてＩＲＰを、指定された通りに次のフィルタに渡すことを受け持っている。このようにすると、フィルタは、特定の接続ピン・インスタンスを表す、どのファイル・オブジェクトがＩＲＰと関連データを受け取って処理するかを指定することができる。従って、ＩＲＰの順次処理のためにそれぞれのデバイス・オブジェクトをスタックするためのIoAttachDeviceのような標準入出力マネージャ・コールは使用されない。
【０１２４】
注目すべきことは、接続ピン・インスタンス間の接続を作成することは、その接続を表すために新しいデバイス・オブジェクトを作成することを意味しないことである。基礎となる単一のデバイス・オブジェクトはフィルタのインスタンスとそのフィルタ上のすべての接続ピン・インスタンスをサポートするために使用される。正しいデータ処理のために必要な具体的情報はファイル・オブジェクトのコンテキスト・エリアに保存されていて、コンテキスト情報はそのまま残されているが、非ページ・メモリ使用量は最小限に保たれている。さらに注目すべきことは、ＩＲＰベースの媒体について説明してきたが、相互接続フィルタ間の通信のための他の媒体も使用できることである。そのようなものとして、非ホスト・ハードウェアとハードウェア間通信での直接関数コールがある。
【０１２５】
次に、図１１と図１２および図１３を参照して、図１（従来技術）と図２（相互接続カーネル・モード・ドライバのハイレベル・ロジック図）に示すソフトウェア・ドライバの正しい作成、接続、および状態遷移順序について説明する。図１１はボックス１６２で囲んだロジック構造とそこに含まれる処理ステップを示している。図１２は接続ピン・インスタンスを作成して、カーネル・モード・フィルタの相互接続を完成する様子を示し、図１３に示すフローチャートにボックス１６４で囲んだ処理ステップを含んでいる。
【０１２６】
すべての相互接続が行われている図１２の状態にあるとき、カーネル・モード・フィルタ・システムは処理を行うために読み書きの準備状態にある。入出力システムは正しい状態遷移プロセスによって正しく設定されたＩＲＰスタック情報を使用して、ストリーム読取りと書込みをそれぞれの接続ピン・インスタンスを通して異なるフィルタ・エレメントに引き渡す。なお、グラフを作成するために使用されたエージェント以外の、ある種の外部ソフトウェアは、ブリッジまたはフィルタ自体とハードウェアも含めて、ストリーム読取りとライトのデータを提供する。
【０１２７】
ステップ１６８からスタートしたあと、サード・パーティ・制御エージェント１７０はステップ１８０で、リーダ・フィルタ１７２、デコンプレッサ・フィルタ１７４、効果フィルタ１７６、およびサウンド・レンダリング・フィルタ１７８のインスタンスを作成する。さらに、リーダ・フィルタ１７２とディスク・ドライバ１８２との間の接続が行われて、データがディスク・ドライブから持ち込まれるようにする。各フィルタ・インスタンスの作成は標準入出力コールを使用してデバイス入出力ディレクトリ階層に見出される適切なデバイス上のファイルをオープンすることにより、ユーザ・モードのサード・パーティ・制御エージェント１７０によって行われる。このコールからは、各フィルタのインスタンスを表すファイル・オブジェクトへのハンドルが返される。
【０１２８】
ステップ１８４で、サード・パーティ・制御エージェント１７０は、リーダ・フィルタ１７２、デコンプレッサ・フィルタ１７４、効果フィルタ１７６、およびサウンド・レンダリング・フィルタ１７８に照会し、接続ピン・ファクトリの機能を判断する。これらの機能は、どのような種類の入出力ピン・インスタンスが作成できるか、特定のフィルタは各接続ピン・ファクトリのインスタンスをいくつサポートするか、各接続ピン・ファクトリでサポートされるデータ・フォーマット、通信パスの媒体またはタイプなどがある。これらの機能は以前に詳しく説明したプロパティ集合メカニズムを使用して照会され、カーネル・モード・フィルタは、適切な「集合」（例えば、プロパティ集合）をサポートしているのでアーキテクチャに従っていることが前提になっている。
【０１２９】
ステップ１８４でのこのようなすべての照会情報は、チェインニングされた接続パスが、適切な接続ピン・インスタンスを作成し、接続することによりそれぞれのフィルタ間で可能であるかどうかを判断するために使用される。サード・パーティ・制御エージェント１７０は、相互接続のために必要なピン・インスタンスのタイプを判断し、与えられた目的を達成するフィルタ・グラフを作成する。
【０１３０】
サポートされるデータ・フォーマットに基づく接続フォーマットの決定はステップ１８６で行われる。フィルタ上のトポロジ情報、データ・フォーマット、およびデータ交差プロパティを使用すると、仮定上の(hypothetical)フィルタ・グラフを作成することができる。接続順序は重要でないので、そのようにする必要はないが、フィルタ・グラフを作成しようとするとき時間を節約することができる。この仮定上のフィルタ・グラフがエラーなしで作成されるのであれば、サード・パーティ・制御エージェント１７０は、相互接続する接続ピン・インスタンスの作成を信頼して行うことができるという安心が得られる。実際のピン・インスタンスが作成されていなければ、ある種の照会からはエラーが返されるので、かかる接続ピン・インスタンスを作成してから仮定上のフィルタ・グラフを作成するようにすると、実行可能であるとの信頼できる指示が返されることになる。この場合も、仮定上のフィルタ・グラフは相互接続を行う前にテストすることが可能である。
【０１３１】
正しい接続情報が分かっているとステップ１８６で決定されると、入力ピン・インスタンスを作成し、相互接続して、図１３のボックス１６４で囲まれた処理ステップのループで表すことができる。このループはデータ・ストリームのソースから最も遠くに離れた入力ピン・インスタンスから始まる処理ステップを含んでいる。この最後の入力ピン・インスタンスは「最も深い」ピン・インスタンスと呼ばれ、これは最初に作成され、そのあとに関連する出力ピン・インスタンスを続けることができる。従って、接続は、以前に作成された入力ピン・インスタンスのハンドルを使用して出力ピン・インスタンスを作成したものである。
【０１３２】
このパターンは、すべての入力ピン・インスタンスが関連出力ピン・インスタンスとの接続の前に、それ以後連続して作成されるように続けられる。このような接続シナリオは単なる例示であり、それぞれの出力と入力ピン・インスタンスを接続して、本発明によるカーネル・モード・フィルタ間の接続を形成する他の可能な方法を限定するものではない。フィルタは、入力ピン・インスタンスからのハンドルが別のフィルタ上の接続された出力ピン・インスタンスの作成期間に使用される限り、実装に従ってどの順序でも接続することが可能である。さらに、前述したように、初期作成後（および使用後も）フィルタ・グラフに変更を行うことが可能である。
【０１３３】
ループの最初の繰り返しでは、入力ピン・インスタンス１８８はステップ１９０で作成される。作成機能からハンドルを受け取ると、サード・パーティ・制御エージェント１７０はそのハンドルをNtCreateFileコールでパラメータとして使用してステップ１９４で出力ピン・インスタンス１９２を作成する。最初の繰り返しでこれを行うと、サウンド・レンダリング・フィルタ１７８は、それぞれ対応する接続ピン・インスタンス１８８と１９２を通して効果フィルタ１７６に実効的に接続される。現実装では、NtCreateFileコールはユーザ・モード・クライアントが利用できるＡＰＩの関数コールの一部として「ラップ(wrapped) 」される。これにより、サード・パーティ・制御エージェントのユーザ・モード開発者は詳細を知る必要から解放されるので、すべての関係機能を単一ユーザ・モードＡＰＩに集中させることができる。
【０１３４】
ステップ１９６で、サード・パーティ・制御エージェント１７０は作成すべき入力ピン・インスタンスが他にも残っているかどうかを判断する。残っていれば、入力ピン・インスタンスを作成し、そのあとに別のフィルタ上の対応する出力ピン・インスタンスを続けなければならない。最終的には、すべての接続が行われ、サード・パーティ・制御エージェント１７０はストリーム化データ処理に対してフィルタ・グラフを準備する。
【０１３５】
以上のようにして、入力ピン・インスタンス２０２はステップ１９０でボックス１６４で囲まれたループの２回目の繰り返しで作成され、他方、出力ピン・インスタンス２０４は入力ピン・インスタンス２０２のハンドルをステップ１９４でその作成の一部として使用する。最後に、この特定の例では、３回目と最後の繰り返しで、入力ピン・インスタンス２０６が作成され、そのあとに出力ピン・インスタンス２０８が続いて接続が完結する。
【０１３６】
ステップ１９７で、サード・パーティ・制御エージェント１７０は、フィルタ・グラフによるストリーム化データ処理に備えて各接続ピン・インスタンスを停止状態から取得状態へ遷移させる。それぞれのフィルタのデバイス・オブジェクトの各々でスタック深さパラメータを正しく設定するためには、状態遷移は「最も深い」または最後の接続ピン・インスタンス（例えば、処理のためのデータを受け取る最後の入力ピン・インスタンス）から始めて、最初の接続ピン・インスタンス（例えば、データをグラフに送り込む最初の出力ピン・インスタンス）に到達するまで相互接続カーネル・モード・フィルタのチェインを順次に「さかのぼる」ように行う必要がある。最初のフィルタまたはブリッジはＩＲＰを作成し、スタック・ロケーションはＩＲＰがグラフ内の各カーネル・モード・フィルタに効率よく連続して受け渡されるように十分に割当てられる。
【０１３７】
最後に、サード・パーティ・制御エージェント１７０はストリーム読取りと書込みを出し、ステップ１９８でデータを処理してからステップ２００で終了する。
【０１３８】
前述したように、出力ピン・インスタンスの各作成には、そこに接続された入力ピン・インスタンスを表すファイル・オブジェクトのハンドルが必要である。
このファイル・オブジェクト参照は、出力ピン・インスタンスの作成ハンドラが入力ピン・インスタンスに対応するデバイス・オブジェクトへの参照を、現在または将来のアクセスのためにセーブしておくことができるようにする。
【０１３９】
もっと具体的に説明すると、これにより、入力ピン・インスタンスを管理するデバイス・オブジェクトのスタック深さパラメータは、停止状態から取得または他の状態へ状態遷移するとき出力ピン・インスタンスのドライバによってアクセスすることが可能になる。入力ピン・インスタンスに関連するスタック深さパラメータの値はアクセスされ、増加され、出力ピン・インスタンスに対応するデバイス・オブジェクトのスタック深さパラメータの中にセーブされる。
【０１４０】
スタック深さパラメータは、共用ＩＲＰスタック構造のどこに特定フィルタ用のスタック・フレーム情報が置かれているかを判断するために使用されるが、これは各フィルタごとに異なっている。フィルタをこのように相互接続し、状態遷移を正しいシーケンスで行うと、通信をユーザ・モードにしなくても、カーネル・モードの相互接続フィルタのチェインを下るように単一ＩＲＰを受け渡してくことができる。
【０１４１】
以上の説明から理解されるように、同一の接続ピン・ファクトリを基礎にした複数のインスタンスをもつことが可能である。例えば、オーディオ・ミキシング・フィルタは複数のピン・インスタンスをミックスして単一の出力ピン・インスタンスにしてから処理することができる。各入力インスタンスは同一タイプであり、フィルタは１つのタイプの入力ピンだけをサポートすることができる。このような構成の別の例として、複数の入力を１つの出力にする例がある。
【０１４２】
逆のことを行うことも可能である。つまり、スプリッタ・フィルタは単一入力接続ピン・インスタンスをもち、複数の出力ピン・インスタンスを提供することによりデータ・ストリームを倍にすることが可能である。この分野の精通者ならば理解されるように、上述してきた接続メカニズムから実際の実装とその要求条件に応じて種々態様に変形し、種々態様に組み合わせることが可能である。
【０１４３】
ドライバ開発者が独立に実装できる共通メカニズム（例えば、プロパティ集合、メソッド集合、およびイベント集合）を、すべてのコンプライアント・フィルタにサポートさせることによって均一性と標準化が達成されているので、サード・パーティ・制御エージェントは異種ソフトウェア・プロバイダから提供されるコンプライアント・フィルタを都合よく接続することができる。さらに、接続ピン・ファクトリの観点から見た機能の多くはある状況では必要であっても、別の状況では必要でない場合がある。必要とされる接続ピン・インスタンスの決定は異なるフィルタ間の相互接続を実際に行うサード・パーティ制御エージェントによって最初に行われる。
【０１４４】
次に、図１４を参照して説明すると、図は複数の処理コンポーネント間で使用されるときの、バッファ・アロケータ・メカニズムのオペレーションを示したものである。図には、特定の処理コンポーネントに関連するバッファ間のデータ・フロー（つまり、バッファ・フレーム間の実際のデータ転送）も示されている。
コントロールは各処理コンポーネントに渡されるが、データは必要時にだけ転送され、一部の処理コンポーネントはデータ操作を実行し、データを既存バッファ・フレームに戻すようにしている。言い換えれば、データは新しいバッファに転送されることなく同じロケーションで処理されるので、「同所(in place)」で処理されると呼ばれている。
【０１４５】
シンク処理コンポーネント２１０はバッファ・アロケータ・メカニズム２１２（四角で表されている）をその機能の一部としてもっている。バッファ・アロケータ・メカニズム２１２は、サウンドまたはビデオ処理カード上のオンボード・メモリなどの特定のメモリにデータが置かれることを保証する必要のある処理コンポーネントや、前のバッファがバイト位置合わせ、フレーム・サイズなどの許容されない特性をもっているような処理コンポーネントにだけ存在している。さらに、バッファ・メモリのフレームを割当てるとき使用されるバッファ・アロケータ・メカニズム２１２への参照は円で示され、すべての処理コンポーネントはそのような参照をもっている。なお、ソース処理コンポーネント２１４は矢印２１８で示すようにシンク処理コンポーネント２１０のバッファ・アロケータ・メカニズム２１２を参照するバッファ・アロケータ参照２１６をもっている。さらに、転送処理コンポーネント２２０はヌル（空白）のバッファ・アロケータ参照２２２をもち、シンク処理コンポーネント２１０も空の円２２３で示すようにヌルのバッファ・アロケータ参照をもっている。
【０１４６】
この単純な処理例では、ソース処理コンポーネント２１４はシンク処理コンポーネント２１０のバッファ・アロケータ・メカニズム２１２を使用してバッファ・フレーム２２４ａを割当て、バッファ・アロケータ参照２１６を使用してアクセスされる。割当てられたフレーム２２４ａには、矢印２２６で示すようにソース処理コンポーネント２１４によってデータが満たされる。なお、ソース処理コンポーネント２１４はある種のデータ操作または変換を行ってから、新たに割当てられたフレーム２２４ａにデータを書き込むことができる。
【０１４７】
この時点で、ソース処理コンポーネント２１４は処理を終えており、処理のコントロールを矢印２２８で示すように変換処理コンポーネント２２０に引き渡す。バッファ・アロケータ参照２２２の参照がヌル値をもっており、バッファ・アロケータ・メカニズムが指示されていないので、変換処理コンポーネント２２０は、バッファの割当ても、データを一方のバッファから他方のバッファへ転送することも行わない。従って、変換処理コンポーネント２２０は矢印２３０で示すように、割当てられたバッファ・フレーム２２４ｂで「同所」のデータ変換を行う。
【０１４８】
データは新しいバッファ・フレームに転送されていないので、バッファ・フレーム２２４ａ、フレーム２２４ｂ、およびフレーム２２４ｃは同じフレームであり、異なる処理コンポーネントへ連続して渡されるだけである。矢印２３１は割当てられたフレームがソース処理コンポーネント２１４と変換処理コンポーネント２２０の間で受け渡されることを示している。
【０１４９】
最後に、変換処理コンポーネント２２０は処理のコントロールを、矢印２３２で示すようにシンク処理コンポーネント２１０に引き渡す。なお、処理コントロールと一緒に、同じフレームがフレーム２２４ｂと２２４ｃの間の矢印２３４で示すように受け渡されて処理される。この場合も、図に示すように、フレーム２２４ａ、フレーム２２４ｂ、およびフレーム２２４ｃはいずれもソース処理コンポーネント２１４によって最初に割当てられた同じフレームであり、別々に示されているのは説明の便宜上である。
【０１５０】
シンク処理コンポーネント２１０はデータの処理を終えると、矢印２３６で示すようにバッファ内の割当て済みフレーム２２４ｃを解放する。シンク処理コンポーネント２１０は最早バッファを使用していないので、矢印２３６は内側に向かってシンク処理コンポーネント２１０を指しており、このフレームは割当て解除することも再使用することも可能である。
【０１５１】
図１５は、バッファ・アロケータ・メカニズムが上述してきた相互接続カーネル・モード・バッファ方式でどのように論理的に実装されるかを示している。図１４と図１５は共に同じフィルタ・グラフ・トポロジを示し、バッファ・アロケータ・メカニズムのオペレーションを理解しやすくするために使用されている。
関係ドライバとその部分はそれぞれ、ユーザ・モード・クライアントがドライバを制御することを可能にするアクセス・ポイントをもち、これらはファイル・オブジェクトで表されている。相互通信はＩＲＰを使用して行われる（ＩＲＰがカーネル・モード・ドライバによって作成されたか、ユーザ・モード入出力オペレーションに応答してＮＴエグゼクティブによって作成されたかとは無関係である）。
【０１５２】
ソース処理コンポーネント２３８のインスタンス（ファイル・オブジェクトで表されている）は出力ピン・インスタンス２４０（これもファイル・オブジェクトで表されている）が関連づけられており、これは別のフィルタ・インスタンスへの接続のソースとなっている。変換フィルタ２４４の「子」である入力ピン・インスタンス２４２は詳しく前述したように、出力ピン・インスタンス２４０への参照をもつように作成されている。同様に、入力ピン・インスタンス２４８をもつシンク・フィルタ２４６は出力ピン・インスタンス２５０に接続され、これは変換フィルタ２４４と関係づけられている。
【０１５３】
相互接続されたカーネル・モード・ソフトウェア・ドライバのシステムでは、バッファ・アロケータ・メカニズムは入力ピン・インスタンスと関係づけられ、入力ピン・インスタンス上に作成または形成されると言われている。さらに、出力ピン・インスタンスは必要ならば、バッファ・アロケータ・メカニズムへの参照を論理的にもち、出力ピン・インスタンスをもつフィルタはこの参照を利用してバッファ・フレームの割当てと新しいフレームへのデータ転送を行ってから、コントロールを別の処理コンポーネントへ引き渡す。すでに説明したように、ヌル参照は、新しいフレームへのデータ転送が必要でないこと、および、処理を既存フレームで行うことができることを示している（つまり、処理の後、データは同じバッファ・フレームに戻される）。バッファ・アロケータ参照が存在するかどうかは、フィルタ・グラフを作成したサード・パーティ制御エージェントの初期交渉によって判断される。
【０１５４】
入力ピン・インスタンス２４８上に形成されたバッファ・アロケータ・メカニズムはファイル・オブジェクトで表されているが、破線２５４は、出力ピン・インスタンス２４０がバッファ・アロケータ２５２を表すファイル・オブジェクトへの参照（例えば、ポインタまたはハンドル）をもっていることを示している。
図１５に示す例では、メモリのフレームはシステム・メモリ２５６から割当てられている。
【０１５５】
フィルタは種々の方法で相互接続できるので、バッファ・アロケータは、用意されている場合であっても、必要でないことがある。バッファ・アロケータのインスタンスを表すファイル・オブジェクトが作成されるのは、フィルタを相互接続するサード・パーティ制御エージェントが必要であると判断した時だけである。このようにすると、フィルタはさまざまな構成で柔軟に接続でき、かつ、最適なデータ転送特性はそのまま保持される。さらに、デフォルトのシステム・バッファ・アロケータを用意すると、ドライバ開発者の開発作業をさらに削減することができる。
【０１５６】
サード・パーティ・制御エージェントは、架空上のモデルを構築する一部として接続ピンに必要なバッファ要件についても照会してから、実際のフィルタ接続を行う。いくつかの実装では、ピンのインスタンス生成前に照会を行うことが可能になっているが、本実施の形態では、必要なバッファ要件を確かめるためには、その前に実際の接続ピン・インスタンスを作成しておくことが要求される。さらに、本明細書に開示されている実施の形態では、照会は前述した集合メカニズムの使用を通して行われる。
【０１５７】
サード・パーティ・クライアントまたはサード・パーティ・制御エージェントはカーネル・モード・フィルタの相互接続を完成してフィルタ・グラフを作成したとき、次に、入力ピン・インスタンス（またはシンク・ピン・インスタンス）のハンドルを使用してアロケータ要件の交渉を開始する。規定により、入力ピン・インスタンスは必要なバッファ割当て量を定義し、バッファ割当てメカニズムを提供するのに対し、出力ピン・インスタンスは入力ピン・インスタンスに関連する適切なバッファ割当てメカニズムへの参照をもっている。この分野の当業者ならば理解されるように、他の規定を使用すると、バッファ割当ての役割を入力ピン・インスタンスと出力ピン・インスタンスの間で逆にするといったように、同じ結果を効果的に達成することができる。
【０１５８】
バッファ割当ての要件は、すべてのコンプライアント・フィルタによってサポートされる特定のプロパティ集合メカニズムを使用して確かめられる。理解されるように、「バッファ・アロケータ」のプロパティ集合は、他の集合と同じようにさまざまな方法で構成することが可能である。例えば、プロパティ集合は単一のプロパティをもつことが可能であり、その場合、そのプロパティはセグメント化された情報をもつデータ構造である。あるいは、プロパティ集合は複数のプロパティをもつことも可能であり、その場合、１つ１つは異なるフレーミング要件エレメント用となっている。データ構造からなる単一プロパティは、すべてのフレーミング要件情報を取り出すためにサード・パーティ・制御エージェントが必要とするプロパティ集合照会が少なくなるので、ある状況によってはより効率的である。さらに、単一データ構造は要件情報を照会するためだけでなく、実際のバッファ・アロケータの作成時にパラメータを指定するためにも使用できる。
【０１５９】
以下の表はデータ構造に、または個別的プロパティとして組み入れることができるフレーミング要件エレメントの非排他的リストを示している。また、これらの表には、このようなエレメントが実施の形態でどのような使い方がされるかの解説も含まれている。
【０１６０】
【表７】

【０１６１】
【表８】

【０１６２】
【表９】

【０１６３】
この分野の当業者ならば理解されるように、組み入れることができる関係フレーミング・プロパティはほかにもある。さらに、ここで説明しているバッファ割当てメカニズムは、表３に指定されているものより多いバッファ・フレーム・エレメントが組み込まれているか、そのサブセットが実装されているかに関係なく、ほぼ同じように機能する。
【０１６４】
フィルタ・グラフ要件がサード・パーティ制御エージェントによって判断されると、次に、適切なカーネル・モード・バッファ・アロケータを適切な入力ピン・インスタンス上に作成することができる。クライアントは適切な接続ピン・インスタンスのハンドルを使用し、バッファ・アロケータの適切な作成パラメータを指定することによってバッファ・アロケータ・インスタンスを作成する。このようにして得られた、バッファ・アロケータを表すファイル・オブジェクトは接続ピン・インスタンスの子となり、そのファイル・オブジェクトとフィルタ自体のインスタンスを表すファイル・オブジェクトからのコンテキスト情報を使用してそれを正しく作成する。
【０１６５】
言い換えれば、接続ピン・インスタンスの作成をバリデーションし、メッセージを特定の接続ピン・インスタンスの適切なハンドラへ転送するための、前述したものと同じメカニズムはバッファ・アロケータのインスタンスの作成にも同じように適用される。この場合も、NtCreateFileコールはサード・パーティ制御・エージェントが使用できるＡＰＩの一部としてハイレベル関数コールの中でラップされることになる。
【０１６６】
バッファ・アロケータ・インスタンスはここで説明している実施の形態では、作成されるとすれば、入力ピン・インスタンスだけで作成される。
【０１６７】
バッファ・アロケータ・インスタンスのハンドルが適切なＡＰＩコールを通して出力ピン・インスタンスのハンドルに対して指定されていなければ、フィルタは、ストリーム入出力コントロールを通して渡されたストリーム・セグメントがフィルタの要件に合致しているものと想定できるので、データを同所で自由に変更することができる。
【０１６８】
システムに用意されているデフォルト・アロケータをフィルタ開発者によって使用すると、入力接続ピン・インスタンスにバッファ割当て機能をもたせる作業が単純化される。このデフォルト・アロケータはデータをシステム・メモリから転送することができるデバイス・ドライバのためにシステム・メモリ・バッファ・フレーム割当てを行うが、特定のメモリ割当てプロパティを必要とする。デフォルト・バッファ・アロケータを使用すると、フィルタ開発者はバッファ割当てを行うコードを実際に準備する作業から解放される。しかし、その場合でも、フィルタは適切なプロパティ集合をサポートすることによって必要バッファ割当て量要求をサポートするように書かれることになる。
【０１６９】
デフォルト・アロケータを使用するためには、フィルタ設計者は、（１）必要バッファ割当て要件要求に応えるコードを準備し、（２）デフォルト・アロケータ作成ハンドラ参照を、デフォルト・アロケータが関係する特定接続ピン・インスタンスのバリデーション・テーブルに入れる。言い換えれば、アロケータ・タイプ・メカニズムの作成要求がフィルタを通して渡されると、特定のＧＵＩＤストリングはバリデーション・テーブルで突き合わされ、デフォルト・アロケータ作成ハンドラへのアクセスができるようにする。
【０１７０】
デフォルト・バッファ・アロケータはシステム・メモリを使用し、作成要求の一部として渡されたバッファ・アロケータ・フレーミング・プロパティに従って動作する。この種のデフォルト・アロケータはその特定機能と相互接続順序に応じて、種々の変換フィルタで使用される可能性がある。
【０１７１】
オンボード・メモリまたは他のデバイスに依存する記憶方式のためのバッファ・アロケータを要求するフィルタは、バッファ・アロケータ・プロパティ集合とメソッド集合をサポートすることで専用のバッファ・アロケータを用意することができる。フィルタ専用アロケータの場合、フィルタは機能全体を実装するプログラム・コードを準備することに責任を有している。しかし、バッファ・アロケータのオペレーションは、デフォルトであるか、フィルタ専用であるかに関係なく、どのバッファ・アロケータの場合も同じであるので、サード・パーティ・制御エージェントはフィルタとバッファ・アロケータを正しく相互接続することができる。
【０１７２】
バッファ・アロケータを表すファイル・オブジェクトは、正常に作成されたときは、データ構造を指すポインタをファイル・コンテキスト・エリアに置いている。このデータ構造には、ＩＲＰを種々のＩＲＰコード（例えば、作成、入出力コントロールなど）に基づいて指定のハンドラへ送るためのディスパッチ・テーブルが、バッファ・アロケータの状態を保持するための他のデータ・エリアと構造と共に収められている。トラッキングできる実装依存情報のいくつかを挙げると、バッファ・アロケータが関係する接続ピン・インスタンスのファイル・オブジェクトへの参照、割当てフレーミング要件データ構造への参照、イベントを待っているクライアントのイベント・キュー、未処理になっている割当て要求（例えば、ＩＲＰによって受信されたもの）のキューなどがある。
【０１７３】
ここで開示されている実施の形態のバッファ割当てメカニズムが利用できるインタフェース、つまり、通信方法は２つある。まず、すべてのアロケータはユーザ・モード・クライアントと正しく通信するためにはＩＲＰベースのインタフェースを提供しなければならない。オプションとして、割当てプール・タイプがオペレーティング・システムのディスッパチ・レベル（サービスの限定されたサブセットが利用できるが、低優先度のタスクがそのプロセッサでブロック・アウトされるような高さの優先度レベル）でサービスを受けることができる場合は、関数テーブル・インタフェースがサポートされるので、相互接続されたフィルタは直接関数コールを使用して（ＤＰＣ処理時に）パフォーマンスを向上することができる。これにより、ＩＲＰを入出力マネージャを通して受け渡すという余分のオーバヘッドを発生することなく、あるいは実行スレッドをスケジュールしてコンテキスト切替えを待つことなく、イベント通知を相互接続されたフィルタ間で伝達することができる。
【０１７４】
ＩＲＰベースのインタフェースはＩＲＰを次のように連続的に処理する。割当て要求が渡されると、バッファ・アロケータはその要求を完了し、割当てられたバッファ・フレームを指すポインタを戻し、すべてのフレームが割当てられていれば、アロケータはＩＲＰに保留(pending) のマークを付け、ＩＲＰをアロケータの要求キューに追加し、ほぼＦＩＦＯ順に処理される。最後に、バッファ・アロケータは保留中というステータスをコール側に戻す。
【０１７５】
バッファ・フレームがアロケータに利用可能になったとき、アロケータはＩＲＰベースのインタフェースの要求キューに置かれている最初の要求を完了することを試みる。以前にサービスを受けることができなかったＩＲＰはこの要求キューに置かれ、処理のために新たに解放されたフレームを待つことになる。これとは逆に、要求キューで待たされている作業がなければ、そのフレームは空きリストに戻される。
【０１７６】
直接関数コール・テーブルを使用するディスパッチ・レベル・インタフェースは次のように動作する。割当て要求が関数コール（これはＤＰＣ時に行うことができる）によって渡されると、アロケータは使用可能なフレームがあれば、そのフレームを指すポインタを戻し、さもなければ、ヌル（空白）を直ちに戻す。この場合、カーネル・モード・リクエスタは空きフレームがあることを知らせる空きイベント通知を待つことができる。この通知を受けると、カーネル・モード・リクエスタは割当て要求を再度試みる。
【０１７７】
なお、ディスパッチ・レベル・インタフェースとＩＲＰベースのインタフェースのどちらもが使用可能な空きフレームを奪い合うことが起こり得る。また、完了待ちに置かれている割当て要求ＩＲＰが要求キューに残っていれば、アロケータは、コール側がフレームを解放したとき現ＩＲＱＬが受動レベルになければ、ワーカ・アイテム(worker item) をスケジュールしなければならないが、これは、直接コール・インタフェースを使用することはＤＰＣレベルにある可能性を意味するからである。基本的には、ＩＲＰの待ち行列はワーカ・アイテムが実行されるまでは空きフレームを探し出さない。
【０１７８】
さらに、ここで説明しているバッファ・アロケータ・メカニズムはＭＤＬ（memory descriptor list：メモリ記述子リスト）と一緒に使用するのに適しているので、バッファ間の転送数をさらに削減することができる。このような実装によると、ＮＴオペレーティング・システムのシステム・メモリ機能とのシームレスな相互作用が向上することになる。
【０１７９】
次に、図１６を参照して説明すると、同図には前述したバッファ割当てメカニズムを利用する図１１と図１２の相互接続フィルタ・システムが示されている。サード・パーティ・制御エージェント１７０はフィルタ間の相互接続を行ったあと、必要バッファ量について各入力ピン・インスタンスに照会する。図に示すように、サウンド・レンダリング・フィルタ１７８はバッファ・フレームをサウンド・カード・メモリ２５８から割当てる必要があり、デコンプレッサ・フィルタ１７４はデータをディスク・ドライブ２６２から直接に受け取ることができるシステム・メモリ２６０からメモリを割当てることになる。
【０１８０】
サード・パーティ・制御エージェント１７０はファイル・オブジェクトで表され、入力ピン・インスタンス１８８上に形成されるバッファ・アロケータ２６４を作成する。バッファ・アロケータ２６４はバッファ・フレームをサウンド・カード・メモリ２５８から割当て、バッファ・アロケータ２６４への参照は破線２６６で示された出力ピン・インスタンス２０４に設定される。この参照はバッファ・アロケータ２６４を表すファイル・オブジェクトへのハンドルとなり、必要時にバッファ・フレームを割当てるためにデコンプレッサ・フィルタ１７４によって使用されてからデータが新しいバッファに転送される。
【０１８１】
同じように、バッファ・アロケータ２６８もファイル・オブジェクトによって表され、入力ピン・インスタンス２０６上に作成される。このバッファ・アロケータ２６８はシステム・メモリ２６０の割当てを管理する。サード・パーティ・制御エージェント１７０はバッファ・アロケータ２６８を作成したあと、破線２７０で示すようにその参照を出力ピン・インスタンスにストアする。この場合も、バッファ・アロケータ２６８はシステム・メモリ２６０間のバッファ・フレームの割当てを担当し、データがディスク・ドライブ２６２からそこに転送できるようにする。
【０１８２】
サード・パーティ・制御エージェント１７０は出力ピン・インスタンス１９２のバッファ・アロケータ参照の値にヌル（空白）を入れ、同所変換が行われることを示し、効果フィルタ１７６はサウンド・カード・メモリ２５８内の既存バッファからデータを読み取り、必要とされる変換または効果を適用したあとでデータをサウンド・カード・メモリ２５８に戻す。逆に、サード・パーティ・制御エージェントがバッファ・アロケータ参照を設定していなければ、値が空白であり、同所変換が行われると想定される。
【０１８３】
次に、図１７のフローチャートと図１６のロジック図を参照して、バッファ・アロケータのオペレーションについて説明する。このプロセスは相互接続が行われたあとで実行され、ストリーム読取りと書込みはサード・パーティ・制御エージェント１７０からリーダ・フィルタ１７２に渡される。
【０１８４】
最初に、リーダ・フィルタ１７２はステップ２７２で、デコンプレッサ・フィルタ１７４のバッファ・アロケータ２６８を使用してシステム・メモリにフレームを割当てる。リーダ・フィルタ１７２の出力ピン・インスタンス２０８はライン２７０で示すように、バッファ・アロケータ２６８を表すファイル・オブジェクトへのハンドルを受け取るので、直接にアクセスしてバッファ・アロケータ２６８を制御することができる。
【０１８５】
リーダ・フィルタ１７２はシステム・メモリ２６０内の実際のバッファ・フレームへのアクセス権を得ると、ステップ２７６で矢印２７４で示すように、ディスク・ドライブ２６２からのデータをフレームに入れる。このことから理解されるように、リーダ・フィルタ１７２はデータをシステム・メモリ２６０に持ち込むとき、変換または他の操作をデータに対して行うことができる。
【０１８６】
次に、リーダ・フィルタ１７２はステップ２７８でデコンプレッサ・フィルタ１７４へのストリーム書込みを開始する。このストリーム書込みはＩＲＰによってＮＴ入出力マネージャに渡される。ステップ２８０で、デコンプレッサ・フィルタ１７４はバッファ・アロケータ２６４を使用してサウンド・カード・メモリ２５８のフレームを割当てる。デコンプレッサ・フィルタ１７４がバッファ・アロケータ２６４を知っているのは、そこへのハンドルが出力ピン・インスタンス２０４に対してストアされていたためである。
【０１８７】
デコンプレッサ・フィルタ１７４はデータを伸張し、矢印２８４で示すようにそのデータを、サウンド・カード・メモリ２５８に以前に割当てられたフレームに転送する。なお、データを伸張するとき、サウンド・カード・メモリから割当てられたフレームがシステム・メモリに存在するよりも多くなっている場合がある。この余剰バッファ・フレーム比が必要になるのは、データの伸張効果を受け入れるためである。
【０１８８】
重要なことは、データを一方のバッファから他方のバッファへ転送するとき、転送されるデータ量が１：１の対応関係でない場合があることである。言い換えれば、受信側バッファが必要とするスペース（またはフレーム数）は、バッファ転送間でどのようなフィルタリングまたは変換が行われるかに応じて、多くなる場合と少なくなる場合とがある。
【０１８９】
デコンプレッサ・フィルタ１７４は特定フレームの伸張を終えると、ＮＴ入出力マネージャの機能を使用してストリーム書込みを効果フィルタ１７６に渡す。
効果フィルタ１７６はステップ２８８でストリーム書込みＩＲＰを受け取り、既存サウンド・カード・メモリ２５８でデータを同所処理する。この効果処理はデータを１：１で置換するのと同じであるので、必要なバッファ・メモリは多くなることも、少なくなることもない。
【０１９０】
効果フィルタ１７６がデータの同所処理を終えると、ストリーム書込みＩＲＰはステップ２９０でサウンド・レンダリング・フィルタに渡される。この場合も、ストリーム書込みＩＲＰをサウンド・レンダリング・フィルタ１７８に転送させるメカニズムは効果フィルタ１７６によってコールされたＮＴ入出力マネージャの機能である。
【０１９１】
最後に、サウンド・レンダリング・フィルタ１７８はステップ２９２でストリーム書込みＩＲＰを受け取り、サウンド・カード・メモリ２５８に存在するサウンド・データの実際のレンダリングを形成するようにサウンド・カード・ハードウェアを制御する。この時点で、以前に割当てられていたサウンド・カード・バッファ・フレームは書込み要求を満たすために再使用することも、未処理の要求がなければ解放することもできる。バッファ・フレームが使用可能であることはデコンプレッサ・フィルタ１７４に知らされるので、待ちに置かれているストリーム書込みを使用してデータを処理し、割当てが解放されたバッファ・フレームに入れることができる。同様に、システム・メモリ２６０のバッファ・フレームは再使用されるか、解放される。
【０１９２】
次に、図１８を参照して説明すると、図はシステムの概要を示す図であり、そこでは、リアルタイムで生成され、「ライブ」であると呼ばれる２つのデータ・ストリームをマスタ・クロック・メカニズムを使用して同期化することが可能になっている。オーディオ・レンダラ２９６は矢印３００で示すように、ライブ・オーディオ・ストリーム２９８を受信して処理する。オーディオ・レンダラ２９６がデータを処理するとき、オーディオ・レンダラ２９６がデータ・サンプルを適切な電子信号に変換して、この信号を矢印３０４で示すようにスピーカ３０２に送信すると、データはスピーカ３０２からサウンドとして知覚される。
【０１９３】
同様に、ビデオ・レンダラ３０６は矢印３１０で示すようにライブ・ビデオ・ストリーム３０８を受信して処理する。ビデオ・レンダラ３０６によって処理されると、データ・サンプルは適切なビデオ信号に変換され、矢印３１４で示すようにモニタ３１２に送られ、そこでデータ・サンプルはイメージとして知覚される。
【０１９４】
代表例として、ライブ・ビデオ・ストリーム３０８とライブ・オーディオ・ストリーム２９８は同時にレンダリング・コンポーネントに着信する。コヒーレントなプレゼンテーションを再現するために、スピーカ３０２とモニタ３１２でレンダリングされるときビデオをオーディオと整合させることは重要であるので、ライブ・ビデオ・ストリーム３０８とライブ・オーディオ・ストリーム２９８の処理は同期化されなければならない。
【０１９５】
これを行なうためには、一方のデータ・ストリームがマスタとなるように選択される。ここでは、説明の便宜上、ライブ・オーディオ・ストリーム２９８がマスタ・データ・ストリームとなるように任意的に選択されている。なお、ライブ・ビデオ・ストリーム３０８がマスタとして選択されることも、他のデータ・ストリームがマスタとして選択されることも可能であり、それを妨げるものはなにもない。さらに、フィルタ・グラフの外部にあるデータ・ストリームに基づく外部クロックを使用して、ライブ・オーディオ・ストリーム２９８とライブ・ビデオ・ストリーム３０８を共に同期化することが可能である。従って、図示のマスタ・クロック３１６では、実線でオーディオ・レンダラ２９６と結ばれ、破線３１８でビデオ・レンダラと結ばれているが、このことは、ビデオ・レンダラがオーディオ・ストリームをマスタとして使用しているマスタ・クロック３１６から同期化情報をなんらかの方法で受信することを示している。
【０１９６】
マスタ・クロック３１６は、オーディオ・レンダラ２９６での処理レートをオリジナル・オーディオ・ストリーム２９８のレートと整合するためにオーディオ・レンダラ２９６によって使用することも可能である。言い換えれば、ライブ・オーディオ・ストリーム２９８は、別のシステム上のディジタル化フィルタ／ディジタル化ハードウェアなどの別の処理コンポーネントによって処理されている。オーディオ・ストリームはディジタル化サンプルから構成されているので、これらのサンプルはオリジナル処理コンポーネントのハードウェアおよびオシレータに従うレートで作られている。オリジナル処理コンポーネントがライブ・オーディオ・ストリーム２９８を出力するときの、この発生レート(origination rate)はライブ・オーディオ・ストリーム２９８のインターバル情報の中に入っているか、そこから得られている。
【０１９７】
データ・ストリームに入っているサンプル情報には、いくつかの方法で時間インターバル情報を収めることができる。１つの方法は、各サンプルまたはサンプル・グループにタイムスタンプを関連づけることである。さらに、データのフォーマット自体にサンプル・レートを意味させることもできる。例えば、データ・フォーマットの定義によって、一定時間インターバル（例えば、ビデオ・サンプルでは１／３０秒単位、オーディオ・データでは１／２２，０５０秒単位）で各サンプルをとることができる。さらに、タイムスタンプがレンダリング処理ユニットでクロックと整合されるプレゼンテーション時間を示すようにすれば、特定のサンプルをいつレンダリングまたは「プレゼンテーション」するべきかを判断することができる。また、タイムスタンプは、タイムスタンプ間の相対的差から時間インターバル情報を知ることができる、ある種の他の時間値を示すこともできる。最後に、データ・フォーマットとタイムスタンプ情報をミックスして使用すると、処理される参照データ・ストリーム内の位置に基づいてタイムクロックを作成するときに必要になる時間インターバル情報を得ることができる。
【０１９８】
以上から理解されるように、時間またはデータ・ギャップに基づいて、データ・ストリームの中に「中断(discontinuities) 」をコーディングすることができる。時間的中断とは、レコーディングがある時刻に終了し、その後のある時刻に突然開始するときのように、ストリームが単純に別のプレゼンテーション時刻にジャンプすることである。データの中断とは、沈黙の周期をあるコードで表し、そのあとに沈黙の持続時間が続くといったように、ストリームがそのストリームの中により効率的にコーディングできる反復データの周期をもつことができる場所である。
【０１９９】
マスタ・クロック３１６から得られるある時間値はデータ・サンプルのストリームに入っている時間インターバル情報に基づいており、メディア時間と呼ばれている。メディア時間は、マスタ・ストリーム内の位置を表しているので位置時間であり、この場合、マスタ・ストリームはライブ・オーディオ・ストリーム２９８として選択されている。さらに、処理がオーディオ・レンダラ２９６で終了したとき、メディア時間もマスタ・クロック３１６で凍結される。データ・ストリーム内の中断はストリーム内のその「位置」まで処理され、基礎となるハードウェア・オシレータまたは他のソースを使用して時間の進みをトラッキングすることによって、中断にある間進み続ける。このようにすると、複数のデータ・ストリームを、時間またはデータの中断を有するデータ・ストリームと同期させることができる。
【０２００】
ビデオ・レンダラ３０６をマスタ・クロック３１６に入っているメディア時間と同期させ、マスタ・クロックの方をライブ・オーディオ・ストリーム２９８に入っている時間インターバル情報に基づかせると、メディア時間はライブ・オーディオ・ストリーム２９６がオーディオ・レンダラ２９６で処理される時だけ進む（「刻時(ticks) 」）ので、停止または休止状態を管理するためのオーバヘッドが不要になる。
【０２０１】
以上から理解されるように、ビデオ・ストリーム３０８も、同期化と同時にレート整合を行う必要がある。ビデオ・ストリーム３０８のレート整合はライブ・オーディオ・ストリーム２９８およびオーディオ・レンダラ２９６に関して以下で説明するのと同じ方法で行われる。当然のことであるが、ライブ・ビデオ・ストリーム３０８のレート整合はビデオ・レンダラ３０６のハードウェア・オシレータ（物理時間）に基づいている。
【０２０２】
マスタ・クロック３１６から得られるものとして、オーディオ・レンダラ２９６内の基礎となるハードウェアに基づく物理時間もある。物理時間は、オーディオ・レンダラ２９６がアクティブ状態でオーディオ・データを処理しているか、停止または休止状態にあるかに関係なく、進んでいくのが通常である。さらに、メディア時間（発生側ハードウェア処理レートを表す）および物理時間（オーディオ・レンダラ２９６での実際の処理レートを表す）の進みレートをサンプリングすると、レートが相対的に整合されるようにオーディオ・レンダラで調整を行ってライブ・オーディオ・データ２９８を処理することができる。
【０２０３】
レート整合は、ストリーム・データをローカル・ディスクや他の記憶デバイスから読み取るといったように、データ発生のレートがプロセッサの制御下に置かれているときは重要な問題とならないが、データを連続的に発生する「ライブ」データ・ストリームを処理し、発生レートがプロセッサの制御下に置かれていないときは重要な問題となる。ここで用いられている「ライブ」データまたはメディア・ストリームとは、処理コンポーネントの制御下に置かれていないレートで発生するストリームのことであり、完全にリアルタイムで処理されないと失われるようなストリームである。ライブ・データ・ストリームの例としては、次のようなものがあるが、これらに限定されるものではない。つまり、ストリームがローカルまたはネットワーク接続を介してリアルタイムで発生するようなリアルタイム・フィード、リアルタイム・フィードであるか、ネットワークを介して送られてきたストア済みデータであるかに関係なく、ストリームをネットワーク接続から受信することなどがある。いずれの場合も、ストリームはその受信と同時に処理されなければならない。
【０２０４】
ライブ・メディア・ストリームが発生させるデータが多すぎるため、オーディオ・レンダラ２９６が処理できないときは、オーディオ・レンダラ２９６は、バッファリング容量に限りがあるためデータ「あふれ(follding)」と呼ばれる状態が起こり、最終的にはデータを失うことになる。他方、ライブ・オーディオ・ストリーム２９８がオーディオ・レンダラ２９６よりも低レートでデータを発生する場合には、オーディオ・レンダラ２９６には、処理すべきデータがなくなるというデータ「枯渇(starvation)」状態が起こることになる。どちらの場合も、オーディオ・レンダラ２９６でのレンダリング・レートを、ライブ・オーディオ・ストリーム２９８内の時間インターバル情報で表されている発生レートに一致するように調整を行うと、ライブ・オーディオ・ストリーム２９８のレンダリングが高品質に行われるという利点がある。
【０２０５】
レート補正調整を行う１つの方法は、オーディオ・レンダラにデータ枯渇が起こらないようにデータ・サンプルを周期的に複製するか、あるいはオーディオ・レンダラがその能力を超えて出力するライブ・オーディオ・ストリーム２９８に追いつくようにサンプルを捨てることである。どちらの場合も、データ・サンプルの複製または破棄は、スピーカ３０２で知覚される影響量が最小になるようにストリーム処理時に間隔を置いて行うのが賢明である。
【０２０６】
マスタ・クロック３１６と直接に同期をとるのではなく、マスタ・クロック３１６に入っているメディア時間に一致するように別のクロックのタイムベースを変換するか、あるいはマスタ・クロック３１６のメディア時間に一致するように別のメディア・ストリーム内のプレゼンテーション時間情報を変換するようにすると便利である。この変換を行いやすくするために、マスタ・クロック３１６は２つの別個の時間値、つまり、メディア時間値と他のコンポーネントに共通の参照時間値とからなる相関メディア時間値を提供し、これをアトミック・オペレーションで行ってタイミング誤差の発生を低減化している。相関物理時間値も提供される。
【０２０７】
参照時間は、すべての処理コンポーネントが利用できるＰＣクロックまたはシステム上の他のクロック・メカニズムに基づいているのが代表的であるが、別のクロックを選択することも可能である。アトミック・オペレーションはネーティブ・システム機能を利用して、中断または干渉量を最小にして両方の値が取り出せるように実装する。相関時間（メディアまたは物理）はフィルタなどの別の処理コンポーネントが使用して、メディア時間と参照時間との相対的オフセットまたはデルタを判断し、発生誤差を最小にして必要な変換を行うことができる。これについては、以下で詳しく説明する。
【０２０８】
次に、図１９および図２０を参照して説明すると、上述したクロック・メカニズムは前述した相互接続フィルタ・システムと共に実装されている。図１９は、オーディオ・ストリームと同期がとられ、マスタ・クロック・メカニズムから同期化情報を受け取るライブ・ビデオ・ストリーム処理フィルタの集合を示している。図２０は、マスタ・クロック・メカニズムのマスタ時間参照を生成するために使用されるライブ・オーディオ・ストリームをレンダリングするための相互接続フィルタの集合を示している。
【０２０９】
まず、図１９に示すビデオ・ストリーム処理コンポーネントについて説明すると、ライブ・ビデオ・ストリーム３２０は矢印３２４で示すように、ビデオ・リーダ・フィルタ３２２によって受信される。ライブ・ビデオ・ストリーム３２０のソースとしては、コンピュータに置かれたオンボード・ディジタル化ハードウェア、コンピュータ・ネットワーク経由で受信されるディジタル・サンプルのパケットなどがある。ライブ・ビデオ・ストリーム３２０は実際のビデオ・イメージにレンダリングできるディジタル化サンプルから構成され、これらのサンプルは前述したように時間インターバル情報が関連づけられている。この場合も、ここで説明している相互接続フィルタ・システムによれば、ビデオ・リーダ・フィルタ３２２はファイル・オブジェクトで表されている。
【０２１０】
ビデオ・リーダ・フィルタ３２２は、ビデオ・デコンプレッサ・フィルタ３３０上の入力ピン・インスタンス３２８に接続された出力ピン・インスタンス３２６をもっている。ビデオ・デコンプレッサ・フィルタ３３０はライブ・ビデオ・データを圧縮フォーマットで受信し、そのデータをビデオ・レンダリング・ハードウェアに受け付けられるフォーマットに伸張する。ビデオ・データのフレームを処理すると、ビデオ・デコンプレッサ・フィルタはコントロールをビデオ・レンダラ・フィルタ３３２に渡す。ビデオ・レンダラ・フィルタ３３２とビデオ・デコンプレッサ・フィルタ３３０との接続は、それぞれ出力ピン・インスタンス３３４と入力ピン・インスタンス３３６によって行われる。
【０２１１】
入力ピン・インスタンス３３６は同期化のためのタイミング指示を、ボックス３３８と破線３４０で示すように、オーディオ・ストリーム処理コンポーネント内のマスタ・クロック・メカニズムから受信する（図１８参照）。この同期化タイミング情報を受信するには、さまざまな方法が可能である。まず、図１９と図２０に示すフィルタ・グラフ・トポロジを相互接続する制御エージェント３４２はマスタ・オーディオ・ストリーム内の特定の位置（つまり、時間）に基づいてクロック・メカニズム３４４にイベント通知を行わせることも、特定の時間インターバルを選択してインターバル・イベント通知を行うことも可能である。別の方法として、ビデオ・レンダラ・フィルタ３３２はクロック・メカニズム３４４に照会することも可能である（図２０参照）。クロック・メカニズム３４４はファイル・オブジェクトで表されているので、制御エージェント３４２はクロック・メカニズム３４４への該当する参照を入力ピン・インスタンス３３６またはビデオ・レンダラ・フィルタ３３２に対して行うことができるので、ビデオ・レンダラ・フィルタ３３２はクロック・メカニズムに照会して相関時間値を得て、必要ならば変換を行うことも、メディア時間値を得て処理が同期化されていることを確かめることもできる。
【０２１２】
最後に、ビデオ・レンダラ・フィルタ３３２はビデオ・ハードウェア３４６を制御し、データを矢印３４８で示すようにそこへ転送する。ビデオ・ハードウェア３４６はデータをレンダリングし、イメージをモニタ３５０から表示させるビデオ信号を生成する。
【０２１３】
次に、図２０を参照して、ライブ・オーディオ・ストリームの処理コンポーネントについて詳しく説明する。この場合も、同じ制御エージェント３４２は、必要な入力ピン・インスタンスおよび出力ピン・インスタンスと一緒にそれぞれのフィルタ・インスタンスを作成し、それぞれのフィルタ間の相互接続を行うが、カーネル・モード・フィルタ・グラフ・トポロジ全体を作成するのは制御エージェント３４２である。
【０２１４】
ライブ・オーディオ・ストリーム３５２は最初に、矢印３５６で示すようにオーディオ・リーダ・フィルタ３５４によってフィルタ・グラフ・トポロジに持ち込まれる。データはそれぞれの出力ピン・インスタンス３６０と入力ピン・インスタンス３６２を使用してオーディオ・リーダ・ファイルに接続されているオーディオ・デコンプレッサ・フィルタ３５８によって伸張される。この場合も、ここで説明している各フィルタと接続ピン・インスタンスはファイル・オブジェクトで表され、前述したように作成される。
【０２１５】
オーディオ・デコンプレッサ・フィルタ３５８は、出力ピン・インスタンス３６６と入力ピン・インスタンス３６８を通してオーディオ・レンダラ・フィルタ３６４に接続されている。入力ピン・インスタンス３６８と関連づけられているものとして、メディア時間、物理時間、および／または相関時間を提供またはその通知を他のエンティティへ送信するクロック・メカニズム３４４のインスタンス、特に、ボックス３７０と破線３７２で示すようにビデオ・レンダラ・フィルタ３３２（図１９参照）の入力ピン・インスタンス３３６がある。クロック・メカニズム３４４の実際の実装と利用可能性については、以下で詳しく説明する。このクロック・メカニズム３４４を使用すると、他のデータ・ストリームは、図２０に示すようにその処理を「マスタ」または「参照」オーディオ・ストリーム３５２の処理と同期化することができる。
【０２１６】
オーディオ・レンダラ・フィルタ３６４はオーディオ・ハードウェア３７４を制御し、制御情報とデータを矢印３７６で示すように引き渡す。オーディオ・ハードウェアは、オーディオ・レンダラ・フィルタ３６４の制御の下で、ディジタル化データ・サンプルをスピーカ３７８へ送信し、そこから知覚されるようにするリアルタイム電子信号にレンダリングする。
【０２１７】
相互接続カーネル・モード・フィルタを前述したように作成するとき、各フィルタ・インスタンスはシステムが利用できる「デバイス」から作成される。このようにすると、ビデオ・リーダ・フィルタ３２２とオーディオ・リーダ・フィルタ３５４は同じファイル・リーダ・デバイスの別々のインスタンスにすることができる。
【０２１８】
さらに、特定のフィルタは接続ピン・インスタンスを作成するために多数の接続ピン・ファクトリをサポートできるので、ビデオ・デコンプレッサ・フィルタ３３０とオーディオ・デコンプレッサは同じデコンプレッサ・デバイスのインスタンスにすることができる。制御エージェントがそれぞれのフィルタ・インスタンス上に接続ピン・インスタンスを作成するとき、フィルタを通して処理されるデータのタイプに応じて異なるピン・ファクトリが接続ピン・インスタンスを作成するときのテンプレートとして選択される。これは、ここで説明している相互接続カーネル・モード・フィルタ・システムが本来的に備えた柔軟性である。
【０２１９】
クロック・メカニズム３４４を形成するためには、制御エージェント３４２は、オーディオ・レンダラ・フィルタ３６４上の入力ピン・インスタンス３６８のように、接続ピン・インスタンスに照会してクロック・メカニズムが使用可能であるかどうかを判断するのが代表的である。他の実装では、制御エージェント３４２は接続ピン・インスタンス上にクロック・メカニズムを作成することを試みるだけで、クロック・メカニズムが使用可能かどうかを試行錯誤で判断できるようになっている。さらに、クロック・メカニズムはユーザ・モードで存在し、そのクロックまたは他のメカニズムのカーネル・モード・プロキシを通して通知などを、カーネル・モードのフィルタの入力ピン・インスタンスに送信することができる。
【０２２０】
実施の形態では、選択した規則により、タイミング・イベント通知とクロック・メカニズムは入力接続ピン・インスタンスと関連づけられて通常見つけられる。しかし、明らかなように、ファイル・オブジェクトで表されたどのエンティティも、イベント要求をＩＲＰを通して受け取ることも、前のＩＲＰ要求を通して直接プロシージャ・コール・テーブルを検索した後で直接プロシージャ・コールで受け取ることも可能である。
【０２２１】
デフォルトとして実装したクロック・メカニズムがシステムに用意されているので、これをソフトウェア・フィルタ開発者に提供または利用できるようにすると、余分のコードを開発しなくてもタイミング機能を得ることが可能である。どのクロック・メカニズム（デフォルト版またはカスタムとして供給）の形成も、作成要求の中でＧＵＩＤストリング値を指定することによって行われるが、このストリング値は接続ピン・インスタンス・バリデーション・テーブルで使用されて、クロック・メカニズムを接続ピン・インスタンス上に作成するための正しい作成ハンドラをアクセスできるようにする。ファイル・オブジェクトの作成、バリデーション、およびＩＲＰの指定のプロセスは図３〜図８を参照して詳しく前述した通りである。接続ピン・インスタンスを作成するのと同じように、クロック・メカニズム作成要求は正しくパス選択し、正当性を調べることができる。
【０２２２】
システムに用意されているデフォルト・クロックを使用するためには、ドライバ開発者は作成し、システムに用意している作成ハンドラの中からデフォルト・クロック作成メソッドをコールする。この作成ハンドラは接続ピン・インスタンスを表すファイル・オブジェクトのコンテキスト・エリアから前述したようにアクセスされる。従って、ドライバ開発者はドライバ専用クロック・メカニズムを実装し、適切なドライバ専用作成ハンドラはバリデーション・テーブルに置かれることになる。作成ハンドラ開発の複雑性はクロック機能をコーディングし、実装するのではなく、デフォルト・クロック作成メソッドをコールすることによって低減化される。
【０２２３】
クロック・メカニズムをこれまでに説明してきた相互接続フィルタ・システムに従って作成する場合は、そのクロック・メカニズムは特定のプロパティ集合とイベント集合をサポートしていなければならない。当然のことながら、デフォルト・クロック・メカニズムは特定の集合をサポートしているが、フィルタ専用クロック・メカニズムの場合は、フィルタ開発者はクロック・メカニズムのプロパティ集合とイベント集合を実装するコードを書いて、用意しておく必要がある。
このようにすると、クロック・メカニズムへのハンドルをもつ制御エージェントは特定の集合がサポートされるかどうかを照会し、クロック・メカニズムの操作方法を知ることができる。以下に示す表４は、クロック・メカニズムのプロパティ集合に含めることができる、いくつかのプロパティを示したものである。
【０２２４】
【表１０】

【０２２５】
【表１１】

【０２２６】
【表１２】

【０２２７】
【表１３】

【０２２８】
この分野の当業者ならば理解されるように、表４にリストされている以外のプロパティまたは表４にリストされているプロパティのサブセットを使用して、ここで説明している相互接続フィルタ・システムに準拠する機能をもつクロック・メカニズム・プロパティ集合を作ることも可能である。さらに、プロパティ集合メカニズムには柔軟性があるので、独自のタイミング機能をもつフィルタ開発者は独自のＧＵＩＤをもつ別のプロパティ集合を追加することによって「必須」のプロパティ集合を拡張すると、より拡張した機能を得ることができる。集合メカニズムには、フィルタ開発者が最小限の機能量を実施して、フィルタをシステム・アーキテクチャに準拠させることができるという柔軟性があると同時に、フィルタ開発者がカストマイズして追加の機能を追加できるという無限性がある。
【０２２９】
プロパティ集合によると、カーネル・モード・フィルタなどの他の処理コンポーネントは関係する時間プロパティについて照会することができるが、クロック・メカニズムはイベント集合もサポートするので、通知をイベント通知ＩＲＰを通して関係のクロック・メカニズム・クライアントに直接に送信することができる。ファイル・オブジェクトのハンドルはイベントを割込み可能にする一部としてクロック・メカニズムに「登録」しておくと、クロック・メカニズムはイベント通知をどこに送信すべきかを知ることができる。オプションとして、直接関数コール・ハンドルはＤＰＣ処理がカーネル・モード・エンティティ間で行えるように使用すると、パフォーマンスを向上することができる。
【０２３０】
以下に示す表５は、コンプライアント・ドライバにサポートさせることができるイベント集合を構成する、起こり得る通知イベントのいくつかを示したものである。サード・パーティ制御エージェントはイベントを受け取るエンティティを、特定のフィルタ・グラフ・トポロジに基づいて相互接続または登録することができる。
【０２３１】
【表１４】

【０２３２】
当業者ならば理解されるように、他のタイミング関係イベントをクロック・メカニズムに対して作成することが可能である。例えば、イベントはクロック・メカニズムがサポートできる異種の時間別（つまり、メディア時間または物理時間）に分類することが可能である。さらに、インターバル・イベントと位置イベント、さらには状態変化に基づく他のイベントのエレメントを組み合わせると、「ハイブリッド」イベントにすることも可能である。
【０２３３】
次に、図２１（Ａ）を参照して説明すると、同図は、１つまたは２つ以上の「スレーブ」処理コンポーネントまたはフィルタを、「マスタ」メディア処理時間に基づいて同期化する方法を示している。ステップ３８０からスタートして、スレーブ処理コンポーネントまたはフィルタはステップ３８２でマスタ・クロック・メディア時間値を受信する。この受信は、スレーブ・フィルタまたはコンポーネントがマスタ・クロック・メカニズムに照会してメディア時間値を得ることによって行われるが、マスタ・クロック・メカニズムが通知をスレーブ処理コンポーネントまたはフィルタに送信することも可能である。図２１（Ａ）のフローチャートに示されている方法を図１９と図２０に示すフィルタ・グラフ・トポロジに適用すると、クロック・メカニズムは、ビデオ・レンダラ・フィルタ３３２の入力ピン・インスタンス３３６とスレーブ処理コンポーネントとして通信するファイル・オブジェクトによって表される。
【０２３４】
なお、使用されるメディア時間値はマスタ・データ・ストリームの処理によって左右される。メディア・レンダリングが休止または停止されると、時間は同期をとる目的のための停止されることになる。
【０２３５】
スレーブ処理コンポーネントまたはフィルタはステップ３８４で、マスタ・クロック・メディア時間値をスレーブ・データ・ストリーム・メディア時間値と比較して、スレーブ・メディア処理がどれだけ進んでいたか、あるいは遅れていたかを判断する。なお、メディア時間は実際のデータ・サンプルのストリーム内の時間インターバル情報に基づいているので、位置時間として見ることができる。
言い換えれば、同期化とは、ストリーム内の同じ相対時間位置で２つのデータ・ストリームを処理することである。
【０２３６】
ステップ３８８で終了する前に、スレーブ処理コンポーネントまたはフィルタはステップ３８６でマスタ・メディア処理時間に一致するようにスレーブ・メディア処理を調整する。この調整としては、スレーブ・メディア・ストリーム処理を減速または加速すること、基礎となるハードウェア・プロセッサのレートを変更すること、などがある。
【０２３７】
メディア・ストリーム処理レートを減速することは、処理すべきサンプルを複製し、間欠的時間遅延を引き起こし、あるいは再サンプリングすることによって達成される。メディア・ストリーム処理を加速することは、処理すべきメディア・サンプルを省くか、再サンプリングすることによって達成される。この分野の当業者ならば理解されるように、変更が必要であると判断された後でメディア処理レートを調整する方法は多数存在する。
【０２３８】
以上から理解されるように、図１９と図２０に示すトポロジ例では、入力ピン・インスタンス３３６はビデオ・レンダラ・フィルタ３３２のタイミング通知を受信する。ビデオ・レンダラ・フィルタ３３２は必要とされる調整を処理に行って図１９のビデオ・ストリームの処理を図２０のオーディオ・ストリームの処理と同期させる。
【０２３９】
次に、図２１（Ｂ）のフローチャートを参照して、ライブまたはリアルタイム・オーディオ・ストリーム発生レートを処理コンポーネントまたはフィルタの処理レートとレート整合する処理ステップについて説明する。ステップ３９０でスタートした後、物理時間サンプルはステップ３９２で処理コンポーネントまたはフィルタで受信される。この場合も、これは、クロック・メカニズムに照会するか、あるいはタイミング・イベント通知を受信することによって行われる。図２０に示すように、最終的にはオーディオ・レンダラ・フィルタ３６４でレンダリングされるライブ・オーディオ・ストリーム３５２の処理では、関係する処理コンポーネントはイベント通知と制御情報が入力ピン・インスタンス３６８で受信されたときオーディオ・レンダラ・フィルタ３６４となる。また、クロック・メカニズム３４４は異なるタイミング情報を提供する。
【０２４０】
ステップ３９２で受信された物理時間サンプルから、これらの時間サンプル間で処理されたデータ量をステップ３９４で使用すると、物理時間レートを計算または判断することができる。物理時間レートとは、オーディオ・ハードウェアが実際にデータをレンダリングするときのレートであり、データ・レンダリング・スループットを表し、フィルタ処理レートとも呼ばれている。ライブ・データ・ストリームのソースがフィルタ処理レートよりも早い発生レートでデータ・サンプルを発生すると、余剰データが発生する。発生レートがフィルタ処理レート以下であれば、データ処理のギャップまたは枯渇が発生する。どちらの場合も、パフォーマンスが低下することになる。
【０２４１】
データ・サンプルを発生するプロセッサの実際の処理レート、つまり、発生レートは、メディアまたはデータ・サンプル自体から判断することができる。メディア・サンプルは規則または実際のタイムスタンプ情報の形態になった時間インターバル情報をもっているので、メディア時間サンプルはステップ３９６でメディア・ストリームから計算することができる。これにより、メディア・サンプルを作成したハードウェアの処理レートを表す発生レートは、一定のデータ処理量を使用し、この処理量をメディア時間サンプルから判断されたそのデータ処理時間で除すことにより計算することができる。
【０２４２】
ステップ４００で終了する前に、メディア・ストリーム処理はステップ３９８で発生レートをフィルタ処理レートに一致させるように調整される。この場合も、調整はレンダリングするサンプルを省き、サンプル・レンダリング間に時間遅延を追加し、この分野で公知の他の方法によって行うことができる。
【０２４３】
次に、図２１（Ｃ）に示すフローチャートを参照して、クロック・メカニズムを使用して変換を行うための処理ステップについて説明する。ステップ４０２でスタートした後、処理コンポーネントまたはフィルタはステップ４０４でクロック・メカニズムから相関時間値を受信する。なお、処理コンポーネントまたはフィルタはＰＣクロックのように、相関時間値の参照時間値部分を生成する参照時間クロックにアクセスすることができる。メディア時間データは、ＰＣクロックまたは以前に受信された相関時間値に入っている他の参照時間値からメディア時間値を減算することによってステップ４０６で計算される。メディア時間データは変換のために処理コンポーネントまたはフィルタによって使用され、ＰＣクロック時間からのメディア時間の変化を示している。
【０２４４】
変換を行うためには、処理コンポーネントまたはフィルタはステップ４０８で現在のＰＣクロック時間値（または他の参照時間値）を取得する。処理コンポーネントまたはフィルタでの現在メディア時間は、ステップ４１０で現在ＰＣクロック時間値とマスタ・メディア・デルタを使用して変換することができる。メディア時間デルタは、参照時間を基準にしたＰＣクロック時間からのメディア時間の変化を示しているので、これを現在ＰＣクロック時間値に加えるだけで、タイムスタンプ情報の正しい「変換」または新時間値を得ることができる。ステップ４１０で変換プロセスを終了すると、処理はステップ４１２で終了する。この通信がＤＳＰなどのリモート・プロセッサ上の２つのコンポーネント間で行われる場合は、参照時間値はＰＣ時間ではなく、ローカル・ホスト時間となる。
【０２４５】
図２１（Ｃ）のフローチャートに示す変換のメソッドを相互接続カーネル・モード・フィルタに適用して図１９と図２０に示すライブ・オーディオとビデオ・ストリームを処理し、レンダリングする場合は、ステップ４０４でクロック・メカニズム３４４から相関時間値を受信するのはビデオ・レンダラ・フィルタ３３２上の入力ピン・インスタンス３３６である。最後に、ライブ・ビデオ・ストリーム３２０上のタイムスタンプの計算と変換を行うか、あるいはクロック・メカニズム３４４のメディア時間に基づいて変換参照時間を作成するのは、ビデオ・レンダラ・フィルタ３３２である。
【０２４６】
この分野の当業者ならば理解されるように、本明細書に開示されている相互接続フィルタのシステムにおいては、均一バッファ割当て機能とタイミング機能は実施上の問題解決の要件に応じて、処理効率向上のために組み合わせて使用することも、単独で使用することも可能である。さらに、タイミング機能は、相互接続フィルタのシステムから独立して使用することも可能である。
【０２４７】
この分野の精通者ならば理解されるように、本発明の種々方法はコンピュータ・プログラム・コード手段として、磁気ディスク、ＣＤ−ＲＯＭ、およびこの分野で共通している他の媒体やまだ未開発の他の共通媒体などの、コンピュータ読取り可能媒体上にストアされるコンピュータ命令として組み込んでおくことが可能である。さらに、コンピュータ・ハードウェア・メモリに置かれる重要なデータ構造は、上記のようなコンピュータ・プログラム・コード手段をオペレーションにより作成することができる。
【０２４８】
本発明は本発明の基本的特徴の精神から逸脱しない限り、他の実施形態で実現することも可能である。上述してきた各種実施の形態はすべての点で説明した通りであるが、これらの実施の形態に限定されるものではない。従って、本発明の範囲は上述してきた説明によってではなく、特許請求の範囲に記載されている事項によってのみ限定されるものである。特許請求の範囲の等価技術の意味と範囲に属する一切の変更は本発明の範囲に属するものである。
【図面の簡単な説明】
【図１】制御エージェントの指示を受けてサウンド・データをディスク・ファイルから持ち込み、サウンド・データをなんらかの形態で処理し、サウンド・データをレンダリングしてスピーカから再生させる相互接続フィルタとドライバのシステムを示す従来技術のデータ・フロー図である。
【図２】図１に示すシステムと目的が同じであり、サウンド・データをディスク・ドライバから読み取り、そのデータを処理し、そのデータをレンダリングしてスピーカから聞こえるようにし、処理フィルタとレンダリングは、この場合も制御エージェントの指示を受けて相互接続カーネル・モード・ドライバによって処理されるようした本発明によるシステムを示す図である。
【図３】オペレーティング・システムで作成され、使用されるドライバ・オブジェクト、デバイス・オブジェクトおよびファイル・オブジェクト間の関係を示す垂直関係モデルを示す図である。
【図４】ドライバ・オブジェクトのロジック・ブロック図であり、本発明のシステムに従ってメッセージを適切なプロセス・ハンドリング・コードへ転送し、新しいファイル・オブジェクトの作成をバリデーションするためのデータ構造およびプログラム・コードとの論理的関係を示す図である。
【図５】デバイス・オブジェクトのロジック・ブロック図であり、本発明のシステムに従ってメッセージを適切なプロセス・ハンドリング・コードへ転送し、新しいファイル・オブジェクトの作成をバリデーションするためのデータ構造およびプログラム・コードとの論理的関係を示す図である。
【図６】ファイル・オブジェクトのロジック・ブロック図であり、本発明のシステムに従ってメッセージを適切なプロセス・ハンドリング・コードへ転送し、新しいファイル・オブジェクトの作成をバリデーションするためのデータ構造およびプログラム・コードとの論理的関係を示す図である。
【図７】ルーチングとバリデーション・コンポーネントリの初期セットアップとカーネル・モード・ドライバによる入出力メッセージの処理を示すフローチャートである。
【図８】制御エージェントの処理、ルーチングとバリデーション・メカニズム、および新しいファイル・オブジェクトを作成する具体的な作成ハンドラ・ルーチンを示す詳細フローチャートである。
【図９】オペレーティング・システムでファイル・オブジェクト構造を利用して、接続を標準化された方法で行う接続フィルタ間の水平関係を示すロジック図である。
【図１０】図９のカーネル・モード・フィルタまたはドライバを作成し、接続するためにユーザ・モードの制御エージェントによってとられる処理ステップを示すフローチャートであり、制御エージェントから受け取った入出力要求を処理するために接続を行い、その処理が異なるドライバ（フィルタ）間で続けられる様子を示している。
【図１１】ユーザ・モードの制御エージェントの指示を受けてカーネル・モード・フィルタのチェインを作成するために使用され、サウンド・データをハード・ドライブから読み取り、カーネル・モード・フィルタでそのデータを処理し、そのデータをレンダリングしてスピーカから聞こえるようにするシステムを実装するためのカーネル・モード・ドライバと接続を示す概要ロジック図である。
【図１２】ユーザ・モードの制御エージェントの指示を受けてカーネル・モード・フィルタのチェインを作成するために使用され、サウンド・データをハード・ドライブから読み取り、カーネル・モード・フィルタでそのデータを処理し、そのデータをレンダリングしてスピーカから聞こえるようにするシステムを実装するためのカーネル・モード・ドライバと接続を示す概要ロジック図である。
【図１３】図１１と図１２に示すシステム用に相互接続カーネル・モード・ドライバを作成するための処理ステップを示すフローチャートである。
【図１４】バッファ割当てメカニズムがどのような働きをするかを示す図であり、割当てられたバッファ・フレームがある処理コンポーネントから別の処理コンポーネントへ渡されるときの、バッファ・フレームの論理的構成と処理を示す。
【図１５】バッファ割当てメカニズムがどのような働きをするかを示す図であり、相互接続カーネル・モード・フィルタのシステムにおいて入力ピン・インスタンスを表すファイル・オブジェクトの「子」であるファイル・オブジェクトとして表されるバッファ・アロケータを示している。図１４と図１５はどちらも同じフィルタ・グラフ・トポロジを示している。
【図１６】図１１および図１２に示すシステムの遷移において、バッファ・フレームの割当てを制御するバッファ・アロケータを利用して行われるバッファ割当てを示す図である。
【図１７】相互接続カーネル・モード・フィルタのチェインを通してデータをディスク・ドライバから持ち込んで、サウンド処理ハードウェア上でデータをレンダリングする処理ステップを示すフローチャートであり、具体的には、バッファ・アロケータのオペレーションと図１６に示すシステムでバッファ間で実際に行われるデータ転送を示している。
【図１８】２つのライブ・データ・ストリームが単一のマスタ・クロック・メカニズムとどのようにして同期化されるかを示すロジック・ブロック図である。
【図１９】図１６を参照して詳しく説明されている相互接続フィルタ・システムを使用して実施されている図１８のライブ・オーディオ・システムを示すロジック・ブロック図であり、図１９はマスタ・クロック同期化信号を受信するライブ・ビデオ・ストリーム・レンダリング・フィルタを示す。
【図２０】図１６を参照して詳しく説明されている相互接続フィルタ・システムを使用して実施されている図１８のライブ・オーディオ・システムを示すロジック・ブロック図であり、図２０は両方のストリームを一緒に同期化し、ライブ・オーディオ・データを実際のオーディオ・レンダリング・ハードウェアとレート整合するマスタ・クロック・メカニズムをもつライブ・オーディオ・レンダリング・システムを示す図である。
【図２１】（Ａ）ないし（Ｃ）は、複数のデータ・ストリームのデータ処理を同期化し、あるデータ・ストリームをハードウェア・レンダラの物理的機能とレート整合し、あるタイムベースを共通タイムベースを使用して別のタイムベースに変換するためにクロック・メカニズムがどうように使用されるかを示す図であり、（Ａ）は同期化処理ステップを示すフローチャート、（Ｂ）はレート整合処理ステップを示すフローチャート、（Ｃ）は変換処理ステップを示すフローチャートである。
【符号の説明】
４４，１７０，３４２ 制御エージェント
４６，２６２ ディスク・ドライブ
４８，１８２ ディスク・ドライバ
５０ リーダ・ドライバ
５２ デコンプレッサ・ドライバ
５４ 効果フィルタ
５６ 効果プロセッサ
５８ レンダリング・ドライバ
６２，３０２ スピーカ
６４，７６，８０ ドライバ・オブジェクト
６６ デバイス・オブジェクト
７０，７２，７４，９０ ファイル・オブジェクト
７８ 汎用マルチプレクシング・ディスパッチ機能
８２ デバイス・エクステンション・エリア
８４，１００ ファイル・タイプ・バリデーション・テーブル
８６，１０２ ファイル・オブジェクト・タイプ
８８ 作成ハンドラ
９２ ファイル・コンテキスト・エリア
９４ ＩＲＰ要求ハンドラ・テーブル
９６ ＩＲＰ要求
９８ ハンドラ
１０４ 参照
１４６ フィルタＡ
１４８ フィルタＢ
１５４，１８８，２０２，２０６，２４２，２４８，３２８，３３６，３６２，３６８ 入力ピン・インスタンス
１５８，１９２，２０４，２０８，２４０，２５０，３２６，３３４，３６０，３６６ 出力ピン・インスタンス
１７２ リーダ・フィルタ
１７４ デコンプレッサ・フィルタ
１７６ 効果フィルタ
１７８ サウンド・レンダリング・フィルタ
２１０ シンク処理コンポーネント
２１２ バッファ・アロケータ・メカニズム
２１４，２３８ ソース処理コンポーネント
２１６，２２２ バッファ・アロケータ参照
２２０ 変換処理コンポーネント
２２４ａ バッファ・フレーム
２４４ 変換フィルタ
２４６ シンク・フィルタ
２５２，２６４，２６８ バッファ・アロケータ
２５６ システム・メモリ
２５８ サウンド・カード・メモリ
２６０ システム・メモリ
２９６ オーディオ・レンダラ
２９８，３５２ ライブ・オーディオ・ストリーム
３０６ ビデオ・レンダラ
３０８，３２０ ライブ・ビデオ・ストリーム
３１２，３５０ モニタ
３１６ マスタ・クロック・メカニズム
３２２ ビデオ・リーダ・フィルタ
３２８ 入力ピン・インスタンス
３３０ ビデオ・デコンプレッサ・フィルタ
３３２ ビデオ・レンダリング・フィルタ
３４４ クロック・メカニズム
３４６ ビデオ・ハードウェア
３５４ オーディオ・リーダ・フィルタ
３５８ オーディオ・デコンプレッサ・フィルタ
３６４ オーディオ・レンダラ・フィルタ

Claims (16)

1. データをカーネル・モードで処理することを効率化するようにソフトウェア・ドライバを相互接続し、異なるデータ・ストリームを同期化し、およびハードウェア・プロセッサへの処理コンポーネントの異なるハードウェア・クロックをレート整合するためのタイミング情報を標準化された方法で提供する方法であって、
   オペレーティング・システムの１つまたは２つ以上の、前記カーネル・モードでのドライバを実行するステップと、
   前記ドライバを接続するための１つまたは２つ以上の接続ピン・インスタンスを作成するステップであって、各前記接続ピン・インスタンスは、前記ドライバを元に作成され、該ドライバと親子関係にあり、該ドライバ間でのデータ伝送のために使用されるものであるステップと、
   前記レート整合と前記異なるデータ・ストリームの同期化のための１つまたは２つ以上のクロックのインスタンスを作成するステップであって、各前記クロックのインスタンスは、前記１つまたは２つ以上の接続ピン・インスタンスの１つと親子関係にあり、前記同期化のために使用され、および基礎となるハードウェア・オシレータに基づいて前記データ・ストリームの位置時間と物理時間を提供するものであるステップと、
   該１つまたは２つ以上の接続ピン・インスタンスを相互接続し、前記カーネル・モードに置かれた前記ドライバを通る連続のデータ・パスが得られるようにするステップであって、前記クロックのインスタンスは異なるクロック・メカニズム間でレート整合するときと、前記異なるデータ・ストリームを同期化するときにタイミング情報を利用できるようにするものであるステップと、
   複数のデータ・サンプルの基準データ・ストリームに基づいてマスタ・クロックの基準を作成するステップであって、各前記データ・サンプルは、前記基準データ・ストリーム内の位置を指示する時間インターバル情報を有し、前記マスタ・クロックの基準は前記基準データ・ストリームの時間インターバル情報から作成されるものであるステップと、
   １つまたは２つ以上の他のデータ・ストリームを前記基準データ・ストリームと、前記他のデータ・ストリームの処理を調整することにより同期させ、その結果、前記マスタ・クロックの基準に基づいて前記他のデータ・ストリームの位置と、前記基準データ・ストリーム内の位置を一致させるステップと、
   前記ハードウェア・プロセッサのハードウェアのクロック・メカニズムに基づいて、前記処理コンポーネントに、物理時間の基準を提供するステップと、
   前記処理コンポーネントで前記他のデータ・ストリームの処理のレートを調整して、前記物理時間の基準に基づき前記ハードウェア・プロセッサでの処理のレートを一致させるステップであって、前記他のデータ・ストリームはそれと関連する時間インターバル情報を有する複数のサンプルを有しているものであるステップと
   を備えていることを特徴とする方法。
2. 請求項１に記載の方法において、前記１つまたは２つ以上のカーネル・モードのドライバは、共通のハードウェア・オシレータを使用する第１の処理コンポーネントおよび第２の処理コンポーネントを有し、さらに、
   前記第１の処理コンポーネントで、前記第２の処理コンポーネントから相関時間値を受け取るステップであって、前記相関時間値は前記共通のハードウェア・オシレータに基づく、前記第２の処理コンポーネントの指定時間値および共通の物理時間値を有するものであるステップと、
   前記第１の処理コンポーネントにより前記共通のハードウェア・オシレータの現在の値を照会するステップと、
   前記共通のハードウェア・オシレータの現在の時間値および前記第２の処理コンポーネントから受け取った相関時間値に基づいて、前記第１の処理コンポーネントにより、前記第１の処理コンポーネントの指定時間値に変換するステップと
   備えたことを特徴とする方法。
3. 請求項１または２に記載の方法において、前記各接続ピン・インスタンスはファイル・オブジェクトによって表され、前記ドライバと該接続ピン・インスタンスとの親子関係は、接続ピン・インスタンスのファイル・オブジェクトの作成時に関係づけられる前記ドライバを指定することによって作成され、該関係づけられるドライバはシステム上で利用できる入出力デバイスのファイル・オブジェクトとして参照され、各前記クロックのインスタンスはファイル・オブジェクトによって表され、かつ、該クロックのインスタンスと前記接続ピン・インスタンスとの親子関係はクロックのインスタンスのファイル・オブジェクトの作成時に関係づけられる接続ピン・インスタンスのファイル・オブジェクトを親として指定することによって作成されることを特徴とする方法。
4. 請求項１または２に記載の方法において、前記１つまたは２つ以上のドライバ上の前記接続ピン・インスタンスの各々について照会し、前記クロックのインスタンスが使用可能であるかどうかを判断し、特定の接続ピン・インスタンスで同期化またはレート整合を行うためのクロック・メカニズムをインスタンス生成すべきかどうかを判断してから、該１つまたは２つ以上の接続ピン・インスタンスを相互接続するようにするステップをさらに含むことを特徴とする方法。
5. 請求項１に記載の方法において、前記１つまたは２つ以上のドライバ上の前記１つまたは２つ以上の接続ピン・インスタンスの少なくとも１つは、少なくとも１つの事前定義されたプロパティ集合、メソッド集合、およびイベント集合をサポートし、前記少なくとも１つの接続ピン・インスタンス上のクロックのインスタンスが利用可能であることをサード・パーティの制御エージェントに示して、該サード・パーティの制御エージェントがそれぞれの前記接続ピン・インスタンスで前記クロック・メカニズムを作ることを可能にしており、前記クロックのインスタンスは少なくとも１つの事前定義されたプロパティ集合、メソッド集合、およびイベント集合をサポートして、前記それぞれのクロックのインスタンスをサード・パーティの制御エージェントによって判断された通りに制御するようにしたことを特徴とする方法。
6. 請求項１または２に記載の方法において、
   前記１つまたは２つ以上の接続ピン・インスタンスと関連する、プロパティ集合、メソッド集合、およびイベント集合を定義するステップと、
   前記少なくとも１つの接続ピン・インスタンス上のクロックのインスタンスを利用可能であることのサード・パーティの制御エージェントへの通知を提供するステップと、
   前記サード・パーティの制御エージェントに対して、予め定められたプロパティ集合、メソッド集合およびイベント集合に基づいてそれぞれの前記接続ピン・インスタンス上の前記クロックのインスタンスに対して１つまたは２つ以上のコネクションを形成することを許すステップと
   をさらに備えたことを特徴とする方法。
7. 請求項１または２に記載の方法において、前記マスタ・クロックの基準はプロパティ集合の一部分としてアクセスされることを特徴とする方法。
8. 請求項１または２に記載の方法において、前記マスタ・クロックの基準は、前記サード・パーティの制御エージェントによる要求に対する応答において作成される、選択的にインスタンスを作成することが可能なクロックのインスタンスの一部分であることを特徴とする方法。
9. 請求項１または２に記載の方法において、前記時間インターバル情報は前記データ・サンプル上のタイムスタンプにより与えられることを特徴とする方法。
10. 請求項１または２に記載の方法において、前記時間インターバル情報は所与のメディア・ストリームの中に含まれる情報であることを特徴とする方法。
11. 請求項１または２に記載の方法において、前記物理時間の基準はプロパティ集合の一部分としてアクセスされることを特徴とする方法。
12. 請求項１または２に記載の方法において、前記物理時間の基準は、サード・パーティの制御エージェントによる要求に対する応答において作成される、選択的にインスタンスを作成することが可能なクロックのインスタンスの一部分であることを特徴とする方法。
13. 請求項１または２に記載の方法において、前記時間インターバル情報はデータ・サンプル上のタイムスタンプにより与えられることを特徴とする方法。
14. 請求項１または２に記載の方法において、前記時間インターバル情報は所与のデータ・ストリームの中に含まれる情報であることを特徴とする方法。
15. 請求項２に記載の方法において、前記第２の処理コンポーネントの前記指定時間値は、それと関連のある時間インターバル情報を有するデータ・ストリーム内の位置に基づく位置時間値であることを特徴とする方法。
16. 請求項２に記載の方法において、前記第２の処理コンポーネントの前記指定時間値はハードウェア・オシレータに基づく物理的な時間値であることを特徴とする方法。

Images