JPH10283199A - 標準クロック・メカニズムを用いて、多重データ・ストリームの処理の同期と異なる処理速度のマッチングを行う方法、コンピュータ・プログラム・プロダクツ、およびシステム - Google Patents

標準クロック・メカニズムを用いて、多重データ・ストリームの処理の同期と異なる処理速度のマッチングを行う方法、コンピュータ・プログラム・プロダクツ、およびシステム

Info

Publication number
JPH10283199A
JPH10283199A JP9180625A JP18062597A JPH10283199A JP H10283199 A JPH10283199 A JP H10283199A JP 9180625 A JP9180625 A JP 9180625A JP 18062597 A JP18062597 A JP 18062597A JP H10283199 A JPH10283199 A JP H10283199A
Authority
JP
Japan
Prior art keywords
component
data
processing
media
filter
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
JP9180625A
Other languages
English (en)
Other versions
JP4575528B2 (ja
Inventor
George H J Shaw
エイチ． ジェイ． ショウ ジョージ
Bryan A Woodruff
エイ． ウッドラフ ブライアン
Thomas J O'rourke
ジェイ．エロウルケ トーマス
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Microsoft Corp
Original Assignee
Microsoft Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Microsoft Corp filed Critical Microsoft Corp
Publication of JPH10283199A publication Critical patent/JPH10283199A/ja
Application granted granted Critical
Publication of JP4575528B2 publication Critical patent/JP4575528B2/ja
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/4302—Content synchronisation processes, e.g. decoder synchronisation
    • H04N21/4307—Synchronising the rendering of multiple content streams or additional data on devices, e.g. synchronisation of audio on a mobile phone with the video output on the TV screen
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/40—Information retrieval; Database structures therefor; File system structures therefor of multimedia data, e.g. slideshows comprising image and additional audio data

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Multimedia (AREA)
  • Data Mining & Analysis (AREA)
  • Databases & Information Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Signal Processing (AREA)
  • Stored Programmes (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

(57)【要約】 （修正有） 【課題】 カーネル・モードで実行される相互接続ソフ
トウェア・フィルタのシステムにおいて、２つまたはそ
れ以上のデータ・ストリーム間の処理を同期化し、相互
に対してドリフトする可能性のある２つの異なるハード
ウェア・クロック間のレートを整合する。 【解決手段】 同期化はイベント通知またはストリーム
位置の照会を通して達成され、別々のストリーム内のデ
ータの対応するフレームが一緒にレンダリングされるよ
うにする（例えば、ビデオ・フレームおよび対応するサ
ウンド・トラック）。レート整合は物理クロックの進行
を、一連のデータ・ストリーム・タイムスタンプと対比
しながらモニタし、異なるクロック・レートを整合する
ように調整を行う。共通物理クロックは、あるコンポー
ネントが特定のクロック時間を、すべてのコンポーネン
トによって共有される時間に変換するときの参照として
使用され、発生する誤差を最小限にする。

Description

【発明の詳細な説明】
【０００１】
【発明の属する技術分野】本発明の分野は、発生クロッ
クとレンダリング・クロックとの間のストリーム同期化
およびレート整合といったように、マルチメディア・ア
プリケーションで起こるタイミング問題に関係する方法
とコンピュータ・プログラム・プログラムに属するもの
である。また、本発明はソフトウェア・ドライバにおけ
る標準化タイミング・メカニズムに関する。より具体的
には、本発明は相互接続されたソフトウェア・ドライバ
などの、複数のエンティティによって使用されるタイミ
ングおよびクロック・メカニズムを標準化された方法で
提供し、複数の処理されるデータ・ストリームが同期化
され、異なるハードウェア・クロック間のレートが整合
されるようにする方法およびコンピュータ・プログラム
・プロダクトに関する。
【０００２】
【現在の技術状況】ディジタル化サウンドやビデオ・デ
ータなどのマルチメディア・データを処理するとき、連
続するメディア・サンプルのストリームを処理している
のが普通である。また、データ・ストリームは、規則ま
たはタイムスタンプ情報のどちらかによってデータと関
連づけられた時間インターバル情報ももっている。タイ
ミング情報は、特定のサンプルをいつ処理すべきかを処
理コンポーネントに知らせるものであるが、処理がタイ
ムスタンプ間で特定のレートで進行するのを保証するた
めにトラッキング参照(tracking reference)としても使
用されている。
【０００３】処理が行われている期間に使用される時間
インターバル情報を伝達するものとして、データ編成(d
ata organization) 、フォーマット、および規定(conve
ntion)もある。例えば、３０フレーム／秒（ｆｐｓ）フ
ォーマットと規定のビデオ・データ・ファイルは、処理
コンポーネントがその規定とフォーマットを知っていれ
ば、各サンプルが１／３０秒のインターバルで処理され
るものと認識される。
【０００４】メディア・ストリームを処理するときに起
こる１つの問題は、２つまたはそれ以上のストリームを
同期化してこれらが一緒にレンダリングされるようにす
ることである。例えば、サウンドトラックを表すオーデ
ィオ・ストリームと、それに付随するビデオ・データ・
ストリームはコヒーレントなマルチメディア・プレゼン
テーションが得られるように同期化する必要がある。
【０００５】ある同期化方法では、ＰＣクロックのよう
な物理クロックやハードウェア・クロックに基づく値を
もつクロック・メカニズムを利用している。データ・ス
トリーム・プロセッサはこのクロック・メカニズムの値
を照会してストリームの処理またはレンダリングを同期
化することが可能になっている。同期化はハードウェア
・クロックを基準にして行われるが、２つの異なるスト
リームは処理するイベントや遅延が各ストリームに対し
て独立に行われることがあるので、常に同期化されると
は限らない。
【０００６】別の同期化方法では、ストリームが処理さ
れている間、「マスタ」・データ・ストリーム上のプレ
ゼンテーション・タイムスタンプ値に基づく時間値を提
供するクロック・メカニズムを利用している。マスタ・
ストリームが休止または停止されると、時間値はＰＣク
ロックのような物理クロックまたはハードウェア・クロ
ックを基準にするように切り替わる。第２データまたは
メディア・ストリームのプロセッサはこのクロック・メ
カニズムの値を照会(query) できるが、別の機能が用意
されているので、クロック・メカニズムは物理クロック
上の特定の時間に、あるいは、物理クロックに基づく一
定のインターバル（例えば、１０ｍｓごと）に、プロセ
ッサに通知するようになっている。
【０００７】イベント通知は物理クロックに基づいてい
るので、処理がマスタ・データまたはメディア・ストリ
ームで休止または停止されたときでも、このようなイベ
ントは引き続き起こる場合がある。通知は一時的に禁止
することができるが、そうすると、余分の処理オーバヘ
ッドが発生するという犠牲が伴い、処理コードがさらに
複雑化することになる。通知が明示的に禁止されたとき
でも、通知が誤って行われるというタイミング上の問題
が生じることがある。
【０００８】メディアまたはデータ・ストリームを処理
するとき起こるもう１つの問題は、メディア・ストリー
ムに関連する異なるハードウェア・クロックのレートを
整合するという問題である。あるハードウェア・クロッ
クはメディア・ストリームのメディア・サンプルを生成
し、タイムスタンプ情報を各サンプルと関連づけるとき
に使用されている。他方、全く別のハードウェア・クロ
ックはメディア・ストリームをレンダリングするために
使用されている。２つのハードウェア・クロックは見か
け上同じレートで動作しているように見えるが、物理ク
ロック・レートが変動すると、処理に影響することにな
る。
【０００９】ここでレート整合(rate matching) とは、
物理クロックに起こる実際の周波数変動を補償する概念
である。例えば、ライブ・オーディオのストリームがロ
ーカル・オーディオ・ハードウェア側でレンダリングす
るためにネットワーク接続から受信されるとき、ストリ
ームの受信時のレートはローカル・オーディオ・ハード
ウェアが実際にストリームをレンダリングするときのレ
ートに一致していない場合がある。このようなことが起
こるのは、オーディオ・ハードウェア側のクリスタル
が、ネットワーク接続の他端に置かれたオーディオ・ハ
ードウェア側のクリスタルとは無関係であるためであ
る。
【００１０】場合によっては、ローカル・オーディオ・
ハードウェア側で微調整を行うようにすると、ローカル
側をソース側が発生している周波数に近づけることが可
能な場合もある。しかし、すべてのオーディオ・ハード
ウェアがこれを可能にしているとは限らない。ハードウ
ェアによっては、周波数解像度にある種の制約があるた
め調整の精度が制限されているものや、許容される調整
量が制限されているものがある。
【００１１】処理時の「ドリフト(drift) 」はこのレー
ト差が原因で起こるため、ドリフト量を正確かつ迅速に
判断するための方法が追求されている。さらに、ドリフ
トの補償は、大きな調整を低頻度で行なうよりも、小刻
みに高頻度で行なうと最適化されるので、ドリフト補償
がエンド・ユーザに気づかれることがなくなる。この気
づかれやすい調整は、サウンド・データを「スキップす
る(skipping)」および／またはビデオ・データが「滑ら
かに動かなくなる(jerking) 」という形で現れる。
【００１２】メディアまたはデータ・ストリームを処理
するときに起こるさらに別の問題は、ある時間フレーム
を別の時間フレームに変換する問題である。この問題
は、「スレーブ」・ストリームのプレゼンテーション時
間がマスタ・フレームの時間フレームに変換されるとき
の同期の間によく起こっている。エラー発生を最小限に
してこの変換を行なうための方法が探究されている。
【００１３】マルチメディア環境では、ソフトウェア・
ドライバを相互接続し、実行優先度が非常に高く、セキ
ュリティ保護度が低いオペレーティング・システム・モ
ードで実行され、多くの場合、ドライバが直接に操作す
る実際のハードウェアにアクセスできるソフトウェア・
ドライバで処理を行なうようにすると好都合である。多
くのアプリケーションは、本明細書においてWindows NT
用語で「カーネル・モード(kernel mode) 」と呼ばれ
る、この制約がゆるやかでパフォーマンス指向のモード
で実行させると有利である。他の強固なオペレーティン
グ・システムも機能的に同等のモードをもっている。こ
のような相互接続ソフトウェア・ドライバの場合も、同
じように複数のメディア・ストリームを同期化し、物理
クロックのレートを整合する必要がある。
【００１４】
【発明が解決しようとする課題】現在、本明細書で用い
られているカーネル・モード・ドライバを容易に使用す
ることができないプログラムの主要例の１つとして、ユ
ーザがフィルタと呼ばれる、異なる処理ブロックを選択
し、１つに接続してマルチメディア・データ・ストリー
ムを連続的に操作できるようにするグラフ作成機能があ
る。データは、サウンドまたはビデオを表す一連のサン
プルであるのが代表的であり、処理ブロックとしては、
圧縮データのデコンプレション(decompression) 処理、
特殊効果処理、CODEC 機能、データをアナログ信号にレ
ンダリングすることなどがある。
【００１５】このようなフィルタはユーザ・モードで置
かれているのが代表的であるので、プログラムのグラフ
作成部分は、フィルタのオペレーションを相互接続して
その制御を行い、ユーザの入力と処理ブロックの配置替
えに応答できるようになっている。マルチメディア・デ
ータ・ストリームはその性質上一貫性があり、大量のデ
ータが生成されるので、パフォーマンスは重大な問題と
なっている。汎用オペレーティング・システムでは、ユ
ーザ・モードとカーネル・モードとの間の受渡し／切替
えを繰返し行うと、システム・パフォーマンスはある種
のマルチメディア・アプリケーションが禁止されるほど
に低下することがある。
【００１６】カーネル・モード・フィルタの相互接続を
標準化する方法が望まれているが、標準化クロック・メ
カニズムがあると、複数のマルチメディア・ストリーム
を同時に処理するとき起こる同期化の問題が解決しやす
くなるという利点がある。さらに、このような標準化ク
ロック・メカニズムはデータを送信し、異なる物理クロ
ックを使用してデータをレンダリングするとき起こるレ
ート整合問題も取り扱って、解決する必要がある。
【００１７】本発明の目的は、各々が、関連する時間イ
ンターバル情報を有するデータ・サンプルからなる複数
のデータ・ストリームの処理を同期化することである。
【００１８】本発明の別の目的は、データ・ストリーム
がストリーム・データ・サンプルに表された発生側物理
クロックと、ハードウェアの一部と関連づけられたレン
ダリング側物理クロックとによって発生された場合にデ
ータ・ストリームの処理レートの整合を容易化すること
である。
【００１９】さらに、本発明の目的は、相互接続された
カーネル・モード・ソフトウェア・ドライバのシステム
で使用される標準化インタフェースをもつ有用なクロッ
ク・メカニズムを提供することである。
【００２０】さらに、本発明の別の目的は、一方のクロ
ック・メカニズム上の時間から他方のクロック・メカニ
ズム情報の時間への変換を容易化することである。
【００２１】本発明のその他の目的および利点は以下の
説明に記載されているが、その一部はその説明から理解
されるものと、本発明を実施することにより知得し得る
ものとがある。本発明の目的と利点は、請求の範囲に個
々に記載されているインストリューメント(instrument)
の手段および組合せにより実現し、得られるものであ
る。
【００２２】
【課題を解決するための手段】上記目的を達成するため
に、また本明細書に具現化され、広い意味で説明されて
いる本発明によれば、標準化クロック・メカニズムを使
用して複数のデータ・ストリームを同期化し、異なる処
理レートを整合する方法とコンピュータ・プログラム・
プロダクトが提供されている。クロック・メカニズムは
種々の異なる方法で実現することが可能であるが、本明
細書では、データ・ストリームの処理を効率化する相互
接続可能なカーネル・モード・ドライバを中心にして説
明されている。
【００２３】本発明のクロック・メカニズムは３つの異
なる時間値をもち、他のコンポーネントが利用できるよ
うにする。これらの時間値を照会することも、クロック
・メカニズムが一定の時間値に来たことに基づいて、ま
たは周期的インターバルで通知を送ることも可能であ
る。
【００２４】本発明のクロック・メカニズムで利用でき
る最初の時間値は位置時間値(positional time value)
であり、これはデータ・ストリームに関連する時間イン
ターバル情報に基づいており、処理されるデータ・スト
リーム内の位置を反映している。第２の時間値はＰＣク
ロックやレンダリング・プロセッサ・クロックなどの実
際のハードウェア・オシレータまたはクロックに基づく
物理時間値である。最後に、第３の時間値は相関時間値
(corrclated time value) であり、これは位置時間値な
どの指定時間値(designated time value) をＰＣクロッ
クなどの共通に利用可能なハードウェア・クロックに基
づく参照時間値と共に提供する。
【００２５】クロック・メカニズムをマスタ・クロック
としたときは、位置時間値は他のデータ・ストリームを
処理する他の処理コンポーネントが同期をとるために使
用することができる。位置時間値はデータ・ストリーム
の処理に基づいているので、基礎となるデータ・ストリ
ームの処理が停止すると、クロックも停止する。さら
に、タイミング・イベント通知も絶対時間を基準にして
凍結されるが、位置時間値に対して完全にタイミングは
合い続ける。このことは、「休止された」時間をトラッ
キング（追跡）したり、操作したり、あるいは気にした
りしないで済むという大きな利点がある。「スレーブ」
・クロック・メカニズムとコンポーネントは位置時間値
から得られる時間を基準にして処理を行う。
【００２６】データ・ストリーム・レンダラまたは他の
プロセッサに関連する基礎となるハードウェア・クロッ
クの物理時間値は、処理されるデータ・ストリームのレ
ートをレンダリング・プロセッサの処理レートと一致さ
せるために使用できる。データ・ストリームは関連づけ
られている時間インターバル情報を有しているので、発
生側プロセッサの処理レートは固有であるので、これを
確かめて、物理時間値に入っているレンダリング・プロ
セッサの実際の処理レートと比較することができる。こ
れにより、処理レートの「ドリフト」を迅速かつ正確に
判断できるので、レンダリングされたデータに目立った
影響を与えることなく処理の調整を行うことができる。
【００２７】最後に、相関時間値は他のクロック・メカ
ニズムと処理コンポーネントが時間情報をある基準から
別の基準へ変換するときの手段となるものである。共通
ハードウェア・クロックは共通の参照として使用できる
ように、他のクロック・メカニズムまたはコンポーネン
トが利用できるようになっていなければならない。相関
時間はアトミック・オペレーションとして返されるまた
はアクセスされるので、発生する誤差は最小限であり、
非累積的になっている。
【００２８】相関時間はここで説明している実施の形態
では２種類がサポートされ、どちらの場合も、ＰＣクロ
ックを参照として使用している。一方はメディア時間を
指定時間(designated time) として使用し、他方は物理
時間を指定時間として使用している。本明細書では、相
関時間が単独で使用されるときは、２種類の相関時間の
どちらか、またはこの分野の当業者ならば自明である他
の種類の相関時間を意味している。これらを区別する必
要があるときは、相関メディア時間と相関物理時間の用
語が使用され、それぞれの指定時間が共通参照と比較さ
れるようになっている。
【００２９】本発明の一実施の形態は、標準化された方
法でカーネル・モード・ドライバを接続する一部として
行われる。ある所定のドライバまたはフィルタは接続ポ
イントの「ピン・ファクトリ(pin factory) 」をサポー
トし、定義している。ピン・ファクトリは他のドライバ
上の他のピン・インスタントと相互接続される接続ピン
・インスタンスをインスタンス生成するために使用さ
れ、ユーザ・モード・エージェントに頼らなくても、処
理メッセージをドライバがカーネル・モードで連続的に
処理できるようにする。
【００３０】コンプライアント・ドライバ(compliant d
river)を接続することを希望するサード・パーティ・エ
ージェントはドライバに能力(cabability)があるかどう
かを照会する。そのような能力としては、どの種類の接
続ピン・インスタンスがインスタンス生成できるか、と
いったことがあり、この中には、処理されるデータのタ
イプ、データ・フォーマット、転送レート、転送媒体ま
たはモード、接続ピン・インスタンスの入力または出力
の性質などの関係特性が含まれる。照会されるものとし
て、ほかにも、必要なデータ・バッファ容量と、各接続
ピン・ファクトリで利用できるバッファを割り当てる能
力がある。
【００３１】ユーザ・モードで実行されるのが代表的で
あるサード・パーティ・エージェントが１つまたは２つ
以上のコンプライアント・ドライバの機能について照会
したあと、そのエージェントは、複数のドライバを１つ
に「チェイニング」してデータがドライバ間で最適に処
理されるようにする最良の接続特性を決定する。この決
定ステップは、すべてのドライバ機能の照会を終えて、
最適な接続基準が選択できるようになったあとで行われ
る。
【００３２】各接続ピン・インスタンスごとに、サード
・パーティ・エージェントはバッファ・アロケータ(buf
fer allocator)を特定のピン・インスタンスで作成する
必要があるかどうかも判断する。この場合も、これはす
べての異なるフィルタとピン・ファクトリの照会を終え
たあとで行われ、そのあとで相互接続が行われる。
【００３３】そのあと、サード・パーティ・エージェン
トは、各ドライバ上の接続ピン・ファクトリに基づいて
接続ピン・インスタンスを作成することによってドライ
バを相互接続する。エージェントは接続ピン・インスタ
ンス作成の一部としてデータ・フォーマットと接続フォ
ーマットを指定する。ＮＴオペレーティング・システム
の下で実装された実施の形態では、実際の接続ピン・イ
ンスタンスは「ファイル」へのハンドルを戻す作成入出
力オペレーションによって作成される。作成入出力要求
はドライバ・インスタンス・ハンドルと、接続ピン・イ
ンスタンスのデータ・フォーマットと接続フォーマット
を示しているデータ構造への参照とを収めている。
【００３４】さらに、以前に作成された接続ピン・イン
スタンス（例えば、入力ピンまたはＩＲＰ「シンク」・
ピン）への参照は、他の接続ピン・インスタンス（例え
ば、出力ピンまたはＩＲＰ「ソース」・ピン）を作成す
る要求の中で指定され、接続ピン・インスタンス間の接
続が行われるようにする。ソース・ピン・インスタンス
がバッファ・アロケータをもつ入力ピン・インスタンス
への参照を使用して作成されると、バッファ・アロケー
タのソース・ピン・インスタンスと一緒に通知が行わ
れ、データが既存バッファから新しいバッファに送り込
まれるようにする。参照が示されていなければ、ソース
・ピン・インスタンスは処理を終えた後、データを既存
バッファに残しておく。
【００３５】コンプライアント・ドライバを作成するた
めには、ドライバ開発者は、ユーザ・モードのエージェ
ントが機能について照会し、ドライバ間の相互接続を行
えるようにする、ある種の標準機能をサポートしてい
る。Windows NTオペレーティング・システム上で構築さ
れている、ある実施の形態では、これは、必要とする機
能を実装している「集合(set) 」（つまり、プロパテ
ィ、メソッド、およびイベントの集合）の使用によって
達成されている。
【００３６】集合は、集合全体を特定するＧＵＩＤ(glo
bally unique identifier)（グローバルにユニークな識
別子）と、集合内の各機能エレメントのＲＵＩＤ(relat
ively unique identifier)（相対的にユニークな識別
子、例えば、集合自体内で相対的な識別子）をもつもの
として論理的に定義されている。各集合は１つまたは２
つのＩＯＣＴＬｓ(IO Controls)(入出力コントロール）
だけと関連づけられ、ＩＯＣＴＬは、集合の仕様と組み
合わされて、ドライバとのすべてのインタラクションを
制御する。
【００３７】本実施の形態では、３タイプの集合が使用
されている。つまり、プロパティ集合、メソッド集合、
およびイベント集合である。プロパティ集合はサウンド
・ボリューム、転送レートなどの、値または設定値をド
ライバ内で管理するために使用され、コールがプロパテ
ィ値を得ようとしているのか、および／またはプロパテ
ィ値を設定しようしているのかを示すフラグと一緒に単
一のＩＯＣＴＬを使用する。メソッド集合は、メモリの
割当て、バッファのフラッシング(flushing)などのよう
に、ドライバが実行できるオペレーションを管理するた
めに使用され、単一のＩＯＣＴＬを使用して特定のメソ
ッドをコールする。イベント集合は、デバイス変更通
知、データ・スターベーション(data starvation) 通知
などのように、ドライバの処理に関連するイベントを管
理するために使用され、２つのＩＯＣＴＬを使用する。
１つは特定のイベントをイネーブル(enable)にするため
のもので、もう１つは特定のイベントをディスエイブル
(disable) にするためのものである。
【００３８】集合を使用するには、入出力制御オペレー
ションは特定のＩＯＣＴＬと、集合のＧＵＩＤ、ＲＵＩ
Ｄをもつデータ構造への参照およびその他の必要なデー
タを使用して開始される。例えば、サウンド・カード・
ドライバでボリューム・プロパティを設定する場合は、
集合プロパティのＩＯＣＴＬを使用し、ボリューム設定
値をもつプロパティ集合の適切なＧＵＩＤを指定し、そ
の集合内の特定ＲＵＩＤがボリューム・プロパティを示
していることを指示し、新しいボリューム設定値を含ん
でいる入出力制御オペレーションが行われることにな
る。
【００３９】サポートされる集合について照会するに
は、ヌルＧＵＩＤが特定集合タイプの特定ＩＯＣＴＬ
（例えば、プロパティ集合ＩＯＣＴＬ、メソッド集合Ｉ
ＯＣＴＬ、またはイベント・イネーブルＩＯＣＴＬ）で
照会フラグと一緒に使用され、サポートされる集合ＧＵ
ＩＤのリストが返される。ある集合内のサポートされた
プロパティ、メソッド、またはイベントについて照会す
るには、集合ＧＵＩＤ、集合タイプＩＯＣＴＬ、および
照会フラグが、サポートされたＲＵＩＤのリストを返す
オペレーションと一緒に使用される。
【００４０】汎用集合メカニズムを使用すると、コンプ
ライアント・ドライバをサポートするために最小限の機
能を実装することができるが、それでも拡張性は無制限
である。集合は、特定の集合が実装されている限り、相
互動作可能で、相互接続可能なドライバのシステムを作
成するために、多数の異なるドライバ開発者によって独
立してコーディングすることができる仕様書に定義する
ことができる。さらに、この仕様書には、サポートする
必要のある必須のプロパティ、メソッドおよびイベント
を定義できるだけでなく、ドライバの機能と拡張機能に
依存して実装できるオプションのプロパティ、メソッ
ド、およびイベントも定義することができる。要求され
る基本的最小限の共通性のほかに、ドライバ開発者は独
自の集合を定義し、その集合にＧＵＩＤを割当てること
によって追加の機能を組み込むことも可能である。サポ
ートされる機能（つまり、サポートされるＧＵＩＤとＲ
ＵＩＤの照会を行うこと）を列挙できるようにすると、
サード・パーティ制御エージェントなどの、呼出し側(c
aller)は期待を調整することも、基礎となるフィルタの
機能に依存して適切な補償を行うこともできる。
【００４１】位置時間値、物理時間値、相関位置時間
値、および相関物理時間値をもつクロック・メカニズム
の実施の形態は、コンプライアント接続ピン・インスタ
ンス上に作成することができる。「ファイル」は、接続
ピン・インスタンスを親として表しているファイル・オ
ブジェクトのハンドルと、クロック・メカニズムのファ
イル・タイプを示すＧＵＩＤストリング値を指定して、
入出力の特定のデバイス上でオープンされる。ハンドル
はクロック・メカニズムを表すファイル・オブジェクト
に返され、フィルタはそれぞれの時間値を提供するプロ
パティ集合を、このファイル・オブジェクトを通してサ
ポートする。位置時間値はフィルタによって処理され、
特定の接続ピン・インスタンスに渡されるデータ・スト
リームに基づいている。物理時間は、ハードウェア・ク
ロックまたは存在すればフィルタに関連するオシレー
タ、つまり、ＰＣクロックに基づいている。相関時間値
はどちらも、ＰＣクロックが普及しているので、ＰＣク
ロックを参照として使用しているのが代表的である。
【００４２】クロック・メカニズムを「マスタ」として
使用すると、他のクロック・メカニズムまたはコンポー
ネントを「スレーブ」にし、あるいはその時間トラッキ
ングと同期させることができる。さらに、ＰＣクロック
に基づくデフォルトの実装が用意されている。
【００４３】本発明の上記およびその他の目的と特徴は
以下の説明および請求の範囲に詳しく記載されている通
りであるが、以下に説明する本発明を実施することによ
って知得することも可能である。
【００４４】本発明の上記およびその他の利点と目的が
どのようにして得られるかという方法を示すために、以
下では、添付図面に図示されている具体的実施の形態を
参照して、以上で簡単に説明してきた本発明を詳しく説
明することにする。添付図面は本発明の代表的な実施の
形態を示したにずぎず、従って、本発明の範囲を限定す
るものではないとの了解の下で、以下、添付図面を使用
しながら本発明をもっと具体的にかつ詳しく記述し説明
することにする。
【００４５】
【発明の実施の形態】本明細書で用いられている「ユー
ザ・モード(user mode) 」という用語は、ユーザが書い
たプログラムの大部分が実行されるときの、オペレーテ
ィング・システムにおける動作レベルのことである。ユ
ーザ・モードの動作レベルはセキュリティ・レベルが最
も高く、あるアプリケーション・プログラムまたはプロ
セスが別のアプリケーション・プログラムまたはプロセ
スに干渉するのを防止するために大量のオーバヘッドが
消費されるのが代表的である。さらに、システム・リソ
ースへのアクセスは特定のインタフェースを通して厳格
に制御され、実行優先度は最低ではないとしても、最低
優先度の１つであるのが一般である。
【００４６】本明細書で用いられている「カーネル・モ
ード(kernel mode) 」という用語はユーザ・モードの動
作モードよりも制約が非常に少ない、オペレーティング
・システムにおける動作レベルのことである。カーネル
・モードのプログラムまたはプロセスの例としては、ハ
ードウェア・コンポーネントを制御するソフトウェア・
ドライバ(software driver) を含む。代表例として、カ
ーネル・モードのプログラムはパフォーマンスに影響さ
れやすく、従って、動作上のオーバヘッドはユーザ・モ
ードのプログラムよりも少なくなっている。さらに、ハ
ードウェアや多くのシステム・リソースへのアクセスは
無制約であるか、あるいはユーザ・モードのプログラム
の場合よりも制約がはるかに少なくなっている。多くの
場合、カーネル・モードで実行されるプログラム・コー
ドは、規則(convention)に対するプログラマの規律正し
さと準拠とを信頼して、システムが良好に動作するよう
にする（例えば、別のプログラムのアドレス空間を破壊
しないようにする）。カーネル・モードを表わす別の用
語として、「トラステッド(trusted) 」コードがある。
【００４７】本明細書で用いられている「ドライバ(dri
ver)」という用語はカーネル・モードで実行されるのが
代表的である、ソフトウェア・ドライバ・プログラムの
ことである。ドライバという用語は、オペレーティング
・システム上にロードされる実際の実行可能プログラム
またはある種の機能を分け与えるプログラム部分を意味
する場合もある。ドライバは、多くの場合、ある形態の
ハードウェアと関連づけられているが、必ずしもそうで
ある必要はない。
【００４８】本明細書で用いられている「フィルタ(fil
ter)」という用語はソフトウェア・ドライバ内に置かれ
ている機能部分のことであり、この中には、ドライバ自
体も含まれ、そこでは、接続ポイントがフィルタを通し
てデータを送信するために公開されている。例えば、ソ
フトウェア・ドライバはいくつかの異なるフィルタをサ
ポートする場合もあれば、１つの単一機能をもっている
場合もある。さらに、内部的には１つに接続され、外部
的には入出力用に接続ポイントを公開している異なるド
ライバからの複数のフィルタは単一フィルタとして集合
的に参照される場合もある。また、もっと総称的な意味
では、フィルタという用語は、伸張(decompression) な
どのように、それがカーネル・モードで実行されるソフ
トウェア・ドライバ・フィルタで起こるか、ユーザ・モ
ードで実行される別のプログラム・コードで起こるかに
関係なく、実行されるオペレーションを意味する場合も
ある。
【００４９】本明細書で用いられている「ドライバ・オ
ブジェクト(driver object) 」という用語は、ソフトウ
ェア・ドライバを管理し、これをシステム・リソースと
して知らせるオペレーティング・システムによって定義
されているオペレーティング・システムのエンティティ
のことである。
【００５０】本明細書で用いられている「デバイス・オ
ブジェクト(device object) 」という用語はシステムに
よって定義されたシステム・レベルのエンティティのこ
とであり、これは利用が可能であるドライバの機能の一
部をシステム・リソースとして知らせ、ドライバの機能
と他のシステム・コンポーネントが利用できるかどうか
を定義している。ドライバ・オブジェクトとデバイス・
オブジェクトはどちらも、代表的にドライバ・ソフトウ
ェアのロード時と初期化時に作成される。
【００５１】本明細書で用いられている「ファイル・オ
ブジェクト(file object) 」という用語は、デバイス・
オブジェクトによって指定されたリソースの呼出しを管
理するオペレーティング・システムのエンティティのこ
とであり、これはオペレーティング・システムによって
定義されている。ファイル・オブジェクトはドライバ・
オブジェクトの使用状況に関するコンテキストを提供す
る。さらに、ファイル・オブジェクトは、以前のファイ
ル・オブジェクトが新しいファイル・オブジェクトの作
成時に「親」と指定されていれば、別のファイル・オブ
ジェクトと階層的に関係づけることが可能である。ファ
イル・オブジェクトは、代表的にデータ・ストリーム上
に操作するすべての入出力オペレーションの管理に使用
される。
【００５２】本明細書で用いられている「データ(dat
a)」という用語は、相互接続されたカーネル・モードの
フィルタを通して処理される一切の情報のことである。
そのようなデータは、ビデオ、オーディオ、テキスト、
ＭＩＤＩなどを表すメディア・データを含むが、他のア
プリケーションの場合には制御情報やパラメータも含ん
でいる場合がある。例えば、カーネル・モード・フィル
タ・グラフはプロセス制御オペレーションで使用される
ことがあるが、そこでは、異なるフィルタ間で受け渡し
される制御情報はマシン類をアクチュエートする制御信
号を創り出すために使用されている。メディア処理シス
テムの例が示されているが、他のアプリケーションも、
本明細書に説明されている相互接続カーネル・モード・
フィルタのシステムから、同じような方法で利点を得る
ことが可能である。
【００５３】本明細書では、本発明の説明は、Microsof
t(登録商標）社から提供されているWindows NT（商標）
オペレーティング・システムのコンテキスト内で記載さ
れている。さらに、本明細書に説明されている好適実施
の形態を理解するためには、Windows NTの入出力アーキ
テクチャの知識が前提になっている。入出力システムお
よび NT オペレーティング・システム全般について解説
した好適書としては、Helen Custer著「Windows NTの内
部(Inside Windows NT) 」(Microsoft Press発行）があ
るが、本書は引用により本明細書の一部を構成するもの
である。
【００５４】ドライバおよびファイル・オブジェクト、
デバイス・オブジェクト、ドライバ・オブジェクトなど
のシステム・エンティティの以下の説明では、Windows
NTオペレーティング・システム上でこれらがどのような
働き方をするかが解説されているが、この分野の精通者
ならば理解されるように、本発明は、類似のコンポーネ
ントを持つ他のオペレーティング・システム上で実装す
ることが可能であり、これらのオペレーティング・シス
テムが同じ用語を使用しているかどうかとは無関係であ
る。例えば、別のオペレーティング・システムがファイ
ル・オブジェクトとして動作するエンティティを持って
いれば、そのエンティティはその実際の名称に関係な
く、ファイル・オブジェクトと解釈することができる。
【００５５】まず、図１を参照して説明すると、図示の
システム例は、サウンド・データのストリームをディス
ク・ドライブから読み取り、そのサウンド・データをレ
ンダリング(rendering) して、従来のモデルに従ってス
ピーカから聞こえるようにするものである。あるデータ
量はハード・ドライブ２０にストアされるが、これはデ
ィジタル化されたサウンド・サンプルの形態でサウンド
を表している。ほかにも、サウンド・データ・ストリー
ムのソースとしては、電話回線を利用して送られてくる
ディジタル化情報、ネットワークや他の通信パケットか
らのディジタル化情報、この分野で公知の他のソースが
考えられる。データ・ストリームはディジタル化サンプ
ルから構成され、これらのサンプルはデータ・フォーマ
ットと規則によって、または各サンプルに付加される明
示的タイムスタンプ情報によってタイム・インターバル
情報が関連づけられている。カーネル・モードのディス
ク・ドライバ２２はディスク・ドライブ・ハードウェア
２０と相互作用し、ユーザ・モードのリーダ(reader)プ
ログラム・コンポーネント２４の制御下に置かれてい
る。制御エージェント(controlling agent) ２６はサウ
ンド・データのレンダリングを行うために異なるコンポ
ーネントを管理するが、動的グラフ作成機能(dynamic g
raph building capability) を備えている場合は、異な
るソフトウェア・コンポーネントが動的に割当てられ
て、エンド・ユーザの指定に従ってカスタム・フィルタ
リングまたは他の処理経路を提供できるようにする。
【００５６】リーダ・コンポーネント２４はオペレーテ
ィング・システムの標準入出力制御インタフェースを使
用してディスク・ドライバ２２と相互作用し、圧縮サウ
ンド・データをディスク・ドライブ２０から読み取っ
て、ユーザ・モード・プロセスのアドレス空間(address
space) の一部としてユーザ・モードで割当てたバッフ
ァに入れる働きをする。次に、デコンプレッサ(decompr
essor)・コンポーネント２８は圧縮データを処理に適し
た伸張(decompressed)フォーマットに伸張する。図示の
ように、このステップ全体は、付随の低優先度の、プロ
セス動作(processbehavior)安全メカニズムを使用して
ユーザ・モードで実行される。
【００５７】効果フィルタ(effects filter)３０はデー
タに操作を加えて、ある種の特殊効果が得られるように
し、カーネル・モードで動作する附属の効果フィルタ３
２をもっている。さらに、効果プロセッサ３４が存在す
る場合もあれば、効果フィルタ全体が実際のハードウェ
ア・プロセッサをエミュレートするソフトウェアで動作
する場合もある。効果フィルタ３２をアクセスするため
には、効果コンポーネント３０はシステム入出力制御メ
カニズムを使用して、データと制御を効果フィルタに転
送する。この場合も、カーネル・モード／ユーザ・モー
ド境界を交差して、この遷移が行われる。
【００５８】効果フィルタ３２は効果プロセッサ３４を
制御し、必要または望ましいとされる特殊効果がそのデ
ータ上に作られるようにする。これは、効果コンポーネ
ント３０から全データをコピーし、そのコピーを効果フ
ィルタ３２に、実際のシステム構成によっては、再度効
果プロセッサ３４にも移すことにより行われる。多くの
ソフトウェア効果コンポーネントはハードウェア・プロ
セッサが関連づけられているが、他のコンポーネント
は、ホスト・プロセッサ上で実行されるシステム・ソフ
トウェア内で完全に機能している。
【００５９】効果コンポーネント３０の処理の完了時に
コントロールとデータがユーザ・モードに戻されると、
これは、次に、サウンド・レンダリング・コンポーネン
ト３６に転送される。サウンド・レンダリング・コンポ
ーネント３６はコントロールとデータをサウンド・レン
ダリング・ドライバ３８に転送し、これを受けてサウン
ド・レンダリング・ドライバは、処理され、フィルタリ
ングされたデータをスピーカ４２からのサウンドとして
レンダリングするようにサウンド・カード４０を制御す
る。以上から容易に理解されるように、ユーザ・モード
とカーネル・モード間の転送は多種類存在するために、
サウンド・データのレンダリングを非効率化している。
連続するサウンドまたはビデオ・ストリームのように、
マルチメディア・データはタイミングに影響されやすい
性質のため、これらの非効率性とコントロールの遷移を
少なくすると共に、異なるバッファ間でなん度もデータ
をコピーすることを少なくすると、好都合である。
【００６０】本明細書で用いられている本発明の一実施
の形態は、Windows NTオペレーティング・システム・ア
ーキテクチャ上で提供されるサービスから構成されてい
る。このサービスはシステムのユーザがアクセスする、
いくつかの異なるソフトウェア・コンポーネントに分割
されている。第１は、ユーザ・モードのＡＰＩであり、
これは、接続ピン・インスタンスと、クロック・メカニ
ズムやバッファ割当てメカニズムなどの特定の機能を表
している他のファイル・オブジェクトとを作成するため
のルーチンを含んでいる。ほかにも、もっと重要なもの
として、ドライバ開発者が標準化アーキテクチャに従う
ドライバを作成するのを支援するルーチンとデータ構造
が完備されている。システムに用意されているこれらの
機能を利用すると、異なるドライバ開発者は特定のアー
キテクチャに準拠して相互に相互作用するコンプライア
ント・ドライバを作成することができる。ユーザ・モー
ド・エージェントはＮＴエグゼクティブおよび入出力マ
ネージャのシステム・サービスと通信する、ユーザ・モ
ードで実行中の環境サブシステムを通してコンプライア
ント・ドライバと通信する。これは、他のすべての入出
力に対する同じ標準入出力メカニズムであり、好適実施
の形態の本実装では、既存のシステム・サービスを可能
な限り利用するようになっている。
【００６１】本発明を利用する図１のシステムのアーキ
テクチャは図２に示すようになっている。制御エージェ
ント４４は知らされているドライバに照会し、データ・
フォーマットと接続フォーマットに従って相互接続を行
い、レンダリングを完全にカーネル・モードで行うよう
にする。さらに、制御エージェントは重要なイベントの
通知を受けるので、必要に応じて制御を行うことができ
る。このようなイベントの例としては、処理の終了、デ
ータ・スターベーション事態などを含む。
【００６２】この構成では、サウンド・データは前述し
たように、ディスク・ドライバ４８によってディスク・
ドライブ４６から読み取られる。リーダ・ドライバ５０
はディスク・ドライバ４８を制御し、従来の使い方と同
じようにＮＴ層(NT layered)入出力アーキテクチャに従
ってディスク・ドライバ４８と「垂直方向」に関連づけ
られている。「垂直方向」と「水平方向」の用語は、Ｎ
Ｔ層入出力アーキテクチャの一部として現在行われてい
るドライバ接続（垂直方向）と、サード・パーティ制御
エージェントによって動的に行われる相互接続カーネル
・モード・ドライバに従う接続（水平方向）とを区別す
るために用いられている。
【００６３】リーダ・ドライバ５０は以下で説明する接
続メソッドに従ってデコンプレッサ・ドライバ５２とも
「水平方向」に相互接続され、制御エージェント４４に
よって管理されている。デコンプレッサ５２は伸張をカ
ーネル・モードで行ってから、データとコントロールを
効果フィルタ５４に引き渡す。効果フィルタは必要に応
じて効果プロセッサ５６を利用して特殊効果を適用して
からデータとコントロールをサウンド・レンダリング・
ドライバ５８に引き渡し、このドライバはサウンド・カ
ードを制御し、データをスピーカ６２からのサウンドと
してレンダリングする。図２から理解されるように、処
理をカーネル・モードのままにしておくと、ユーザ・モ
ードとカーネル・モードとの間の複数の遷移がなくな
り、処理をユーザ・モードで行うと通常起こるオーバヘ
ッド量が減少するので、効率面の利点が得られる。
【００６４】次に、図３を参照して説明する。図３は、
本発明の一実施の形態に従う相互接続ソフトウェア・ド
ライバに関係するシステム・オブジェクトの階層的性質
を示すロジック図である。ドライバ・オブジェクト６４
は、メモリにロードされるときの、実行可能ソフトウェ
ア・コード・イメージを表すために作成される。ドライ
バ・コード・イメージはドライバの機能全体を含んでお
り、ドライバ・オブジェクト６４はシステムに置かれて
いる場所、サポートされるドライバの種類などのイメー
ジに関する情報を含んでいる。
【００６５】制御エージェントによって独立にアクセス
できる機能の各タイプ別に、デバイス・オブジェクト６
６a 〜６６N が入出力ディレクトリ構造に作成され、こ
れらのオブジェクトは利用可能で、ユーザ・モードのク
ライアントによってアクセスされる異なる機能を表して
いる。これらは、フィルタまたは独立に利用できる他の
機能部分を表しているのが代表的である。ドライバ・オ
ブジェクト６４とデバイス・オブジェクト６６a 〜６６
N は囲みボックス６８で示すように、ドライバ・コード
のインストール時に作成される。
【００６６】歴史的には、デバイス・オブジェクトは物
理ハードウェアの各エレメントごとに存在する。しかる
に、最新の入出力システムの柔軟性は、デバイス・オブ
ジェクトが完全にソフトウェアで実装されたフィルタを
表すことを可能にさせている。そのため、デバイス・オ
ブジェクトは専らソフトウェアで実装されたフィルタの
各インスタンスごとに作成することが容易になってい
る。従って、ソフトウェア・フィルタは、デバイス・オ
ブジェクトで表された各インスタンスがデバイス・オブ
ジェクトと１対１の対応関係をもつように実装すること
も、単一のデバイス・オブジェクトがより伝統的な手法
に従い、各々がフィルタのクライアント・インスタンス
を表している複数のファイル・オブジェクトを管理する
ように実装することも可能になっている。
【００６７】デバイス・オブジェクト、図示の例では、
デバイス・オブジェクト６６a 上には、ファイル・オブ
ジェクトが作成され、これはデバイス・オブジェクトで
表された機能の独立インスタンスを表している。デバイ
ス・オブジェクトはフィルタを表し、そのフィルタの複
数のインスタンスを管理するのに対し、ファイル・オブ
ジェクトは特定のエンティティによって使用される、そ
のフィルタの実際のインスタンスを表している。従っ
て、ファイル・オブジェクト７０はデバイス・オブジェ
クト６６a によって定義されたフィルタのインスタンス
である。
【００６８】フィルタを使用するには、制御エージェン
トまたは他のユーザ・モード・クライアントは入出力デ
ィレクトリ構造内で利用可能なデバイス上でファイルを
オープンする。適切なコンテキスト情報を収めているフ
ァイル・オブジェクトが作成され、そのファイルへのハ
ンドルがユーザ・モード・クライアントに返される。フ
ァイル・オブジェクトは、作成時に「親」ファイル・オ
ブジェクトを指定することによって階層的に関係づける
ことが可能であるが、ファイル・オブジェクトはすべて
が同一デバイス・オブジェクトの子であるような、兄弟
(sibling) 関係も持っている。
【００６９】ファイル・オブジェクト内のコンテキスト
情報は、ユーザ・モード・クライアントとの入出力イン
タフェースを管理する情報、ファイル・オブジェクトが
表わしているエンティティの「状態(state) 」などから
なっている。コンテキスト情報には、システムが必要と
する情報があり、さらに、特殊な意味をもたせることが
できる、ユーザ定義可能エリアも含まれている。ユーザ
定義可能エリアの使い方の例は、下述するバリデーショ
ン(validation)とＩＲＰルーチング(routing)・メソッ
ドのインプリメーテンションの説明個所に示されてい
る。
【００７０】接続ピン・インスタンスを提供するために
は、フィルタ・インスタンスを表すファイル・オブジェ
クト７０が親として使用され、特定フィルタの接続ピン
・インスタンスを表す子ファイル・オブジェクトが作成
される。ファイル・オブジェクト７０は接続ピン・ファ
クトリの定義と可用性に関して照会されるのに対し、実
際のファイル・オブジェクトは特定のファイル・オブジ
ェクトを適切な情報コンテキストとして使用して、ピン
・ファクトリの各インスタンスごとに作成され、接続ピ
ン・インスタンスが有効に、かつ正しく作成されるよう
にする。例えば、ファイル・オブジェクト７２と７４は
ファイル・オブジェクト７０で表されたフィルタの接続
ピン・インスタンスを表し、ファイル・オブジェクト７
０と階層的に関係づけられている。それぞれファイル・
オブジェクト７２と７４で表された接続ピン・インスタ
ンスはフィルタ・インスタンス（ファイル・オブジェク
ト７０で表されている）に入ったあとで、そこから出る
データ・パスにすることができ、これは一連のチェイン
・フィルタまたは他のドライバ機能を形成するときに他
の接続ピン・インスタンスと接続するために使用でき
る。
【００７１】ピン・インスタンスがフィルタ・インスタ
ンスを表す別のファイル・オブジェクトと階層関係をも
つファイル・オブジェクトで表されて、ピン・インスタ
ンスのコンテキスト情報を提供するようにするのとまっ
たく同じように、他のファイル・オブジェクトをピン・
インスタンスと階層的に関係づけて他の機能を表すよう
にすると、正しいコンテキスト情報が得られるようにな
る。コンテキスト情報は、ピン・データ・フォーマッ
ト、通信タイプなどのように、作成時に使用される個々
のパラメータに従って、あるピン・インスタンスを他の
ピン・インスタンスと区別するために必要である。
【００７２】バッファ割当てメカニズム、タイミング・
メカニズムなどのように、個別コンテキストかユーザ・
モードのコントロールのどちらかをハンドルを通して要
求する他の操作エンティティも、ファイル・オブジェク
トで表すことができる。さらに、ファイル・オブジェク
ト（例えば、特定の接続ピン・インスタンスと関連づけ
られたバッファ割当てメカニズム）間の階層関係は、必
要ならば、子ファイル・オブジェクトの作成時に親ファ
イル・オブジェクトを指定することにより確立すること
ができる。これらの親子関係は、操作エンティティを表
すファイル・オブジェクト間の関係と構造を決定するた
めに存在する。さらに、特定タイプの「親」ファイル・
オブジェクトはある種のタイプの「子」ファイル・オブ
ジェクトだけを作ることができるので、以下で説明する
ように作成バリデーション・メカニズムが必要になる。
この場合も、このようなファイル・オブジェクトは対応
するハンドルがユーザ・モードで利用可能になってお
り、これらのハンドルはNtCreateFileなどのシステムＡ
ＰＩコールを通してクライアントに返される。
【００７３】ファイル・オブジェクトへのハンドルはカ
ーネル・モード・ドライバと通信するために、制御エー
ジェントなどのユーザ・モード・クライアントによって
使用される。ファイル・オブジェクト、デバイス・オブ
ジェクト、およびドライバ・オブジェクトの階層的チェ
インは、入出力サブシステムが階層関係をもつファイル
・オブジェクトとデバイス・オブジェクトを通ってドラ
イバ・オブジェクトまで戻り、実際のドライバ・コード
に入るエントリ・ポイント(entry point) に到達するこ
とができるようにする。このようなエントリ・ポイント
はソフトウェア・ドライバ・コードの中の機能を指す参
照（例えば、ポインタ）になっている。さらに、特定の
ファイル・オブジェクトと、ソフトウェア・ドライバ・
コードへのエントリ・ポイントをもつドライバ・オブジ
ェクトとの間のオブジェクト通路(pathway) 上にあるオ
ブジェクトの各々は、入出力サブシステムがＩＲＰを作
成するときに重要なコンテキスト情報のほかに、下述す
るルーチングおよびバリデーション・メカニズムに従っ
てＩＲＰを正しくルーチングするときに使用されるデー
タ構造への参照も提供する。
【００７４】ファイル・オブジェクトと他のシステム・
オブジェクトに対するハンドルはプロセス専用であり、
ユーザ・モード・プロセスが基礎となるオブジェクトと
通信するときの手段となる。注目すべきことは、ファイ
ル・オブジェクトなどの、基礎となる単一システム・オ
ブジェクトを参照するために複数のハンドルが作成でき
ることである。このことは、複数のアプリケーションが
ファイル・オブジェクトで表されたピン・インスタンス
に情報を供給できることを意味する。
【００７５】異なるドライバを相互接続するとき重要と
なる情報エレメントの１つとして、デバイス・オブジェ
クト・スタックの深さ(depth) パラメータがある。これ
は特定のドライバ・オブジェクトのＩＲＰスタック・ロ
ケーションを示している。このようにすると、入出力マ
ネージャを使用して、相互接続されたドライバ間で単一
のＩＲＰを使用し受け渡しできるので、ＩＲＰを別々に
作成し、それを種々の相互接続ドライバ間で送信するよ
りもパフォーマンス向上を提供できることになる。別の
方法として、各ドライバは適切な入出力マネージャのコ
ールを通して、各連続通信ごとに新しいＩＲＰを作成
し、各々の新ＩＲＰを相互接続されたドライバのチェイ
ン上の次のドライバへ送信させることも可能である。
【００７６】次に、図４〜図６を参照して説明する。図
は、異なるタイプのファイル・オブジェクト作成のバリ
デーションと適切なハンドラへの入出力要求パケット
（I/ORequest Packet：ＩＲＰ）のルーチングを可能に
するシステム・ドライバ・オブジェクト、デバイス・オ
ブジェクト、およびファイル・オブジェクトのエクステ
ンションを示している。図４は、１つまたは２つ以上の
フィルタまたは他のドライバ機能を実装している実行可
能コードを表すドライバ・オブジェクト７６を示してい
る。ドライバ・オブジェクト内では、Windows NTアーキ
テクチャはソフトウェア・ドライバ開発者が用意した作
成ハンドラへの参照を要求している。この実施の形態に
よれば、マルチプレクシング・ディスパッチ機能(multi
plexing dispatch function)７８は作成ハンドラとして
ドライバ・オブジェクト７６から参照され、メッセージ
を作成されるファイル・オブジェクトのタイプに応じて
特定の作成ハンドラへルーチングするために使用され
る。マルチプレクシング・ディスパッチ機能７８のオペ
レーションは図８に示すフローチャートを参照して以下
で説明する。
【００７７】同じように、ドライバ・オブジェクトから
の他のハンドラはマルチプレクシング・ディスパッチ機
能を示し、どのように実装するかに応じて、これらは同
じ機能にすることが可能である。言い換えれば、以下で
詳しく説明するように、各タイプの入出力ハンドラ参照
（例えば、読取り、書込み、デバイス制御など）はデバ
イス・オブジェクト内のエクステンション・データとフ
ァイル・オブジェクト内のコンテキスト情報を使用し
て、メッセージを適切なハンドラへルーチングするマル
チプレクシング・ディスパッチ機能を指している。バリ
デーション・テーブルを参照するデバイス・オブジェク
ト内のエクステンション・データは、作成オペレーショ
ンで親ファイル・オブジェクトの指定がないとき使用さ
れる。指定があれば、親ファイル・オブジェクトのコン
テキスト情報は正しいバリデーション・テーブルを示し
ている。
【００７８】図５は、ドライバ開発者によって所望によ
り利用でき、ドライバ専用情報を含んでいる特定のデバ
イス・エクステンション・エリア８２をもつドライバ・
オブジェクト８０を示している。ドライバ・オブジェク
ト８０のデバイス・エクステンション・エリア８２内の
定義されたロケーションには、ファイル・タイプ・バリ
デーション・テーブル８４と呼ばれ、ファイル・オブジ
ェクト・タイプ８６のストリング表現を含んでいるデー
タ構造への参照と、表現される各ファイル・タイプ別の
関連する作成ハンドラ８８への参照が置かれている。作
成マルチプレクシング・ディスパッチ機能はファイル・
タイプ・バリデーション・テーブル８４を使用して、作
成されるファイル・オブジェクト・タイプを検査し、そ
のあと、コントロールを適切な作成ハンドラへ引き渡
す。これについては、以下の図８の説明個所で詳しく説
明する。検査されるストリングはＩＲＰ作成要求に見出
され、ユーザ・モードのNtCreateFile関数コールと共に
使用されるファイル名ストリングから創られる。NtCrea
teFile関数コールは、ピン・インスタンスまたは他のメ
カニズムを作成するためにユーザ・モード関数セルの中
で行われる。
【００７９】図６は、ソフトウェア・ドライバ開発者が
使用するために解放されているファイル・コンテキスト
・エリア９２をもつファイル・オブジェクト９０を示し
ている。参照はファイル・コンテキスト・エリア９２か
らＩＲＰ要求ハンドラ・テーブル９４へ行われる。ＩＲ
Ｐ要求９６の異なるタイプは特定のハンドラ９８と関連
づけられ、適切なマルチプレクシング・ディスパッチ機
能はこの情報を使用して正しいハンドラにアクセスす
る。正しい作成ハンドラを決定する場合には、ファイル
・タイプ・バリデーション・テーブル１００と呼ばれる
データ構造が参照され、そこには、ファイル・オブジェ
クト・タイプ１０２のストリング表現と、表現される各
ファイル・タイプ別の関連する作成ハンドラへの参照１
０４が入っている。子ファイル・オブジェクト（つま
り、デバイス・オブジェクトではなく別のファイル・オ
ブジェクトを親としてもつファイル・オブジェクト）の
場合は、タイプはファイル・オブジェクト・タイプ１０
２内のストリングと比較されるストリングで表されてい
る。一致するものが見つかると、関連する作成ハンドラ
は、参照１０４のうち、一致したファイル・オブジェク
ト・タイプ・ストリングと関連づけられている参照を使
用してアクセスされる。一致するものが見つからなけれ
ば、要求は無効であるので、エラー表示が出されること
になる。
【００８０】次に、図７を参照して説明すると、図は作
成バリデーションとメカニズムをセットアップするため
のインストレーション・プロシージャを示している。ス
テップ１０６で、インストール・プログラムは適切なマ
ルチプレクシング・ディスパッチ機能への参照をドライ
バ・オブジェクトの中に作成する。図４に示すように、
作成ハンドラは汎用マルチプレクシング・ディスパッチ
機能を指している。同様に、ドライバ・オブジェクト７
６の中の他のすべてのハンドラ参照は、特定ハンドラと
密接な関係をもつ他の汎用(generic) マルチプレクシン
グ・ディスパッチ機能を必要に応じて指している。別の
方法として、各ハンドラ参照は同一マルチプレクシング
・ディスパッチ機能を指すことも可能であり、その場合
は、このディスパッチ機能はＩＲＰ要求を処理したあ
と、それを適切なハンドラへルーチングすることができ
る。この方法によるマルチプレクシング機能は異なる種
類の要求（例えば、作成、書込みなど）を受け付ける必
要があるため、複雑化することが避けられない。
【００８１】次に、ステップ１０８で、ソフトウェア・
ドライバ実行可能コードのインストールの一部として作
成された各デバイス・オブジェクトは、図５に示すよう
にファイル・タイプ・バリデーション・テーブル８４を
参照するように調整される。最後に、ステップ１１０
で、ＩＲＰ要求の処理は、適切なデバイス・オブジェク
ト８０から参照されたファイル・タイプ・バリデーショ
ン・テーブル８４を使用してマルチプレクシング・ディ
スパッチ機能から開始される。
【００８２】ファイル・オブジェクトが作成されると、
適切なＩＲＰディスパッチ・テーブル９４が作成され、
必要ならば、インデックスされたファイル・オブジェク
ト・タイプ・バリデーション・テーブル１００と一緒に
参照される。ファイル・オブジェクト・タイプ・バリデ
ーション・テーブルの作成は、ファイル・オブジェクト
・タイプに従って用意された作成ハンドラ内で行われ
る。データ構造が作成され、これはＩＲＰディスパッチ
・テーブル９４とファイル・オブジェクト・タイプ・バ
リデーション・テーブル１００を表しており、それを指
す参照は作成される特定ファイル・オブジェクト９０の
ファイル・コンテキスト情報９２と一緒に特定ロケーシ
ョンにストアされる。
【００８３】次に、図８を参照して説明すると、図は作
成マルチプレクシング・ディスパッチ機能のオペレーシ
ョンとそのバリデーション・メカニズムを示すフローチ
ャートであり、そこには、システム・ドライバ・オブジ
ェクト、デバイス・オブジェクト、およびファイル・オ
ブジェクトから参照されるデータ構造との相互作用も示
されている。ステップ１１２で、ユーザ・モード・プロ
セスはファイル・オブジェクトを作成する入出力要求を
送信する。この入出力作成要求はNtCreateFileのシステ
ムＡＰＩを呼び出すことによって行われる。ステップ１
１４で、入出力マネージャはドライバ・オブジェクト７
６内の参照に基づいてＩＲＰをマルチプレクシング・デ
ィスパッチ機能７８に送信する（図４参照）。
【００８４】マルチプレクシング・ディスパッチ機能７
８が作成要求のＩＲＰを受け取ると、ステップ１１６で
テストが行われ、親ファイル・オブジェクトがあるかど
うかが判断される。この判断を行うために必要な情報は
ＩＲＰ自体の中にあるが、これはユーザ・モード・プロ
セスによって元来用意されたものである。ユーザ・モー
ド・プロセスは「親」ファイル・オブジェクトを参照す
るハンドルを作成要求の一部として用意し、ＮＴシステ
ムは「親」ファイル・オブジェクトへの正しい参照をも
つＩＲＰを作成する。
【００８５】親ファイル・オブジェクトがなければ、右
へのブランチがとられ、マルチプレクシング・ディスパ
ッチ機能７８は適切なデバイス・オブジェクト８０から
のデバイス・エクステンション８２を使用して、ファイ
ル・タイプ・バリデーション・テーブル８４をステップ
１１８で参照する（図５参照）。バリデーション・テー
ブル８４を使用して、マルチプレクシング・ディスパッ
チ機能７８は要求の中のストリングをファイル・オブジ
ェクト・タイプ８６のストリングと比較することによっ
て、ステップ１２０でファイル・オブジェクト・タイプ
を検査する。
【００８６】ステップ１２２でストリングが一致してい
ると判断されると、適切な作成ハンドラがステップ１２
４でアクセスされる。一致していなければ、作成要求は
ステップ１２６で拒否される。ステップ１２４でアクセ
スされた作成ハンドラはステップ１２６でファイル・オ
ブジェクトを作成するか、あるいは作成させる。作成さ
れたファイル・オブジェクトを使用して、適切な作成ハ
ンドラは、以前に作成していたＩＲＰディスパッチ・テ
ーブル９４を指すファイル・オブジェクト参照をファイ
ル・コンテキスト９２の中に作成する。
【００８７】再びステップ１１６に戻って、親ファイル
・オブジェクトが存在するかどうかが判断される。親フ
ァイル・オブジェクトが存在するとステップ１１６で判
断され、それが作成要求に関連するＩＲＰに入っていれ
ば、マルチプレクシング・ディスパッチ機能７８は親フ
ァイル・オブジェクト９０からのファイル・コンテキス
ト９２を使用して、ステップ１３０でＩＲＰディスパッ
チ・テーブル９２を参照する（図６）。作成要求の場合
は、マルチプレクシング・ディスパッチ機能７８はステ
ップ１３２でファイル・タイプ・バリデーション・テー
ブル１００を参照する。ファイル・タイプ・バリデーシ
ョン・テーブル１００を使用して、マルチプレクシング
・ディスパッチ機能７８は、上記と同じように、要求の
中のストリングをファイル・オブジェクト・タイプ１０
２のストリングと比較することによってステップ１３３
でファイル・オブジェクト・タイプを検査する。
【００８８】ストリングが一致しているとステップ１３
４で判断されると、適切な作成ハンドラがステップ１３
８でアクセスされる。一致していなければ、作成要求は
ステップ１３６で拒否される。適切な作成ハンドラを使
用して、ファイル・オブジェクトは１４０で作成され、
作成ハンドラは新しく作成されたファイル・オブジェク
トの新しいＩＲＰディスパッチ・テーブル９４を作成
し、新しく作成されたＩＲＰディスパッチ・テーブル９
４を指す参照を新しく作成されたファイル・オブジェク
ト９０のファイル・コンテキスト・エリア９２の中にス
テップ１４２で作成する。注意すべきことは、親ファイ
ル・オブジェクトおよび有効に作成された子ファイル・
オブジェクトとの相互作用を説明するために、どちらの
場合も、図６に示す同じファイル・オブジェクト構造が
使用されていることである。どちらの場合も同じ構造が
存在するが（新しいファイル・オブジェクトが作成され
たあと）、これらはその使い方が異なり、含んでいる情
報も異なっている。
【００８９】接続ピン・インスタンスが作成されるとい
つでも、接続ピンＩＤが引き渡され、これはピン・イン
スタンスの作成を「サポート」するファイル内のピン・
ファクトリを示している。この分野の精通者ならば理解
されるように、接続ピンＩＤは、ファイル・オブジェク
トが検査されるのとまったく同じように、バリデーショ
ンテーブルでストリングとして検査することも可能であ
り、また、その実装方法もさまざまである。
【００９０】異なるドライバ間の接続を行うためには、
あるドライバがそのような相互接続をサポートしている
ことを確かめるための共通メカニズムが必要である。こ
の共通メカニズムは、接続ピン・ファクトリ機能を含む
フィルタ機能を明らかにすることを可能にするものでな
ければならない。さらに、この種のメカニズムは、ドラ
イバ開発者の柔軟性を向上するように拡張可能であるこ
とも必要である。
【００９１】コンプライアント・ドライバを定義し、機
能を明らかにすることを可能にするために本実施の形態
で選択されている１つのメカニズムは関連アイテムの
「集合」と名づけられている。これは既存の入出力通信
メカニズムと一緒に使用すると便利なメカニズムであ
る。集合は集合全体を特定するＧＵＩＤ（グローバルに
ユニークな識別子）と集合内の各機能エレメントのＲＵ
ＩＤ（相対的にユニークな識別子、例えば、集合自体内
の相対的な識別子）を持つものとして論理的に定義され
ている。集合識別子および選択されたＲＵＩＤアイテム
と一緒にオペレーションするために必要な他のデータ構
造は、フィルタ・ハンドルをパラメータとして使用して
入出力制御コールの一部として引き渡される。機能の完
全なシステムを実装するためには、少数のＩＯＣＴＬを
割当てるだけで十分である。実装されるとき、３つの異
なる種類の集合がその機能に応じて確立されるので、必
要になるＩＯＣＴＬは総計４個である。他の実装では、
集合の使い方が異なる場合がある。特定のＩＯＣＴＬ
は、選択されたエレメント（ＲＵＩＤを使用する）をな
んらかの方法で解釈または使用するように入出力制御の
ハンドラに通知する。さらに、制御フラグをＧＵＩＤお
よびＲＵＩＤと一緒に渡して、制御情報をもっと詳しく
指定することができる。
【００９２】最初の集合タイプはプロパティ集合であ
り、これはドライバ内または関連ハードウェア上に置か
れている値または設定値と一緒に使用される。そのよう
な設定値の例としては、転送レート、ボリューム・レベ
ル（音量）などがある。１つのＩＯＣＴＬがプロパティ
集合と関連づけられ、制御フラグは"get" プロパティ・
コマンドと"set" プロパティ・コマンドとを区別してい
る。このようにすると、同じデータ構造が特定のプロパ
ティを設定または取得するように使用でき、ドライバは
必要なアクションを使用されたＩＯＣＴＬに基づいて決
定することができる。正しいプロパティは、ユニークな
ＧＵＩＤとＲＵＩＤの組合せからなる集合識別子(set i
dentifier)によって特定される。
【００９３】メソッド集合は使用されるもう１つの集合
タイプであり、これはドライバによって実行できるアク
ションの集合である。メソッド集合を特定するために必
要なＩＯＣＴＬは１つだけであり、アクチュエートされ
る正しいメソッドは集合識別子のユニークなＧＵＩＤと
ＲＵＩＤの組合せによって特定される。メソッドはドラ
イバを制御するために使用され、ドライバを使用するた
めの初期化、バッファのクリアといった機能を含んでい
る。
【００９４】イベント集合は、デバイス変更通知、デー
タ・スターベーション通知などのドライバ処理や、ユー
ザ・モード・アプリケーションで使用すると便利である
集合によって定義された他の通知に関連するイベントを
管理するために使用される。２つのＩＯＣＴＬが使用さ
れ、１つは特定のイベントをイネーブルにするためのも
のであり、もう１つは特定のイベントをディスエーブル
にするためのものである。ＲＵＩＤで識別された、与え
られたイベントに必要なデータ構造は、イベントをイネ
ーブルにするか、ディスエーブルにするかに関係なく共
用することができる。
【００９５】集合を使用するには、入出力制御オペレー
ションは特定のＩＯＣＴＬおよび集合ＧＩＤ、 ＲＵＩＤ
をもつデータ構造と他の必要なデータ（例えば、制御フ
ラグ、データ構造など）を指す参照を使用して開始され
る。例えば、サウンド・カード・ドライバでボリューム
・プロパティを設定することは、入出力制御オペレーシ
ョンをプロパティ集合ＩＯＣＴＬ、集合プロパティ・オ
ペレーションを示す制御フラグ、ボリューム設定値をも
つプロパティ集合の適切なＧＵＩＤ、ボリューム・プロ
パティを示しているその集合内の特定ＲＵＩＤ、および
新しいボリューム設定値を使用することを必然的に伴な
う。
【００９６】サポートされる集合についてタイプ別に照
会するには、ヌルＧＵＩＤとサポートされる集合の列挙
を示す制御フラグとをもつ、特定の集合タイプのＩＯＣ
ＴＬ（例えば、プロパティＩＯＣＴＬ、メソッドＩＯＣ
ＴＬ、またはイベント・イネーブルＩＯＣＴＬ）が入出
力コマンドの一部として出され、サポートされる集合Ｇ
ＵＩＤのリストが返される。ある集合内のサポートされ
るプロパティ、メソッドまたはイベントについて照会す
るには、集合ＧＵＩＤ、集合タイプＩＯＣＴＬ、ヌルＲ
ＵＩＤ、およびサポートされるエレメントの列挙を示す
制御フラグが入出力オペレーションと共に使用される。
サポートされるＲＵＩＤのリストは入出力オペレーショ
ンの結果として返される。このリストから、サード・パ
ーティ・エージェントは、実装されている集合のどのオ
プション・エレメント（もしある場合）がサポートされ
るかを判断することができる。
【００９７】ＧＵＩＤでユニークに識別された集合の仕
様書は、ドライバ開発者とサード・パーティ制御エージ
ェントのどちらもが実装ガイドとして利用できるメカニ
ズムをドキュメント化している。サード・パーティ開発
者は、あるドライバの機能を照会に対する応答に基づい
て知り、事前プログラムされた知識を抽象的集合定義に
基づいて知ることになる。同様に、ドライバ開発者は、
知った機能をどのようなサード・パーティ・エージェン
トに対して提供する集合または集合グループを実装する
ときのガイドとして抽象的集合定義を使用することがで
きる。
【００９８】ここで説明している接続機能を提供するた
めには、コンプライアント・ドライバはある種の集合を
サポートしていなければならない。以下の表は、プロパ
ティ集合フォーマットでサポートされ、本発明を実装す
るときに使用できるいくつかの重要な情報を示してい
る。最初の表は、フィルタによって実装される接続ピン
・ファクトリに関するプロパティに関し、２番目の表
は、特定の接続ピン・ファクトリをテンプレートとして
使用して作成される実際の接続ピン・インスタンスに関
するプロパティを示している。
【００９９】
【表１】
【０１００】
【表２】
【０１０１】
【表３】
【０１０２】
【表４】
【０１０３】
【表５】
【０１０４】
【表６】
【０１０５】上記の表は単なる例示であり、これに限定
されるものではない、この分野の精通者ならば理解され
るように、異なるドライバ間の接続を作成するためには
多数の異なるプロパティとスキーマを実装することが可
能である。１つの重要な要素は標準化係数(standardiza
tion factor)であり、異なるドライバ製造者または開発
グループは同一のプロパティ集合を実装する能力をもっ
ているので、相互接続できるドライバを作成できるよう
にすることである。
【０１０６】もう１つの有用なプロパティ集合は、ある
フィルタ上の入力と出力の接続ピン・ファクトリの内部
関係に関するトポロジ情報を与える。この情報はあるフ
ィルタ上の入力ピン・ファクトリおよび対応する出力ピ
ン・ファクトリの関係だけでなく、入力と出力のピン・
ファクトリの間でどのようなタイプの処理が行われるか
も記載している。行われる処理の例としては、異なるデ
ータ変換、データ伸張、エコー打消し(cancellation)な
どがある。このような情報は複数のフィルタを使用して
仮定上の接続パスをトレースしてから実際の接続ピン・
インスタンスおよび接続を作成する自動化フィルタ・グ
ラフ作成機能で使用すると、便利である。基本的には、
トポロジ情報はフィルタの内部構造を説明し、これをプ
ロパティ集合メカニズムを通してサード・パーティ・エ
ージェントからの照会に公開する。
【０１０７】従って、コンプライアント・ドライバは指
定されたプロパティ集合を実装しているものにすぎな
い。そのため、サード・パーティ制御エージェントは、
あるプロパティ集合がサポートされていることが分かっ
たとき、コンプライアント・フィルタに対し照会と設定
を行うことができる。全体目標は、異なるフィルタを１
つに接続してフィルタ・グラフを作る方法に関する十分
な情報を得ることである。
【０１０８】汎用集合メカニズムを使用すると、最小限
の機能を実装してコンプライアント・ドライバのシステ
ムをサポートできるが、その場合でも、拡張性は無制限
である。集合は、特定の集合が実装されている限り、相
互操作可能で相互接続可能なドライバのシステムを作成
するために多数の異なるドライバ開発者によって独立に
コーディングできる仕様書の中で定義することができ
る。さらに、この仕様書には、サポートしなければなら
ない必須のプロパティ、メソッド、およびイベントを定
義できるだけでなく、ドライバ機能と拡張機能に応じて
実装できるオプションのプロパティ、メソッド、および
イベントも定義できる。最小限に要求される基本的共通
性のほかに、ドライバ開発者は独自の集合を定義し、こ
れらにＧＵＩＤを割当てることにより追加の機能を組み
入れることも可能である。
【０１０９】次に、図９および図１０を参照して説明す
る。図は２つのカーネル・モード・フィルタを接続する
プロセスを図形化して示している。図９はロジック・ブ
ロック説明図であり、そこでは各フィルタ・インスタン
スと接続ピン・インスタンスはファイル・オブジェクト
で表されている。図１０はファイル・オブジェクトおよ
び適切な接続を作成するときのステップを示すフローチ
ャートである。
【０１１０】ステップ１４４からスタートして、フィル
タＡ１４６のインスタンスおよびフィルタＢ１４８のイ
ンスタンスはユーザ・モード・エージェントによって作
成される。これらは特定のデバイスでファイルを作成す
る標準ファイル・システムＡＰＩを使用して作成され
る。フィルタＡ１４６とフィルタＢ１４８がコンプライ
アント・フィルタまたはドライバとなっているのは、こ
れらが適切なプロパティ、メソッド、およびイベント集
合を実装して接続ピン・インスタンスの作成をサポート
し、サポートされる集合とそのフィルタ用に定義された
接続ピン・ファクトリに関してそれぞれのフィルタの機
能に照会するようになっているからである。
【０１１１】サード・パーティ制御エージェントは、ス
テップ１５０でフィルタＡ１４６とフィルタＢ１４８に
それぞれ照会し、利用可能な接続ピン・ファクトリおよ
びそれから作成できる接続ピン・インスタンスの属性を
判断する。これらの属性には、前述したように、各フィ
ルタ１４６と１４８のそれぞれのピン・ファクトリのタ
イプ別の接続フォーマットとデータ・フォーマットがあ
る。照会は、以下で詳しく説明する集合ベース照会メカ
ニズムを使用して行われる。
【０１１２】上記情報の照会を終えると、サード・パー
ティ制御エージェントは、以前に照会したデータ・フォ
ーマットと接続フォーマットの範囲に基づいて最適接続
フォーマットを決定する。この決定はステップ１５２で
行われ、選択した接続パスの要求事項に応じて同じフィ
ルタをサード・パーティ・エージェントが異なった使い
方をできるようにする。サード・パーティ制御エージェ
ントはデータ交差プロパティ(data intersection prope
rty)、トポロジ情報、および接続ピン・ファクトリを両
方のフィルタで使用して、作成される実際のフィルタ・
グラフに応じてデータ・フォーマットと接続配置の最良
の選択方法を決定する。
【０１１３】入力フィルタ・ピン・インスタンス１５４
はステップ１５２で判断された最適検出情報を使用し
て、ステップ１５６でサード・パーティ・エージェント
によって作成される。入力ピン・インスタンス１５４は
ファイル・オブジェクトであるので、ハンドルが作成プ
ロセスから返されるが、これは入出力要求を入力インス
タンス１５４へ送るために使用できる。さらに、入力ピ
ン・インスタンス１５４の作成が有効性の検査をされて
いるが、この作成には、図４〜図６、図７および図８を
参照して前述したルーチングおよびバリデーション・メ
カニズムが使用される。
【０１１４】接続を完成するために、出力ピン・インス
タンス１５８は、以前に作成された入力ピン・インスタ
ンス１５４のハンドルをNtCreateFileコールの中でパラ
メータとして使用してステップ１６０で作成される。出
力ピン・インスタンス１５８がこのようにして作成され
る効果として、システム・ファイル管理機能と入出力管
理機能を使用して内部ＩＲＰスタック構造が作成され
る。このスタック構造により、オリジナルの書込みコマ
ンドは、さまざまな方法で接続された接続ピン・インス
タンスとフィルタによって適当な順序で連続処理するこ
とが可能になるので、異なるフィルタ間の直接データ・
フローが容易化される。これを行うためには、入力ピン
・インスタンスを供給する関連出力ピン・インスタンス
の前に入力ピン・インスタンスが作成されていることが
必要である。
【０１１５】デバイス・オブジェクトのスタック深さパ
ラメータは、このドライバに送られるＩＲＰ用にスタッ
ク・ロケーションをいくつ作成するかを制御する。スタ
ック深さパラメータは、デバイス・オブジェクトが初め
て作られるときは１つであると想定されているが、複数
のドライバが１つにチェイニングされているかどうかに
応じて、あとで変更することも可能である。現システム
では、この変更は、必要ならば、出力ピン・インスタン
スが初期「停止」状態から「取得」または他の状態に遷
移するとき行われる。接続ピン・インスタンスの状態遷
移はＩＲＰを正しく作成し、処理するための正しいスタ
ック深さパラメータ情報を決定するメカニズムである。
【０１１６】チェイニングされた接続ピン・インスタン
ス集合を正しく割当てるためには、接続ピン・インスタ
ンスを特定の順序で停止状態から出るように遷移させる
必要がある。つまり、最後の入力ピン・インスタンス
（この例では、入力ピン・インスタンス１５４）から始
まって、関連の（例えば、接続された）出力ピン・イン
スタンス（この例では、出力ピン・インスタンス１５
８) まで連続的に逆方向に戻っていく必要がある。多数
のフィルタが１つにチェイニングされていれば、最も深
いフィルタまたはブリッジの入力ピン・インスタンスが
遷移の開始ポイントであって、ブリッジまたはフィルタ
上の初期出力ピン・インスタンスが設定されるまで逆方
向に連続的に構築していかなければならない。言い換え
れば、停止状態から出る遷移はチェインを逆昇るように
行われ、各接続ピン・インスタンスが前の接続ピン・イ
ンスタンスの後で必要になるスタック・サイズを得るよ
うにしなければならない。代表例として、必ずしもそう
する必要はないが、接続ピン・インスタンスは停止状態
から取得状態へ遷移するが、以下での説明の便宜上、取
得状態への遷移はスタック深さパラメータの調整に関し
ては、停止状態から出る遷移と同じ目的を果たすように
なっている。
【０１１７】すべてのピン・インスタンスが取得状態に
なったあとは、ストリーム読取りと書込みをフィルタ・
グラフに対して出すことができる。なお、注目すべきこ
とは、ここで説明しているシステムが、関連入力と出力
ピン・インスタンスの接続をどの順序でも行うことがで
き、停止状態からの遷移だけはボトムアップ方式、つま
り、最も深いものから先に行わなければならないことで
ある。さらに、フィルタ・グラフは初期作成後に変更が
行えるように再構成可能になっている。変更が行われる
ときは、状態遷移は停止状態にある接続ピン・インスタ
ンスだけで行い、正しいスタック深さパラメータ情報が
得られるようにする必要がある。
【０１１８】フィルタ上に見出される接続ピン・ファク
トリは、フィルタが特定フォーマットでデータを消費お
よび／または作成できる場所を表している。例えば、特
定の接続ピン・ファクトリは、１６ビットの４４キロヘ
ルツＰＣＭオーディオや８ビットの２２キロヘルツＰＣ
Ｍオーディオなどの、いくつかの異なるデータ・フォー
マットをサポートすることができる。前述したように、
接続ピン・ファクトリやそのデータ・フォーマットなど
の異なる機能については、適切なプロパティ集合メカニ
ズムとシステム入出力機能を使用してフィルタから照会
することができる。実際の接続ピン・インスタンスはピ
ン・ファクトリから受信した情報に基づいて作成され
る。
【０１１９】単一のストリーム書込みまたはストリーム
読取りオペレーションがユーザ・モード・エージェント
から出されると、接続されたフィルタを通してデータの
連続処理が行われるストリーミング環境では、ＩＲＰ制
御用の２つのメイン・メソッドがＮＴオペレーティング
・システムのネーティブ機能の一部として使用すること
ができる。第１のメソッドでは、個別ＩＲＰは各フィル
タによって作成され、次のフィルタへ送られて処理さ
れ、このフィルタは新しいＩＲＰを作成し、チェインを
下って次々と処理されていく。他のメソッドでは、単一
のＩＲＰが使用され、入出力マネージャと相互作用する
ために用意された標準プロシージャを使用して連続フィ
ルタ間で受け渡しされていく。チェイン上の各連続フィ
ルタごとに新しいＩＲＰを作成していく第１のメソッド
が使用される場合は、フィルタ間の相互接続順序が重要
でないのは、フィルタはＩＲＰのデスティネーション(d
estination) だけを知っていればよく、入出力マネージ
ャをコールしてＩＲＰを指定のフィルタへ送ることがで
きるからである。ＩＲＰが再使用される場合に重要なこ
とは、停止状態からの接続ピン・インスタンスの遷移が
再使用ＩＲＰを受け取る最後のフィルタから始まるよう
に行われ、再使用ＩＲＰを受け取る最初のフィルタま
で、または処理のためにＩＲＰを作成したフィルタまで
逆方向に処理していくことである。
【０１２０】相互接続カーネル・モード・フィルタの本
実施の形態と実装例は、ＩＲＰ共用を利用してドライバ
開発の複雑さを軽減し、より堅牢なドライバが作成され
ることを可能にし、処理を効率化するという利点があ
る。「ボトム・アップ」のピン・インスタンス状態遷移
パスは、正しいスタック順序が連続ドライバによって処
理されるＩＲＰに作成され、各ドライバ・オブジェクト
が適切なスタック深さパラメータ集合をもつことを保証
する。さらに、受信側入力ピン・ファクトリの現状態
は、状態遷移シーケンスを正しくたどっていたかどうか
を確かめるためにチェックされる。そのような理由か
ら、特定の接続ピン・ファクトリの通信プロパティは起
こり得るフロー方向を判断し、接続ピン・インスタンス
の状態遷移を正しく分配する上で支援する。
【０１２１】出力ピン・インスタンス（またはＩＲＰソ
ース）を作成するとき、別のフィルタ上の入力ピン・イ
ンスタンス（またはＩＲＰシンク(sink)）を表すファイ
ル・オブジェクトへの参照はNtCreateFileコールの一部
として引き渡される。適切な作成ハンドラはマルチプレ
クシング・ディスパッチ機能とデバイス・オブジェクト
／ファイル・オブジェクト階層を使用して、前述したよ
うに実行される。この作成ハンドラは入力ピン・インス
タンスをもつフィルタ（例えば、図９のフィルタＢ１４
８）のデバイス・オブジェクトを、入力接続ピン・イン
スタンス・ファイル・オブジェクト（例えば、入力ピン
・インスタンス１５４）を通してアクセスすることがで
きる。デバイス・オブジェクトから、前のスタック深さ
パラメータを読み取ることができ、出力ピン・インスタ
ンスをもつフィルタのデバイス・オブジェクトのスタッ
ク深さパラメータが増加される。例えば、フィルタＡ１
４６に関連するデバイス・オブジェクトは、図９に示す
接続ではフィルタＢ１４８に関連するデバイス・オブジ
ェクトのそれから増加されるスタック深さパラメータを
もっている。これは停止状態から出る遷移のとき行われ
るのが通常であり、ＩＲＰは接続ピン・インスタンスが
停止状態にある間はルーチングされない。
【０１２２】フィルタがＩＲＰを処理するとき、その特
定フィルタ用に指定された情報を含んでいる、ＩＲＰス
タック内のどのスタック・フレームまたはロケーション
をアクセスすべきかを、関連デバイス・オブジェクトの
スタック深さパラメータを参照するか、あるいはそれを
使用することによって知る。さらに、現フィルタは、デ
バイス・オブジェクトのスタック深さパラメータを減ら
して次のフィルタのＩＲＰスタック・ロケーションに位
置づけることによって、処理チェイン上の次のフィルタ
用のＩＲＰを準備する。
【０１２３】フィルタ・コードはＩＲＰスタック内の次
のロケーションを準備し、入出力マネージャをコールし
てＩＲＰを、指定された通りに次のフィルタに渡すこと
を受け持っている。このようにすると、フィルタは、特
定の接続ピン・インスタンスを表す、どのファイル・オ
ブジェクトがＩＲＰと関連データを受け取って処理する
かを指定することができる。従って、ＩＲＰの順次処理
のためにそれぞれのデバイス・オブジェクトをスタック
するためのIoAttachDeviceのような標準入出力マネージ
ャ・コールは使用されない。
【０１２４】注目すべきことは、接続ピン・インスタン
ス間の接続を作成することは、その接続を表すために新
しいデバイス・オブジェクトを作成することを意味しな
いことである。基礎となる単一のデバイス・オブジェク
トはフィルタのインスタンスとそのフィルタ上のすべて
の接続ピン・インスタンスをサポートするために使用さ
れる。正しいデータ処理のために必要な具体的情報はフ
ァイル・オブジェクトのコンテキスト・エリアに保存さ
れていて、コンテキスト情報はそのまま残されている
が、非ページ・メモリ使用量は最小限に保たれている。
さらに注目すべきことは、ＩＲＰベースの媒体について
説明してきたが、相互接続フィルタ間の通信のための他
の媒体も使用できることである。そのようなものとし
て、非ホスト・ハードウェアとハードウェア間通信での
直接関数コールがある。
【０１２５】次に、図１１と図１２および図１３を参照
して、図１（従来技術）と図２（相互接続カーネル・モ
ード・ドライバのハイレベル・ロジック図）に示すソフ
トウェア・ドライバの正しい作成、接続、および状態遷
移順序について説明する。図１１はボックス１６２で囲
んだロジック構造とそこに含まれる処理ステップを示し
ている。図１２は接続ピン・インスタンスを作成して、
カーネル・モード・フィルタの相互接続を完成する様子
を示し、図１３に示すフローチャートにボックス１６４
で囲んだ処理ステップを含んでいる。
【０１２６】すべての相互接続が行われている図１２の
状態にあるとき、カーネル・モード・フィルタ・システ
ムは処理を行うために読み書きの準備状態にある。入出
力システムは正しい状態遷移プロセスによって正しく設
定されたＩＲＰスタック情報を使用して、ストリーム読
取りと書込みをそれぞれの接続ピン・インスタンスを通
して異なるフィルタ・エレメントに引き渡す。なお、グ
ラフを作成するために使用されたエージェント以外の、
ある種の外部ソフトウェアは、ブリッジまたはフィルタ
自体とハードウェアも含めて、ストリーム読取りとライ
トのデータを提供する。
【０１２７】ステップ１６８からスタートしたあと、制
御エージェント１７０はステップ１８０で、リーダ・フ
ィルタ１７２、デコンプレッサ・フィルタ１７４、効果
フィルタ１７６、およびサウンド・レンダリング・フィ
ルタ１７８のインスタンスを作成する。さらに、リーダ
・フィルタ１７２とディスク・ドライバ１８２との間の
接続が行われて、データがディスク・ドライブから持ち
込まれるようにする。各フィルタ・インスタンスの作成
は標準入出力コールを使用してデバイス入出力ディレク
トリ階層に見出される適切なデバイス上のファイルをオ
ープンすることにより、ユーザ・モード制御エージェン
ト１７０によって行われる。このコールからは、各フィ
ルタのインスタンスを表すファイル・オブジェクトへの
ハンドルが返される。
【０１２８】ステップ１８４で、サード・パーティ・エ
ージェントは効果フィルタ１７２、デコンプレッサ・フ
ィルタ１７４、効果フィルタ１７６、およびサウンド・
レンダリング・フィルタ１７８に照会し、接続ピン・フ
ァクトリの機能を判断する。これらの機能は、どのよう
な種類の入出力ピン・インスタンスが作成できるか、特
定のフィルタは各接続ピン・ファクトリのインスタンス
をいくつサポートするか、各接続ピン・ファクトリでサ
ポートされるデータ・フォーマット、通信パスの媒体ま
たはタイプなどがある。これらの機能は以前に詳しく説
明したプロパティ集合メカニズムを使用して照会され、
カーネル・モード・フィルタは、適切な「集合」（例え
ば、プロパティ集合）をサポートしているのでアーキテ
クチャに従っていることが前提になっている。
【０１２９】ステップ１８４でのこのようなすべての照
会情報は、チェインニングされた接続パスが、適切な接
続ピン・インスタンスを作成し、接続することによりそ
れぞれのフィルタ間で可能であるかどうかを判断するた
めに使用される。サード・パーティ・エージェントは、
相互接続のために必要なピン・インスタンスのタイプを
判断し、与えられた目的を達成するフィルタ・グラフを
作成する。
【０１３０】サポートされるデータ・フォーマットに基
づく接続フォーマットの決定はステップ１８６で行われ
る。フィルタ上のトポロジ情報、データ・フォーマッ
ト、およびデータ交差プロパティを使用すると、仮定上
の(hypothetical)フィルタ・グラフを作成することがで
きる。接続順序は重要でないので、そのようにする必要
はないが、フィルタ・グラフを作成しようとするとき時
間を節約することができる。この仮定上のフィルタ・グ
ラフがエラーなしで作成されるのであれば、サード・パ
ーティ・エージェントは、相互接続する接続ピン・イン
スタンスの作成を信頼して行うことができるという安心
が得られる。実際のピン・インスタンスが作成されてい
なければ、ある種の照会からはエラーが返されるので、
かかる接続ピン・インスタンスを作成してから仮定上の
フィルタ・グラフを作成するようにすると、実行可能で
あるとの信頼できる指示が返されることになる。この場
合も、仮定上のフィルタ・グラフは相互接続を行う前に
テストすることが可能である。
【０１３１】正しい接続情報が分かっているとステップ
１８６で決定されると、入力ピン・インスタンスを作成
し、相互接続して、図１３のボックス１６４で囲まれた
処理ステップのループで表すことができる。このループ
はデータ・ストリームのソースから最も遠くに離れた入
力ピン・インスタンスから始まる処理ステップを含んで
いる。この最後の入力ピン・インスタンスは「最も深
い」ピン・インスタンスと呼ばれ、これは最初に作成さ
れ、そのあとに関連する出力ピン・インスタンスを続け
ることができる。従って、接続は、以前に作成された入
力ピン・インスタンスのハンドルを使用して出力ピン・
インスタンスを作成したものである。
【０１３２】このパターンは、すべての入力ピン・イン
スタンスが関連出力ピン・インスタンスとの接続の前
に、それ以後連続して作成されるように続けられる。こ
のような接続シナリオは単なる例示であり、それぞれの
出力と入力ピン・インスタンスを接続して、本発明によ
るカーネル・モード・フィルタ間の接続を形成する他の
可能な方法を限定するものではない。フィルタは、入力
ピン・インスタンスからのハンドルが別のフィルタ上の
接続された出力ピン・インスタンスの作成期間に使用さ
れる限り、実装に従ってどの順序でも接続することが可
能である。さらに、前述したように、初期作成後（およ
び使用後も）フィルタ・グラフに変更を行うことが可能
である。
【０１３３】ループの最初の繰り返しでは、入力ピン・
インスタンス１８８はステップ１９０で作成される。作
成機能からハンドルを受け取ると、サード・パーティ制
御エージェント１７０はそのハンドルをNtCreateFileコ
ールでパラメータとして使用してステップ１９４で出力
ピン・インスタンス１９２を作成する。最初の繰り返し
でこれを行うと、サウンド・レンダリング・フィルタ１
７８は、それぞれ対応する接続ピン・インスタンス１８
８と１９２を通して効果フィルタ１７６に実効的に接続
される。現実装では、NtCreateFileコールはユーザ・モ
ード・クライアントが利用できるＡＰＩの関数コールの
一部として「ラップ(wrapped) 」される。これにより、
サード・パーティ・エージェントのユーザ・モード開発
者は詳細を知る必要から解放されるので、すべての関係
機能を単一ユーザ・モードＡＰＩに集中させることがで
きる。
【０１３４】ステップ１９６で、サード・パーティ・エ
ージェントは作成すべき入力ピン・インスタンスが他に
も残っているかどうかを判断する。残っていれば、入力
ピン・インスタンスを作成し、そのあとに別のフィルタ
上の対応する出力ピン・インスタンスを続けなければな
らない。最終的には、すべての接続が行われ、サード・
パーティ制御エージェント１７０はストリーム化データ
処理に対してフィルタ・グラフを準備する。
【０１３５】以上のようにして、入力ピン・インスタン
ス２０２はステップ１９０でボックス１６４で囲まれた
ループの２回目の繰り返しで作成され、他方、出力ピン
・インスタンス２０４は入力ピン・インスタンス２０２
のハンドルをステップ１９４でその作成の一部として使
用する。最後に、この特定の例では、３回目と最後の繰
り返しで、入力ピン・インスタンス２０６が作成され、
そのあとに出力ピン・インスタンス２０８が続いて接続
が完結する。
【０１３６】ステップ１９７で、サード・パーティ制御
エージェント１７０は、フィルタ・グラフによるストリ
ーム化データ処理に備えて各接続ピン・インスタンスを
停止状態から取得状態へ遷移させる。それぞれのフィル
タのデバイス・オブジェクトの各々でスタック深さパラ
メータを正しく設定するためには、状態遷移は「最も深
い」または最後の接続ピン・インスタンス（例えば、処
理のためのデータを受け取る最後の入力ピン・インスタ
ンス）から始めて、最初の接続ピン・インスタンス（例
えば、データをグラフに送り込む最初の出力ピン・イン
スタンス）に到達するまで相互接続カーネル・モード・
フィルタのチェインを順次に「さかのぼる」ように行う
必要がある。最初のフィルタまたはブリッジはＩＲＰを
作成し、スタック・ロケーションはＩＲＰがグラフ内の
各カーネル・モード・フィルタに効率よく連続して受け
渡されるように十分に割当てられる。
【０１３７】最後に、サード・パーティ制御エージェン
ト１７０はストリーム読取りと書込みを出し、ステップ
１９８でデータを処理してからステップ２００で終了す
る。
【０１３８】前述したように、出力ピン・インスタンス
の各作成には、そこに接続された入力ピン・インスタン
スを表すファイル・オブジェクトのハンドルが必要であ
る。このファイル・オブジェクト参照は、出力ピン・イ
ンスタンスの作成ハンドラが入力ピン・インスタンスに
対応するデバイス・オブジェクトへの参照を、現在また
は将来のアクセスのためにセーブしておくことができる
ようにする。
【０１３９】もっと具体的に説明すると、これにより、
入力ピン・インスタンスを管理するデバイス・オブジェ
クトのスタック深さパラメータは、停止状態から取得ま
たは他の状態へ状態遷移するとき出力ピン・インスタン
スのドライバによってアクセスすることが可能になる。
入力ピン・インスタンスに関連するスタック深さパラメ
ータの値はアクセスされ、増加され、出力ピン・インス
タンスに対応するデバイス・オブジェクトのスタック深
さパラメータの中にセーブされる。
【０１４０】スタック深さパラメータは、共用ＩＲＰス
タック構造のどこに特定フィルタ用のスタック・フレー
ム情報が置かれているかを判断するために使用される
が、これは各フィルタごとに異なっている。フィルタを
このように相互接続し、状態遷移を正しいシーケンスで
行うと、通信をユーザ・モードにしなくても、カーネル
・モードの相互接続フィルタのチェインを下るように単
一ＩＲＰを受け渡してくことができる。
【０１４１】以上の説明から理解されるように、同一の
接続ピン・ファクトリを基礎にした複数のインスタンス
をもつことが可能である。例えば、オーディオ・ミキシ
ング・フィルタは複数のピン・インスタンスをミックス
して単一の出力ピン・インスタンスにしてから処理する
ことができる。各入力インスタンスは同一タイプであ
り、フィルタは１つのタイプの入力ピンだけをサポート
することができる。このような構成の別の例として、複
数の入力を１つの出力にする例がある。
【０１４２】逆のことを行うことも可能である。つま
り、スプリッタ・フィルタは単一入力接続ピン・インス
タンスをもち、複数の出力ピン・インスタンスを提供す
ることによりデータ・ストリームを倍にすることが可能
である。この分野の精通者ならば理解されるように、上
述してきた接続メカニズムから実際の実装とその要求条
件に応じて種々態様に変形し、種々態様に組み合わせる
ことが可能である。
【０１４３】ドライバ開発者が独立に実装できる共通メ
カニズム（例えば、プロパティ集合、メソッド集合、お
よびイベント集合）を、すべてのコンプライアント・フ
ィルタにサポートさせることによって均一性と標準化が
達成されているので、制御エージェントは異種ソフトウ
ェア・プロバイダから提供されるコンプライアント・フ
ィルタを都合よく接続することができる。さらに、接続
ピン・ファクトリの観点から見た機能の多くはある状況
では必要であっても、別の状況では必要でない場合があ
る。必要とされる接続ピン・インスタンスの決定は異な
るフィルタ間の相互接続を実際に行うサード・パーティ
制御エージェントによって最初に行われる。
【０１４４】次に、図１４を参照して説明すると、図は
複数の処理コンポーネント間で使用されるときの、バッ
ファ・アロケータ・メカニズムのオペレーションを示し
たものである。図には、特定の処理コンポーネントに関
連するバッファ間のデータ・フロー（つまり、バッファ
・フレーム間の実際のデータ転送）も示されている。コ
ントロールは各処理コンポーネントに渡されるが、デー
タは必要時にだけ転送され、一部の処理コンポーネント
はデータ操作を実行し、データを既存バッファ・フレー
ムに戻すようにしている。言い換えれば、データは新し
いバッファに転送されることなく同じロケーションで処
理されるので、「同所(in place)」で処理されると呼ば
れている。
【０１４５】シンク処理コンポーネント２１０はバッフ
ァ・アロケータ・メカニズム２１２（四角で表されてい
る）をその機能の一部としてもっている。バッファ・ア
ロケータ・メカニズムは、サウンドまたはビデオ処理カ
ード上のオンボード・メモリなどの特定のメモリにデー
タが置かれることを保証する必要のある処理コンポーネ
ントや、前のバッファがバイト位置合わせ、フレーム・
サイズなどの許容されない特性をもっているような処理
コンポーネントにだけ存在している。さらに、バッファ
・メモリのフレームを割当てるとき使用されるバッファ
・アロケータ・メカニズムへの参照は円で示され、すべ
ての処理コンポーネントはそのような参照をもってい
る。なお、ソース処理コンポーネント２１４は矢印２１
８で示すようにシンク・バッファ・アロケータ２１２を
参照するバッファ・アロケータ参照２１６をもってい
る。さらに、転送処理コンポーネント２２０はヌル（空
白）のバッファ・アロケータ参照２２２をもち、シンク
処理コンポーネント２１０も空の円２２３で示すように
ヌルのバッファ・アロケータ参照をもっている。
【０１４６】この単純な処理例では、ソース処理コンポ
ーネント２１４はシンクバッファ・アロケータ２１２を
使用してバッファ・フレーム２２４ａを割当て、バッフ
ァ・アロケータ参照２１６を使用してアクセスされる。
割当てられたフレーム２２４ａには、矢印２２６で示す
ようにソース処理コンポーネント２１４によってデータ
が満たされる。なお、ソース処理コンポーネントはある
種のデータ操作または変換を行ってから、新たに割当て
られたフレーム２２４ａにデータを書き込むことができ
る。
【０１４７】この時点で、シンク処理コンポーネント２
１４は処理を終えており、処理のコントロールを矢印２
２８で示すように変換処理コンポーネント２２０に引き
渡す。バッファ・アロケータ参照２２２の参照がヌル値
をもっており、バッファ・アロケータ・メカニズムが指
示されていないので、変換処理コンポーネント２２０
は、バッファの割当ても、データを一方のバッファから
他方のバッファへ転送することも行わない。従って、変
換処理コンポーネント２２０は矢印２３０で示すよう
に、割当てられたバッファ・フレーム２２４ｂで「同
所」のデータ変換を行う。
【０１４８】データは新しいバッファ・フレームに転送
されていないので、バッファ・フレーム２２４ａ、フレ
ーム２２４ｂ、およびフレーム２２４ｃは同じフレーム
であり、異なる処理コンポーネントへ連続して渡される
だけである。矢印２３１は割当てられたフレームがソー
ス処理コンポーネント２１４と変換処理コンポーネント
２２０の間で受け渡されることを示している。
【０１４９】最後に、変換処理コンポーネントは処理の
コントロールを、矢印２３２で示すようにシンク処理コ
ンポーネント２１０に引き渡す。なお、処理コントロー
ルと一緒に、同じフレームがフレーム２２４ｂと２２４
ｃの間で矢印２３４で示すように受け渡されて処理され
る。この場合も、図に示すように、フレーム２２４ａ、
フレーム２２４ｂ、およびフレーム２２４ｃはいずれも
ソース処理コンポーネント２１４によって最初に割当て
られた同じフレームであり、別々に示されているのは説
明の便宜上である。
【０１５０】シンク処理コンポーネント２１０はデータ
の処理を終えると、矢印２３６で示すようにバッファ内
の割当て済みフレーム２２４ｃを解放する。シンク処理
コンポーネント２１０は最早バッファを使用していない
ので、矢印２３６は内側に向かってシンク処理コンポー
ネント２１０を指しており、このフレームは割当て解除
することも再使用することも可能である。
【０１５１】図１５は、バッファ・アロケータ・メカニ
ズムが上述してきた相互接続カーネル・モード・バッフ
ァ方式でどのように論理的に実装されるかを示してい
る。図１４と図１５は共に同じフィルタ・グラフ・トポ
ロジを示し、バッファ・アロケータ・メカニズムのオペ
レーションを理解しやすくするために使用されている。
関係ドライバとその部分はそれぞれ、ユーザ・モード・
クライアントがドライバを制御することを可能にするア
クセス・ポイントをもち、これらはファイル・オブジェ
クトで表されている。相互通信はＩＲＰを使用して行わ
れる（ＩＲＰがカーネル・モード・ドライバによって作
成されたか、ユーザ・モード入出力オペレーションに応
答してＮＴエグゼクティブによって作成されたかとは無
関係である）。
【０１５２】ソース処理コンポーネント２３８のインス
タンス（ファイル・オブジェクトで表されている）は出
力ピン・インスタンス２４０（これもファイル・オブジ
ェクトで表されている）が関連づけられており、これは
別のフィルタ・インスタントの接続のソースとなってい
る。変換フィルタ２４４の「子」である入力ピン・イン
スタンス２４２は詳しく前述したように、出力ピン・イ
ンスタンス２４０への参照をもつように作成されてい
る。同様に、入力ピン・インスタンス２４８をもつシン
ク・フィルタ２４６は出力ピン・インスタンス２５０に
接続され、これは変換処理コンポーネント２４４と関係
づけられている。
【０１５３】相互接続されたカーネル・モード・ソフト
ウェア・ドライバのシステムでは、バッファ・アロケー
タ・メカニズムは入力ピン・インスタンスと関係づけら
れ、入力ピン・インスタンス上に作成または形成される
と言われている。さらに、出力ピン・インスタンスは必
要ならば、バッファ・アロケータ・メカニズムへの参照
を論理的にもち、出力ピン・インスタンスをもつフィル
タはこの参照を利用してバッファ・フレームの割当てと
新しいフレームへのデータ転送を行ってから、コントロ
ールを別の処理コンポーネントへ引き渡す。すでに説明
したように、ヌル参照は、新しいフレームへのデータ転
送が必要でないこと、および、処理を既存フレームで行
うことができることを示している（つまり、処理の後、
データは同じバッファ・フレームに戻される）。バッフ
ァ・アロケータ参照が存在するかどうかは、フィルタ・
グラフを作成したサード・パーティ制御エージェントの
初期交渉によって判断される。
【０１５４】入力ピン・インスタンス２４８上に形成さ
れたバッファ・アロケータ・メカニズムはファイル・オ
ブジェクトで表されているが、破線２５４は、出力ピン
・インスタンス２４０がバッファ・アロケータ２５２を
表すファイル・オブジェクトへの参照（例えば、ポイン
タまたはハンドル）をもっていることを示している。図
１５に示す例では、メモリのフレームはシステム・メモ
リ２５６から割当てられている。
【０１５５】フィルタは種々の方法で相互接続できるの
で、バッファ・アロケータは、用意されている場合であ
っても、必要でないことがある。バッファ・アロケータ
のインスタンスを表すファイル・オブジェクトが作成さ
れるのは、フィルタを相互接続するサード・パーティ制
御エージェントが必要であると判断した時だけである。
このようにすると、フィルタはさまざまな構成で柔軟に
接続でき、かつ、最適なデータ転送特性はそのまま保持
される。さらに、デフォルトのシステム・バッファ・ア
ロケータを用意すると、ドライバ開発者の開発作業をさ
らに削減することができる。
【０１５６】サード・パーティ制御エージェントは、架
空上のモデルを構築する一部として接続ピンに必要なバ
ッファ要件についても照会してから、実際のフィルタ接
続を行う。いくつかの実装では、ピンのインスタンス生
成前に照会を行うことが可能になっているが、本実施の
形態では、必要なバッファ要件を確かめるためには、そ
の前に実際の接続ピン・インスタンスを作成しておくこ
とが要求される。さらに、本明細書に開示されている実
施の形態では、照会は前述した集合メカニズムの使用を
通して行われる。
【０１５７】サード・パーティ・クライアントまたは制
御エージェントはカーネル・モード・フィルタの相互接
続を完成してフィルタ・グラフを作成したとき、次に、
入力ピン・インスタンス（またはシンク・ピン・インス
タンス）のハンドルを使用してアロケータ要件の交渉を
開始する。規定により、入力ピン・インスタンスは必要
なバッファ割当て量を定義し、バッファ割当てメカニズ
ムを提供するのに対し、出力ピン・インスタンスは入力
ピン・インスタンスに関連する適切なバッファ割当てメ
カニズムへの参照をもっている。この分野の当業者なら
ば理解されるように、他の規定を使用すると、バッファ
割当ての役割を入力ピン・インスタンスと出力ピン・イ
ンスタンスの間で逆にするといったように、同じ結果を
効果的に達成することができる。
【０１５８】バッファ割当ての要件は、すべてのコンプ
ライアント・フィルタによってサポートされる特定のプ
ロパティ集合メカニズムを使用して確かめられる。理解
されるように、「バッファ・アロケータ」のプロパティ
集合は、他の集合と同じようにさまざまな方法で構成す
ることが可能である。例えば、プロパティ集合は単一の
プロパティをもつことが可能であり、その場合、そのプ
ロパティはセグメント化された情報をもつデータ構造で
ある。あるいは、プロパティ集合は複数のプロパティを
もつことも可能であり、その場合、１つ１つは異なるフ
レーミング要件エレメント用となっている。データ構造
からなる単一プロパティは、すべてのフレーミング要件
情報を取り出すためにサード・パーティ制御エージェン
トが必要とするプロパティ集合照会が少なくなるので、
ある状況によってはより効率的である。さらに、単一デ
ータ構造は要件情報を照会するためだけでなく、実際の
バッファ・アロケータの作成時にパラメータを指定する
ためにも使用できる。
【０１５９】以下の表はデータ構造に、または個別的プ
ロパティとして組み入れることができるフレーミング要
件エレメントの非排他的リストを示している。また、こ
れらの表には、このようなエレメントが実施の形態でど
のような使い方がされるかの解説も含まれている。
【０１６０】
【表７】
【０１６１】
【表８】
【０１６２】
【表９】
【０１６３】この分野の当業者ならば理解されるよう
に、組み入れることができる関係フレーミング・プロパ
ティはほかにもある。さらに、ここで説明しているバッ
ファ割当てメカニズムは、表３に指定されているものよ
り多いバッファ・フレーム・エレメントが組み込まれて
いるか、そのサブセットが実装されているかに関係な
く、ほぼ同じように機能する。
【０１６４】フィルタ・グラフ要件がサード・パーティ
制御エージェントによって判断されると、次に、適切な
カーネル・モード・バッファ・アロケータを適切な入力
ピン・インスタンス上に作成することができる。クライ
アントは適切な接続ピン・インスタンスのハンドルを使
用し、バッファ・アロケータの適切な作成パラメータを
指定することによってバッファ・アロケータ・インスタ
ンスを作成する。このようにして得られた、バッファ・
アロケータを表すファイル・オブジェクトは接続ピン・
インスタンスの子となり、そのファイル・オブジェクト
とフィルタ自体のインスタンスを表すファイル・オブジ
ェクトからのコンテキスト情報を使用してそれを正しく
作成する。
【０１６５】言い換えれば、接続ピン・インスタンスの
作成をバリデーションし、メッセージを特定の接続ピン
・インスタンスの適切なハンドラへ転送するための、前
述したものと同じメカニズムはバッファ・アロケータの
インスタンスの作成にも同じように適用される。この場
合も、NtCreateFileコールはサード・パーティ制御エー
ジェントが使用できるＡＰＩの一部としてハイレベル関
数コールの中でラップされることになる。
【０１６６】バッファ・アロケータ・インスタンスはこ
こで説明している実施の形態では、作成されるとすれ
ば、入力ピン・インスタンスだけで作成される。
【０１６７】バッファ・アロケータ・インスタンスが適
切なのＡＰＩを通して出力ピン・インスタンス・ハンド
ルに対して指定されていなければ、フィルタは、ストリ
ーム入出力コントロールを通して渡されたストリーム・
セグメントがフィルタの要件に合致しているものと想定
できるので、データを同所で自由に変更することができ
る。
【０１６８】システムに用意されているデフォルト・ア
ロケータをフィルタ開発者によって使用すると、入力接
続ピン・インスタンスにバッファ割当て機能をもたせる
作業が単純化される。このデフォルト・アロケータはデ
ータをシステム・メモリから転送することができるデバ
イス・ドライバのためにシステム・メモリ・バッファ・
フレーム割当てを行うが、特定のメモリ割当てプロパテ
ィを必要とする。デフォルト・バッファ・アロケータを
使用すると、フィルタ開発者はバッファ割当てを行うコ
ードを実際に準備する作業から解放される。しかし、そ
の場合でも、フィルタは適切なプロパティ集合をサポー
トすることによって必要バッファ割当て量要求をサポー
トするように書かれることになる。
【０１６９】デフォルト・アロケータを使用するために
は、フィルタ設計者は、（１）必要バッファ割当て要件
要求に応えるコードを準備し、（２）デフォルト・アロ
ケータ作成ハンドラ参照を、デフォルト・アロケータが
関係する特定接続ピン・インスタンスのバリデーション
・テーブルに入れる。言い換えれば、アロケータ・タイ
プ・メカニズムの作成要求がフィルタを通して渡される
と、特定のＧＵＩＤストリングはバリデーション・テー
ブルで突き合わされ、デフォルト・アロケータ作成ハン
ドラへのアクセスができるようにする。
【０１７０】デフォルト・バッファ・アロケータはシス
テム・メモリを使用し、作成要求の一部として渡された
バッファ・アロケータ・フレーミング・プロパティに従
って動作する。この種のデフォルト・アロケータはその
特定機能と相互接続順序に応じて、種々の変換フィルタ
で使用される可能性がある。
【０１７１】オンボード・メモリまたは他のデバイスに
依存する記憶方式のためのバッファ・アロケータを要求
するフィルタは、バッファ・アロケータ・プロパティ集
合とメソッド集合をサポートすることで専用のバッファ
・アロケータを用意することができる。フィルタ専用ア
ロケータの場合、フィルタは機能全体を実装するプログ
ラム・コードを準備することに責任を有している。しか
し、バッファ・アロケータのオペレーションは、デフォ
ルトであるか、フィルタ専用であるかに関係なく、どの
バッファ・アロケータの場合も同じであるので、サード
・パーティ・エージェントはフィルタとバッファ・アロ
ケータを正しく相互接続することができる。
【０１７２】バッファ・アロケータを表すファイル・オ
ブジェクトは、正常に作成されたときは、データ構造を
指すポイントをファイル・コンテキスト・エリアに置い
ている。このデータ構造には、ＩＲＰを種々のＩＲＰコ
ード（例えば、作成、入出力コントロールなど）に基づ
いて指定のハンドラへ送るためのディスパッチ・テーブ
ルが、バッファ・アロケータの状態を保持するための他
のデータ・エリアと構造と共に収められている。トラッ
キングできる実装依存情報のいくつかを挙げると、バッ
ファが関係する接続ピン・インスタンスのファイル・オ
ブジェクトへの参照、割当てフレーミング要件データ構
造への参照、イベントを待っているクライアントのイベ
ント・キュー、未処理になっている割当て要求（例え
ば、ＩＲＰによって受信されたもの）のキューなどがあ
る。
【０１７３】ここで開示されている実施の形態のバッフ
ァ割当てメカニズムが利用できるインタフェース、つま
り、通信方法は２つある。まず、すべてのアロケータは
ユーザ・モード・クライアントと正しく通信するために
はＩＲＰベースのインタフェースを提供しなければなら
ない。オプションとして、割当てプール・タイプがオペ
レーティング・システムのディスッパチ・レベル（サー
ビスの限定されたサブセットが利用できるが、低優先度
のタスクがそのプロセッサでブロック・アウトされるよ
うな高さの優先度レベル）でサービスを受けることがで
きる場合は、関数テーブル・インタフェースがサポート
されるので、相互接続されたフィルタは直接関数コール
を使用して（ＤＰＣ処理時に）パフォーマンスを向上す
ることができる。これにより、ＩＲＰを入出力マネージ
ャを通して受け渡すという余分のオーバヘッドを発生す
ることなく、あるいは実行スレッドをスケジュールして
コンテキスト切替えを待つことなく、イベント通知を伝
達することができる。
【０１７４】ＩＲＰベースのインタフェースはＩＲＰを
次のように連続的に処理する。割当て要求が渡される
と、バッファ・アロケータはその要求を完了し、割当て
られたバッファ・フレームを指すポインタを戻し、すべ
てのフレームが割当てられていれば、アロケータはＩＲ
Ｐに保留(pending) のマークを付け、ＩＲＰをアロケー
タの要求キューに追加し、ほぼＦＩＦＯ順に処理され
る。最後に、アロケータは保留中というステータスをコ
ール側に戻す。
【０１７５】バッファ・フレームがアロケータに利用可
能になったとき、アロケータはＩＲＰベースのインタフ
ェースの要求キューに置かれている最初の要求を完了す
ることを試みる。以前にサービスを受けることができな
かったＩＲＰはこの要求キューに置かれ、処理のために
新たに解放されたフレームを待つことになる。これとは
逆に、要求キューで待たされている作業がなければ、そ
のフレームは空きリストに戻される。
【０１７６】直接関数コール・テーブルを使用するディ
スパッチ・レベル・インタフェースは次のように動作す
る。割当て要求が関数コール（これはＤＰＣ時に行うこ
とができる）によって渡されると、アロケータは使用可
能なフレームがあれば、そのフレームを指すポインタを
戻し、さもなければ、ヌル（空白）を直ちに戻す。この
場合、カーネル・モード・リクエスタは空きフレームが
あることを知らせる空きイベント通知を待つことができ
る。この通知を受けると、カーネル・モード・リクエス
タは割当て要求を再度試みる。
【０１７７】なお、ディスパッチ・レベル・インタフェ
ースとＩＲＰベースのインタフェースのどちらもが使用
可能な空きフレームを奪い合うことが起こり得る。ま
た、完了待ちに置かれている割当て要求ＩＲＰが要求キ
ューに残っていれば、アロケータは、コール側がフレー
ムを解放したとき現ＩＲＱＬが受動レベルになければ、
ワーカ・アイテム(worker item) をスケジュールしなけ
ればならないが、これは、直接コール・インタフェース
を使用することはＤＰＣレベルにある可能性を意味する
からである。基本的には、ＩＲＰの待ち行列はワーカ・
アイテムが実行されるまでは空きフレームを探し出さな
い。
【０１７８】さらに、ここで説明しているバッファ・ア
ロケータ・メカニズムはＭＤＬ（memory descriptor li
st：メモリ記述子リスト）と一緒に使用するのに適して
いるので、バッファ間の転送数をさらに削減することが
できる。このような実装によると、ＮＴオペレーティン
グ・システムのシステム・メモリ機能とのシームレスな
相互作用が向上することになる。
【０１７９】次に、図１６を参照して説明すると、同図
には前述したバッファ割当てメカニズムを利用する図１
１と図１２の相互接続フィルタ・システムが示されてい
る。制御エージェント１７０はフィルタ間の相互接続を
行ったあと、必要バッファ量について各入力ピン・イン
スタンスに照会する。図に示すように、サウンド・レン
ダリング・フィルタ１７８はバッファ・フレームをサウ
ンド・カード・メモリ２５８から割当てる必要があり、
デコンプレッサ・フィルタ１７４はデータをディスク・
ドライブ２６２から直接に受け取ることができるシステ
ム・メモリ２６０からメモリを割当てることになる。
【０１８０】制御エージェント１７０はファイル・オブ
ジェクトで表され、入力ピン・インスタンス１８８上に
形成されるバッファ・アロケータ２６４を作成する。バ
ッファ・アロケータ２６４はバッファ・フレームをサウ
ンド・カード・メモリ２５８から割当て、バッファ・ア
ロケータ２６４への参照は破線２６６で示された出力ピ
ン・インスタンス２０４に設定される。この参照はバッ
ファ・アロケータ２６４を表すファイル・オブジェクト
へのハンドルとなり、必要時にバッファ・フレームを割
当てるためにデコンプレッサ・フィルタ１７４によって
使用されてからデータが新しいバッファに転送される。
【０１８１】同じように、バッファ・アロケータ２６８
もファイル・オブジェクトによって表され、入力ピン・
インスタンス２０６上に作成される。このバッファ・ア
ロケータ２６８はシステム・メモリ２６０の割当てを管
理する。制御エージェント１７０はバッファ・アロケー
タ２６８を作成したあと、破線２７０で示すようにその
参照を出力ピン・インスタンスにストアする。この場合
も、バッファ・アロケータ２６８はシステム・メモリ２
６０間のバッファ・フレームの割当てを担当し、データ
がディスク２６２からそこに転送できるようにする。
【０１８２】制御エージェントは出力ピン・インスタン
ス１９２のバッファ・アロケータ参照の値にヌル（空
白）を入れ、同所変換が行われることを示し、効果フィ
ルタ１７６はサウンド・カード・メモリ２５８内の既存
バッファからデータを読み取り、必要とされる変換また
は効果を適用したあとでデータをサウンド・カード・メ
モリ２５８に戻す。逆に、制御エージェントがバッファ
・アロケータ参照を設定していなければ、値が空白であ
り、同所変換が行われると想定される。
【０１８３】次に、図１７のフローチャートと図１６の
ロジック図を参照して、バッファ・アロケータのオペレ
ーションについて説明する。このプロセスは相互接続が
行われたあとで実行され、ストリーム読取りと書込みは
制御エージェント１７０からリーダ・フィルタ１７２に
渡される。
【０１８４】最初に、リーダ・フィルタ１７２はステッ
プ２７２で、デコンプレッサ・フィルタ１７４のバッフ
ァ・アロケータ２６８を使用してシステム・メモリにフ
レームを割当てる。リーダ・フィルタ１７２の出力ピン
・インスタンス２０８はライン２７０で示すように、バ
ッファ・アロケータ２６８を表すファイル・オブジェク
トへのハンドルを受け取るので、直接にアクセスしてバ
ッファ・アロケータ２６８を制御することができる。
【０１８５】ファイル・リーダ・フィルタ１７２はシス
テム・メモリ２６０内の実際のバッファ・フレームへの
アクセス権を得ると、ステップ２７６で矢印２７４で示
すように、ディスク２６２からのデータをフレームに入
れる。このことから理解されるように、リーダ・フィル
タ１７２はデータをシステム・メモリ２６０に持ち込む
とき、変換または他の操作をデータに対して行うことが
できる。
【０１８６】次に、ファイル・リーダ・フィルタ１７２
はステップ２７８でデコンプレッサ・フィルタ１７４へ
のストリーム書込みを開始する。このストリーム書込み
はＩＲＰによってＮＴ入出力マネージャに渡される。ス
テップ２８０で、デコンプレッサ・フィルタ１７４はバ
ッファ・アロケータ２６４を使用してサウンド・カード
・メモリ２５８のフレームを割当てる。デコンプレッサ
・フィルタ１７４がバッファ・アロケータ２６４を知っ
ているのは、そこへのハンドルが出力ピン・インスタン
ス２０４に対してストアされていたためである。
【０１８７】デコンプレッサ・フィルタ１７４はデータ
を伸張し、矢印２８４で示すようにそのデータを、サウ
ンド・カード・メモリ２５８に以前に割当てられたフレ
ームに転送する。なお、データを伸張するとき、サウン
ド・カード・メモリから割当てられたフレームがシステ
ム・メモリに存在するよりも多くなっている場合があ
る。この余剰バッファ・フレーム比が必要になるのは、
データの伸張効果を受け入れるためである。
【０１８８】重要なことは、データを一方のバッファか
ら他方のバッファへ転送するとき、転送されるデータ量
が１：１の対応関係でない場合があることである。言い
換えれば、受信側バッファが必要とするスペース（また
はフレーム数）は、バッファ転送間でどのようなフィル
タリングまたは変換が行われるかに応じて、多くなる場
合と少なくなる場合とがある。
【０１８９】デコンプレッサ・フィルタ１７４は特定フ
レームの伸張を終えると、ＮＴ入出力マネージャの機能
を使用してストリーム書込みを効果フィルタ１７６に渡
す。効果フィルタ１７６はステップ２８８でストリーム
書込みＩＲＰを受け取り、既存サウンド・カード・メモ
リ２５８でデータを同所処理する。この効果処理はデー
タを１：１で置換するのと同じであるので、必要なバッ
ファ・メモリは多くなることも、少なくなることもな
い。
【０１９０】効果フィルタ１７６がデータの同所処理を
終えると、ストリーム書込みＩＲＰはステップ２９０で
サウンド・レンダリング・フィルタに渡される。この場
合も、ストリーム書込みＩＲＰをサウンド・レンダリン
グ・フィルタ１７８に転送させるメカニズムは効果フィ
ルタ１７６によってコールされたＮＴ入出力マネージャ
の機能である。
【０１９１】最後に、サウンド・レンダリング・フィル
タ１７８はステップ２９２でストリーム書込みＩＲＰを
受け取り、サウンド・カード・メモリ２５８に存在する
サウンド・データの実際のレンダリングを形成するよう
にサウンド・カード・ハードウェアを制御する。この時
点で、以前に割当てられていたサウンド・カード・バッ
ファ・フレームは書込み要求を満たすために再使用する
ことも、未処理の要求がなければ解放することもでき
る。バッファ・フレームが使用可能であることはデコン
プレッサ・フィルタ１７４に知らされるので、待ちに置
かれているストリーム書込みを使用してデータを処理
し、割当てが解放されたバッファ・フレームに入れるこ
とができる。同様に、システム・メモリ２６０のバッフ
ァ・フレームは再使用されるか、解放される。
【０１９２】次に、図１８を参照して説明すると、図は
システムの概要を示す図であり、そこでは、リアルタイ
ムで生成され、「ライブ」であると呼ばれる２つのデー
タ・ストリームをマスタ・クロック・メカニズムを使用
して同期化することが可能になっている。オーディオ・
レンダラ２９６は矢印３００で示すように、ライブ・オ
ーディオ・ストリーム２９８を受信して処理する。オー
ディオ・レンダラ２９６がデータを処理するとき、オー
ディオ・レンダラ２９６がデータ・サンプルを適切な電
子信号に変換して、この信号を矢印３０４で示すように
スピーカ３０２に送信すると、データはスピーカ３０２
からサウンドとして知覚される。
【０１９３】同様に、ビデオ・レンダラ３０６は矢印３
１０で示すようにライブ・ビデオ・ストリーム３０８を
受信して処理する。ビデオ・レンダラ３０６によって処
理されると、データ・サンプルは適切なビデオ信号に変
換され、矢印３１４で示すようにモニタ３１２に送ら
れ、そこでデータ・サンプルはイメージとして知覚され
る。
【０１９４】代表例として、ライブ・ビデオ・ストリー
ム３０８とライブ・オーディオ・ストリーム２９８は同
時にレンダリング・コンポーネントに着信する。コヒー
レントなプレゼンテーションを再現するために、スピー
カ３０２とモニタ３１２でレンダリングされるときビデ
オをオーディオと整合させることは重要であるので、ラ
イブ・ビデオ・ストリーム３０８とライブ・オーディオ
・ストリーム２９８の処理は同期化されなければならな
い。
【０１９５】これを行なうためには、一方のデータ・ス
トリームがマスタとなるように選択される。ここでは、
説明の便宜上、ライブ・オーディオ・ストリーム２９８
がマスタ・データ・ストリームとなるように任意的に選
択されている。なお、ライブ・ビデオ・ストリーム３０
８がマスタとして選択されることも、他のデータ・スト
リームがマスタとして選択されることも可能であり、そ
れを妨げるものはなにもない。さらに、フィルタ・グラ
フの外部にあるデータ・ストリームに基づく外部クロッ
クを使用して、ライブ・オーディオ・ストリーム２９８
とライブ・ビデオ・ストリーム３０８を共に同期化する
ことが可能である。従って、図示のマスタ・クロック・
メカニズム３１６では、実線でオーディオ・レンダラ２
９６と結ばれ、破線３１８でビデオ・レンダラと結ばれ
ているが、このことは、ビデオ・レンダラがオーディオ
・ストリームをマスタとして使用しているマスタ・クロ
ック３１６から同期化情報をなんらかの方法で受信する
ことを示している。
【０１９６】マスタ・クロック３１６は、オーディオ・
レンダラ２９６での処理レートをオリジナル・オーディ
オ・ストリーム２９８のレートと整合するためにオーデ
ィオ・レンダラ２９６によって使用することも可能であ
る。言い換えれば、ライブ・オーディオ・ストリーム２
９８は、別のシステム上のディジタル化フィルタ／ディ
ジタル化ハードウェアなどの別の処理コンポーネントに
よって処理されている。オーディオ・ストリームはディ
ジタル化サンプルから構成されているので、これらのサ
ンプルはオリジナル処理コンポーネントのハードウェア
およびオシレータに従うレートで作られている。オリジ
ナル処理コンポーネントがライブ・オーディオ・ストリ
ーム２９８を出力するときの、この発生レート(origina
tion rate)はライブ・オーディオ・ストリーム２９８の
インターバル情報の中に入っているか、そこから得られ
ている。
【０１９７】データ・ストリームに入っているサンプル
情報には、いくつかの方法で時間インターバル情報を収
めることができる。１つの方法は、各サンプルまたはサ
ンプル・グループにタイムスタンプを関連づけることで
ある。さらに、データのフォーマット自体にサンプル・
レートを意味させることもできる。例えば、データ・フ
ォーマットの定義によって、一定時間インターバル（例
えば、ビデオ・サンプルでは１／３０秒単位、オーディ
オ・データでは１／２２，０５０秒単位）で各サンプル
をとることができる。さらに、タイムスタンプがレンダ
リング処理ユニットでクロックと整合されるプレゼンテ
ーション時間を示すようにすれば、特定のサンプルをい
つレンダリングまたは「プレゼンテーション」するべき
かを判断することができる。また、タイムスタンプは、
タイムスタンプ間の相対的差から時間インターバル情報
を知ることができる、ある種の他の時間値を示すことも
できる。最後に、データ・フォーマットとタイムスタン
プ情報をミックスして使用すると、処理される参照デー
タ・ストリーム内の位置に基づいてタイムクロックを作
成するときに必要になる時間インターバル情報を得るこ
とができる。
【０１９８】以上から理解されるように、時間またはデ
ータ・ギャップに基づいて、データ・ストリームの中に
「中断(discontinuities) 」をコーディングすることが
できる。時間的中断とは、レコーディングがある時刻に
終了し、その後のある時刻に突然開始するときのよう
に、ストリームが単純に別のプレゼンテーション時刻に
ジャンプすることである。データの中断とは、沈黙の周
期をあるコードで表し、そのあとに沈黙の持続時間が続
くといったように、ストリームがそのストリームの中に
より効率的にコーディングできる反復データの周期をも
つことができる場所である。
【０１９９】マスタ・クロック３１６から得られるある
時間値はデータ・サンプルのストリームに入っている時
間インターバル情報に基づいており、メディア時間と呼
ばれている。メディア時間は、マスタ・ストリーム内の
位置を表しているので位置時間であり、この場合、マス
タ・ストリームはライブ・オーディオ・ストリーム２９
８として選択されている。さらに、処理がオーディオ・
レンダラ２９６で終了したとき、メディア時間もマスタ
・クロック３１６で凍結される。データ・ストリーム内
の中断はストリーム内のその「位置」まで処理され、基
礎となるハードウェア・オシレータまたは他のソースを
使用して時間の進みをトラッキングすることによって、
中断にある間進み続ける。このようにすると、複数のデ
ータ・ストリームを、時間またはデータの中断を有する
データ・ストリームと同期させることができる。
【０２００】ビデオ・レンダラ３０６をマスタ・クロッ
ク３１６に入っているメディア時間と同期させ、マスタ
・クロックの方をライブ・オーディオ・ストリーム２９
８に入っている時間インターバル情報に基づかせると、
メディア時間はライブ・オーディオ・ストリーム２９６
がオーディオ・レンダラ２９６で処理される時だけ進む
（「刻時(ticks) 」）するので、停止または休止状態を
管理するためのオーバヘッドが不要になる。
【０２０１】以上から理解されるように、ビデオ・スト
リーム３０８も、同期化と同時にレート整合を行う必要
がある。ビデオ・ストリーム３０８のレート整合はライ
ブ・オーディオ・ストリーム２９８およびオーディオ・
レンダラ２９６に関して以下で説明するのと同じ方法で
行われる。当然のことであるが、ライブ・ビデオ・スト
リーム３０８のレート整合はビデオ・レンダラ２９６の
ハードウェア・オシレータ（物理時間）に基づいてい
る。
【０２０２】マスタ・クロック３１６から得られるもの
として、オーディオ・レンダラ２９６内の基礎となるハ
ードウェアに基づく物理時間もある。物理時間は、オー
ディオ・レンダラ２９６がアクティブ状態でオーディオ
・データを処理しているか、停止または休止状態にある
かに関係なく、進んでいくのが通常である。さらに、メ
ディア時間（発生側ハードウェア処理レートを表す）お
よび物理時間（オーディオ・レンダラ２９６での実際の
処理レートを表す）の進みレートをサンプリングする
と、レートが相対的に整合されるようにオーディオ・レ
ンダラで調整を行ってライブ・オーディオ・データ２９
８を処理することができる。
【０２０３】レート整合は、ストリーム・データをロー
カル・ディスクや他の記憶デバイスから読み取るといっ
たように、データ発生のレートがプロセッサの制御下に
置かれているときは重要な問題とならないが、データを
連続的に発生する「ライブ」データ・ストリームを処理
し、発生レートがプロセッサの制御下に置かれていない
ときは重要な問題となる。ここで用いられている「ライ
ブ」データまたはメディア・ストリームとは、処理コン
ポーネントの制御下に置かれていないレートで発生する
ストリームのことであり、完全にリアルタイムで処理さ
れないと失われるようなストリームである。ライブ・デ
ータ・ストリームの例としては、次のようなものがある
が、これらに限定されるものではない。つまり、ストリ
ームがローカルまたはネットワーク接続を介してリアル
タイムで発生するようなリアルタイム・フィード、リア
ルタイム・フィードであるか、ネットワークを介して送
られてきたストア済みデータであるかに関係なく、スト
リームをネットワーク接続から受信することなどがあ
る。いずれの場合も、ストリームはその受信と同時に処
理されなければならない。
【０２０４】ライブ・メディア・ストリームが発生する
データが多すぎるため、オーディオ・レンダラ２９６が
処理できないときは、オーディオ・レンダラ２９６は、
バッファリング容量に限りがあるためデータ「あふれ(f
ollding)」と呼ばれる状態が起こり、最終的にはデータ
を失うことになる。他方、ライブ・オーディオ・ストリ
ームがオーディオ・レンダラ２９６よりも低レートでデ
ータを発生する場合には、オーディオ・レンダラには、
処理すべきデータがなくなるというデータ「枯渇(starv
ation)」状態が起こることになる。どちらの場合も、オ
ーディオ・レンダラ２９６でのレンダリング・レート
を、ライブ・オーディオ・ストリーム２９８内の時間イ
ンタバール情報で表されている発生レートに一致するよ
うに調整を行うと、ライブ・オーディオ・ストリーム２
９８のレンダリングが高品質に行われるという利点があ
る。
【０２０５】レート補正調整を行う１つの方法は、オー
ディオ・レンダラにデータ枯渇が起こらないようにデー
タ・サンプルを周期的に複製するか、あるいはオーディ
オ・レンダラがその能力を超えて出力するライブ・オー
ディオ・ストリーム２９８に追いつくようにサンプルを
捨てることである。どちらの場合も、データ・サンプル
の複製または破棄は、スピーカ３０２で知覚される影響
量が最小になるようにストリーム処理時に間隔を置いて
行うのが賢明である。
【０２０６】マスタ・クロック３１６と直接に同期をと
るのではなく、マスタ・クロック３１６に入っているメ
ディア時間に一致するように別のクロックのタイムベー
スを変換するか、あるいはマスタ・クロック３１６のメ
ディア時間に一致するように別のメディア・ストリーム
内のプレゼンテーション時間情報を変換するようにする
と便利である。この変換を行いやすくするために、マス
タ・クロック３１６は２つの別個の時間値、つまり、メ
ディア時間値と他のコンポーネントに共通の参照時間値
とからなる相関メディア時間値を提供し、これをアトミ
ック・オペレーションで行ってタイミング誤差の発生を
低減化している。相関物理時間値も提供される。
【０２０７】参照時間は、すべての処理コンポーネント
が利用できるＰＣクロックまたはシステム上の他のクロ
ック・メカニズムに基づいているのが代表的であるが、
別のクロックを選択することも可能である。アトミック
・オペレーションはネーティブ・システム機能を利用し
て、中断または干渉量を最小にして両方の値が取り出せ
るように実装する。相関時間（メディアまたは物理）は
フィルタなどの別の処理コンポーネントが使用して、メ
ディア時間と参照時間との相対的オフセットまたはデル
タを判断し、発生誤差を最小にして必要な変換を行うこ
とができる。これについては、以下で詳しく説明する。
【０２０８】次に、図１９および図２０を参照して説明
すると、上述したクロック・メカニズムは前述した相互
接続フィルタ・システムと共に実装されている。図１
９、オーディオ・ストリームと同期がとられ、マスタ・
クロック・メカニズムから同期化情報を受け取るライブ
・ビデオ・ストリーム処理フィルタの集合を示してい
る。図２０は、マスタ・クロック・メカニズムのマスタ
時間参照を生成するために使用されるライブ・オーディ
オ・ストリームをレンダリングするための相互接続フィ
ルタの集合を示している。
【０２０９】まず、図１９に示すビデオ・ストリーム処
理コンポーネントについて説明すると、ライブ・ビデオ
・ストリーム３２０は矢印３２４で示すように、ビデオ
・リーダ・フィルタ３２２によって受信される。ライブ
・ビデオ・ストリーム３２０のソースとしては、コンピ
ュータに置かれたオンボード・ディジタル化ハードウェ
ア、コンピュータ・ネットワーク経由で受信されるディ
ジタル・サンプルのパケットなどがある。ライブ・ビデ
オ・ストリーム３２０は実際のビデオ・イメージにレン
ダリングできるディジタル化サンプルから構成され、こ
れらのサンプルは前述したように時間インターバル情報
が関連づけられている。この場合も、ここで説明してい
る相互接続フィルタ・システムによれば、ビデオ・リー
ダ・フィルタ３２２はファイル：オブジェクトで表され
ている。
【０２１０】ビデオ・リーダ・フィルタ３２２は、ビデ
オ・デコンプレッサ・フィルタ３３０上の入力ピン・イ
ンスタンス３２８に接続された出力ピン・インスタンス
３２６をもっている。ビデオ・デコンプレッサ・フィル
タ３３０はライブ・ビデオ・データを圧縮フォーマット
で受信し、そのデータをビデオ・レンダリング・ハード
ウェアに受け付けられるフォーマットに伸張する。ビデ
オ・データのフレームを処理すると、デコンプレッサ・
フィルタはコントロールをビデオ・レンダリング・フィ
ルタ３３２に渡す。ビデオ・レンダラ・フィルタ３３２
とビデオ・デコンプレッサ・フィルタ３３０との接続
は、それぞれ出力ピン・インスタンス３３４と入力ピン
・インスタンス３３６によって行われる。
【０２１１】入力ピン・インスタンス３３６は同期化の
ためのタイミング指示を、ボックス３３８と破線３４０
で示すように、オーディオ・ストリーム処理コンポーネ
ント内のマスタ・クロック・メカニズムから受信する
（図１８参照）。この同期化タイミング情報を受信する
には、さまざまな方法が可能である。まず、図１９と図
２０に示すフィルタ・グラフ・トポロジを相互接続する
制御エージェント３４２はマスタ・オーディオ・ストリ
ーム内の特定の位置（つまり、時間）に基づいてクロッ
ク・メカニズム３４４にイベント通知を行わせること
も、特定の時間インターバルを選択してインターバル・
イベント通知を行うことも可能である。別の方法とし
て、ビデオ・レンダリング・フィルタ３３２はクロック
・メカニズム３４４に照会することも可能である（図２
０参照）。クロック・メカニズム３４４はファイル・オ
ブジェクトで表されているので、制御エージェント３４
２はクロック・メカニズム３４４への該当する参照を入
力ピン・インスタンス３３６またはビデオ・レンダラ・
フィルタ３３２に対して行うことができるので、ビデオ
・レンダラ・フィルタ３３２はクロック・メカニズムに
照会して相関時間値を得て、必要ならば変換を行うこと
も、メディア時間値を得て処理が同期化されていること
を確かめることもできる。
【０２１２】最後に、ビデオ・レンダラ・フィルタ３３
２はビデオ・ハードウェア３４６を制御し、データを矢
印３４８で示すようにそこへ転送する。ビデオ・ハード
ウェアはデータをレンダリングし、イメージをモニタ３
５０から表示させるビデオ信号を生成する。
【０２１３】次に、図２０を参照して、ライブ・オーデ
ィオ・ストリームの処理コンポーネントについて詳しく
説明する。この場合も、同じ制御エージェント３４２
は、必要ならば入力ピン・インスタンスおよび出力ピン
・インスタンスと一緒にそれぞれのフィルタ・インスタ
ンスを作成し、それぞれのフィルタ間の相互接続を行う
が、カーネル・モード・フィルタ・グラフ・トポロジ全
体を作成するのは制御エージェントである。
【０２１４】ライブ・オーディオ・ストリーム３５２は
最初に、矢印３５６で示すようにオーディオ・リーダ・
フィルタ３５４によってフィルタ・グラフ・トポロジに
持ち込まれる。データはそれぞれの出力ピン・インスタ
ンス３６０と入力ピン・インスタンス３６２を使用して
オーディオ・リーダ・ファイルに接続されているオーデ
ィオ・デコンプレッサ・フィルタ３５８によって伸張さ
れる。この場合も、ここで説明している各フィルタと接
続ピン・インスタンスはファイル・オブジェクトで表さ
れ、前述したように作成される。
【０２１５】オーディオ・デコンプレッサ・フィルタは
それぞれ出力ピン・インスタンス３６６と入力ピン・イ
ンスタンス３６８を通してオーディオ・レンダラ・フィ
ルタ３６４に接続されている。入力ピン・インスタンス
３６８と関連づけられているものとして、メディア時
間、物理時間、および／または相関時間を提供またはそ
の通知を他のエンティティへ送信するクロック・メカニ
ズム３４４のインスタンス、特に、ボックス３７０と破
線３７２で示すようにビデオ・レンダラ・フィルタ３３
２（図１９参照）の入力ピン・インスタンス３３６があ
る。クロック・メカニズム３４４の実際の実装と利用可
能性については、以下で詳しく説明する。このクロック
・メカニズム３４４を使用すると、他のデータ・ストリ
ームは、図２０に示すようにその処理を「マスタ」また
は「参照」オーディオ・ストリーム３５２の処理と同期
化することができる。
【０２１６】オーディオ・レンダラ・フィルタ３６４は
オーディオ・ハードウェア３７４を制御し、制御情報と
データを矢印３７６で示すように引き渡す。オーディオ
・ハードウェアは、オーディオ・レンダラ・フィルタ３
６４の制御の下で、ディジタル化データ・サンプルをス
ピーカ３７８へ送信し、そこから知覚されるようにする
リアルタイム電子信号にレンダリングする。
【０２１７】相互接続カーネル・モード・フィルタを前
述したように作成するとき、各フィルタ・インスタンス
はシステムが利用できる「デバイス」から作成される。
このようにすると、ビデオ・リーダ・フィルタ３２２と
オーディオ・リーダ・フィルタ３５４は同じファイル・
リーダ・デバイスの別々のインスタンスにすることがで
きる。
【０２１８】さらに、特定のフィルタは接続ピン・イン
スタンスを作成するために多数の接続ピン・ファクトリ
をサポートできるので、デコンプレッサ・フィルタ３３
０とオーディオ・デコンプレッサは同じデコンプレッサ
・デバイスのインスタンスにすることができる。制御エ
ージェントがそれぞれのフィルタ・インスタンス上に接
続ピン・インスタンスを作成するとき、フィルタを通し
て処理されるデータのタイプに応じて異なるピン・ファ
クトリが接続ピン・インスタンスを作成するときのテン
プレートとして選択される。これは、ここで説明してい
る相互接続カーネル・モード・フィルタ・システムが本
来的に備えた柔軟性である。
【０２１９】クロック・メカニズム３４４を形成するた
めには、制御エージェント３４２は、オーディオ・レン
ダラ・フィルタ３６４上の入力ピン・インスタンス３６
８のように、接続ピン・インスタンスに照会してクロッ
ク・メカニズムが使用可能であるかどうかを判断するの
が代表的である。他の実装では、制御エージェント３４
２は接続ピン・インスタンス上にクロック・メカニズム
を作成することを試みるだけで、クロック・メカニズム
が使用可能かどうかを試行錯誤で判断できるようになっ
ている。さらに、クロック・メカニズムはユーザ・モー
ドで存在し、そのクロックまたは他のメカニズムのカー
ネル・モード・プロキシを通して通知などを、カーネル
・モードのフィルタの入力ピン・インスタンスに送信す
ることができる。
【０２２０】実施の形態では、選択した規則により、タ
イミング・イベント通知とクロック・メカニズムは入力
接続ピン・インスタンスと関連づけられて通常見つけら
れる。しかし、明らかなように、ファイル・オブジェク
トで表されたどのエンティティも、イベント要求をＩＲ
Ｐを通して受け取ることも、前のＩＲＰ要求を通して直
接プロシージャ・コール・テーブルを検索した後で直接
プロシージャ・コールで受け取ることも可能である。
【０２２１】デフォルトとして実装したクロック・メカ
ニズムがシステムに用意されているので、これをソフト
ウェア・フィルタ開発者に提供または利用できるように
すると、余分のコードを開発しなくてもタイミング機能
を得ることが可能である。どのクロック・メカニズム
（デフォルト版またはカスタムとして供給）の形成も、
作成要求の中でＧＵＩＤストリング値を指定することに
よって行われるが、このストリング値は接続ピン・イン
スタンス・バイリデーション・テーブルで使用されて、
クロック・メカニズムを接続ピン・インスタンス上に作
成するための正しい作成ハンドラをアクセスできるよう
にする。ファイル・オブジェクトの作成、バリデーショ
ン、およびＩＲＰの指定のプロセスは図３〜図８を参照
して詳しく前述した通りである。接続ピン・インスタン
スを作成するのと同じように、クロック・メカニズム作
成要求は正しくパス選択し、正当性を調べることができ
る。
【０２２２】システムに用意されているデフォルト・ク
ロックを使用するためには、ドライバ開発者は作成し、
システムに用意している作成ハンドラの中からデフォル
ト・クロック作成メソッドをコールする。この作成ハン
ドラは接続ピン・インスタンスを表すファイル・オブジ
ェクトのコンテキスト・エリアから前述したようにアク
セスされる。従って、ドライバ開発者はドライバ専用ク
ロック・メカニズムを実装し、適切なドライバ専用作成
ハンドラはバリデーション・テーブルに置かれることに
なる。作成ハンドラ開発の複雑性はクロック機能をコー
ディングし、実装するのではなく、デフォルト・クロッ
ク作成メソッドをコールすることによって低減化され
る。
【０２２３】クロック・メカニズムをこれまでに説明し
てきた相互接続フィルタ・システムに従って作成する場
合は、そのクロック・メカニズムは特定のプロパティ集
合とイベント集合をサポートしていなければならない。
当然のことながら、デフォルト・クロック・メカニズム
は特定の集合をサポートしているが、フィルタ専用クロ
ック・メカニズムの場合は、フィルタ開発者はクロック
・メカニズムのプロパティ集合とイベント集合を実装す
るコードを書いて、用意しておく必要がある。このよう
にすると、クロック・メカニズムへのハンドルをもつ制
御エージェントは特定の集合がサポートされるかどうか
を照会し、クロック・メカニズムの操作方法を知ること
ができる。以下に示す表４は、クロック・メカニズムの
プロパティ集合に含めることができる、いくつかのプロ
パティを示したものである。
【０２２４】
【表１０】
【０２２５】
【表１１】
【０２２６】
【表１２】
【０２２７】
【表１３】
【０２２８】この分野の当業者ならば理解されるよう
に、表４にリストされている以外のプロパティまたは表
４にリストされているプロパティのサブセットを使用し
て、ここで説明している相互接続フィルタ・システムに
準拠する機能をもつクロック・メカニズム・プロパティ
集合を作ることも可能である。さらに、プロパティ集合
メカニズムには柔軟性があるので、独自のタイミング機
能をもつフィルタ開発者は独自のＧＵＩＤをもつ別のプ
ロパティ集合を追加することによって「必須」のプロパ
ティ集合を拡張すると、より拡張した機能を得ることが
できる。集合メカニズムには、フィルタ開発者が最小限
の機能量を実施して、フィルタをシステム・アーキテク
チャに準拠させることができるという柔軟性があると同
時に、フィルタ開発者がカストマイズして追加の機能を
追加できるという無限性がある。
【０２２９】プロパティ集合によると、カーネル・モー
ド・フィルタなどの他の処理コンポーネントは関係する
時間プロパティについて照会することができるが、クロ
ック・メカニズムはイベント集合もサポートするので、
通知をイベント通知ＩＲＰを通して関係のクロック・メ
カニズム・クライアントに直接に送信することができ
る。ファイル・オブジェクトのハンドルはイベントを割
込み可能にする一部としてクロック・メカニズムに「登
録」しておくと、クロック・メカニズムはイベント通知
をどこに送信すべきかを知ることができる。オプション
として、直接関数コール・ハンドルはＤＰＣ処理がカー
ネル・モード・エンティティ間で行えるように使用する
と、パフォーマンスを向上することができる。
【０２３０】以下に示す表５は、コンプライアント・ド
ライバにサポートさせることができるイベント集合を構
成する、起こり得る通知イベントのいくつかを示したも
のである。サード・パーティ制御エージェントはイベン
トを受け取るエンティティを、特定のフィルタ・グラフ
・トポロジに基づいて相互接続または登録することがで
きる。
【０２３１】
【表１４】
【０２３２】当業者ならば理解されるように、他のタイ
ミング関係イベントをクロック・メカニズムに対して作
成することが可能である。例えば、イベントはクロック
・メカニズムがサポートできる異種の時間別（つまり、
メディア時間または物理時間）に分類することが可能で
ある。さらに、インターバル・イベントと位置イベン
ト、さらには状態変化に基づく他のイベントのエレメン
トを組み合わせると、「ハイブリッド」イベントにする
ことも可能である。
【０２３３】次に、図２１（Ａ）を参照して説明する
と、同図は、１つまたは２つ以上の「スレーブ」処理コ
ンポーネントまたはフィルタを、「マスタ」メディア処
理時間に基づいて同期化する方法を示している。ステッ
プ３８０からスタートして、スレーブ処理コンポーネン
トまたはフィルタはステップ３８２でマスタ・クロック
・メディア時間値を受信する。この受信は、スレーブ・
フィルタまたはコンポーネントがマスタ・クロック・メ
カニズムに照会してメディア時間値を得ることによって
行われるが、マスタ・クロック・メカニズムが通知をス
レーブ処理コンポーネントまたはフィルタに送信するこ
とも可能である。図２１（Ａ）のフローチャートに示さ
れている方法を図１９と図２０に示すフィルタ・グラフ
・トポロジに適用すると、マスタ・クロック・メカニズ
ムは３４４は、ビデオ・レンダラ・フィルタ３３２の入
力ピン・インスタンス３３６とスレーブ処理コンポーネ
ントして通信するファイル・オブジェクトによって表さ
れる。
【０２３４】なお、使用されるメディア時間値はマスタ
・データ・ストリームの処理によって左右される。メデ
ィア・レンダリングが休止または停止されると、時間は
同期をとる目的のための停止されることになる。
【０２３５】スレーブ処理コンポーネントまたはフィル
タはステップ３８４で、マスタ・クロック・メディア時
間値をスレーブ・データ・ストリーム・メディア時間値
と比較して、スレーブ・メディア処理がどれだけ進んで
いたか、あるいは遅れていたかを判断する。なお、メデ
ィア時間は実際のデータ・サンプルのストリーム内の時
間インターバル情報に基づいているので、位置時間とし
て見ることができる。言い換えれば、同期化とは、スト
リーム内の同じ相対時間位置で２つのデータ・ストリー
ムを処理することである。
【０２３６】ステップ３８８で終了する前に、スレーブ
処理コンポーネントまたはフィルタはステップ３８６で
マスタ・メディア処理時間に一致するようにスレーブ・
メディア処理を調整する。この調整としては、スレーブ
・メディア・ストリーム処理を減速または加速するこ
と、基礎となるハードウェア・プロセッサのレートを変
更すること、などがある。
【０２３７】メディア・ストリーム処理レートを減速す
ることは、処理すべきサンプルを複製し、間欠的時間遅
延を引き起こし、あるいは再サンプリングすることによ
って達成される。メディア・ストリーム処理を加速する
ことは、処理すべきメディア・サンプルを省くか、再サ
ンプリングすることによって達成される。この分野の当
業者ならば理解されるように、変更が必要であると判断
された後でメディア処理レートを調整する方法は多数存
在する。
【０２３８】以上から理解されるように、図１９と図２
０に示すトポロジ例では、入力ピン・インスタンス３３
６はビデオ・レンダラ・フィルタ３３２のタイミング通
知を受信する。ビデオ・レンダラ・フィルタ３３２は必
要とされる調整を処理に行って図１９のビデオ・ストリ
ームの処理を図２０のオーディオ・ストリームの処理と
同期させる。
【０２３９】次に、図２１（Ｂ）のフローチャートを参
照して、ライブまたはリアルタイム・オーディオ・スト
リーム発生レートを処理コンポーネントまたはフィルタ
の処理レートとレート整合する処理ステップについて説
明する。ステップ３９０でスタートした後、物理時間サ
ンプルはステップ３９２で処理コンポーネントまたはフ
ィルタで受信される。この場合も、これは、クロック・
メカニズムに照会するか、あるいはタイミング・イベン
ト通知を受信することによって行われる。図２０に示す
ように、最終的にはオーディオ・レンダラ・フィルタ３
６４でレンダリングされるライブ・オーディオ・ストリ
ーム３５２の処理では、関係する処理コンポーネントは
イベント通知と制御情報が入力ピン・インスタンス３６
８で受信されたときオーディオ・レンダラ・フィルタ３
６８となる。また、クロック・メカニズム３４４は異な
るタイミング情報を提供する。
【０２４０】ステップ３９２で受信された物理時間サン
プルから、これらの時間サンプル間で処理されたデータ
量をステップ３９４で使用すると、物理時間レートを計
算または判断することができる。物理時間レートとは、
オーディオ・ハードウェアが実際にデータをレンダリン
グするときのレートであり、データ・レンダリング・ス
ループットを表し、フィルタ処理レートとも呼ばれてい
る。ライブ・データ・ストリームのソースがフィルタ処
理レートよりも早い発生レートでデータ・サンプルを発
生すると、余剰データが発生する。発生レートがフィル
タ処理レート以下であれば、データ処理のギャップまた
は枯渇が発生する。どちらの場合も、パフォーマンスが
低下することになる。
【０２４１】データ・サンプルを発生するプロセッサの
実際の処理レート、つまり、発生レートは、メディアま
たはデータ・サンプル自体から判断することができる。
メディア・サンプルは規則または実際のタイムスタンプ
情報の形態になった時間インターバル情報をもっている
ので、メディア時間サンプルはステップ３９６でメディ
ア・ストリームから計算することができる。これによ
り、メディア・サンプルを作成したハードウェアの処理
レートを表す発生レートは、一定のデータ処理量を使用
し、この処理量をメディア時間サンプルから判断された
そのデータ処理時間で除すことにより計算することがで
きる。
【０２４２】ステップ４００で終了する前に、メディア
・ストリーム処理はステップ３９８で発生レートをフィ
ルタ処理レートに一致させるように調整される。この場
合も、調整はレンダリングするサンプルを省き、サンプ
ル・レンダリング間に時間遅延を追加し、この分野で公
知の他の方法によって行うことができる。
【０２４３】次に、図２１（Ｃ）に示すフローチャート
を参照して、クロック・メカニズムを使用して変換を行
うための処理ステップについて説明する。ステップ４０
２でスタートした後、処理コンポーネントまたはフィル
タはステップ４０４でクロック・メカニズムから相関時
間値を受信する。なお、処理コンポーネントまたはフィ
ルタはＰＣクロックのように、相関時間値の参照時間値
部分を生成する参照時間クロックにアクセスすることが
できる。メディア時間データは、ＰＣクロックまたは以
前に受信された相関時間値に入っている他の参照時間値
からメディア時間値を減算することによってステップ４
０６で計算される。メディア時間データは変換のために
処理コンポーネントまたはフィルタによって使用され、
ＰＣクロック時間からのメディア時間の変化を示してい
る。
【０２４４】変換を行うためには、処理コンポーネント
またはフィルタはステップ４０８で現在のＰＣクロック
時間値（または他の参照時間値）を取得する。処理コン
ポーネントまたはフィルタでの現在メディア時間は、ス
テップ４１０で現在ＰＣクロック時間値とマスタ・メデ
ィア・デルタを使用して変換することができる。メディ
ア時間デルタは、参照時間を基準にしたＰＣクロック時
間からのメディア時間の変化を示しているので、これを
現在ＰＣクロック時間値に加えるだけで、タイムスタン
プ情報の正しい「変換」または新時間値を得ることがで
きる。ステップ４１０で変換プロセスを終了すると、処
理はステップ４１２で終了する。この通信がＤＳＰなど
のリモート・プロセッサ上の２つのコンポーネント間で
行われる場合は、参照時間値はＰＣ時間ではなく、ロー
カル・ホスト時間となる。
【０２４５】図２１（Ｃ）のフローチャートに示す変換
のメソッドを相互接続カーネル・モード・フィルタに適
用して図１９と図２０に示すライブ・オーディオとビデ
オ・ストリームを処理し、レンダリングする場合は、ス
テップ４０４でクロック・メカニズム３４４から相関時
間値を受信するのはビデオ・レンダラ・フィルタ３３２
上の入力ピン・インスタンス３３６である。最後に、ラ
イブ・ビデオ・ストリーム３２０上のタイムスタンプの
計算と変換を行うか、あるいはクロック・メカニズム３
４４のメディア時間に基づいて変換参照時間を作成する
のは、ビデオ・レンダラ・フィルタ３３２である。
【０２４６】この分野の当業者ならば理解されるよう
に、本明細書に開示されている相互接続フィルタのシス
テムにおいては、均一バッファ割当て機能とタイミング
機能は実施上の問題解決の要件に応じて、処理効率向上
のために組み合わせて使用することも、単独で使用する
ことも可能である。さらに、タイミング機能は、相互接
続フィルタのシステムから独立して使用することも可能
である。
【０２４７】この分野の精通者ならば理解されるよう
に、本発明の種々方法はコンピュータ・プログラム・コ
ード手段として、磁気ディスク、ＣＤ−ＲＯＭ、および
この分野で共通している他の媒体やまだ未開発の他の共
通媒体などの、コンピュータ読取り可能媒体上にストア
されるコンピュータ命令として組み込んでおくことが可
能である。さらに、コンピュータ・ハードウェア・メモ
リに置かれる重要なデータ構造は、上記のようなコンピ
ュータ・プログラム・コード手段をオペレーションによ
り作成することができる。
【０２４８】本発明は本発明の基本的特徴の精神から逸
脱しない限り、他の実施形態で実現することも可能であ
る。上述してきた各種実施の形態はすべての点で説明し
た通りであるが、これらの実施の形態に限定されるもの
ではない。従って、本発明の範囲は上述してきた説明に
よってではなく、特許請求の範囲に記載されている事項
によってのみ限定されるものである。特許請求の範囲の
等価技術の意味と範囲に属する一切の変更は本発明の範
囲に属するものである。
【図面の簡単な説明】
【図１】制御エージェントの指示を受けてサウンド・デ
ータをディスク・ファイルから持ち込み、サウンド・デ
ータをなんらかの形態で処理し、サウンド・データをレ
ンダリングしてスピーカから再生させる相互接続フィル
タとドライバのシステムを示す従来技術のデータ・フロ
ー図である。
【図２】図１に示すシステムと目的が同じであり、サウ
ンド・データをディスク・ドライバから読み取り、その
データを処理し、そのデータをレンダリングしてスピー
カから聞こえるようにし、処理フィルタとレンダリング
は、この場合も制御エージェントの指示を受けて相互接
続カーネル・モード・ドライバによって処理されるよう
した本発明によるシステムを示す図である。
【図３】オペレーティング・システムで作成され、使用
されるドライバ・オブジェクト、デバイス・オブジェク
トおよびファイル・オブジェクト間の関係を示す垂直関
係モデルを示す図である。
【図４】ドライバ・オブジェクトのロジック・ブロック
図であり、本発明のシステムに従ってメッセージを適切
なプロセス・ハンドリング・コードへ転送し、新しいフ
ァイル・オブジェクトの作成をバリデーションするため
のデータ構造およびプログラム・コードとの論理的関係
を示す図である。
【図５】デバイス・オブジェクトのロジック・ブロック
図であり、本発明のシステムに従ってメッセージを適切
なプロセス・ハンドリング・コードへ転送し、新しいフ
ァイル・オブジェクトの作成をバリデーションするため
のデータ構造およびプログラム・コードとの論理的関係
を示す図である。
【図６】ファイル・オブジェクトのロジック・ブロック
図であり、本発明のシステムに従ってメッセージを適切
なプロセス・ハンドリング・コードへ転送し、新しいフ
ァイル・オブジェクトの作成をバリデーションするため
のデータ構造およびプログラム・コードとの論理的関係
を示す図である。
【図７】ルーチングとバリデーション・コンポーネント
リの初期セットアップとカーネル・モード・ドライバに
よる入出力メッセージの処理を示すフローチャートであ
る。
【図８】制御エージェントの処理、ルーチングとバリデ
ーション・メカニズム、および新しいファイル・オブジ
ェクトを作成する具体的な作成ハンドラ・ルーチンを示
す詳細フローチャートである。
【図９】オペレーティング・システムでファイル・オブ
ジェクト構造を利用して、接続を標準化された方法で行
う接続フィルタ間の水平関係を示すロジック図である。
【図１０】図９のカーネル・モード・フィルタまたはド
ライバを作成し、接続するためにユーザ・モードの制御
エージェントによってとられる処理ステップを示すフロ
ーチャートであり、制御エージェントから受け取った入
出力要求を処理するために接続を行い、その処理が異な
るドライバ（フィルタ）間で続けられる様子を示してい
る。
【図１１】ユーザ・モードの制御エージェントの指示を
受けてカーネル・モード・フィルタのチェインを作成す
るために使用され、サウンド・データをハード・ドライ
ブから読み取り、カーネル・モード・フィルタでそのデ
ータを処理し、そのデータをレンダリングしてスピーカ
から聞こえるようにするシステムを実装するためのカー
ネル・モード・ドライバと接続を示す概要ロジック図で
ある。
【図１２】ユーザ・モードの制御エージェントの指示を
受けてカーネル・モード・フィルタのチェインを作成す
るために使用され、サウンド・データをハード・ドライ
ブから読み取り、カーネル・モード・フィルタでそのデ
ータを処理し、そのデータをレンダリングしてスピーカ
から聞こえるようにするシステムを実装するためのカー
ネル・モード・ドライバと接続を示す概要ロジック図で
ある。
【図１３】図１１と図１２に示すシステム用に相互接続
カーネル・モード・ドライバを作成するための処理ステ
ップを示すフローチャートである。
【図１４】バッファ割当てメカニズムがどのような働き
をするかを示す図であり、割当てられたバッファ・フレ
ームがある処理コンポーネントから別の処理コンポーネ
ントへ渡されるときの、バッファ・フレームの論理的構
成と処理を示す。
【図１５】バッファ割当てメカニズムがどのような働き
をするかを示す図であり、相互接続カーネル・モード・
フィルタのシステムにおいて入力ピン・インスタンスを
表すファイル・オブジェクトの「子」であるファイル・
オブジェクトとして表されるバッファ・アロケータを示
している。図１４と図１５はどちらも同じフィルタ・グ
ラフ・トポロジを示している。
【図１６】図１１および図１２に示すシステムの遷移に
おいて、バッファ・フレームの割当てを制御するバッフ
ァ・アロケータを利用して行われるバッファ割当てを示
す図である。
【図１７】相互接続カーネル・モード・フィルタのチェ
インを通してデータをディスク・ドライバから持ち込ん
で、サウンド処理ハードウェア上でデータをレンダリン
グする処理ステップを示すフローチャートであり、具体
的には、バッファ・アロケータのオペレーションと図１
６に示すシステムでバッファ間で実際に行われるデータ
転送を示している。
【図１８】２つのライブ・データ・ストリームが単一の
マスタ・クロック・メカニズムとどのようにして同期化
されるかを示すロジック・ブロック図である。
【図１９】図１６を参照して詳しく説明されている相互
接続フィルタ・システムを使用して実施されている図１
８のライブ・オーディオ・システムを示すロジック・ブ
ロック図であり、図１９はマスタ・クロック同期化信号
を受信するライブ・ビデオ・ストリーム・レンダリング
・フィルタを示す。
【図２０】図１６を参照して詳しく説明されている相互
接続フィルタ・システムを使用して実施されている図１
８のライブ・オーディオ・システムを示すロジック・ブ
ロック図であり、図２０は両方のストリームを一緒に同
期化し、ライブ・オーディオ・データを実際のオーディ
オ・レンダリング・ハードウェアとレート整合するマス
タ・クロック・メカニズムをもつライブ・オーディオ・
レンダリング・システムを示す図である。
【図２１】（Ａ）ないし（Ｃ）は、複数のデータ・スト
リームのデータ処理を同期化し、あるデータ・ストリー
ムをハードウェア・レンダラの物理的機能とレート整合
し、あるタイムベースを共通タイムベースを使用して別
のタイムベースに変換するためにクロック・メカニズム
がどうように使用されるかを示す図であり、（Ａ）は同
期化処理ステップを示すフローチャート、（Ｂ）はレー
ト整合処理ステップを示すフローチャート、（Ｃ）は変
換処理ステップを示すフローチャートである。
【符号の説明】
４４，１７０，３４２ 制御エージェント ４６，２６２ ディスク・ドライブ ４８，１８２ ディスク・ドライバ ５０ リーダ・ドライバ ５２ デコンプレッサ・ドライバ ５４ 効果フィルタ ５６ 効果プロセッサ ５８ レンダリング・ドライバ ６２，３０２ スピーカ ６４，７６，８０ ドライバ・オブジェクト ６６ デバイス・オブジェクト ７０，７２，７４，９０ ファイル・オブジェクト ７８ 汎用マルチプレクシング・ディスパッチ機能 ８２ デバイス・エクステンション・エリア ８４，１００ ファイル・タイプ・バリデーション・テ
ーブル ８６，１０２ ファイル・オブジェクト・タイプ ８８ 作成ハンドラ ９２ ファイル・コンテキスト・エリア ９４ ＩＲＰ要求ハンドラ・テーブル ９６ ＩＲＰ要求 ９８ ハンドラ １０４ 参照 １４６ フィルタＡ １４８ フィルタＢ １５４，１８８，２０２，２０６，２４２，２４８，３
２８，３３６，３６２，３６８ 入力ピン・インスタン
ス １５８，１９２，２０４，２０８，２４０，２５０，３
２６，３３４，３６０，３６６ 出力ピン・インスタン
ス １７２ リーダ・フィルタ １７４ デコンプレッサ・フィルタ １７６ 効果フィルタ １７８ サウンド・レンダリング・フィルタ ２１０ シンク処理コンポーネント ２１２ バッファ・アロケータ・メカニズム ２１４，２３８ ソース処理コンポーネント ２１６，２２２ バッファ・アロケータ参照 ２２０ 変換処理コンポーネント ２２４ａ バッファ・フレーム ２４４ 変換フィルタ ２４６ シンク・フィルタ ２５２，２６４，２６８ バッファ・アロケータ ２５６ システム・メモリ ２５８ サウンド・カード・メモリ ２６０ システム・メモリ ２９６ オーディオ・レンダラ ２９８，３５２ ライブ・オーディオ・ストリーム ３０６ ビデオ・レンダラ ３０８，３２０ ライブ・ビデオ・ストリーム ３１２，３５０ モニタ ３１６ マスタ・クロック・メカニズム ３２２ ビデオ・リーダ・フィルタ ３２８ 入力ピン・インスタンス ３３０ ビデオ・デコンプレッサ・フィルタ ３３２ ビデオ・レンダリング・フィルタ ３４４ クロック・メカニズム ３４６ ビデオ・ハードウェア ３５４ オーディオ・リーダ・フィルタ ３５８ オーディオ・デコンプレッサ・フィルタ ３６４ オーディオ・レンダラ・フィルタ
───────────────────────────────────────────────────── フロントページの続き (72)発明者 ブライアン エイ． ウッドラフ アメリカ合衆国 98045 ワシントン州 ニュー ベンド サウス ウエスト 10テ ィーエイチ ストリート 1020 (72)発明者 トーマス ジェイ．エロウルケ フィンランド 90800 オウル リコニナ ルヤティエ 29

Claims (36)

    【特許請求の範囲】
  1. 【請求項１】 データをカーネル・モードで処理するこ
    とを効率化するようにソフトウェア・ドライバを相互接
    続し、異なるデータ・ストリームを同期化または異なる
    ハードウェア・クロックをレート整合するためのタイミ
    ング情報を標準化された方法で提供する方法であって、
    該方法は、 １つまたは２つ以上のカーネル・モード・ドライバをオ
    ープンするステップと、 ドライバを接続するための１つまたは２つ以上の接続ピ
    ン・インスタンスを形成するステップであって、各接続
    ピン・インスタンスは前記１つまたは２つ以上のドライ
    バと階層的に関係づけられ、該１つまたは２つ以上のド
    ライバ間でデータ伝送のために使用されるステップと、 レート整合とストリーム同期化のための１つまたは２つ
    以上のクロック・メカニズムを作成するステップであっ
    て、各クロックは、前記１つまたは２つ以上の接続ピン
    ・インスタンスの１つと階層的に関係づけられ、基礎と
    なるハードウェア・オシレータに基づいてデータ・スト
    リーム時間と物理時間を提供するステップと、 該１つまたは２つ以上の接続ピン・インスタンスを相互
    接続し、カーネル・モードに置かれた１つまたは２つ以
    上のドライバを通る連続データ・フロー・パスが得られ
    るようにするステップであって、前記クロックは異種ク
    ロック・オシレーション間でレート整合するときと、異
    種データ・ストリームを同期化するときにタイミング情
    報を利用できるようにするステップとを備えていること
    を特徴とする方法。
  2. 【請求項２】 請求項１に記載の方法において、各接続
    ピン・インスタンスはファイル・オブジェクトによって
    表され、階層関係は、接続ピン・インスタンス・ファイ
    ル・オブジェクトの作成時に関係ドライバを指定するこ
    とによって作成され、ドライバはシステム上で利用でき
    る入出力デバイスのファイル・オブジェクトとして参照
    され、各クロック・メカニズムはファイル・オブジェク
    トによって表され、かつ、接続ピン・インスタンスとの
    階層関係はクロック・ファイル・オブジェクトの作成時
    に関係接続ピン・インスタンス・ファイル・オブジェク
    トを親として指定することによって作成されることを特
    徴とする方法。
  3. 【請求項３】 請求項１に記載の方法において、前記１
    つまたは２つ以上のドライバ上の前記接続ピン・インス
    タンスの各々について照会し、クロック・メカニズムが
    使用可能であるかどうかを判断し、特定の接続ピン・イ
    ンスタンスで同期化またはレート整合を行うためのクロ
    ック・メカニズムをインスタンス生成すべきかどうかを
    判断してから、該１つまたは２つ以上の接続ピン・イン
    スタンスを相互接続するようにするステップをさらに含
    むことを特徴とする方法。
  4. 【請求項４】 請求項１に記載の方法において、前記１
    つまたは２つ以上のドライバ上の前記１つまたは２つ以
    上の接続ピン・インスタンスの少なくとも１つは、少な
    くとも１つの事前定義されたプロパティ集合、メソッド
    集合、およびイベント集合をサポートし、前記少なくと
    も１つの接続ピン・インスタンスに対してクロック・メ
    カニズムが利用可能であることをサード・パーティ・コ
    ンポーネントに示して、サード・パーティ・コンポーネ
    ントがそれぞれの接続ピン・インスタンスで前記クロッ
    ク・メカニズムを作ることを可能にしており、クロック
    は少なくとも１つの事前定義されたプロパティ集合、メ
    ソッド集合、およびイベント集合をサポートして、前記
    それぞれのクロックをサード・パーティ・コンポーネン
    トによって判断された通りに制御するようにしたことを
    特徴とする方法。
  5. 【請求項５】 コンピュータ・プログラム・プロダクト
    において、 カーネル・モードの他のコンポーネントとの標準化され
    た相互接続メカニズムを提供するためにそこに具現化さ
    れている、コンピュータ読取り可能プログラム・コード
    手段を収めているコンピュータ使用可能媒体であって、
    該コンピュータ使用可能媒体は、 接続ピン・インスタンスを形成するためのプログラム・
    コード手段であって、該接続ピン・インスタンスはカー
    ネル・モードの他のコンポーネントとの間でデータを受
    け渡しするために使用され、他のコンポーネント上に置
    かれている他の接続ピン・インスタンスとの相互接続が
    可能になっている手段と、 該接続ピン・インスタンスのいくつかでクロック・メカ
    ニズムを形成するためのプログラム・コード手段であっ
    て、該クロック・メカニズムは時間インターバル情報が
    関連づけられているデータのストリーム内の現在位置を
    反映している位置時間値を提供する手段とを備えている
    ことを特徴とするコンピュータ・プログラム・プロダク
    ト。
  6. 【請求項６】 請求項５に記載のコンピュータ・プログ
    ラム・プロダクトにおいて、クロック・メカニズムは、
    複数のコンポーネントが利用できる共通ハードウェア・
    オシレータに基づく参照時間値と前記位置時間値とを備
    える相関時間値をアトミック・オペレーションでさらに
    提供し、他のコンポーネントが前記共通ハードウェア・
    オシレータを参照として使用して時間変換を行えるよう
    にしたことを特徴とするコンピュータ・プログラム・プ
    ロダクト。
  7. 【請求項７】 請求項５に記載のコンピュータ・プログ
    ラム・プロダクトにおいて、クロック・メカニズムは、
    複数のコンポーネントが利用できる共通ハードウェア・
    オシレータに基づく参照時間値と指定時間値とを備える
    相関時間値をアトミック・オペレーションでさらに提供
    し、他のコンポーネントが前記共通ハードウェア・オシ
    レータを参照として使用して時間変換を行えるようにし
    たことを特徴とするコンピュータ・プログラム・プロダ
    クト。
  8. 【請求項８】 請求項５に記載のコンピュータ・プログ
    ラム・プロダクトにおいて、クロック・メカニズムはハ
    ードウェア・オシレータに基づく物理時間値をさらに提
    供することを特徴とするコンピュータ・プログラム・プ
    ロダクト。
  9. 【請求項９】 請求項８に記載のコンピュータ・プログ
    ラム・プロダクトにおいて、クロック・メカニズムは、
    複数のコンポーネントが利用できる共通ハードウェア・
    オシレータに基づく参照時間値と前記物理時間値とを備
    える相関物理時間値をアトミック・オペレーションでさ
    らに提供し、他のコンポーネントが前記共通ハードウェ
    ア・オシレータを参照として使用して時間変換を行える
    ようにしたことを特徴とするコンピュータ・プログラム
    ・プロダクト。
  10. 【請求項１０】 請求項５に記載のコンピュータ・プロ
    グラム・プロダクトにおいて、前記位置時間値は前記プ
    ログラム・コード手段に実装されているプロパティ集合
    の一部として他のコンポーネントによってアクセスされ
    ることを特徴とするコンピュータ・プログラム・プロダ
    クト。
  11. 【請求項１１】 請求項５に記載のコンピュータ・プロ
    グラム・プロダクトにおいて、クロック・メカニズムは
    さらに関係イベントの通知を他のコンポーネントに提供
    することを特徴とするコンピュータ・プログラム・プロ
    ダクト。
  12. 【請求項１２】 請求項５に記載のコンピュータ・プロ
    グラム・プロダクトにおいて、クロック・メカニズムは
    さらに関係イベントの通知を前記位置時間に基づいて他
    のコンポーネントに提供し、有用な同期点を提供するよ
    うにしたことを特徴とするコンピュータ・プログラム・
    プロダクト。
  13. 【請求項１３】 複数のデータ・ストリームを同期化す
    る方法であって、 データ・サンプルの参照データ・ストリームに基づいて
    マスタ・クロック参照を作成するステップであって、各
    データ・サンプルは参照データ・ストリーム内の位置を
    示す時間インターバル情報をもち、マスタ・クロック参
    照は時間インターバル情報から作成されるステップと、 １つまたは２つ以上の他のデータ・ストリームをマスタ
    ・クロック参照に基づいて処理し、他のデータ・ストリ
    ームが参照データ・ストリームの処理と同期化されるよ
    うにするステップとを備えることを特徴とする方法。
  14. 【請求項１４】 請求項１３に記載の方法において、マ
    スタ・クロック参照はプロパティ集合の一部としてアク
    セスされることを特徴とする方法。
  15. 【請求項１５】 請求項１３に記載の方法において、マ
    スタ・クロック参照は、サード・パーティ・エージェン
    トからの要求に応答して作成される、選択的にインスタ
    ンス生成可能なクロック・メカニズムの一部であること
    を特徴とする方法。
  16. 【請求項１６】 請求項１３に記載の方法において、時
    間インターバル情報はメディア・サンプルに関するタイ
    ムスタンプ情報によって得られることを特徴とする方
    法。
  17. 【請求項１７】 請求項１３に記載の方法において、時
    間インターバル情報はメディア・ストリーム規則によっ
    て得られることを特徴とする方法。
  18. 【請求項１８】 処理コンポーネントを通して処理され
    るデータ・ストリームをハードウェア・プロセッサに合
    わせてレート整合する方法であって、 ハードウェア・プロセッサのハードウェア・オシレーシ
    ョンに基づく物理時間参照を処理コンポーネントに提供
    するステップと、 処理コンポーネントで行われるデータ・ストリームの処
    理レートを物理時間参照に基づいてハードウェア・プロ
    セッサの処理レートに整合するように調整するステップ
    であって、データ・ストリームは時間インターバル情報
    が関連づけられているサンプルから構成されているもの
    とを備えることを特徴とする方法。
  19. 【請求項１９】 請求項１８に記載の方法において、物
    理時間参照はプロパティ集合の一部としてアクセスされ
    ることを特徴とする方法。
  20. 【請求項２０】 請求項１８に記載の方法において、物
    理時間参照は、サード・パーティ・エージェントからの
    要求に応答して作成される、選択的にインスタンス生成
    可能なクロック・メカニズムの一部であることを特徴と
    する方法。
  21. 【請求項２１】 請求項１８に記載の方法において、時
    間インターバル情報はデータ・サンプルに関するタイム
    スタンプ情報によって得られることを特徴とする方法。
  22. 【請求項２２】 請求項１８に記載の方法において、時
    間インターバル情報はデータ・ストリーム規則によって
    得られることを特徴とする方法。
  23. 【請求項２３】 複数のメディア・ストリームを同期化
    する方法であって、 メディア・サンプルの参照メディア・ストリームに基づ
    いてマスタ・クロック参照を作成するステップであっ
    て、各サンプルは参照メディア・ストリーム内の位置を
    示す時間インターバル情報をもち、マスタ・クロック参
    照はタイムスタンプ情報から作成されるステップと、 １つまたは２つ以上の他のメディア・ストリームをマス
    タ・クロック参照に基づいて処理し、他のメディア・ス
    トリームが参照メディア・ストリームの処理と同期化さ
    れるようにするステップとを備えることを特徴とする方
    法。
  24. 【請求項２４】 請求項２３に記載の方法において、マ
    スタ・クロック参照はプロパティ集合の一部としてアク
    セスされることを特徴とする方法。
  25. 【請求項２５】 請求項２３に記載の方法において、マ
    スタ・クロック参照は、サード・パーティ・エージェン
    トからの要求に応答して作成される、選択的にインスタ
    ンス生成可能なクロック・メカニズムの一部であること
    を特徴とする方法。
  26. 【請求項２６】 処理コンポーネントを通して処理され
    るメディア・ストリームをハードウェア・レンダラに合
    わせてレート整合する方法であって、 ハードウェア・レンダラのハードウェア・オシレーショ
    ンに基づく物理時間参照を処理コンポーネントに提供す
    るステップと、 処理コンポーネントで行われるメディア・ストリームの
    処理レートを、物理時間参照に基づいてハードウェア・
    レンダラの処理レートに整合するように調整するステッ
    プであって、メディア・ストリームは時間インターバル
    情報が関連づけられているメディア・サンプルから構成
    されているステップとを備えることを特徴とする方法。
  27. 【請求項２７】 請求項２６に記載の方法において、物
    理時間参照はプロパティ集合の一部としてアクセスされ
    ることを特徴とする方法。
  28. 【請求項２８】 請求項２６に記載の方法において、物
    理時間参照は、サード・パーティ・エージェントからの
    要求に応答して作成される、選択的にインスタンス生成
    可能なクロック・メカニズムの一部であることを特徴と
    する方法。
  29. 【請求項２９】 請求項２６に記載の方法において、時
    間インターバル情報はメディア・サンプルに関するタイ
    ムスタンプ情報によって得られることを特徴とする方
    法。
  30. 【請求項３０】 請求項２６に記載の方法において、時
    間インターバル情報はメディア・ストリーム規則によっ
    て得られることを特徴とする方法。
  31. 【請求項３１】 第１コンポーネントにおける位置時間
    値を第２コンポーネントにおける位置時間値に基づい
    て、および共通ハードウェア・オシレータを利用して変
    換する方法であって、 相関時間値をシングル・オペレーションで第２コンポー
    ネントから第１コンポーネントで受信するステップであ
    って、相関時間値は時間インターバル情報が関連づけら
    れているデータ・ストリーム内の位置に基づく位置時間
    値と、共通ハードウェア・オシレータに基づく共通時間
    値とを含んでいるステップと、 共通ハードウェア・オシレータの現在値を第１コンポー
    ネントによって照会するステップと、 第１コンポーネントにおける位置時間値を共通ハードウ
    ェア・オシレータの現在値と第２コンポーネントから受
    信した相関時間値に基づいて第１コンポーネントによっ
    て変換するステップとを備えることを特徴とする方法。
  32. 【請求項３２】 第１コンポーネントにおける指定時間
    値を第２コンポーネントにおける指定時間値に基づい
    て、および共通ハードウェア・オシレータを利用して変
    換する方法であって、 相関時間値をシングル・オペレーションで第２コンポー
    ネントから第１コンポーネントで受信するステップであ
    って、相関時間値は指定時間値と共通ハードウェア・オ
    シレータに基づく共通時間値とを含んでいるステップ
    と、 共通ハードウェア・オシレータの現在値を第１コンポー
    ネントによって照会するステップと、 第１コンポーネントにおける指定時間値を共通ハードウ
    ェア・オシレータの現在値と第２コンポーネントから受
    信した相関時間値に基づいて第１コンポーネントによっ
    て変換するステップとを備えることを特徴とする方法。
  33. 【請求項３３】 請求項３２に記載の方法において、指
    定時間値は時間インターバル情報が関連づけられている
    データ・ストリーム内の位置に基づく位置時間値である
    ことを特徴とする方法。
  34. 【請求項３４】 請求項３２に記載の方法において指定
    時間値はハードウェア・オシレータに基づく物理時間値
    であることを特徴とする方法。
  35. 【請求項３５】 ２つのデータストリームの同期処理を
    可能にするカーネル・モード・データ処理システムにお
    いて、 第１データ・ソースと、 発生コンポーネントと終結コンポーネントを含む複数の
    第１カーネル・モード・データ処理コンポーネントであ
    って、発生コンポーネントは第１データ・ソースから送
    られてきた第１データ・ストリームのデータ・サンプル
    を読み取り、処理コンポーネントの少なくとも１つはマ
    スタ・クロック・コンポーネントが関連づけられている
    ものと、 第２データ・ソースと、 発生コンポーネントと終結コンポーネントを含む複数の
    第２カーネル・モード・データ処理コンポーネントであ
    って、発生コンポーネントは第２データ・ソースから送
    られてきた第２データ・ストリームのデータ・サンプル
    を読み取り、処理コンポーネントの少なくとも１つは複
    数の第１処理コンポーネントに置かれている、処理コン
    ポーネントに関連づけられているマスタ・クロック・コ
    ンポーネントに基づいて処理を同期化するものと、 複数の第１と第２のそれぞれのカーネル・モード・デー
    タ処理コンポーネントのデータ処理コンポーネント間の
    カーネル・モード・コンポーネント相互接続であって、
    それぞれのデータ・サンプルの処理をそれぞれの発生コ
    ンポーネントから発生コンポーネントへ転送するように
    したものとを備えていることを特徴とするカーネル・モ
    ード・データ処理システム。
  36. 【請求項３６】 ２つのメディア・ストリームの同期処
    理を可能にするカーネル・モード・メディア・レンダリ
    ング・システムにおいて、 第１メディア・ソースと、 発生コンポーネントと終結コンポーネントを含む複数の
    第１カーネル・モード・メディア処理コンポーネントで
    あって、 発生コンポーネントは第１メディア・ソースからの第１
    メディア・ストリームのメディア・サンプルを読み取
    り、 終結コンポーネントは前記第１メディア・ストリームを
    レンダリングし、 各メディア処理コンポーネントはメディア処理コンポー
    ネント間で第１メディア・サンプルを受け渡しするため
    の接続ピン・インスタンスをもち、 少なくとも１つの接続ピン・インスタンスはマスタ・ク
    ロック・コンポーネントが関連づけられているものと、 第２メディア・ソースと、 発生コンポーネントと終結コンポーネントを含む複数の
    第２カーネル・モード・メディア処理コンポーネントで
    あって、 発生コンポーネントは第２メディア・ソースからの第２
    メディア・ストリームのメディア・サンプルを読み取
    り、 終結コンポーネントは前記第２メディア・ストリームを
    レンダリングし、 各メディア処理コンポーネントはメディア処理コンポー
    ネント間で第２メディア・サンプルを受け渡しするため
    の接続ピン・インスタンスをもち、 少なくとも１つの接続ピン・インスタンスは、複数の第
    １処理コンポーネントに置かれている処理コンポーネン
    トのピン・インスタンスの１つと関連づけられているマ
    スタ・クロック・コンポーネントを使用して第２メディ
    ア・ストリームの処理を第１メディア・ストリームの処
    理と同期化するものと、 複数の第１と第２のそれぞれのカーネル・モード処理コ
    ンポーネントに置かれていて、それぞれの接続ピン・イ
    ンスタンスを使用して作成されたそれぞれのメディア処
    理コンポーネント間のカーネル・モード・コンポーネン
    ト相互接続であって、それぞれのメディア・サンプルの
    処理コントロールをそれぞれの発生コンポーネントから
    それぞれの終結コンポーネントへ転送するようにしたも
    のと を備えていることを特徴とするカーネル・モード・メデ
    ィア・レンダリング・システム。
JP18062597A 1997-04-04 1997-06-20 標準クロック・メカニズムを用いて、多重データ・ストリームの処理の同期と異なる処理速度のマッチングを行う方法 Expired - Lifetime JP4575528B2 (ja)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US08/826,560 1997-04-04
US08/826,560 US5815689A (en) 1997-04-04 1997-04-04 Method and computer program product for synchronizing the processing of multiple data streams and matching disparate processing rates using a standardized clock mechanism

Publications (2)

Publication Number Publication Date
JPH10283199A true JPH10283199A (ja) 1998-10-23
JP4575528B2 JP4575528B2 (ja) 2010-11-04

Family

ID=25246895

Family Applications (1)

Application Number Title Priority Date Filing Date
JP18062597A Expired - Lifetime JP4575528B2 (ja) 1997-04-04 1997-06-20 標準クロック・メカニズムを用いて、多重データ・ストリームの処理の同期と異なる処理速度のマッチングを行う方法

Country Status (5)

Country Link
US (1) US5815689A (ja)
EP (1) EP0869443B1 (ja)
JP (1) JP4575528B2 (ja)
CA (1) CA2208418C (ja)
DE (1) DE69739687D1 (ja)

Families Citing this family (191)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5253275A (en) 1991-01-07 1993-10-12 H. Lee Browne Audio and video transmission and receiving system
US6002720A (en) 1991-01-07 1999-12-14 H. Lee Browne, D/B/A Greenwich Information Technologies Llc Audio and video transmission and receiving system
US6223204B1 (en) * 1996-12-18 2001-04-24 Sun Microsystems, Inc. User level adaptive thread blocking
JP3097737B2 (ja) * 1997-01-27 2000-10-10 日本電気株式会社 バーストクロック対応メモリ回路
US6643712B1 (en) 1997-04-04 2003-11-04 Microsoft Corporation Validating the creation of and routing of messages to file objects
US6016515A (en) * 1997-04-04 2000-01-18 Microsoft Corporation Method, computer program product, and data structure for validating creation of and routing messages to file object
US6105147A (en) * 1997-04-16 2000-08-15 Compaq Computer Corporation Using process pairs as transaction-coordinated resource managers
US6058388A (en) * 1997-06-16 2000-05-02 Compaq Computer Corporation Implementation of escrow-locking scalar quantities via process-pair resource managers
US6128615A (en) * 1997-06-17 2000-10-03 Compaq Computer Corporation Process-pair resource manager implementation of object bags
KR100248404B1 (ko) * 1997-09-04 2000-03-15 정선종 다중 객체 환경에서 우선 순위 정보를 이용한 순화적 계산량 감소 방법
AU1411799A (en) * 1997-11-18 1999-06-07 Tridium Research, Inc. Method and apparatus for phase-locking a plurality of display devices and multi-level driver for use therewith
US6665835B1 (en) * 1997-12-23 2003-12-16 Verizon Laboratories, Inc. Real time media journaler with a timing event coordinator
US6317760B1 (en) 1998-01-14 2001-11-13 Microsoft Corporation Extensible ordered information within a web page
US6810503B1 (en) * 1998-02-11 2004-10-26 Microsoft Corporation Method and apparatus for controlling the timing of the invocation of events within a computer runtime environment
US6810358B1 (en) * 1998-03-24 2004-10-26 Exergetic Systems Llc Method to synchronize data when used for input/loss performance monitoring of a power plant
US6340997B1 (en) * 1998-04-08 2002-01-22 Microsoft Corporation Worldwide television tuning system with object-based tuning control modules
US7042526B1 (en) * 1998-04-08 2006-05-09 Microsoft Corporation Worldwide television tuning system with country code based tuning
US7272298B1 (en) 1998-05-06 2007-09-18 Burst.Com, Inc. System and method for time-shifted program viewing
US6243753B1 (en) * 1998-06-12 2001-06-05 Microsoft Corporation Method, system, and computer program product for creating a raw data channel form an integrating component to a series of kernel mode filters
US6563863B1 (en) * 1998-06-22 2003-05-13 Ati International Srl Computer modem
US6202164B1 (en) 1998-07-02 2001-03-13 Advanced Micro Devices, Inc. Data rate synchronization by frame rate adjustment
US6061802A (en) * 1998-07-02 2000-05-09 Advanced Micro Devices, Inc. Software based clock synchronization
US6279058B1 (en) 1998-07-02 2001-08-21 Advanced Micro Devices, Inc. Master isochronous clock structure having a clock controller coupling to a CPU and two data buses
US8380041B2 (en) 1998-07-30 2013-02-19 Tivo Inc. Transportable digital video recorder system
US6233389B1 (en) 1998-07-30 2001-05-15 Tivo, Inc. Multimedia time warping system
US7558472B2 (en) 2000-08-22 2009-07-07 Tivo Inc. Multimedia signal processing system
US8577205B2 (en) 1998-07-30 2013-11-05 Tivo Inc. Digital video recording system
US7451448B1 (en) 1998-08-28 2008-11-11 Oracle International Corporation Methods for selectively quiescing a computer system
US7020878B1 (en) 1998-08-28 2006-03-28 Oracle International Corporation System for allocating resource using the weight that represents a limitation on number of allowance active sessions associated with each resource consumer group
US7526767B1 (en) * 1998-08-28 2009-04-28 Oracle International Corporation Methods for automatic group switching according to a resource plan
US6622171B2 (en) * 1998-09-15 2003-09-16 Microsoft Corporation Multimedia timeline modification in networked client/server systems
US6807667B1 (en) * 1998-09-21 2004-10-19 Microsoft Corporation Method and system of an application program interface for abstracting network traffic control components to application programs
US7047554B1 (en) * 1998-12-09 2006-05-16 Intel Corporation System and method for integrating and controlling audio/video devices
WO2000062298A1 (en) 1999-03-30 2000-10-19 Tivo, Inc. System for automatic playback position correction after fast forward or reverse
US7007096B1 (en) 1999-05-12 2006-02-28 Microsoft Corporation Efficient splitting and mixing of streaming-data frames for processing through multiple processing modules
US6658477B1 (en) * 1999-05-12 2003-12-02 Microsoft Corporation Improving the control of streaming data through multiple processing modules
US6745368B1 (en) 1999-06-11 2004-06-01 Liberate Technologies Methods, apparatus, and systems for storing, retrieving and playing multimedia data
US6438750B1 (en) * 1999-06-18 2002-08-20 Phoenix Technologies Ltd. Determining loading time of an operating system
WO2001018678A2 (en) * 1999-09-07 2001-03-15 Liberate Technologies, L.L.C. Methods, apparatus, and systems for storing, retrieving and playing multimedia data
US7904317B1 (en) 1999-10-14 2011-03-08 The TriZetto Group Method and apparatus for repricing a reimbursement claim against a contract
AU1375101A (en) * 1999-11-09 2001-06-06 University Of Victoria Innovation And Development Corporation Modified move to rear list system and methods for thread scheduling
US6594773B1 (en) * 1999-11-12 2003-07-15 Microsoft Corporation Adaptive control of streaming data in a graph
US7155739B2 (en) * 2000-01-14 2006-12-26 Jbip, Llc Method and system for secure registration, storage, management and linkage of personal authentication credentials data over a network
US6754709B1 (en) * 2000-03-29 2004-06-22 Microsoft Corporation Application programming interface and generalized network address translator for intelligent transparent application gateway processes
US6961631B1 (en) * 2000-04-12 2005-11-01 Microsoft Corporation Extensible kernel-mode audio processing architecture
US6646195B1 (en) * 2000-04-12 2003-11-11 Microsoft Corporation Kernel-mode audio processing modules
US7096416B1 (en) * 2000-10-30 2006-08-22 Autovod Methods and apparatuses for synchronizing mixed-media data files
US6993604B2 (en) * 2000-11-15 2006-01-31 Seagate Technology Llc Dynamic buffer size allocation for multiplexed streaming
US6882891B2 (en) 2000-12-06 2005-04-19 Microsoft Corporation Methods and systems for mixing digital audio signals
US7447754B2 (en) * 2000-12-06 2008-11-04 Microsoft Corporation Methods and systems for processing multi-media editing projects
US7103677B2 (en) * 2000-12-06 2006-09-05 Microsoft Corporation Methods and systems for efficiently processing compressed and uncompressed media content
US7287226B2 (en) 2000-12-06 2007-10-23 Microsoft Corporation Methods and systems for effecting video transitions represented by bitmaps
US6983466B2 (en) 2000-12-06 2006-01-03 Microsoft Corporation Multimedia project processing systems and multimedia project processing matrix systems
US6768499B2 (en) * 2000-12-06 2004-07-27 Microsoft Corporation Methods and systems for processing media content
US6774919B2 (en) 2000-12-06 2004-08-10 Microsoft Corporation Interface and related methods for reducing source accesses in a development system
US6959438B2 (en) 2000-12-06 2005-10-25 Microsoft Corporation Interface and related methods for dynamically generating a filter graph in a development system
US7114162B2 (en) 2000-12-06 2006-09-26 Microsoft Corporation System and methods for generating and managing filter strings in a filter graph
CA2440807A1 (en) * 2001-03-30 2002-10-10 British Telecommunications Public Limited Company Multi-modal interface
US20020145622A1 (en) * 2001-04-09 2002-10-10 International Business Machines Corporation Proxy content editing system
US6870887B2 (en) * 2001-04-09 2005-03-22 International Business Machines Corporation Method and system for synchronization between different content encoding formats
US7280738B2 (en) * 2001-04-09 2007-10-09 International Business Machines Corporation Method and system for specifying a selection of content segments stored in different formats
US20020172309A1 (en) * 2001-05-15 2002-11-21 International Business Machines Corporation Universal clock reference
US7571445B2 (en) * 2001-11-29 2009-08-04 Dell Products L.P. System and method for dynamic device driver support in an open source operating system
AU2002361767A1 (en) 2001-12-17 2003-07-09 Becomm Corporation Method and system for synchronization of content rendering
US6930620B2 (en) * 2002-01-15 2005-08-16 Microsoft Corporation Methods and systems for synchronizing data streams
WO2003084173A1 (en) * 2002-03-28 2003-10-09 British Telecommunications Public Limited Company Synchronisation in multi-modal interfaces
DE60320889D1 (de) * 2002-04-26 2008-06-26 Yamaha Corp System und Verfahren zur Verarbeitung von Daten in einem Datenstrom
WO2004046969A1 (en) * 2002-11-15 2004-06-03 Bigchampagne, Llc. Monitor file storage and transfer on a peer-to-peer network
JP2006511058A (ja) * 2002-12-20 2006-03-30 コーニンクレッカ　フィリップス　エレクトロニクス　エヌ　ヴィ ハロゲン白熱ランプ
US7010538B1 (en) * 2003-03-15 2006-03-07 Damian Black Method for distributed RDSMS
US7133818B2 (en) * 2003-04-17 2006-11-07 Sun Microsystems, Inc. Method and apparatus for accelerated post-silicon testing and random number generation
US7880909B2 (en) * 2003-05-20 2011-02-01 Bukowski Mark A Extensible framework for parsing varying formats of print stream data
US7639716B2 (en) * 2003-07-04 2009-12-29 University College Dublin, National University Of Ireland, Dublin System and method for determining clock skew in a packet-based telephony session
US7613767B2 (en) 2003-07-11 2009-11-03 Microsoft Corporation Resolving a distributed topology to stream data
US11650784B2 (en) 2003-07-28 2023-05-16 Sonos, Inc. Adjusting volume levels
US8234395B2 (en) 2003-07-28 2012-07-31 Sonos, Inc. System and method for synchronizing operations among a plurality of independently clocked digital data processing devices
US11294618B2 (en) 2003-07-28 2022-04-05 Sonos, Inc. Media player system
US11106425B2 (en) 2003-07-28 2021-08-31 Sonos, Inc. Synchronizing operations among a plurality of independently clocked digital data processing devices
US9207905B2 (en) 2003-07-28 2015-12-08 Sonos, Inc. Method and apparatus for providing synchrony group status information
US8086752B2 (en) 2006-11-22 2011-12-27 Sonos, Inc. Systems and methods for synchronizing operations among a plurality of independently clocked digital data processing devices that independently source digital data
US11106424B2 (en) 2003-07-28 2021-08-31 Sonos, Inc. Synchronizing operations among a plurality of independently clocked digital data processing devices
US8290603B1 (en) 2004-06-05 2012-10-16 Sonos, Inc. User interfaces for controlling and manipulating groupings in a multi-zone media system
US7089604B2 (en) * 2003-11-05 2006-08-15 Wright Glenn H Toilet support device and method
US7733962B2 (en) 2003-12-08 2010-06-08 Microsoft Corporation Reconstructed frame caching
US7900140B2 (en) * 2003-12-08 2011-03-01 Microsoft Corporation Media processing methods, systems and application program interfaces
US7712108B2 (en) * 2003-12-08 2010-05-04 Microsoft Corporation Media processing methods, systems and application program interfaces
US7735096B2 (en) * 2003-12-11 2010-06-08 Microsoft Corporation Destination application program interfaces
US8768494B1 (en) 2003-12-22 2014-07-01 Nvidia Corporation System and method for generating policy-based audio
KR100630052B1 (ko) * 2004-01-26 2006-09-27 삼성전자주식회사 실시간 전송 프로토콜 데이터의 전송을 위한 처리 시스템 및 방법
US7669113B1 (en) * 2004-01-30 2010-02-23 Apple Inc. Media stream synchronization using device and host clocks
US20050185718A1 (en) * 2004-02-09 2005-08-25 Microsoft Corporation Pipeline quality control
US7934159B1 (en) 2004-02-19 2011-04-26 Microsoft Corporation Media timeline
US7941739B1 (en) 2004-02-19 2011-05-10 Microsoft Corporation Timeline source
US7664882B2 (en) * 2004-02-21 2010-02-16 Microsoft Corporation System and method for accessing multimedia content
US7359898B1 (en) * 2004-02-26 2008-04-15 Yahoo! Inc. Scoring mechanism selection along multiple dimensions
US7870039B1 (en) 2004-02-27 2011-01-11 Yahoo! Inc. Automatic product categorization
US7609653B2 (en) * 2004-03-08 2009-10-27 Microsoft Corporation Resolving partial media topologies
US7577940B2 (en) * 2004-03-08 2009-08-18 Microsoft Corporation Managing topology changes in media applications
US9374607B2 (en) 2012-06-26 2016-06-21 Sonos, Inc. Media playback system with guest access
US9977561B2 (en) 2004-04-01 2018-05-22 Sonos, Inc. Systems, methods, apparatus, and articles of manufacture to provide guest access
US7574274B2 (en) * 2004-04-14 2009-08-11 Nvidia Corporation Method and system for synchronizing audio processing modules
US7669206B2 (en) * 2004-04-20 2010-02-23 Microsoft Corporation Dynamic redirection of streaming media between computing devices
US8868698B2 (en) 2004-06-05 2014-10-21 Sonos, Inc. Establishing a secure wireless network with minimum human intervention
US8326951B1 (en) 2004-06-05 2012-12-04 Sonos, Inc. Establishing a secure wireless network with minimum human intervention
US7756594B2 (en) * 2004-06-14 2010-07-13 Microsoft Corporation Systems and methods for parsing flexible audio codec topologies
US20060041895A1 (en) * 2004-08-04 2006-02-23 Microsoft Corporation Systems and methods for interfacing with codecs across an architecture optimized for audio
US7590065B2 (en) * 2004-08-04 2009-09-15 Microsoft Corporation Equal-opportunity bandwidth regulation
US7590750B2 (en) * 2004-09-10 2009-09-15 Microsoft Corporation Systems and methods for multimedia remoting over terminal server connections
US7706901B2 (en) * 2004-10-01 2010-04-27 Microsoft Corporation Low latency real-time audio streaming
US8768729B2 (en) 2004-10-14 2014-07-01 Trizetto Corporation System and method for using a first electronic representation of contract terms for generating a second electronic representation of the contract terms
US8099736B2 (en) 2004-10-14 2012-01-17 The Trizetto Group, Inc. Systems and methods providing intelligent routing of data between software systems
US20060085361A1 (en) * 2004-10-14 2006-04-20 The Trizetto Group, Inc. Anomaly detector in a health care system using adapter
US20060085376A1 (en) * 2004-10-14 2006-04-20 The Trizetto Group, Inc. Centralized management of software adapters
WO2006047502A2 (en) * 2004-10-25 2006-05-04 Brigham And Women's Hospital Automated segmentation, classification and tracking of cell nuclei in time-lapse microscopy
ES2630168T3 (es) 2004-11-19 2017-08-18 Tivo Solutions Inc Procedimiento y aparato para la transferencia segura y la reproducción de contenido multimedia
US8738787B2 (en) 2005-04-20 2014-05-27 Limelight Networks, Inc. Ad server integration
US8291095B2 (en) * 2005-04-20 2012-10-16 Limelight Networks, Inc. Methods and systems for content insertion
US20060253860A1 (en) * 2005-05-09 2006-11-09 The Trizetto Group, Inc. Systems and methods for interfacing an application of a first type with multiple applications of a second type
US7827562B1 (en) 2005-06-16 2010-11-02 The Trizetto Group, Inc. System and method for flexible publishing and consumption of data between disparate applications
US7948557B2 (en) 2005-06-22 2011-05-24 Fraunhofer-Gesellschaft Zur Foerderung Der Angewandten Forschung E.V. Apparatus and method for generating a control signal for a film event system
KR100664961B1 (ko) * 2005-09-29 2007-01-04 삼성전자주식회사 다중 음향 출력을 지원하는 모바일 기기
US7835366B2 (en) * 2005-11-01 2010-11-16 Ciena Corporation Three-way message exchange clock synchronization
US7885859B2 (en) * 2006-03-10 2011-02-08 Yahoo! Inc. Assigning into one set of categories information that has been assigned to other sets of categories
US20080036911A1 (en) * 2006-05-05 2008-02-14 Robert Noory Method and apparatus for synchronizing a graphics signal according to a reference signal
US8762395B2 (en) 2006-05-19 2014-06-24 Oracle International Corporation Evaluating event-generated data using append-only tables
US8131696B2 (en) * 2006-05-19 2012-03-06 Oracle International Corporation Sequence event processing using append-only tables
US20080033750A1 (en) * 2006-06-02 2008-02-07 The Trizetto Group, Inc. Enhanced systems and methods for processing of healthcare information
US8483853B1 (en) 2006-09-12 2013-07-09 Sonos, Inc. Controlling and manipulating groupings in a multi-zone media system
US8788080B1 (en) 2006-09-12 2014-07-22 Sonos, Inc. Multi-channel pairing in a media system
US9202509B2 (en) 2006-09-12 2015-12-01 Sonos, Inc. Controlling and grouping in a multi-zone media system
KR100861104B1 (ko) * 2006-10-16 2008-09-30 킹스정보통신(주) 유에스비 키보드의 보안장치 및 그 방법
TW200820125A (en) * 2006-10-24 2008-05-01 Sunplus Technology Co Ltd Image processing method and system for personal computer
EP2595151A3 (en) 2006-12-27 2013-11-13 Electronics and Telecommunications Research Institute Transcoding apparatus
US20080250190A1 (en) * 2007-04-03 2008-10-09 Brian Johnson Portable memory device operating system and method of using same
US7657333B2 (en) * 2007-09-27 2010-02-02 Rockwell Automation Technologies, Inc. Adjustment of data collection rate based on anomaly detection
US8165450B2 (en) 2007-11-19 2012-04-24 Echostar Technologies L.L.C. Methods and apparatus for filtering content in a video stream using text data
US8165451B2 (en) 2007-11-20 2012-04-24 Echostar Technologies L.L.C. Methods and apparatus for displaying information regarding interstitials of a video stream
US8136140B2 (en) 2007-11-20 2012-03-13 Dish Network L.L.C. Methods and apparatus for generating metadata utilized to filter content from a video stream using text data
US8341454B1 (en) 2007-12-28 2012-12-25 Marvell International Ltd. Rendering a video stream based on digital clock generated based on timing information
US7925640B2 (en) * 2008-02-14 2011-04-12 Oracle America, Inc. Dynamic multiple inheritance method dispatch data structure including an m-table size, i-table containing one or more holder addressor regions and type extension testing by frugal perfect hashing
US8606085B2 (en) 2008-03-20 2013-12-10 Dish Network L.L.C. Method and apparatus for replacement of audio data in recorded audio/video stream
US8156520B2 (en) 2008-05-30 2012-04-10 EchoStar Technologies, L.L.C. Methods and apparatus for presenting substitute content in an audio/video stream using text data
US20100151845A1 (en) * 2008-12-15 2010-06-17 Rountree Collin Legault Presence based communication control
US8588579B2 (en) 2008-12-24 2013-11-19 Echostar Technologies L.L.C. Methods and apparatus for filtering and inserting content into a presentation stream using signature data
US8407735B2 (en) 2008-12-24 2013-03-26 Echostar Technologies L.L.C. Methods and apparatus for identifying segments of content in a presentation stream using signature data
US8510771B2 (en) 2008-12-24 2013-08-13 Echostar Technologies L.L.C. Methods and apparatus for filtering content from a presentation stream using signature data
US8437617B2 (en) 2009-06-17 2013-05-07 Echostar Technologies L.L.C. Method and apparatus for modifying the presentation of content
US8934758B2 (en) 2010-02-09 2015-01-13 Echostar Global B.V. Methods and apparatus for presenting supplemental content in association with recorded content
US11265652B2 (en) 2011-01-25 2022-03-01 Sonos, Inc. Playback device pairing
US11429343B2 (en) 2011-01-25 2022-08-30 Sonos, Inc. Stereo playback configuration and control
US8756075B1 (en) 2011-05-18 2014-06-17 Trizetto Corporation System and method for processing payment bundles
US10310824B2 (en) 2011-09-07 2019-06-04 Imagine Communications Corp. Distributed ledger platform for computing applications
US9152470B2 (en) * 2011-09-07 2015-10-06 Imagine Communications Corp. Systems and methods for computing applications
US10296976B1 (en) 2011-09-23 2019-05-21 Cognizant Trizetto Software Group, Inc. System and method for calculating estimated payment based on partial coding data
US9729115B2 (en) 2012-04-27 2017-08-08 Sonos, Inc. Intelligently increasing the sound level of player
US10318923B1 (en) 2012-08-01 2019-06-11 Cognizant Trizetto Software Group, Inc. Payment assurance and claim pre-validation
US8910191B2 (en) 2012-09-13 2014-12-09 Nvidia Corporation Encoder and decoder driver development techniques
US9008330B2 (en) 2012-09-28 2015-04-14 Sonos, Inc. Crossover frequency adjustments for audio speakers
US9510055B2 (en) 2013-01-23 2016-11-29 Sonos, Inc. System and method for a media experience social interface
US9307508B2 (en) 2013-04-29 2016-04-05 Google Technology Holdings LLC Systems and methods for syncronizing multiple electronic devices
US20150095679A1 (en) 2013-09-30 2015-04-02 Sonos, Inc. Transitioning A Networked Playback Device Between Operating Modes
US9720576B2 (en) 2013-09-30 2017-08-01 Sonos, Inc. Controlling and displaying zones in a multi-zone system
US9654545B2 (en) 2013-09-30 2017-05-16 Sonos, Inc. Group coordinator device selection
US9288596B2 (en) 2013-09-30 2016-03-15 Sonos, Inc. Coordinator device for paired or consolidated players
US9300647B2 (en) 2014-01-15 2016-03-29 Sonos, Inc. Software application and zones
US9313591B2 (en) 2014-01-27 2016-04-12 Sonos, Inc. Audio synchronization among playback devices using offset information
US20150220498A1 (en) 2014-02-05 2015-08-06 Sonos, Inc. Remote Creation of a Playback Queue for a Future Event
US9226073B2 (en) 2014-02-06 2015-12-29 Sonos, Inc. Audio output balancing during synchronized playback
US9226087B2 (en) 2014-02-06 2015-12-29 Sonos, Inc. Audio output balancing during synchronized playback
US9679054B2 (en) 2014-03-05 2017-06-13 Sonos, Inc. Webpage media playback
US10708328B2 (en) * 2014-03-17 2020-07-07 Intel Corporation Hardware assisted media playback and capture synchronization
US10587693B2 (en) 2014-04-01 2020-03-10 Sonos, Inc. Mirrored queues
US20150324552A1 (en) 2014-05-12 2015-11-12 Sonos, Inc. Share Restriction for Media Items
US20150356084A1 (en) 2014-06-05 2015-12-10 Sonos, Inc. Social Queue
US9874997B2 (en) 2014-08-08 2018-01-23 Sonos, Inc. Social playback queues
US9667679B2 (en) 2014-09-24 2017-05-30 Sonos, Inc. Indicating an association between a social-media account and a media playback system
US9690540B2 (en) 2014-09-24 2017-06-27 Sonos, Inc. Social media queue
EP3114625A1 (en) 2014-09-24 2017-01-11 Sonos, Inc. Social media connection recommendations based on playback information
US9723038B2 (en) 2014-09-24 2017-08-01 Sonos, Inc. Social media connection recommendations based on playback information
US9860286B2 (en) 2014-09-24 2018-01-02 Sonos, Inc. Associating a captured image with a media item
US9959087B2 (en) 2014-09-24 2018-05-01 Sonos, Inc. Media item context from social media
US10645130B2 (en) 2014-09-24 2020-05-05 Sonos, Inc. Playback updates
US9571407B2 (en) 2014-12-10 2017-02-14 Limelight Networks, Inc. Strategically scheduling TCP stream transmissions
US10248376B2 (en) 2015-06-11 2019-04-02 Sonos, Inc. Multiple groupings in a playback system
US9886234B2 (en) 2016-01-28 2018-02-06 Sonos, Inc. Systems and methods of distributing audio to one or more playback devices
US10712997B2 (en) 2016-10-17 2020-07-14 Sonos, Inc. Room association based on name
US10389764B2 (en) 2016-10-18 2019-08-20 At&T Intellectual Property I, L.P. Network data source time management for data streaming processing system
US10560373B2 (en) * 2017-04-06 2020-02-11 Gvbb Holdings S.A.R.L. System and method for timely and uniform distribution for real-time packet transmission
CN110351496B (zh) * 2019-07-05 2021-11-26 晶晨半导体(上海)股份有限公司 一种信号源的切换分析方法
US11172269B2 (en) 2020-03-04 2021-11-09 Dish Network L.L.C. Automated commercial content shifting in a video streaming system
CN114339353B (zh) * 2021-12-31 2023-09-29 晶晨半导体科技(北京)有限公司 音视频同步方法和装置及电子设备和计算机可读存储介质

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4780893A (en) * 1987-04-16 1988-10-25 Harris Corporation Bit synchronizer
US5625845A (en) * 1992-10-13 1997-04-29 International Business Machines Corporation System for facilitating continuous, real-time, unidirectional, and asynchronous intertask and end-device communication in a multimedia data processing system using open architecture data communication modules
US5420801A (en) * 1992-11-13 1995-05-30 International Business Machines Corporation System and method for synchronization of multimedia streams
US5471576A (en) * 1992-11-16 1995-11-28 International Business Machines Corporation Audio/video synchronization for application programs
US5452435A (en) * 1993-03-31 1995-09-19 Kaleida Labs, Inc. Synchronized clocks and media players
US5608651A (en) * 1995-01-31 1997-03-04 Intel Corporation Method and apparatus for scheduling and mixing media in a multi-media environment
US5623483A (en) * 1995-05-11 1997-04-22 Lucent Technologies Inc. Synchronization system for networked multimedia streams

Also Published As

Publication number Publication date
CA2208418C (en) 2008-05-20
EP0869443B1 (en) 2009-12-09
JP4575528B2 (ja) 2010-11-04
EP0869443A3 (en) 2001-05-09
CA2208418A1 (en) 1998-10-04
US5815689A (en) 1998-09-29
EP0869443A2 (en) 1998-10-07
DE69739687D1 (de) 2010-01-21

Similar Documents

Publication Publication Date Title
JP4575528B2 (ja) 標準クロック・メカニズムを用いて、多重データ・ストリームの処理の同期と異なる処理速度のマッチングを行う方法
JP3929551B2 (ja) セパレート・プロセッシング・コンポーネント間のバッファ間データ転送を減らす方法およびコンピュータ読取り可能媒体
JP3929554B2 (ja) ファイル・オブジェクトの生成をバリデーションし、ファイル・オブジェクトへのメッセージをルーチングする方法
CA2208289C (en) Method and computer program product for interconnecting software drivers in kernel mode
Steinmetz Analyzing the multimedia operating system
US5339413A (en) Data stream protocol for multimedia data streaming data processing system
Levergood et al. AudioFile: A network-transparent system for distributed audio applications
US7080386B2 (en) Architecture with digital signal processor plug-ins for general purpose processor media frameworks
US6658477B1 (en) Improving the control of streaming data through multiple processing modules
US8078302B2 (en) Low latency real-time audio streaming
JP3770616B2 (ja) オブジェクト指向ビデオ・システム
US20050060422A1 (en) Methods and systems for processing multi-media editing projects
EP0620936A1 (en) Collaborative working in a network
US6643712B1 (en) Validating the creation of and routing of messages to file objects
US7725920B2 (en) Media foundation media sink
JP2000250868A (ja) 動的データフローブデザイン生成方法
CN114296809B (zh) 一种基于操作系统的对象模型构建方法及其系统调用接口
Rizzo The FreeBSD audio driver
Bulterman et al. Multimedia Synchronization and UNIX—or—If Multimedia Support is the Problem, Is UNIX the Solution?
Erkkilä Real-time audio servers on BSD Unix derivatives
Duke et al. An Overview of PREMO
Haines et al. On the design of Chant: A talking threads package(Final Report)
JP2002544739A (ja) ストリーミングデータフレームの分割及び混合
JP2009098800A (ja) 情報処理装置及び情報処理方法

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20040621

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20040621

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20060616

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20060919

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20070206

RD13 Notification of appointment of power of sub attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7433

Effective date: 20070507

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A821

Effective date: 20070508

A601 Written request for extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A601

Effective date: 20100510

RD16 Notification of change of power of sub attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7431

Effective date: 20100512

A602 Written permission of extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A602

Effective date: 20100513

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A821

Effective date: 20100512

A601 Written request for extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A601

Effective date: 20100609

A602 Written permission of extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A602

Effective date: 20100614

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20100723

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20100820

R150 Certificate of patent or registration of utility model

Free format text: JAPANESE INTERMEDIATE CODE: R150

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20130827

Year of fee payment: 3

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

S111 Request for change of ownership or part of ownership

Free format text: JAPANESE INTERMEDIATE CODE: R313113

R350 Written notification of registration of transfer

Free format text: JAPANESE INTERMEDIATE CODE: R350

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

EXPY Cancellation because of completion of term