(57)【要約】      （修正有）【課題】音声遅延を低減して音声を映像と同期させるための方法およびシステムを提供する。【解決手段】音声データを処理するためのプログラム命令を実行する際に音声遅延を低減するための方法が提供されている。この方法では、上側閾値および下側閾値が準備される。次に、音声レンダラの音声バッファに格納された音声データの量が決定される。その後、その量は、上側閾値および下側閾値と比較され、それに応じて、その量が上側閾値と下側閾値との間になるように、音声レンダラへの音声データ供給が、漸次的に調整される。【選択図】図１
2006313310.tif 000002
【特許請求の範囲】
【請求項１】
音声データを処理するためのプログラム命令を実行する際に音声遅延を低減するための方法であって、
上側閾値を準備する工程と、
下側閾値を準備する工程と、
音声レンダラの音声バッファに格納された前記音声データの量を決定する工程と、
前記量を前記上側閾値および前記下側閾値と比較する工程と、
前記量が前記上側閾値と前記下側閾値との間になるように、前記音声レンダラへの音声デ―タ供給を漸次的に調整する工程と、を備える、方法。
【請求項２】
請求項１に記載の方法において、前記音声データ供給を漸次的に調整する工程は、
前記量が前記上側閾値よりも大きい場合に、前記音声レンダラへの前記音声データ供給を漸次量だけ減らす工程と、
前記量が前記下側閾値よりも小さい場合に、前記音声レンダラへの前記音声データ供給を前記漸次量だけ増やす工程と、を備える、方法。
【請求項３】
請求項２に記載の方法において、前記音声データ供給を減らす工程は、
前記音声データのサンプルを受信する工程と、
補間法を用いて前記受信音声データの前記サンプルを前記漸次量だけ減らす工程と、
前記音声データの前記減らされたサンプルを前記音声レンダラに出力する工程と、を備える、方法。
【請求項４】
請求項３に記載の方法ではさらに、
前記量が前記上側閾値以下になるまで、前記音声データの次のサンプルに対して、前記工程の各々を繰り返す工程を備える、方法。
【請求項５】
請求項２に記載の方法において、前記音声データ供給を増やす工程は、
前記音声データのサンプルを受信する工程と、
補間法を用いて前記受信音声データの前記サンプルを前記漸次量だけ増やす工程と、
前記音声データの前記増やされたサンプルを前記音声レンダラに出力する工程と、を備える、方法。
【請求項６】
請求項５に記載の方法はさらに、
前記量が前記下側閾値以上になるまで、前記音声データの次のサンプルに対して、前記工程の各々を繰り返す工程を備える、方法。
【請求項７】
請求項２に記載の方法において、前記漸次量は、元のサンプルサイズ×（音声レンダリングクロック周波数／音声キャプチャクロック周波数−１）と定義される、方法。
【請求項８】
請求項１に記載の方法において、前記上側閾値は、標準音声周波数と最大遅延時間との積を前記音声データのサンプルで割ったものとして定義される、方法。
【請求項９】
請求項１に記載の方法において、前記下側閾値は、前記上側閾値を３で割ったものとして定義される、方法。
【請求項１０】
音声データを処理するためのプログラム命令を実行する際に音声遅延を低減するためのプログラム命令を備えるコンピュータ読み取り可能な媒体であって、
上側閾値を準備するためのプログラム命令と、
下側閾値を準備するためのプログラム命令と、
音声レンダラの音声バッファに格納された前記音声データの量を決定するためのプログラム命令と、
前記量を前記上側閾値および前記下側閾値と比較するためのプログラム命令と、
前記量が前記上側閾値よりも大きい場合に、ストリーミングドライバから前記音声レンダラへの前記音声データ供給を漸次量だけ減らすためのプログラム命令と、
前記量が前記下側閾値よりも小さい場合に、前記ストリーミングドライバから前記音声レンダラへの前記音声データ供給を前記漸次量だけ増やすためのプログラム命令と、を備える、コンピュータ読み取り可能な媒体。
【請求項１１】
請求項１０に記載のコンピュータ読み取り可能な媒体において、前記音声データ供給を減らすためのプログラム命令は、
前記音声データのサンプルを受信するためのプログラム命令と、
補間法を用いて前記受信音声データの前記サンプルを前記漸次量だけ減らすためのプログラム命令と、
前記音声データの前記減らされたサンプルを前記音声レンダラに出力するためのプログラム命令と、を備える、コンピュータ読み取り可能な媒体。
【請求項１２】
請求項１０に記載のコンピュータ読み取り可能な媒体において、前記音声データ供給を増やすためのプログラム命令は、
前記音声データのサンプルを受信するためのプログラム命令と、
補間法を用いて前記受信音声データの前記サンプルを前記漸次量だけ増やすためのプログラム命令と、
前記音声データの前記増やされたサンプルを前記音声レンダラに出力するためのプログラム命令と、を備える、コンピュータ読み取り可能な媒体。
【請求項１３】
請求項１０に記載のコンピュータ読み取り可能な媒体において、前記漸次量は、元のサンプルサイズ×（音声レンダリングクロック周波数／音声キャプチャクロック周波数−１）と定義される、コンピュータ読み取り可能な媒体。
【請求項１４】
請求項１０に記載のコンピュータ読み取り可能な媒体において、前記上側閾値は、標準音声周波数と最大遅延時間との積を前記音声データのサンプルで割ったものとして定義される、コンピュータ読み取り可能な媒体。
【請求項１５】
請求項１０に記載のコンピュータ読み取り可能な媒体において、前記下側閾値は、前記上側閾値を３で割ったものとして定義される、コンピュータ読み取り可能な媒体。
【請求項１６】
音声データを処理するためのプログラム命令を実行する際に音声遅延を低減するためのコンピュータシステムであって、
ストリーミングドライバプログラムを格納するよう構成されたメモリと、
前記メモリに格納された前記ストリーミングドライバプログラムを実行するよう構成されたプロセッサと、を備え、
前記ストリーミングドライバプログラムは、
音声レンダラの音声バッファに格納された前記音声データの量を決定するためのプログラム命令と、
前記量を上側閾値および下側閾値と比較するためのプログラム命令と、
前記量が前記上側閾値よりも大きい場合に、前記音声レンダラへの前記音声データ供給を減らして、前記減らされた音声データ供給が、前記音声レンダラによる前記音声データのレンダリングよりも遅くなるようにするためのプログラム命令と、
前記量が前記下側閾値よりも小さい場合に、前記音声レンダラへの前記音声データ供給を増やして、前記増やされた音声データ供給が、前記音声レンダラによる前記音声データの前記レンダリングよりも速くなるようにするためのプログラム命令と、を備える、コンピュータシステム。
【請求項１７】
請求項１６に記載のコンピュータシステムにおいて、前記音声データ供給を減らすためのプログラム命令は、
前記音声データのサンプルを受信するためのプログラム命令と、
補間法を用いて前記受信音声データの前記サンプルを漸次量だけ減らすためのプログラム命令と、
前記音声データの前記減らされたサンプルを前記音声レンダラに出力するためのプログラム命令と、を備える、コンピュータシステム。
【請求項１８】
請求項１６に記載のコンピュータシステムにおいて、前記音声データ供給を増やすためのプログラム命令は、
前記音声データのサンプルを受信するためのプログラム命令と、
補間法を用いて前記受信音声データの前記サンプルを漸次量だけ増やすためのプログラム命令と、
前記音声データの前記増やされたサンプルを前記音声レンダラに出力するためのプログラム命令と、を備える、コンピュータシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般に、音声処理に関し、特に、音声遅延を低減するための方法およびシステムに関する。
【背景技術】
【０００２】
コンピュータは、ビデオカメラ、テレビ、ビデオカセットレコーダなどの様々なソースから出力された音声／映像を取り込むよう構成可能である。ソースからのリアルタイムの音声／映像をコンピュータ上でプレビューする際に、ユーザは、通例、音声遅延により、音声と映像とが同期しないことを経験する。換言すると、音声は、数秒だけ映像に対して遅延したり先行したりする場合がある。
【０００３】
音声遅延は、映像／音声キャプチャ装置とコンピュータとが、異なるクロック周波数を用いることから引き起こされうる。特に、映像／音声キャプチャ装置内で用いられる第１の周波数は、通例、コンピュータ内の音声レンダラが音声エンコーダに音声データを送信する際の音声キャプチャクロックの第２の周波数とは異なる。例えば、第１の周波数が第２の周波数よりも大きい場合には、レンダリングがキャプチャリングよりも遅いために、音声遅延が増大する。逆に、第１の周波数が第２の周波数よりも小さい場合には、レンダリングがキャプチャリングよりも速いために、クリック音として現れる音声ギャップが引き起こされる。
【０００４】
したがって、音声遅延を低減して音声を映像と同期させるための方法およびシステムが求められている。
【発明の開示】
【０００５】
概して、本発明は、これらの要求を満たすために、音声遅延を低減するための方法およびシステムを提供する。本発明は、方法、システム、または装置を含む多くの形態で実施可能であることを理解されたい。以下では、本発明のいくつかの実施形態を説明する。
【０００６】
本発明の第１の態様によると、音声データを処理するためのプログラム命令を実行する際に音声遅延を低減するための方法が提供されている。この方法では、上側閾値および下側閾値が準備される。次に、音声レンダラの音声バッファに格納された音声データの量が決定される。その後、その量は、上側閾値および下側閾値と比較され、それに応じて、その量が上側閾値と下側閾値との間になるように、音声レンダラへの音声データ供給が、漸次的に調整される。
【０００７】
本発明の第２の態様によると、音声データを処理するためのプログラム命令を実行する際に音声遅延を低減するためのプログラム命令を備えるコンピュータ読み取り可能な媒体が提供されている。そのコンピュータ読み取り可能な媒体は、上側閾値および下側閾値を準備するためのプログラム命令を備える。さらに、音声レンダラの音声バッファに格納された音声データの量を決定するためのプログラム命令と、その量を上側閾値および下側閾値と比較するためのプログラム命令とが備えられている。さらに、コンピュータ読み取り可能な媒体は、上述の量が上側閾値よりも大きい場合に、ストリーミングドライバから音声レンダラへの音声データ供給を漸次量だけ減らすためのプログラム命令と、上述の量が下側閾値よりも小さい場合に、ストリーミングドライバから音声レンダラへの音声データ供給を漸次量だけ増やすためのプログラム命令とを備える。
【０００８】
本発明の第３の態様によると、音声データを処理するためのプログラム命令を実行する際に音声遅延を低減するためのコンピュータシステムが提供されている。コンピュータシステムは、ストリーミングドライバプログラムを格納するよう構成されたメモリと、メモリに格納されたストリーミングドライバプログラムを実行するよう構成されたプロセッサとを備える。ストリーミングドライバプログラムは、音声レンダラの音声バッファに格納された音声データの量を決定するためのプログラム命令と、その量を上側閾値および下側閾値と比較するためのプログラム命令とを備える。さらに、上述の量が上側閾値よりも大きい場合に、音声レンダラへの音声データ供給を減らして、減らされた音声データ供給が、音声レンダラによる音声データのレンダリングよりも遅くなるようにするためのプログラム命令と、上述の量が下側閾値よりも小さい場合に、音声レンダラへの音声データ供給を増やして、増やされた音声データ供給が、音声レンダラによる音声データのレンダリングよりも速くなるようにするためのプログラム命令とが備えられている。
【０００９】
本発明の他の態様および利点は、本発明の原理を例示的に示した添付の図面を参照して行う以下の詳細な説明から明らかになる。
【発明を実施するための最良の形態】
【００１０】
音声遅延を低減するためのハードウェアによる方法およびシステムの発明について説明する。しかしながら、本発明は、これらの具体的な詳細事項の一部または全部がなくとも実施可能であることは、当業者にとって明らかである。また、本発明を不必要に分かりにくくしないため、周知の処理動作に関しては詳細に説明していない。
【００１１】
本明細書に記載された実施形態は、音声データを処理するためのプログラム命令を実行する際に音声遅延を低減するための方法およびシステムを提供する。一実施形態では、音声バッファに格納された音声データの量が決定され、その量は、上側閾値および下側閾値と比較される。以下で詳細に説明するように、音声レンダラへの音声デ―タ供給は、上述の量が上側閾値と下側閾値との間になるように漸次的に調整される。音声バッファに格納された音声データの量を上側閾値と下側閾値との間に維持することにより、音声遅延は、低減または完全に排除される。
【００１２】
図１は、本発明の一実施形態に従って、アナログ音声信号をレンダリングするためのシステムを示す簡略なブロック図である。図１に示すように、システム１４０は、オペレーティングシステム１５２と、映像／音声キャプチャ装置１５０と、音声エンコーダ１７０と、スピーカ１７２とを備える。オペレーティングシステム１５２は、映像／音声キャプチャ装置１５０および音声エンコーダ１７０と通信する。オペレーティングシステム１５２は、ハードウェアおよび基本的なシステムオペレーションの制御および管理と、アプリケーションソフトウェアの実行とに関与するシステムソフトウェアである。オペレーティングシステム１５２の例としては、Ｍｉｃｒｏｓｏｆｔ  Ｗｉｎｄｏｗｓ（登録商標）、Ｍｉｃｒｏｓｏｆｔ−ＤＯＳ、ＵＮＩＸ（登録商標）、Ｌｉｎｕｘ、Ｍａｃｉｎｔｏｓｈ  Ｏｐｅｒａｔｉｎｇ  Ｓｙｅｔｅｍなどが挙げられる。オペレーティングシステム１５２には、ストリーミングドライバ１６６および音声レンダラ１６８が備えられている。ストリーミングドライバ１６６は、サウンドカード、ＴＶチューナカード、ビデオグラフィクスカードなどのマルチメディア装置のためのストリーミングデータの処理をサポートする任意の適切なドライバを含んでよいことを理解されたい。音声レンダラ１６８は、音声データをレンダリングする任意の適切なレンダラを含む。音声レンダラ１６８の例としては、音声データのフィルタリングとレンダリングとを行うＭｉｃｒｏｓｏｆｔ  ＤｉｒｅｃｔＳｏｕｎｄ  Ａｕｄｉｏ  Ｒｅｎｄｅｒｅｒが挙げられる。
【００１３】
システム１４０は、さらに、ソース（例えば、ビデオゲーム機、ビデオカメラ、テレビ、ビデオカセットレコーダなど）からのアナログ音声／映像出力を、コンピュータシステムへのリアルタイムストリーミングのためのデジタルフォーマットに変換するための装置である映像／音声キャプチャ装置１５０を備えてよい。映像／音声キャプチャ装置１５０は、ソースからの映像および音声をコンピュータシステム上で視聴および取り込みできるように、ユニバーサルシリアルバス（ＵＳＢ）を介してコンピュータシステムにソースを接続するために用いられてよい。映像／音声キャプチャ装置１５０は、ソースとコンピュータシステムとの間の接続の一例に過ぎないことを理解されたい。他の種類の接続は、ソースをコンピュータシステムのサウンドカードに接続するオーディオケーブル、ソースをコンピュータシステムのビデオカードに接続するビデオケーブルなどを含んでよい。システム１４０は、さらに、デジタル音声データをアナログ音声データに変換してアナログ音声データをスピーカ１７２に対してレンダリングする音声エンコーダ１７０を備える。
【００１４】
図１に示すように、音声デコーダ１６２は、アナログ音声信号１５４を受信して、そのアナログ音声信号を音声キャプチャクロック周波数（例えば、４８ＫＨｚ、４８．０５ＫＨｚなど）でデジタル音声データ１５６に変換し、ＵＳＢコントローラ１６４に出力する。ＵＳＢコントローラ１６４は、デジタル音声データ１５６を受信して、ストリーミングデジタル音声データを、ＵＳＢバス１５８を介してオペレーティングシステム１５２のストリーミングドライバ１６６に転送する。次に、ストリーミングドライバ１６６は、音声データを処理して、デジタル音声データ１６０をレンダリングのための音声レンダラ１６８に出力する。その結果、音声レンダラ１６８は、バッファリングされたデジタル音声データを音声レンダリングクロック周波数（例えば、４８．００ＫＨｚ）で音声エンコーダ１７０に送信する。次に、音声エンコーダ１７０は、スピーカ１７２でのレンダリングに向けて、デジタル音声データをアナログ音声データに変換する。
【００１５】
図２は、本発明の一実施形態に従って、図１のオペレーティングシステムを示す詳細なブロック図である。図２に示すように、オペレーティングシステム１５２は、ストリーミングドライバ１６６と音声レンダラ１６８とを備える。ストリーミングドライバ１６６が、デジタル音声データ１６０を音声レンダラ１６８に転送した後に、音声レンダラが、デジタル音声データをレンダリングのために音声バッファ２０４に一時的に格納することにより、異なる速度で音声データを処理する音声レンダラおよび音声エンコーダは、互いに遅延することなしに動作することが可能になる。
【００１６】
音声バッファ２０４に関して、図２は、さらに、音声バッファに格納された音声データの量を示す充満度２０８を示している。例えば、充満度２０８の値が大きいと、音声バッファ２０４に格納された音声データの量が多いことを示す。音声バッファ２０４に格納された音声データの量は、音声信号処理の遅延と正の相関を示すことに注意されたい。例えば、充満度２０８が大きいほど、音声信号の処理の遅延は長くなる。さらに、以下で詳細に説明するように、本発明の実施形態は、上側閾値２０６と下側閾値２１０とを用いて、音声バッファ２０４に格納された音声データの量（すなわち、充満度２０８）が上側閾値と下側閾値との間になるように、音声レンダラ１６８への音声データ供給を漸次的に調整することにより、音声遅延を低減する。
【００１７】
さらに、本発明の一実施形態は、音声レンダラ１６８への音声データ供給を調節するので、ストリーミングドライバ１６６に、本発明の実施形態が備えられてもよい。例えば、一実施形態では、ストリーミングドライバ１６６は、さらに、ストリーミングドライバから音声レンダラ１６８への音声データ供給を漸次的に調節するためのプログラム命令２１２を備えてもよい。具体的には、以下で詳細に説明するように、ストリーミングドライバ１６６に備えられたプログラム命令２１２は、充満度２０８が上側閾値２０６と下側閾値２１０との間になるように、音声レンダラ１６８への音声データ供給を増減することにより、調整を行ってよい。
【００１８】
図３は、本発明の一実施形態に従って、音声データを処理するためのプログラム命令を実行する際に音声遅延を低減する方法の概略を示すフローチャートである。動作３０２で開始され、最初に、音声バッファに格納された音声データの量が決定される。その後、動作３０４において、音声バッファに格納された音声データの量は、上側閾値および下側閾値と比較される。次に、動作３０６において、音声データ供給は、格納されたデータの量が、上側閾値と下側閾値との間になるように、漸次的に調整される。
【００１９】
図４は、本発明の一実施形態に従って、音声データを処理するためのプログラム命令を実行する際に音声遅延を低減する方法の詳細を示すフローチャートである。まず、動作４０２および４０４において、上側閾値および下側閾値が準備される。上側閾値は、任意の適切な値を含んでよく、下側閾値は、上側閾値よりも小さい任意の適切な値を含んでよい。代表的な一実施形態では、上側閾値は、以下の式で算出されてよい。
【００２０】
【数１】
2006313310.tif 000003
【００２１】
式（１．０）に関して、最大遅延時間（すなわち、ｍａｘ＿ｄｅｌａｙ＿ｔｉｍｅ）は、音声レンダラによるレンダリングの際に音声遅延が最大遅延時間の範囲内にあることを保証するために、本発明の実施形態が用いる時間制限である。代表的な最大遅延時間は５０ｍｓである。Ｆｒｅｑ＿ａｕｄｉｏは、標準音声周波数であり、上述のように、音声キャプチャクロック周波数および音声キャプチャクロック周波数とは異なってよい。代表的な標準音声周波数は、４８ＫＨｚ、４４．１ＫＨｚ、３２ＫＨｚなどである。したがって、一実施形態では、最大遅延時間および標準音声周波数が与えられると、上側閾値を算出することができる。例えば、最大遅延時間＝５０ｍｓ、標準音声周波数＝４８ＫＨｚとすると、上側閾値は、（５０ｍｓ／１０００）＊４８０００＝２４００サンプルとなる。
【００２２】
下側閾値は、上側閾値よりも小さい任意の適切な値を含んでよい。一実施形態では、下側閾値は、上側閾値から導かれてよい。例えば、下側閾値は、以下の式で算出されてよい。
【００２３】
【数２】
2006313310.tif 000004
【００２４】
したがって、上述の２４００サンプルの上側閾値から、下側閾値は、単に、２４００サンプル／３＝８００サンプルとなる。
【００２５】
さらに、図４を参照すると、動作４０６において、音声バッファに格納された音声データの量が決定される。音声データの量は、音声レンダラから充満度の値を直接的に受信することによって決定されてよい。その後、動作４０８において、音声データの量は、上側閾値および下側閾値と比較される。動作４１０に示すように、上側閾値は、格納量が上側閾値よりも大きいか否かを決定するために、音声バッファに格納された音声データの量と比較される。音声バッファに格納されたデータの量が、上側閾値よりも大きい場合には、動作４１２において、ストリーミングドライバからの音声データ供給が、漸次量だけ減らされる。具体的には、ストリーミングドライバは、まず、音声データのサンプルを受信し、補間法を用いて、受信した音声データのサンプルを漸次量だけ減らす。任意の適切な補間技術が用いられてよいことを理解されたい。代表的な補間技術としては、線形補間および非線形補間が挙げられる。さらに、補間法は、単に、音声データの下限または上限を取得することを含んでもよい。
【００２６】
次に、ストリーミングドライバは、減らされた音声データのサンプルを音声レンダラに出力する。例えば、漸次量が、１０００サンプルごとに２つの音声データサンプルと指定された場合には、ストリーミングドライバが受信した１０００サンプルごとに、ストリーミングドライバは、１０００の受信サンプルから２サンプルを減らし、１０００の受信サンプルを補間して、９９８のサンプルを生成する。次に、ストリーミングドライバは、９９８の音声データのサンプルを音声レンダラに出力する。音声バッファに格納された音声データの量が、補間後に、上側閾値よりもまだ大きい場合には、音声データは、音声レンダラが音声データをレンダリングできる速度よりも速く、音声レンダラに供給されている。したがって、ストリーミングドライバは、さらに、音声データサンプルの数を９９６に減らす。音声レンダラにバッファリングされる音声データの量が、上側閾値以下になるまで、音声データの次のサンプルが、繰り返し減らされる。
【００２７】
一方、図４に示すように、音声バッファに格納された音声データの量が上側閾値以下の場合には、音声データの量が下側閾値よりも小さいか否かを決定するために、動作４１１において、別の比較を行ってよい。音声データの量が下側閾値以上である場合には、音声データの量は、上側閾値と下側閾値との間であるため、さらなる調整は必要ない。しかしながら、音声データの量が下側閾値よりも小さい場合には、動作４１４において、ストリーミングドライバからの音声データ供給が、漸次量だけ増やされる。具体的には、ストリーミングドライバは、まず、音声データのサンプルを受信し、補間法を用いて、音声データのサンプルを漸次量だけ増やす。次に、ストリーミングドライバは、増やされた音声データのサンプルを音声レンダラに出力する。例えば、漸次量が、１０００サンプルごとに２つの音声データサンプルと指定された場合には、ストリーミングドライバが受信した１０００サンプルごとに、ストリーミングドライバは、補間法により１０００の受信サンプルに２サンプルを追加して、１００２のサンプルを生成する。次に、ストリーミングドライバは、１００２の音声データのサンプルを音声レンダラに出力する。音声バッファに格納された音声データの量が、補間後に、下側閾値よりもまだ小さい場合には、音声データは、音声レンダラが音声データをレンダリングできる速度よりも遅く、音声レンダラに供給されている。したがって、ストリーミングドライバは、さらに、音声データサンプルの数を１００４に増やす。音声レンダラに格納された音声データの量が、下側閾値以上になるまで、次の音声データサンプルが、繰り返し増やされる。
【００２８】
上述のように、漸次量は、音声バッファに格納された音声データの量が、上側閾値よりも大きい、または、下側閾値よりも小さい場合ごとに調整されるサンプルの数である。漸次量は、任意の適切な値を含んでよい。例えば、一実施形態では、漸次量は、以下の式によって算出される。
【数３】
2006313310.tif 000005
式（１．２）によると、元のサンプルサイズは、ストリーミングドライバによって受信された音声サンプルの数である。上述のように、音声レンダリングクロック周波数（すなわち、Ｆｒｅｑ＿２）は、音声レンダラが音声データを音声エンコーダに送信する周波数であり、音声キャプチャクロック周波数（すなわち、Ｆｒｅｑ＿１）は、音声デコーダがアナログ音声信号をデジタル音声データに変換する周波数である。例えば、標準音声周波数（すなわち、ｆｒｅｑ＿ａｕｄｉｏ）が４８ＫＨｚであり、音声バッファに格納された音声データの量が、２４秒間に０から２４００サンプルまで増大する（５０ｍｓの遅延）と仮定すれば、８分間に約１秒の遅延となり（（８＊６０／２４）＊５０ｍｓ＝１０００ｍｓ＝１ｓ）、１秒ごとに、音声データの量は、１００サンプルだけ増大し、Ｆｒｅｑ＿２／Ｆｒｅｑ＿１＝（４８０００＋１００）／４８０００＝４８１／４８０となる。元のサンプルサイズが４８１である場合には、漸次量＝４８１＊（４８１／４８０−１）＝１である。したがって、４８１サンプルごとに１サンプルが減らされ、その結果、減らされた音声データは、音声レンダラが音声データをレンダリングするのと同じ速度で音声レンダラに供給される。
【００２９】
図５は、Ｍｉｃｒｏｓｏｆｔ  Ｗｉｎｄｏｗｓ（登録商標）で本発明の一実施形態を実施するための詳細な方法を示すフローチャートである。まず、動作５０２において、ストリーミングドライバは、ＤｉｒｅｃｔＳｏｕｎｄ  Ａｕｄｉｏ  Ｒｅｎｄｅｒｅｒからバッファ充満度情報を読み込むアプリケーションから音声バッファ充満度情報を受信するためのアプリケーションプログラムインターフェース（ＡＰＩ）を作成する。具体的には、ＡＰＩを作成するために、Ｍｉｃｒｏｓｏｆｔ  Ｓｔｒｅａｍ  Ｃｌａｓｓミニドライバが、以下のプロパティセットグローバル一意識別子（ＧＵＩＤ）を定義して、そのプロパティセットをＩＫＳＰｒｏｐｅｒｔｙＳｅｔインターフェースに実装する。そのプロパティセットは、アプリケーションが、ＧＵＩＤ  ＰＲＯＰＳＥＴＩＤ＿ＡＤＡＰＴＥＣ＿ＰＲＯＰＥＲＴＩＥＳ（｛０ｘ２ｄ２ｃ４ｃｄ１，０ｘｄ８ｃ７，０ｘ４５ａｅ，｛０ｘｂ５，０ｘ４ａ，０ｘｅｅ，０ｘ７ｃ，０ｘ６６，０ｘａ，０ｘ８２，０ｘ５４｝｝と定義されている）と共に、ＩＫＳＰｒｏｐｅｒｔｙＳｅｔインターフェースを通してドライバに命令を送信することを可能にする。ここで、プロパティセットＧＵＩＤ  ＰＲＯＰＳＥＴＩＤ＿ＡＤＡＰＴＥＣ＿ＰＲＯＰＥＲＴＩＥＳは、それら特定のプロパティに関する設定を提供する。例えば、以下の表Ａは、プロパティセットに実装可能な代表的なプロパティＩＤをまとめたものであり、さらに、ＳｅｔおよびＧｅｔ呼び出しに渡されるパラメータを示している。
【００３０】
【表１】
2006313310.tif 000006
【００３１】
図５に示すように、ＡＰＩが作成された後、ＡＰＩは、動作５０４において、ＩＡＭＡｕｄｉｏＲｅｎｄｅｒｅｒＳｔａｔｓ：：ＧｅｔＳｔａｔＰａｒａｍメソッドにより、ＤｉｒｅｃｔＳｏｕｎｄ  Ａｕｄｉｏ  Ｒｅｎｄｅｒｅｒから音声バッファ充満度情報を取得する。次に、動作５０６において、充満度が、上側閾値よりも大きい、または、下側閾値よりも小さいか否かを決定するための比較が実行される。充満度が、上側閾値よりも大きい、または、下側閾値よりも小さい場合には、アプリケーションは、動作５０８において、プロパティセットＧＵＩＤ（ＰＲＯＰＳＥＴＩＤ＿ＡＤＡＰＴＥＣ＿ＰＲＯＰＥＲＴＩＥＳ）およびプロパティＩＤ（ＡＤＰＴ＿ＡＵＤＩＯ＿ＲＥＮＤＥＲＥＲ＿ＦＵＬＬＮＥＳＳ）と共に、ＩＫＳＰｒｏｐｅｒｔｙＳｅｔインターフェースを通して、充満度情報をストリーミングドライバに送信する。逆に、充満度が、上側閾値と下側閾値との間にある場合には、充満度情報は、ストリーミングドライバに送信されない。
【００３２】
図５は、さらに、動作５０８の後に、ストリーミングドライバが、動作５１０において、音声データ供給を漸次的に調整することを示している。上述のように、音声レンダラへの音声データ供給は、補間法によって増減される。換言すれば、ストリーミングドライバは、音声データを音声レンダラに転送する前に、充満度が、上側閾値よりも大きい、または、下側閾値よりも小さいか否かに応じて、補間法を用いて、音声データ供給を縮小または拡大する。以下の表Ｂは、音声データ供給を漸次的に調整して音声遅延を低減するためのプログラム命令の代表的な実施形態である。
【００３３】
【表２】
2006313310.tif 000007
【００３４】
表Ｂに含まれるアルゴリズムは、例示に過ぎず、音声データのサンプルを増減するために、多くの別のアルゴリズムを用いてもよい。
【００３５】
音声遅延を低減するための上述の機能は、メモリ（例えば、ランダムアクセスメモリ（ＲＡＭ）、ハードディスクドライブ、フレキシブルディスク、磁気テープ、光ディスクなど）に格納されてプロセッサによって実行されるプログラムアプリケーションに組み込まれてよい。例えば、上述の機能は、その機能を実行するためのプログラム命令を有するストリーミングドライバなどを介して提供されてよい。一実施形態では、ストリーミングドライバは、音声バッファに格納された音声データの量を決定するためのプログラム命令と、その量を上側閾値および下側閾値と比較するためのプログラム命令とを備える。さらに、その量が上側閾値と下側閾値との間になるように、音声レンダラへの音声データ供給を漸次的に調整するためのプログラム命令が備えられる。
【００３６】
要約すると、上述の発明は、音声データを処理するためのプログラム命令を実行する際に音声遅延を低減するための方法およびシステムを提供する。本質的に、遅延を低減するために、ストリーミングドライバは、音声バッファに格納された音声データの量が上側閾値よりも大きい場合に、音声レンダラが音声データをレンダリングできる速度よりも遅く、音声データを音声レンダラに供給する。逆に、ストリーミングドライバは、音声データの量が下側閾値よりも小さい場合に、音声レンダラが音声データをレンダリングできる速度よりも速く、音声データを音声レンダラに供給するよう、さらに構成されてもよい。このように、音声バッファに格納された音声データの量を上側閾値と下側閾値との間に維持することにより、音声が映像と同期するように、音声遅延が低減または完全に排除される。
【００３７】
上述の実施形態を考慮して、本発明は、コンピュータシステムに格納されたデータを含む様々なコンピュータによる動作を用いてよいことを理解されたい。これらの動作は、物理量の物理的操作を必要とする動作である。通例、必ずとは限らないが、これらの量は、格納、転送、合成、比較、およびその他の操作が可能な電気または磁気信号の形態を取る。さらに、実行される操作は、生成、識別、決定、または比較などの用語で呼ばれることが多い。
【００３８】
本発明は、コンピュータ読み取り可能な媒体上のコンピュータ読み取り可能なコードとして実施されてもよい。コンピュータ読み取り可能な媒体とは、格納後にコンピュータが読み取ることのできるデータを格納可能な任意のデータ記憶装置である。コンピュータ読み取り可能な媒体は、さらに、コンピュータコードが具現化された電磁搬送波を含む。コンピュータ読み取り可能な媒体の例としては、ハードドライブ、ネットワーク接続ストレージ（ＮＡＳ）、読み取り専用メモリ、ランダムアクセスメモリ、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＣＤ−ＲＷ、磁気テープ、その他の光学および非光学式のデータ記憶装置が挙げられる。コンピュータ読み取り可能な媒体は、コンピュータ読み取り可能なコードが分散的に格納および実行されるように、ネットワーク接続されたコンピュータシステム上に分散されてもよい。
【００３９】
本発明の一部を形成する本明細書に記載した動作はすべて、有用な機械動作である。本発明は、さらに、これらの動作を実行するためのデバイスまたは装置に関する。装置は、必要な目的に対して特別に構築されてもよいし、コンピュータに格納されたコンピュータプログラムによって選択的に作動または構成される汎用コンピュータであってもよい。特に、本明細書の教示に従って記述されたコンピュータプログラムと共に、様々な汎用マシンを用いてもよいし、必要な動作を実行するためのより特殊化した装置を構築して、利便性を高めてもよい。
【００４０】
上述の発明は、携帯用デバイス、マイクロプロセッサシステム、マイクロプロセッサを用いた、またはプログラム可能な家庭用電化製品、ミニコンピュータ、メインフレームコンピュータなど、他のコンピュータシステム構成で実施されてもよい。上述の発明は、理解しやすいように、ある程度詳細に説明されているが、添付の特許請求の範囲内で、いくらかの変更や変形を実施できることは明らかである。したがって、上述の実施形態は、例示的なものであって限定的なものではないと見なされ、本発明は、本明細書に開示された詳細事項に限定されず、添付の特許請求の範囲および等価物の範囲内で変形されてよい。請求項では、構成要素および／または工程は、請求項内で特に触れない限りは、動作の特定の順序を示すものではない。
【図面の簡単な説明】
【００４１】
【図１】本発明の一実施形態に従って、アナログ音声信号をレンダリングするためのシステムを示す簡略なブロック図。
【図２】本発明の一実施形態に従って、図１のオペレーティングシステムを示す詳細なブロック図。
【図３】本発明の一実施形態に従って、音声データを処理するためのプログラム命令を実行する際に音声遅延を低減する方法の概略を示すフローチャート。
【図４】本発明の一実施形態に従って、音声データを処理するためのプログラム命令を実行する際に音声遅延を低減する方法の詳細を示すフローチャート。
【図５】本発明の一実施形態に従って、Ｍｉｃｒｏｓｏｆｔ  Ｗｉｎｄｏｗｓ（登録商標）で本発明の一実施形態を実施するための詳細な方法を示すフローチャート。
【図１】
2006313310.tif 000008
【図２】
2006313310.tif 000009
【図３】
2006313310.tif 000010
【図４】
2006313310.tif 000011
【図５】
2006313310.tif 000012
【外国語明細書】
1. TITLE OF THE INVENTION
Method and System for Reducing Audio Latency
2. DETAILED DESCRIPTION OF THE INVENTION
Background of the Invention
1.  Field of the Invention 
This invention relates generally to audio processing and, more particularly, to method and system for reducing audio latency.
2.  Description of the Related Art
A computer can be configured to capture audio/video outputted from a wide variety of sources, such as camcorders, televisions, video cassette recorders, etc.  When previewing a real-time audio/video from a source on a computer, a user will typically experience audio latency whereby the audio and video are not synchronized.  In other words, the audio may lag behind or lead the video by a few seconds.
Audio latency may be caused by the use of different clock frequencies by a video/audio capture device and by the computer.  In particular, a first frequency used within the video/audio capture device is typically different from a second frequency of audio capture clock at which an audio renderer within the computer sends audio data to an audio encoder.  For instance, if the first frequency is greater than the second frequency, then rendering is slower than capturing, which results in an increase in audio latency.  On the other hand, if the first frequency is lesser than the second frequency then rendering is faster than capturing, which results in audio gaps that manifests as audio clicks.
As a result, there is a need to provide method and system for reducing audio latency to synchronize audio with video.
Summary of the Invention
Broadly speaking, the present invention fills these needs by providing method and system for reducing audio latency.  It should be appreciated that the present invention can be implemented in numerous ways, including as a method, a system, or a device.  Several inventive embodiments of the present invention are described below.
In accordance with a first aspect of the present invention, a method for reducing audio latency when executing program instructions for processing audio data is provided.  In this method, a top threshold value and a bottom threshold value are provided.  A determination is then made as to the amount of audio data stored in an audio buffer of an audio renderer.  Thereafter, the amount is compared with the top threshold value and the bottom threshold value, and accordingly, an audio data feed to the audio renderer is adjusted incrementally such that the amount is between the top threshold value and the bottom threshold value.
In accordance with a second aspect of the present invention, a computer readable medium having program instructions for reducing audio latency when executing program instructions for processing audio data is provided.  The computer readable medium includes program instructions for providing a top threshold value and a bottom threshold value.  Additionally included are program instructions for determining an amount of the audio data stored in an audio buffer of an audio renderer and program instructions for comparing the amount with the top threshold value and the bottom threshold value.  Furthermore, the computer readable medium includes program instructions for decreasing the audio data feed from a streaming driver to the audio renderer by an incremental amount if the amount is greater than the top threshold value, and program instructions for increasing the audio data feed from the streaming driver to the audio renderer by the incremental amount if the amount is less than the bottom threshold value.
In accordance with a third aspect of the present invention, a computer system for reducing audio latency when executing program instructions for processing audio data is provided.  The computer system includes a memory configured to store a streaming driver program and a processor configured to execute the streaming driver program stored in the memory.  The streaming driver program includes program instructions for determining an amount of the audio data stored in an audio buffer of an audio renderer and program instructions for comparing the amount with a top threshold value and a bottom threshold value.  Additionally included are program instructions for decreasing the audio data feed to the audio renderer such that the decreased audio data feed is slower than a rendering of the audio data by the audio renderer if the amount is greater than the top threshold value, and program instructions for increasing the audio data feed to the audio renderer such that the increased audio data feed is faster than the rendering of the audio data by the audio renderer if the amount is less than the bottom threshold value.
Other aspects and advantages of the invention will become apparent from the following detailed description, taken in conjunction with the accompanying drawings, illustrating by way of example the principles of the invention.
The present invention will be readily understood by the following detailed description in conjunction with the accompanying drawings, and like reference numerals designate like structural elements.
Detailed Description
An invention is described for hardware implemented method and system for reducing audio latency.  It will be obvious, however, to one skilled in the art, that the present invention may be practiced without some or all of these specific details.  In other instances, well known process operations have not been described in detail in order not to unnecessarily obscure the present invention.
The embodiments described herein provide method and system for reducing audio latency when executing program instructions for processing audio data.  In one embodiment, an amount of audio data stored in an audio buffer is determined, and the amount is compared with a top threshold value and a bottom threshold value.  As will be explained in more detail below, an audio data feed to an audio renderer is adjusted incrementally such that the amount is between the top threshold value and the bottom threshold value.  By keeping the amount of audio data stored in the audio buffer within the top threshold value and the bottom threshold value, audio latency is reduced or altogether eliminated.
Figure 1 is a simplified block diagram of a system for rendering analog audio signals, in accordance with one embodiment of the present invention.  As shown in Figure 1, system 140 includes operating system 152, video/audio capture device 150, audio encoder 170, and speaker 172.  Operating system 152 is in communication with video/audio capture device 150 and audio encoder 170.  Operating system 152 is the system software responsible for the control and management of hardware and basic system operations, as well as running application software.  Exemplary operating system 152 includes Microsoft Windows, Microsoft-DOS, UNIX, Linux, Macintosh Operating System, etc.  Included within operating system 152 are streaming driver 166 and audio renderer 168.  It should be appreciated that streaming driver 166 may include any suitable driver that supports the processing of streamed data for multimedia devices such as sound cards, TV tuner cards, video graphics cards, etc.  Audio renderer 168 includes any suitable renderer that renders audio data.  An exemplary audio renderer 168 is the Microsoft DirectSound Audio Renderer that filters and renders audio data.
System 140 may additionally include video/audio capture device 150 that is an apparatus for converting analog audio/video output from a source (e.g., video game consoles, camcorders, televisions, video cassette recorders, etc.) to a digital format for real-time streaming to a computer system.  Video/audio capture device 150 may be used to connect the source to the computer system through Universal Serial Bus (USB) such that video and audio from the source may be viewed, listened, and captured on the computer system.  It should be appreciated that video/audio capture device 150 is merely an example of one type of connection between a source and computer system.  Other types of connections may include audio cables that connect the source to a sound card of the computer system, video cables that connect the source to a video card of the computer system, etc.  System 140 additionally includes audio encoder 170 which converts digital audio data to analog audio data and renders the analog audio data to speaker 172.
As shown in Figure 1, audio decoder 162 receives analog audio signal 154 and converts the analog audio signal to digitized audio data 156 at an audio capture clock frequency (e.g., 48KHz, 48.05 KHz, etc.) for output to USB controller 164.  USB controller 164 receives digitized audio data 156 and transfers the streaming, digitized audio data to streaming driver 166 of operating system 152 via USB bus 158.  Subsequently, streaming driver 166 processes the audio data and outputs digitized audio data 160 to audio renderer 168 for rendering.  As a result, audio renderer 168 sends a buffered, digital audio data to audio encoder 170 at an audio rendering clock frequency (e.g., 48.00 KHz).  Audio encoder 170 then converts the digital audio data to analog audio data for rendering on speaker 172.
Figure 2 is a more detailed block diagram of the operating system shown in Figure 1, in accordance with one embodiment of the present invention.  As shown in Figure 2, operating system 152 includes streaming driver 166 and audio renderer 168.  After streaming driver 166 passes digitized audio data 160 to audio renderer 168, the audio renderer temporarily stores the digitized audio data in audio buffer 204 for rendering, which allows the audio renderer and an audio encoder that process the audio data at different speeds to operate without being delayed by one another.
With reference to audio buffer 204, Figure 2 additionally shows fullness 208 that indicates the amount of audio data stored in the audio buffer.  For example, a large fullness 208 value indicates a large amount of audio data stored in audio buffer 204.  It should be noted that the amount of audio data stored in audio buffer 204 has a direct correlation with the delay of audio signal processing.  For instance, the larger the fullness 208, the longer the delay of processing the audio signals.  Furthermore, as will be explained in more detail below, embodiments of the invention use top threshold value 206 and bottom threshold value 210 for reducing audio latency by adjusting incrementally the audio data feed to audio renderer 168 such that the amount of audio data (i.e., fullness 208) stored in audio buffer 204 is between the top threshold value and the bottom threshold value.
Further, since an embodiment of the invention adjusts the audio data feed to audio renderer 168, embodiments of the invention may be included in streaming driver 166.  For example, in one embodiment, streaming driver 166 may additionally include program instructions 212 for adjusting incrementally the audio data feed from the streaming driver to audio renderer 168.  Specifically, as will be explained in more detail below, program instructions 212 included in streaming driver 166 may make the adjustments by decreasing or increasing the audio data feed to audio renderer 168 such that fullness 208 is between top threshold value 206 and bottom threshold value 210.
Figure 3 is a flowchart diagram of a high level overview of a method for reducing audio latency when executing program instructions for processing audio data, in accordance with one embodiment of the present invention.  Starting in operation 302, an amount of audio data stored in an audio buffer is first determined.  Thereafter, in operation 304, the amount of audio data stored in the audio buffer is compared with a top threshold value and a bottom threshold value.  The audio data feed is then adjusted incrementally in operation 306 such that the amount of stored audio data is between the top threshold value and the bottom threshold value.
Figure 4 is a flowchart diagram of a more detailed method for reducing audio latency when executing program instructions for processing audio data, in accordance with one embodiment of the present invention.  Starting with operations 402 and 404, a top threshold value and a bottom threshold value are provided.  Top threshold value may include any suitable value, and bottom threshold value may include any suitable value that is less than the top threshold value.  In one exemplary embodiment, top threshold value may be calculated by:
2006313310.tif 000013
With regard to Equation (1.0), maximum delay time (i.e., max_delay_time) is a time limit used by embodiments of the invention to assure that audio latency will be within the maximum delay time during rendering by audio renderer.  An exemplary maximum delay time is 50 ms.  Freq_audio is the standard audio frequency, which may be different from audio capture clock frequency and audio capture clock frequency as discussed above.  Exemplary standard audio frequencies include 48KHz, 44.1KHz, 32KHz, etc.  Accordingly, in one embodiment, a top threshold value may be calculated if the maximum delay time and the standard audio frequency are provided.  For example, assuming maximum delay time = 50 ms and standard audio frequency = 48 KHz, then top threshold is (50 ms / 1000) * 48000, which equals 2400 samples.
Bottom threshold value may include any suitable value that is less than top threshold value.  In one embodiment, bottom threshold value may be derived from top threshold value.  For instance, bottom threshold value may be calculated by:
2006313310.tif 000014
Accordingly, with reference to the top threshold value of 2400 samples discussed above, the bottom threshold value is simply 2400 samples / 3, which equals 800 samples.
Still referring to Figure 4, the amount of audio data stored in the audio buffer is then determined in operation 406.  The amount of audio data may be determined by receiving the fullness value directly from audio renderer.  Thereafter, the amount of audio data is compared with the top threshold value and the bottom threshold value in operation 408.  As shown in operation 410, the top threshold value is compared with the amount of audio data stored in the audio buffer to determine whether the stored amount is greater than the top threshold value.  If the amount of data stored in audio buffer is greater than top threshold value, then the audio data feed from a streaming driver is decreased by an incremental amount in operation 412.  Specifically, the streaming driver first receives a sample of the audio data and reduces the sample of the received audio data by the incremental amount through interpolation.  It should be appreciated that any suitable interpolation techniques may be applied.  Exemplary interpolation techniques include linear interpolation and non-linear interpolation.  Additionally, interpolation may simply include taking the floor or ceiling of the audio data.
Subsequently, the streaming driver outputs the reduced sample of audio data to the audio renderer.  For example, if the incremental amount is specified as two audio data samples in each 1000 samples, then for every 1000 samples received by streaming driver, streaming driver reduces two samples from the 1000 received samples, and interpolates the 1000 received samples to generate 998 samples.  Streaming driver then outputs the 998 samples of audio data to the audio renderer.  If the amount of audio data stored in the audio buffer is still greater than the top threshold value after the interpolation, then the audio data is still fed to the audio renderer faster than the speed at which the audio renderer can render the audio data.  Accordingly, the streaming driver will further reduce the number of audio data samples to 996.  The reduction will repeat for subsequent samples of the audio data until the amount of audio data buffered in audio renderer is less than or equal to the top threshold value.
On the other hand, as shown in Figure 4, if the amount of audio data stored in audio buffer is not greater than top threshold value, then another comparison may be conducted in operation 411 to determine whether the amount of audio data is less than the bottom threshold value.  If the amount of audio data is not less than the bottom threshold value, then the amount of audio data is between the top threshold value and the bottom threshold value, and no further adjustments are necessary.  However, if the amount of audio data is less than the bottom threshold value, then the audio data feed from the streaming driver is increased by an incremental amount in operation 414.  Specifically, the streaming driver first receives a sample of the audio data and increases the sample of the audio data by the incremental amount through interpolation.  Subsequently, the streaming driver outputs the increased sample of the audio data to the audio renderer.  For example, if the incremental amount is again specified as two audio data samples in each 1000 samples, then for every 1000 samples received by streaming driver, the streaming driver adds two samples to the 1000 received samples through interpolation to generate 1002 samples.  Streaming driver then outputs the 1002 samples of audio data to the audio renderer.  If the amount of audio data stored in the audio buffer is still less than the bottom threshold value after the interpolation, then the audio data is still fed to audio renderer slower than the speed at which the audio renderer can render the audio data.  Accordingly, the streaming driver will further increase the number of audio data samples to 1004.  The increase will repeat for subsequent samples of the audio data until the amount of audio data stored in the audio renderer is greater than or equal to the bottom threshold value.
As discussed above, the incremental amount is the number of samples that is adjusted each time when the amount of audio data stored in audio buffer is either larger than the top threshold value or lesser than the bottom threshold vale.  Incremental amount may include any suitable values.  For example, in one embodiment, the incremental amount can be calculated by:
2006313310.tif 000015
Referring to Equation (1.2), original sample size is the number of audio samples received by streaming driver.  As discussed above, audio rendering clock frequency (i.e., Freq_2) is the frequency at which an audio renderer sends audio data to an audio encoder, and audio capture clock frequency (i.e., Freq_1) is the frequency at which an audio decoder converts the analog audio signal to digitized audio data.  For example, assuming that the standard audio frequency (i.e., freq_audio) is 48 KHz and the amount of audio data stored in the audio buffer increases from 0 to 2400 samples (50 ms delay) during 24 seconds, which is about a one second delay in eight minutes ((8*60/24)*50ms = 1000ms = 1s), then for each second the amount of audio data increases by 100 samples, and Freq_2/Freq_1 = (48000 + 100)/48000 = 481/480.  If original sample size is 481, then incremental amount = 481*(481/480-1) =1.  Thus, one sample is reduced for every 481 samples and, as a result, the reduced audio data is fed to the audio renderer at the same speed as the audio renderer renders the audio data.
Figure 5 is a flowchart diagram of a detailed method for implementing an embodiment of the present invention in Microsoft Windows.  Starting in operation 502, the streaming driver creates an application program interface (API) to receive audio buffer fullness information from an application that reads the buffer fullness information from the DirectSound Audio Renderer.  Specifically, to create the API, Microsoft Stream Class minidriver defines the following property set Globally Unique Identifier (GUID) and implements the property set on an IKSPropertySet interface.  The property set allows applications to send commands to the driver through the IKSPropertySet interface with GUID PROPSETID_ADAPTEC_PROPERTIES, which is defined as { 0x2d2c4cd1, 0xd8c7, 0x45ae, { 0xb5, 0x4a, 0xee, 0x7c, 0x66, 0xa, 0x82, 0x54 } }.  Here, the property set GUID PROPSETID_ADAPTEC_PROPERTIES implements settings related to specific properties.  For example, the following Table A summarizes an exemplary Property ID that may be implemented in a property set and also shows the parameters to be passed to the Set and Get calls.
2006313310.tif 000016
As shown in Figure 5, after the API is created, the API gets the audio buffer fullness information from DirectSound Audio Renderer in operation 504 through an IAMAudioRendererStats::GetStatParam method.  Subsequently, operation 506 shows that a comparison is made to determine whether the fullness is greater than a top threshold value or lesser than a bottom threshold value.  If the fullness is greater than the top threshold value or lesser than the bottom threshold value, then the application sends the fullness information to streaming driver in operation 508 through the IKSPropertySet interface with property Set GUID (PROPSETID_ADAPTEC_PROPERTIES) and Property Id (ADPT_AUDIO_RENDERER_FULLNESS).  Else, if the fullness is between the top threshold value and the bottom threshold value, then the fullness information is not sent to the streaming driver.
Figure 5 further shows that after operation 508, streaming driver incrementally adjusts the audio data feed in operation 510.  As discussed above, the audio data feed to the audio renderer is increased or decreased incrementally through interpolation.  In other words, the streaming driver shrinks or expands the audio data feed through interpolation according to whether the fullness is greater than the top threshold value or lesser than the bottom threshold value before passing the audio data to audio renderer.  The following Table B is an exemplary embodiment of program instructions for adjusting incrementally the audio data feed to reduce audio latency.
2006313310.tif 000017
2006313310.tif 000018
The algorithms included in Table B are merely exemplary, and many different algorithms may be used to reduce or increase samples of audio data.
It should be appreciated that the above-described functionality for reducing audio latency may be incorporated in program application stored in memory (e.g., random access memory (RAM), hard disk drives, floppy disks, magnetic tapes, optical discs, etc.) and executed by a processor.  For example, the functionality may be provided through the streaming driver, or the like, having program instructions to perform the above-described functionality.  In one embodiment, streaming driver includes program instructions for determining an amount of the audio data stored in an audio buffer and program instructions for comparing the amount with a top threshold value and a bottom threshold value.  Further, program instructions are included for adjusting incrementally an audio data feed to an audio renderer such that the amount is between the top threshold value and the bottom threshold value.
In summary, the above described invention provides method and system for reducing audio latency when executing program instructions for processing audio data.  Essentially, to reduce latency, streaming driver feeds audio data to an audio renderer slower than the speed at which the audio renderer can render audio data if the amount of audio data stored in the audio buffer is greater than a top threshold value.  On the other hand, streaming driver may be additionally configured to feed audio data to the audio renderer faster than the speed at which the audio renderer can render audio data if the amount of audio data is less than a bottom threshold value.  Thus, by keeping the amount of audio data stored in audio buffer between the top threshold value and the bottom threshold value, audio latency is reduced or altogether eliminated such that audio is synchronized with video.
With the above embodiments in mind, it should be understood that the invention may employ various computer-implemented operations involving data stored in computer systems.  These operations are those requiring physical manipulation of physical quantities.  Usually, though not necessarily, these quantities take the form of electrical or magnetic signals capable of being stored, transferred, combined, compared, and otherwise manipulated.  Further, the manipulations performed are often referred to in terms, such as producing, identifying, determining, or comparing.
The invention can also be embodied as computer readable code on a computer readable medium.  The computer readable medium is any data storage device that can store data which can be thereafter read by a computer system.  The computer readable medium also includes an electromagnetic carrier wave in which the computer code is embodied.  Examples of the computer readable medium include hard drives, network attached storage (NAS), read-only memory, random-access memory, CD-ROMs, CD-Rs, CD-RWs, magnetic tapes, and other optical and non-optical data storage devices.  The computer readable medium can also be distributed over a network coupled computer system so that the computer readable code is stored and executed in a distributed fashion.
Any of the operations described herein that form part of the invention are useful machine operations.  The invention also relates to a device or an apparatus for performing these operations.  The apparatus may be specially constructed for the required purposes, or it may be a general purpose computer selectively activated or configured by a computer program stored in the computer.  In particular, various general purpose machines may be used with computer programs written in accordance with the teachings herein, or it may be more convenient to construct a more specialized apparatus to perform the required operations.  
The above described invention may be practiced with other computer system configurations including hand-held devices, microprocessor systems, microprocessor-based or programmable consumer electronics, minicomputers, mainframe computers and the like.  Although the foregoing invention has been described in some detail for purposes of clarity of understanding, it will be apparent that certain changes and modifications may be practiced within the scope of the appended claims.  Accordingly, the present embodiments are to be considered as illustrative and not restrictive, and the invention is not to be limited to the details given herein, but may be modified within the scope and equivalents of the appended claims.  In the claims, elements and/or steps do not imply any particular order of operation, unless explicitly stated in the claims.
3. BRIEF DESCRIPTION OF THE DRAWINGS
Figure 1 is a simplified block diagram of a system for rendering analog audio signals, in accordance with one embodiment of the present invention.
Figure 2 is a more detailed block diagram of the operating system shown in Figure 1, in accordance with one embodiment of the present invention.
Figure 3 is a flowchart diagram of a high level overview of a method for reducing audio latency when executing program instructions for processing audio data, in accordance with one embodiment of the present invention.
Figure 4 is a flowchart diagram of a more detailed method for reducing audio latency when executing program instructions for processing audio data, in accordance with one embodiment of the present invention.
Figure 5 is a flowchart diagram of a detailed method for implementing an embodiment of the present invention in Microsoft Windows, in accordance with one embodiment of the present invention.
1.  A method for reducing audio latency when executing program instructions for processing audio data, comprising method operations of:
providing a top threshold value;
providing a bottom threshold value;
determining an amount of the audio data stored in an audio buffer of an audio renderer;
comparing the amount with the top threshold value and the bottom threshold value; and
adjusting incrementally an audio data feed to the audio renderer such that the amount is between the top threshold value and the bottom threshold value.
2.  The method of claim 1, wherein the method operation of adjusting incrementally the audio data feed includes,
if the amount is greater than the top threshold value, decreasing the audio data feed to the audio renderer by an incremental amount; and
if the amount is less than the bottom threshold value, increasing the audio data feed to the audio renderer by the incremental amount.
3.  The method of claim 2, wherein the method operation of decreasing the audio data feed includes,
receiving a sample of the audio data;
reducing the sample of the received audio data by the incremental amount through interpolation; and
outputting the reduced sample of the audio data to the audio renderer.
4.  The method of claim 3, further comprising:
repeating each of the method operations for subsequent samples of the audio data until the amount is less than or equal to the top threshold value.
5.  The method of claim 2, wherein the method operation of increasing the audio data feed includes,
receiving a sample of the audio data;
increasing the sample of the received audio data by the incremental amount through interpolation; and
outputting the increased sample of the audio data to the audio renderer.
6.  The method of claim 5, further comprising:
repeating each of the method operations for subsequent samples of the audio data until the amount is greater than or equal to the bottom threshold value.
7.  The method of claim 2, wherein the incremental amount is defined by
original sample size * (audio rendering clock frequency/audio capture clock frequency - 1).
8.  The method of claim 1, wherein the top threshold value is defined by a standard audio frequency multiplied by a maximum delay time divided by a sample of the audio data.
9.  The method of claim 1, wherein the bottom threshold value is defined by the top threshold value divided by three.
10.  A computer readable medium having program instructions for reducing audio latency when executing program instructions for processing audio data, comprising method operations of:
program instructions for providing a top threshold value;
program instructions for providing a bottom threshold value;
program instructions for determining an amount of the audio data stored in an audio buffer of an audio renderer;
program instructions for comparing the amount with the top threshold value and the bottom threshold value;
program instructions for decreasing the audio data feed from a streaming driver to the audio renderer by an incremental amount if the amount is greater than the top threshold value; and
program instructions for increasing the audio data feed from the streaming driver to the audio renderer by the incremental amount if the amount is less than the bottom threshold value.
11.  The computer readable medium of claim 10, wherein the program instructions for decreasing the audio data feed includes,
program instructions for receiving a sample of the audio data;
program instructions for reducing the sample of the received audio data by the incremental amount through interpolation; and
program instructions for outputting the reduced sample of the audio data to the audio renderer.
12.  The computer readable medium of claim 10, wherein the program instructions for increasing the audio data feed includes,
program instructions for receiving a sample of the audio data;
program instructions for increasing the sample of the received audio data by the incremental amount through interpolation; and
program instructions for outputting the increased sample of the audio data to the audio renderer.
13.  The computer readable medium of claim 10, wherein the incremental amount is defined by
original sample size * (audio rendering clock frequency/audio capture clock frequency - 1).
14.  The computer readable medium of claim 10, wherein the top threshold value is defined by a standard audio frequency multiplied by a maximum delay time divided by a sample of the audio data.
15.  The computer readable medium of claim 10, wherein the bottom threshold value is defined by the top threshold value divided by three.
16.   A computer system for reducing audio latency when executing program instructions for processing audio data, comprising:
a memory configured to store a streaming driver program; and
a processor configured to execute the streaming driver program stored in the memory,
the streaming driver program including,
program instructions for determining an amount of the audio data       stored in an audio buffer of an audio renderer,
program instructions for comparing the amount with a top threshold       value and a bottom threshold value,
program instructions for decreasing the audio data feed to the audio       renderer such that the decreased audio data feed is slower than a rendering of the audio data by the audio renderer if the amount is greater than the top threshold value, and
program instructions for increasing the audio data feed to the audio       renderer such that the increased audio data feed is faster than the rendering of the audio data by the audio renderer if the amount is less than the bottom threshold value.
17.  The computer system of claim 16, wherein the program instructions for decreasing the audio data feed includes,
program instructions for receiving a sample of the audio data;
program instructions for reducing the sample of the received audio data by an incremental amount through interpolation; and
program instructions for outputting the reduced sample of the audio data to the audio renderer.
18.  The computer system of claim 16, wherein the program instructions for increasing the audio data feed includes,
program instructions for receiving a sample of the audio data;
program instructions for increasing the sample of the received audio data by an incremental amount through interpolation; and
program instructions for outputting the increased sample of the audio data to the audio renderer.
1. ABSTRACT
A method for reducing audio latency when executing program instructions for processing audio data is provided.  In this method, a top threshold value and a bottom threshold value are provided.  A determination is then made as to the amount of audio data stored in an audio buffer of an audio renderer.  Thereafter, the amount is compared with the top threshold value and the bottom threshold value, and accordingly, an audio data feed to the audio renderer is adjusted incrementally such that the amount is between the top threshold value and the bottom threshold value.
2. REPRESENTATIVE DRAWING
Fig.1
2006313310.tif 000019
2006313310.tif 000020
2006313310.tif 000021
2006313310.tif 000022
2006313310.tif 000023