JP7201033B2 - 音データ処理装置、音データ処理方法及びプログラム - Google Patents

Description

この発明は、音データ処理装置、音データ処理方法及びプログラムに関する。

従来から、音声通信や音声のストリーミング配信等で、デジタル波形データである音データを含むデータパケットを定期的に受信して、その音データを再生する場合において、データパケットが欠落した箇所を修復する技術が知られている。

例えば非特許文献１には、有声音の区間でパケットが欠落した場合に、欠落前の最後の数ミリ秒の音データをテンプレートとして、このテンプレートの中から未再生のパケットと最も一致する部分を探し、その発見した部分の音データを、ピッチを調整して欠落部分に反復して埋め込むことにより、欠落部分の修復を行う技術が記載されている。また、非特許文献１には、埋め込む音データと元の音データとの境界では、埋め込む音データと元のデータとの加重平均を取って、両者をなだらかに繋ぎ合わせることも記載されている。
また、音データを含むデータパケットを定期的に受信して、その音データを再生する技術については、特許文献１及び特許文献２にも記載されている。

特開２０１４－１１０５２５号公報 特開２０１４－１１０５２６号公報

Colin Perkins著，小川晃通監訳，「マスタリングＴＣＰ／ＩＰ ＲＴＰ編」，株式会社オーム社、２００４年４月１５日，p.202-203

この発明は、このような事情に鑑みてなされたものであり、音データを受信して出力する場合に、出力すべき音データを適切なタイミングで受信できなくてもユーザにあまり違和感を与えることなく代替の音データを出力する動作を、確実性よく行えるようにすることを目的とする。

上記の目的を達成するため、この発明のプログラムは、コンピュータに、音データを受信してその受信した音データを第１バッファに格納する受信手順と、上記受信手順で受信した音データを第２バッファに格納する手順と、所定の要求を検出した場合に上記第１バッファに格納されている音データを出力する出力手順と、上記受信手順において音データの受信の欠落が発生したことを検出した場合に、上記第２バッファに格納されている音データのうち、上記出力手順による出力がまだされていない未出力の音データと似た部分に続く音データを選択して、その選択した箇所の音データを上記未出力の音データの直後に書き込む第１書込手順とを実行させるためのプログラムであって、上記第１書込手順において、上記未出力の音データと似た部分を、上記第１バッファに格納されているデータのうち新しい方の、上記未出力の音データの量に応じた範囲のデータである比較用データに基づき、上記第２バッファをサーチして特定するプログラムである。
このようなプログラムにおいて、上記第１書込手順において、上記未出力の音データの量が所定の閾値よりも多い場合、上記第２バッファに格納されている音データのうち、上記未出力の音データの新しい方から所定サンプル数分を上記比較用データとするとよい。
さらに、上記第１書込手順において、上記未出力の音データの量が所定の閾値よりも少ない場合、上記第２バッファに格納されている音データのうち、上記第１バッファに格納されている既に送信済みの音データと上記未出力の音データとを繋げた音データを上記比較用データとするとよい。
また、上記所定の記憶領域が、音データを格納するための第２バッファを備え、上記コンピュータに、上記受信手順で受信した音データを上記第２バッファに格納する手順と、上記第１バッファに格納されている未出力の音データの量が所定の閾値以下になったことを検出した場合に、上記第２バッファに格納されている音データから上記未出力の音データに続けるべき箇所を選択して、その選択した箇所の音データを上記第１バッファの最新の音データの直後に書き込む第２書込手順とをさらに実行させるためのプログラムであるとよい。

また、上記所定の記憶領域が、音データを格納するための第３バッファを備え、上記コンピュータに、上記受信手順において音データの受信の欠落が発生したことを検出した場合に、上記第２バッファに格納されている音データを上記第３バッファにコピーするコピー手順をさらに実行させるためのプログラムであるとよい。
さらに、上記コピー手順が、上記第２バッファに格納されている上記音データを上記第３バッファにコピーすると共に、上記第２バッファをクリアする手順であるとよい。
さらに、上記第２書込手順が、上記第２バッファに格納されている音データから上記未出力の音データに続けるべき箇所を選択できない場合に、上記第３バッファに格納されている音データから上記未出力の音データに続けるべき箇所を選択して、その選択した箇所の音データを上記第１バッファの最新の音データの直後に書き込む手順であるとよい。

また、上記記憶領域が、音データを格納するための一時バッファを備え、上記第２書込手順が、上記第１バッファに格納されている未出力の音データの量が所定の閾値以下になったことを検出した場合に、上記一時バッファに所定量以上の未使用の音データが記憶されていなければ、上記未出力の音データに続けるべき箇所の音データを上記一時バッファに書き込んだ後、上記一時バッファに格納されている音データを上記所定量だけ上記第１バッファの最新の音データの直後に書き込む手順であるとよい。
あるいは、上記記憶領域が、音データを格納するための一時バッファを備え、上記第２書込手順が、上記第１バッファに格納されている未出力の音データの量が所定の閾値以下になったことを検出した場合に、上記一時バッファに所定量以上の未使用の音データが記憶されていなければ、上記未出力の音データに続けるべき箇所の音データを上記第１バッファの最新の音データの直後に書き込むことに代えて、上記未出力の音データに続けるべき箇所の音データを上記一時バッファに書き込んだ後、上記一時バッファに格納されている音データを上記所定量だけ上記第１バッファの最新の音データの直後に書き込む手順であるとよい。
また、上記第２書込手順が、上記第１バッファに格納されている未出力の音データの量が上記所定の閾値以下になったことを検出した場合に、上記一時バッファに上記所定量以上の未使用の音データが記憶されていれば、上記一時バッファに格納されている前回の書き込みの続きの音データを、上記所定量だけ上記第１バッファの最新の音データの直後に書き込む手順であるとよい。
あるいは、上記第２書込手順が、上記第１バッファに格納されている未出力の音データの量が上記所定の閾値以下になったことを検出した場合に、上記一時バッファに上記所定量以上の未使用の音データが記憶されていれば、上記第２バッファに格納されている音データから上記未出力の音データに続けるべき箇所を選択することに代えて、上記一時バッファに格納されている前回の書き込みの続きの音データを、上記未出力の音データに続けるべき箇所として上記所定量だけ上記第１バッファの最新の音データの直後に書き込む手順であるとよい。

また、上記の各プログラムにおいて、上記第２書込手順が、上記第１バッファに音データを書き込む場合に、該書き込もうとする音データの振幅を、上記未出力の音データの振幅に合わせる振幅調整を行う手順であるとよい。
あるいは、上記の各プログラムにおいて、上記受信手順が、音データの受信の欠落が発生し、その後欠落箇所の後の音データを受信した場合に、その受信した音データを、上記第１バッファの、上記欠落がなかったとした場合にその音データを書き込むべき位置へ書き込む手順であるとよい。
さらに、上記記憶領域が、音データを格納するための第２バッファを備え、上記コンピュータに、上記受信手順で受信した音データを上記第２バッファに格納する手順と、上記欠落箇所の後の音データが書き込まれる位置が、上記未出力の音データの末尾よりも後ろである場合に、上記第２バッファに格納されている音データから上記未出力の音データに続けるべき箇所を選択して、その箇所の音データを上記第１バッファの最新の音データの直後に書き込む手順とをさらに実行させるためのプログラムであるとよい。
さらに、上記受信手順は、上記欠落箇所の後の音データを上記第１バッファに書き込む場合、上記第１バッファの該書き込んだ音データよりも後ろに、上記第２バッファから選択されて上記第１バッファに書き込まれた音データがあれば、その音データを削除する手順を含むとよい。
また、この発明は、上記した具体的な態様の他、システム、方法、プログラム、記録媒体等、任意の態様で実施することができる。

以上のようなこの発明の構成によれば、音データを受信して出力する場合に、出力すべき音データを適切なタイミングで受信できなくてもユーザにあまり違和感を与えることなく代替の音データを出力する動作を、確実性よく行うことができる。

この発明の音データ処理装置の一実施形態であるＰＣのハードウェア構成を示す図である。 図１に示したＰＣに実現させる音データ処理機能の概略構成を示す図である。 図２に示した音データ処理部の機能の構成をより詳細に示す図である。 補間の準備を含む、通常状態での音データの送受信動作について説明するための図である。 補完バッファの補間用データを用いた補完動作の流れを示す図である。 補間バッファのバックアップ及びクリア動作の流れを示す図である。 図１に示したＰＣのＣＰＵが実行するメイン処理のフローチャートである。 図７のステップＳ１５で実行する音データ要求時の処理のフローチャートである。 図８の続きの処理のフローチャートである。 図９のステップＳ３３で実行する振幅調整処理のフローチャートである。 図７のステップＳ１３で実行するパケット到着時の処理のフローチャートである。 図１１の続きの処理のフローチャートである。 オーディオバッファ中の未送信データと新たに到着したパケットの音データとの関係の例を示す図である。 その別の例を示す図である。 第１変形例における音データ処理部の構成を示す、図３と対応する図である。 第２変形例における音データ処理部の構成を示す、図３と対応する図である。 第３変形例における音データ処理部の構成を示す、図３と対応する図である。

以下、この発明を実施するための形態を図面に基づいて具体的に説明する。
〔実施形態：図１乃至図１４〕
図１に、この発明の音データ処理装置の一実施形態のハードウェア構成を示す。
図１に示す音データ処理装置は、ハードウェアとしては汎用コンピュータであるＰＣ（パーソナルコンピュータ）である。より具体的には、ＰＣ１００は、ＣＰＵ１０１、フラッシュメモリ１０２、ＲＡＭ１０３、通信Ｉ／Ｆ１０４、表示器１０５、操作子１０６、音信号出力部１０７を備え、これらがシステムバス１０８によって接続されている。
これらのうちＣＰＵ１０１は、ＰＣ１００全体の動作を制御する制御部であり、フラッシュメモリ１０２に記憶された所要のプログラムを実行して所要のハードウェアを制御することにより、図２及び図３を用いて説明するものをはじめとする種々の機能を実現する。

フラッシュメモリ１０２は、ＣＰＵ１０１が実行する制御プログラムや電源を切っても保存しておく必要のあるデータ等を記憶する書き換え可能な不揮発性記憶手段である。ＨＤＤ（ハードディスクドライブ）を併用してもよい。
ＲＡＭ１０３は、一時的に記憶すべきデータを記憶したり、ＣＰＵ１０１のワークメモリとして使用したりする記憶手段である。

通信Ｉ／Ｆ１０４は、音データの供給源となるサーバ装置等の外部装置と通信するためのインタフェースである。通信方式は、有線無線を問わず、また、ピアツーピア、ネットワークを問わず、任意のものを採用可能である。
表示器１０５は、ＣＰＵ１０１からの制御に従い種々の画面を表示する、液晶ディスプレイ等による表示部である。
操作子１０６は、ユーザからの操作を受け付けるための操作部であり、ディスプレイに積層されたタッチパネルに加え、キーやスイッチ等により構成することができる。

音信号出力部１０７は、スピーカやヘッドホン等の音出力装置を接続し、その音出力装置へ音信号を出力するためのインタフェースである。ここでは、音信号出力部１０７がＤＡ変換機能を備え、ＰＣ１００が処理するデジタルの音データをアナログの音信号に変換して出力するものとするが、デジタル出力を行う構成とすることも妨げられない。

この実施形態では、以上のＰＣ１００のＣＰＵ１０１に所要のプログラムを実行させて所要のハードウェアを制御させることにより、オーディオストリーミングサーバ等の音データ供給源からオーディオ形式のデジタル音データを受信すると共に、その音データを、スピーカ等の音出力装置へ、音出力に適した形式及びタイミングで出力する音データ処理機能を実現させ、音データ処理装置として機能させる。このことにより、ＰＣ１００は、音出力装置に、音データ供給源から受信した音データに基づく音を、ほぼリアルタイムで出力させることができる。

次に、図２に、ＰＣ１００に実現させる音データ処理機能の概略構成を示す。
図２に示す制御部１２０が、ＣＰＵ１０１により実現される機能と対応する。この制御部１２０は、ネットワークドライバ１２１、オーディオドライバ１２２及び音データ処理部２００の機能を備える。

これらのうちネットワークドライバ１２１は、通信Ｉ／Ｆ１０４を介した音データの送受信を行う機能を備える。この実施形態では、この送受信機能のうち、複数のパケットに分割された一連の音データを順次受信する機能に注目する。ネットワークドライバ１２１は、音データを含むパケットを受信すると、これを音データ処理部２００に渡して、そこに含まれる音データをバッファさせる。１つのパケットには、オーディオ形式のデジタル波形データである音データが所定のサンプル数含まれる。

音データ処理部２００は、ネットワークドライバ１２１から渡されるパケットに含まれる音データをバッファし、オーディオドライバ１２２からの要求に応じて所定のサンプル数ずつオーディオドライバ１２２に出力する出力部の機能を備える。また、音データ処理部２００は、バッファされている音データのサンプル数が少なくなり、オーディオドライバ１２２からの出力要求に応えられなくなる恐れがある場合や、パケットの欠落が判明した場合に、過去に受信した音データに基づき、不足分や欠落分を補う補間処理を行う機能も備える。この補間処理については後に詳述する。

オーディオドライバ１２２は、音信号出力部１０７に連続的に音信号の出力を行わせるために必要な音データを音信号出力部１０７に供給する機能を備える。オーディオドライバ１２２は、必要なタイミングで必要なサンプル数（ここでは一定値とするがこれに限られない）の音データを音データ処理部２００から取得して、各サンプルの音データを、音信号出力部１０７からの出力に適したタイミングで音信号出力部１０７へ供給する。

次に、図３に、図２に示した音データ処理部２００の機能の構成をより詳細に示す。
図３に示すように、音データ処理部２００は、受信部２１１、保存部２１２、出力部２１３、補間部２１４、およびバッファ管理部２１５の機能を備える。また、音データ処理部２００は、音データを格納するための記憶領域として、オーディオバッファ２２１（第１バッファ）、補間バッファ２２２（第２バッファ）、バックアップバッファ２２３（第３バッファ）、および一時バッファ２２４を備えている。これらの各バッファは、例えばＲＡＭ１０３に設けることができる。

上記各部のうち、受信部２１１は、ネットワークドライバ１２１から音データ（ここでは一定のサンプル数とするがこれに限られない）を含むパケットを受信する機能を備える。この受信に係る動作が、受信手順の動作である。パケットには通し番号が付されており、番号順に受信されるべきものであるが、順番が入れ替わったりパケットが欠落（前回到着したパケットと連続しない、より後の番号のパケットが次に到着すること）したりした場合には、この通し番号によりこれを容易に把握することができる。また、受信部２１１は、受信したパケットに含まれる音データをパケットの通し番号と共に保存部２１２に渡す。

なお、各パケットに、当該パケットに含まれる音データがどのタイミングで再生されるべきものかを再生開始からの経過時間等で示すタイムスタンプを付しておくとよい。音データの先頭のタイムスタンプがあれば、当該タイムスタンプとパケットに含まれる音データのサンプル数とから、末尾の再生タイミングを算出できる。このようなタイムスタンプを用いれば、各パケットに含まれる音データのサンプル数が一定でない状態で途中のパケットが欠落しても、後のパケットの到着時点で、そのパケットに含まれる音データを、受信済みパケットに含まれる音データの末尾の何サンプル後で再生すればよいかを計算できる。

保存部２１２は、受信部２１１から受け取った音データを、オーディオバッファ２２１及び補間バッファ２２２へそれぞれ書き込む機能を備える。オーディオバッファ２２１及び補間バッファ２２２はそれぞれリングバッファであり、保存部２１２は、基本的には、最も新しいサンプルの次のサンプルを格納すべきアドレスを示す各バッファの書き込みポインタの位置から始まる領域に、パケット１つ分の音データを書き込み、書き込んだ分だけ各バッファの書き込みポインタの位置を動かす。しかし、オーディオバッファ２２１については、パケットの欠落が発生した場合など、現在の書き込みポインタの位置と異なる位置から書き込みを開始すべき場合もある。

また、保存部２１２は、パケットの欠落やオーディオバッファ２２１に格納されているサンプル数の減少など、オーディオバッファ２２１中の音データの補間のトリガとなる事象を検出した場合に、補間部２１４に対して補間の実行を指示する機能も備える。何がトリガとなるかについては、後に詳述する。さらに、保存部２１２は、パケットの欠落を検出した場合に、バッファ管理部２１５に対しこれを通知する機能も備える。

次に、出力部２１３は、オーディオドライバ１２２からの所定の音データ送信要求を検出したことに応じて、オーディオバッファ２２１から必要なサンプル数（ここでは一定値とするがこれに限られない）の音データを格納順に読み出してオーディオドライバ１２２へ送信する機能を備える。出力部２１３は、未送信の音データの中で最も古いサンプルが格納されたアドレスを示す読み出しポインタの位置から順に新しいサンプルの方へ向かって音データを読み出し、読み出した分だけ読み出しポインタの位置を動かす。

また、出力部２１３は、読み出しポインタの位置を保存部２１２に伝える機能も有し、保存部２１２は、書き込みポインタと読み出しポインタのアドレス差から、オーディオバッファ２２１に格納されているサンプル数をリアルタイムで把握することができる。なお、補間が行われた場合には、保存部２１２は、補間により書き込まれたサンプル数の情報にも基づいて、オーディオバッファ２２１に格納されているサンプル数を把握する。

補間部２１４は、保存部２１２からの指示に基づき補間を実行すると共に、その実行結果として、補間処理によりオーディオバッファ２２１に格納した音データのサンプル数を保存部２１２に通知する機能を備える。ここで、本明細書において、補間とは、何らかの理由（例えばパケットが欠落したり到着が送れたりしたこと）により、オーディオバッファ２２１内に、出力部２１３が出力すべき（未出力の）音データを十分なサンプル数確保できない場合に、音データ処理部２００が最近受け取った音データ、あるいは過去に受け取ってバックアップした音データに基づき、出力音の聴感になるべく影響を与えないように、不足する音データを生成してオーディオバッファ２２１に書き込むことをいう（この際に必要に応じてフェードイン、フェードアウト、クロスフェード等の加工を施すことも含む）。この補間動作の詳細については後述するが、この実施形態では、この補間に際して一時バッファ２２４を利用する。

バッファ管理部２１５は、保存部２１２からパケットの欠落が生じた旨の通知を受けたことに応じて、補間バッファ２２２に格納されている音データをバックアップバッファ２２３にコピーするバックアップと、補間バッファ２２２のクリアとを実行する機能を備える。この動作の意義についても後述する。

次に、図３に示した各部が実行する音データの処理動作について、図４乃至図６を用いて説明する。これらの図に示すサンプル数は一例であり、図に示したものに限られないことはもちろんである。
まず図４に、補間の準備を含む、通常状態での音データの送受信動作を示す。
図４に示すように、音データ処理部２００へは、音データ供給源から供給される複数の受信パケットＰが順次到着する。ここでは、各受信パケットＰは９６（＝Ｂ１）サンプルの音データを含む。

音データ処理部２００においては、受信部２１１がその各受信パケットＰを受け取って保存部２１２へ渡し、保存部２１２がそのパケットに含まれる音データを、オーディオバッファ２２１と補間バッファ２２２へそれぞれ書き込む。このとき、どちらも書き込み時点で既に格納されている最新のサンプルの続きの位置へ書き込む。オーディオバッファ２２１と補間バッファ２２２へは同じ音データを書き込むが、補間バッファ２２２に書き込まれたデータは、補間処理に用いるデータという意味で「補間用データ」と呼ぶことにする。

なお、補間バッファ２２２への書き込みに際しては、バッファの容量が一杯になったら、古いデータを削除する。ただし、リングバッファを用いる場合には、単に、書き込みポインタが記憶領域の末尾まで移動したら先頭に戻すだけで、新しいサンプルをその時点で最も古いサンプルに上書きすることができる。この書き込みポインタの直後の位置が、現在最も古いサンプルの格納位置、すなわち補間用データの先頭位置となる。
この構造は基本的にはオーディオバッファ２２１でも変わらないが、オーディオバッファ２２１では、まだ出力部２１３により読み出されて送信されていないサンプル（「未送信データ」と呼ぶ）が、有効に格納されている音データであると取り扱う。

ここで、出力部２１３は、オーディオドライバ１２２からの要求に応じてオーディオバッファ２２１の読み出しポインタの位置から始まる１２８（＝Ｂ２）サンプルの音データを読み出して送信データＤとして出力し、読み出した分だけ読み出しポインタを後ろにずらす。従って、この読み出しポインタの位置が未送信データの先頭である。このとき、出力部２１３が読み出した音データ自体をオーディオバッファ２２１の記憶領域から削除する必要はないが、音データ処理部２００は、読み出しポインタより前で書き込みポインタ以降の領域を、有効なデータが格納されていない空の領域であるとして取り扱うので、実質的には削除したことになる。

なお、通常状態では、オーディオバッファ２２１に格納される未送信データは２５６サンプル程度になるように各部の動作タイミングが調整される。未送信データの量が多くなりすぎると、音データがオーディオバッファ２２１に長時間滞留することになり、パケットの受信から音の出力までのタイムラグが増加してしまう一方、未送信データの量が少なすぎると、パケットの到着が少し遅れただけでオーディオバッファ２２１の音データが枯渇することになり、（補間はできるとはいえ）音出力に支障を来すことになる。ここでは、これらのバランスを考慮して、未送信データ量の目標値を定めている。また、オーディオバッファ２２１のサイズは、音データの出力遅延等により想定より多い未送信データが滞留する可能性もあることを考慮して、目標値の２倍の５１２サンプル分としている。

一方、補間用データのサイズにはこのような制約はないので、補間バッファ２２２のサイズについては、補間処理のために十分な量の補間用データが確保できることと、メモリ資源の有効活用とを考慮して、適当なサイズとすればよい。補間用データには連続性が求められるため、パケットの脱落が頻発する環境ではあまり大きなサイズの補間用データを作成できないことにも留意するとよい。ここでは、これらを考慮して補間バッファ２２２のサイズは１０２４サンプル分としている。

次に図５に、補間バッファ２２２の補間用データを用いた補間動作の流れを示す。
補間動作が行われるのは、大きく分けて、オーディオバッファ２２１内の未送信データが減ってしまい、出力部２１３が読み出すための未送信データが不足する（又は不足が予想される）場合及び、パケットが欠落したことにより、欠落箇所の手前の音データと欠落箇所の後の音データとの間を埋める必要が生じた場合である。図５に示すのは、前者の場合の例であり、これが起こるのは、例えばパケットの到着が遅延している場合等である（その後パケットの欠落が判明する場合もある）。

いずれにせよ、保存部２１２は、読み出しポインタと書き込みポインタのアドレスから、図５（ａ）に示すようにオーディオバッファ２２１に十分な量の未送信データが格納されていないことを検出すると、補間部２１４に対して補間の実行を指示し、補間部２１４はこの指示に応じて補間処理を実行する。

この補間処理において、一時バッファ２２４にはまだデータが格納されていないとすると、補間部２１４はまず、図５（ａ）に示すように、補間バッファ２２２に格納されている補間用データの中から、オーディオバッファ２２１に残っている未送信データと似た部分をサーチする。未送信データの量が多い場合は、新しい方から所定サンプル数のみを用いてもよい。また、未送信データの量が少なすぎる場合は、読み出しポインタより前の位置の、既に送信済みのデータを未送信データと繋げて、その繋げたデータと似た部分をサーチしてもよい。

また、ここでは、オーディオバッファ２２１における最新の未送信データがパケット由来のものであれば、その部分は補間用データの最新の部分と一致することと、補間処理を行うためには、発見した部分の後ろに十分な量の補間用データが存在する必要があることとを考慮し、サーチは、補間用データの前半部分に対してのみ行う。しかし、範囲は半分に限られず、より狭い範囲や広い範囲に対して行うことも妨げられない。

また、サーチのアルゴリズムは、例えば、補間用データ中で、少しずつずらした位置の、比較対象の未送信データと同じサンプル数の連続した音データをそれぞれ候補として用意し、未送信データ側の各サンプル値と補間用データ側の各サンプル値とで積和を取って正規化した値を、双方のデータの相関を表す類似度として求め、類似度が最も大きい候補を、「似た部分」のサーチ結果とするものが考えられる。一定以上の類似度の候補が見つかった場合に、その時点でサーチを終了してもよい。
類似度Ｌは、例えば、未送信データ側の各サンプル値をＸ＝（ｘ_１，ｘ_２，・・・，ｘ_ｎ）、補間用データ側の各サンプル値をＹ＝（ｙ_１，ｙ_２，・・・，ｙ_ｎ）として、Ｘ，Ｙをそれぞれベクトルとして見た場合に、Ｌ＝（Ｘ・Ｙ）／（｜Ｘ｜｜Ｙ｜）によりベクトル同士がなす角のコサイン値として求めることが考えられる。ただし、Ｘ・ＹはベクトルＸとベクトルＹの内積であり、｜Ｘ｜はベクトルＸの大きさである。しかし、共分散や相関係数など他の方法で類似度を求めることも妨げられない。

いずれにせよ、サーチ結果の「似た部分」を、図５では類似領域２３１として表している。補間処理の基本的な考え方は、この類似領域２３１がオーディオバッファ２２１の未送信データ（の末尾）と似ていることから、類似領域２３１に続く補間用データも、未送信データに続くべき音データと似ていると推定し、類似領域２３１に続く補間用データを、未送信データに続ける音データとしてオーディオバッファ２２１に書き込む、というものである。

そして、類似領域２３１が特定されると、補間部２１４は、図５（ｂ）に示すように、補間バッファ２２２に格納されている補間用データのうち、類似領域２３１以降の部分（類似領域２３１自体も含む）を、まず一時バッファ２２４にコピーする。一時バッファ２２４のサイズは、補間バッファ２２２と同じにするとよい。また、類似領域２３１より後ろの部分が、未送信データに続けるべき箇所の音データであり、類似領域２３１自体は、未送信データと補間用データとの接続を滑らかに行うべく、未送信データとクロスフェードさせるために用いる音データである。

図５（ｂ）の後、補間部２１４は、図５（ｃ）に示すように、一時バッファ２２４の先頭にある類似領域２３１の音データと、オーディオバッファ２２１の未送信データとをクロスフェードさせた音データを生成し、オーディオバッファ２２１の未送信データをその生成した音データに置き換える（上書きする）。そして、その直後（時系列で次以降のサンプルを書き込むべき領域）に、一時バッファ２２４中の、類似領域２３１の直後の所定サンプル数の音データをコピーする。このことにより、オーディオバッファ２２１には、未送信データの末尾と補間用データとが滑らかに繋がった音データが格納されることになる。コピーするサンプル数は、ここでは２５６（＝Ｂ３）サンプルとするが、この値には限られないし、一定であることにも限られない。また、一時バッファ２２４においては、オーディオバッファ２２１の場合と同様、音データを出力（コピー）した場合に、その分だけ読み出しポインタを後ろにずらし、出力した音データは、バッファ内に存在しないものとして取り扱う。

ここまでで、一度の補間処理が完了する。なお、図５（ｃ）のクロスフェードとコピーに当たっては、補間用データの振幅（レベル）を調整することが望ましいが、この点については図１０を用いて後述する。
なお、図５（ｃ）～（ｅ）では、元々の由来を分かりやすくするために、補間処理によりオーディオバッファ２２１に書き込まれた音データに補間用データと同じハッチングを付している。しかし、補間処理によりオーディオバッファ２２１に書き込まれた音データは、以後、元々オーディオバッファ２２１に格納されていた音データと区別せずに、一連の未送信データとして取り扱われる。

また、図５（ｃ）の後もパケットが到着せず、再度オーディオバッファ２２１に十分な量の未送信データが格納されなくなった状態を、図５（ｄ）に示した。保存部２１２は、このことを検出すると、再度補間部２１４へ補間の実行を指示する。
補間部２１４は、この指示に応じて補間処理を実行する。そしてこのときには、図５（ｅ）に示すように、一時バッファ２２４内に、まだオーディオバッファ２２１にコピーしていない未使用の補間用データが、十分な量（コピー１回分の２５６サンプル以上）残っている。

従って、補間部２１４は、図５（ａ）のような類似領域２３１のサーチを行うことなく、図５（ｅ）に示すように、一時バッファ２２４に格納されている未使用の補間用データの、先頭から所定サンプルを、オーディオバッファ２２１の、未送信データの直後にコピーする。このときには、未送信データの末尾は、今回コピーしようとする補間用データと元々繋がっていたデータであるので、クロスフェードを行わずに繋げても滑らかにつながり、出力音に違和感が生じる可能性は低いと考えられる。

以上のように、類似領域２３１をサーチした際に、サーチ結果に基づき補間用データをなるべく多く一時バッファ２２４に記憶させておけば、一時バッファ２２４に十分な量の補間用データが格納されている間は、補間処理においてサーチを省略しても、十分な品質の補間を行うことができる。補間処理においては類似領域２３１のサーチが負荷の大きい処理であるので、これを省略できれば、負荷軽減の効果は大きい。
この実施形態では、補間バッファ２２２のサイズはオーディオバッファ２２１の２倍であるが、上述のように補間バッファ２２２のサイズ上限の制約は小さいため、さらに大きいサイズの補間バッファ２２２を用いてもよい。大きなサイズの補間バッファ２２２を用いる場合には、一時バッファ２２４にコピーできる補間用データのサイズもその分大きくなることが期待でき、負荷軽減の効果は一層大きくなる。

次に図６に、補間バッファ２２２のバックアップ及びクリア動作の流れを示す。
ここで、補間バッファ２２２に格納される補間用データは、補間後の音データにノイズが混じらないよう、連続性（途中に欠落がないこと）が保証された音データであることが求められる。音データ処理部２００に到着するパケットに欠落がない限りは、各パケットの音データを到着順に補間バッファ２２２に書き込んでいくことでこの連続性は保証される。

図６（ａ）は、この連続性が保証された状態の補間用データを示し、その末尾は、第ｎパケット由来の音データである。
この状態で、保存部２１２が次に第（ｎ＋２）パケットを受け取った場合を考える。このことは、第（ｎ＋１）パケットが（後で到着する可能性はあるが）欠落したことを意味するものである。そして、この第（ｎ＋２）パケットを補間用バッファ２２２に続けて書き込んでしまうと、補間用データの連続性が保証されなくなってしまう。そこで、保存部２１２は、パケットの欠落を検出すると、バッファ管理部２１５にこれを通知する。

そして、この通知を受けたバッファ管理部２１５は、まず図６（ｂ）に示すように、連続性が保証された状態の補間用データを、補間バッファ２２２からバックアップバッファ２２３にコピーする。バックアップバッファ２２３の補間用データもなるべく新しいものの方がよいので、このコピーは上書きコピーでよい。バックアップバッファ２２３は補間バッファ２２２と同サイズである。また、バッファ管理部２１５はその後、補間バッファ２２２をクリアする。

これらの処理が完了すると、バッファ管理部２１５はその旨を保存部２１２に通知し、保存部２１２は、この通知を受けた後で、第（ｎ＋２）パケットの音データを補間バッファ２２２に書き込む。補間バッファ２２２はクリアされているから、このとき書き込んだ音データが、この時点での補間用データの先頭となる。

以上のように、パケットの欠落が生じた時点で補間バッファ２２２を一旦クリアしてしまえば、簡単な処理で、補間用データの連続性を保証しつつ、補間用データとして、直近の音データを用いることができる。しかし、図６（ｃ）に示すような、補間バッファ２２２のクリア直後の状態で補間処理を行う必要が生じると、十分な長さの補間用データがなく、適切な補間処理を行うことができない可能性がある。

バックアップバッファ２２３は、このような事態を防止するために設けたものである。すなわち、補間部２１４は、補間処理に際して、図５（ａ）のサーチで補間バッファ２２２内に未送信データと似たデータを発見できない場合には、図６（ｄ）に示すように、同様なサーチをバックアップバッファ２２３に格納された補間用データに対して行う。バックアップバッファ２２３のデータは、補間バッファ２２２のデータに比べれば少々古いものの、少し前に実際に受信した音データであり、バックアップバッファ２２３のデータを用いても、十分に信頼性の高い補間処理を行うことができる。
すなわち、バックアップバッファ２２３を設けることにより、補間用データの連続性保証と、常に補間処理が可能な状態とを、低い処理負荷で両立させることができる。
非特許文献１に記載のような、パケットの欠落部の音データを修復する技術においては、修復した部分の音に違和感を発生させないために、修復時に書き込む音データは、パケットの欠落がない、連続したものであることが求められる。しかし、パケットの欠落が頻繁に発生する環境においては、連続性が保証された直近の音データを修復用に確保することは、必ずしも容易ではない。
また、非特許文献１に記載の技術は、パケットが欠落した箇所を修復するものであるが、パケットが欠落していない場合でも、到着遅れが発生すると、再生に必要な音データのサンプルを確保できない事態が生じ得る。このような場合でも音データの再生を続けるためには、何らか対処が必要であるが、非特許文献１はこのような事態に対処するための技術を示していない。
すなわち、不足する音データを、修復と同様な手法により取得するとしても、どのようなタイミングでどれだけの音データを取得すればよいか不明であり、非特許文献１に記載の技術を適用しても効率のよい処理はできない。
これに対し、この実施形態では、音データを受信して出力する場合に、出力すべき音データを適切なタイミングで受信できなくてもユーザにあまり違和感を与えることなく代替の音データを出力する動作を、低い処理負荷で確実性よく行えるようにすることができる。

なお、補間バッファ２２２に十分な量の補間用データがある場合であっても、未送信データとの類似度が十分高い領域を発見できなかった場合には、バックアップバッファ２２３をサーチするようにしてもよい。また、バックアップバッファ２２３を複数（ｎ個）設けて、直前ｎ回の補間バッファ２２２のクリア時の補間用データをそれぞれ保持しておき、新しい方から順に補間処理時のサーチをトライするようにすることも考えられる。

次に、図７乃至図１２を用いて、以上の音データ処理装置１００においてＣＰＵ１０１が実行する、音データの入出力及び補間に関連する処理について説明する。なお、これらのフローチャートに示す処理は、音データ処理部２００の機能と対応するものであり、ＣＰＵ１０１が所要のプログラムを実行することにより行うものであるが、その一部又は全部を処理回路により実現することも妨げられない。

まず図７に、メイン処理のフローチャートを示す。
ＣＰＵ１０１は、音データ処理部２００の機能の起動時に、図７のフローチャートに示すメイン処理を開始し、以後、音データ処理部２００の機能が有効である間はこの処理の実行を続ける。
図７の処理において、ＣＰＵ１０１はまず初期処理を実行する（Ｓ１１）。この処理は、ネットワークドライバ１２１と音データ処理部２００とを接続して音データの取得に係る通信機能を有効にする処理、オーディオドライバ１２２と音データ処理部２００とを接続して音データの出力機能を有効にする処理、各バッファのサイズ設定処理等を含む。

以後、ＣＰＵ１０１は、音データを含むパケットが到着したことに応じて図１１，図１２に示すパケット到着時の処理を実行し（Ｓ１２，Ｓ１３）、オーディオドライバ１２２から音データの要求があったことに応じて図８，図９に示す音データ要求時の処理を実行する（Ｓ１４，Ｓ１５）。

次に、図８及び図９に、図７のステップＳ１５で実行する音データ要求時の処理のフローチャートを示す。
この処理において、ＣＰＵ１０１はまず、オーディオドライバ１２２へ送信するＢ２サンプルの未送信データがオーディオバッファ２２１に格納されているか否か判断する（Ｓ２１）。通常状態ではこの判断はＹｅｓになるが、この場合には、ＣＰＵ１０１は、オーディオバッファ２２１の先頭からＢ２サンプルの未送信データを読み出してオーディオドライバ１２２に渡し（Ｓ２２）、読み出したデータをオーディオバッファ２２１から削除して（Ｓ２３）、元の処理に戻る。また、ステップＳ２３の削除は、上述したように、読み出しポインタの移動により実質的に行うことができる。これらの処理は、図４の出力側の動作と対応するものである。

一方、ステップＳ２１でＮｏの場合には、補間が必要であることがわかる。そこで、ＣＰＵ１０１は、Ｂ３サンプルの未使用データが一時バッファ２２４に格納されているか否か判断する（Ｓ２４）。ここでＹｅｓであれば、図５（ａ）に示したサーチを行う必要はないので、ＣＰＵ１０１は、一時バッファ２２４の先頭からＢ３サンプルを、オーディオバッファ２２１の最新のデータの直後にコピーし（Ｓ２５）、コピーしたデータを一時バッファ２２４から削除する（Ｓ２６）。以上で補間処理が完了し、オーディオドライバ１２２に対して音データを送信できる状態になるので、ＣＰＵ１０１はステップＳ２２以降の処理を実行する。

また、ステップＳ２４でＮｏであれば、ＣＰＵ１０１は、図５（ａ）に示したサーチを行う。すなわち、補間バッファ２２２に格納されている、古い方から所定範囲のサンプルの中で、オーディオバッファ２２１中の未送信データと似た部分をサーチする（Ｓ２７）。ここで適当な部分がみつからなければ（Ｓ２８のＮｏ）、バックアップバッファ２２３に格納されているデータに対しても同様なサーチを行う（Ｓ２９）。

これらのいずれでも適当な部分がみつからない場合（Ｓ３０のＮｏ）、補間を行うことはできないため、ＣＰＵ１０１は、エラー処理として、オーディオバッファ２２１中の未送信データをフェードアウトさせるように加工して（Ｓ３１）、ステップＳ２２に進む。ステップＳ３１の処理は、未送信データの末尾で音が急に途切れてノイズが発生することを防止するためのものであり、このケースでは、フェードアウト後次のパケットが到着するまでは、ステップＳ２２で無音の音データをオーディオドライバ１２２に渡すことになる。

また、ステップＳ２７又はＳ２９のサーチで適切な部分（類似領域２３１）がみつかった場合（Ｓ２８又はＳ３０のＹｅｓ）、処理は図９のステップＳ３２に進む。なお、適切な部分とは、未送信データとの類似度（相関）が十分に高く、かつ後続に適切な長さの（少なくともＢ３サンプルの）補間用データが存在する部分である。
図９の処理において、ＣＰＵ１０１はまず、ステップＳ２７又はＳ２９で発見した類似領域２３１以降の補間用データを、一時バッファ２２４にコピーする（Ｓ３２）。この処理は、図５（ｂ）と対応し、コピー元は補間バッファ２２２の場合とバックアップバッファ２２３の場合とがある。

次に、ＣＰＵ１０１は、図１０に示す振幅調整処理を実行する（Ｓ３３）。この処理については後述する。
その後、ＣＰＵ１０１は、一時バッファ２２４の先頭にある類似領域２３１のデータを、オーディオバッファ２２１の未送信データとクロスフェードさせ（Ｓ３４）、一時バッファ２２４の類似領域２３１の後ろのＢ３サンプル分の音データを、オーディオバッファ２２１のクロスフェード済みデータの続きの領域にコピーする（Ｓ３５）。さらに、ここでクロスフェード又はコピーしたサンプルのデータを、一時バッファ２２４から削除する（Ｓ３６）。この削除も、上述したように、読み出しポインタの移動により実質的に行うことができる。以上のステップＳ３４乃至Ｓ３６の処理は、図５（ｃ）と対応する。

以上でステップＳ２４がＮｏの場合の補間処理が完了し、オーディオドライバ１２２に対して音データを送信できる状態になるので、ＣＰＵ１０１は次にステップＳ２２以降の処理を実行する。
以上の処理により、オーディオバッファ２２１中の未送信データをオーディオドライバ１２２へ出力する出力手順の処理と、オーディオバッファ２２１中の未送信データが不足する場合の補間処理に係る補間手順の処理とを実行することができる。

なお、オーディオバッファ２２１中の未送信データの不足は、音データの要求をトリガに判定あるいは検出する必要はない。その他のタイミングでも随時監視し、不足を検出した場合に、ステップＳ２５及びＳ２６あるいはステップＳ２７乃至Ｓ３６の補間処理を実行してもよい。補間処理に割けるリソースが少ない場合には、オーディオドライバ１２２からの音データの要求がある前に補間処理を開始し、処理時間を十分確保することも有効である。

次に、図１０に、図９のステップＳ３３で実行する振幅調整処理のフローチャートを示す。
図１０の処理において、ＣＰＵ１０１はまず、オーディオバッファ２２１中の未送信データの最大振幅と、ステップＳ３２でコピーされた一時バッファ２２４中の類似領域２３１の音データの最大振幅とを求める（Ｓ５１，Ｓ５２）。対象範囲内に、振幅として信頼性のある値を求められる程度のサンプル数がない場合には、サンプル値の絶対値の最大値を、最大振幅として採用してもよい。

次に、ＣＰＵ１０１は、ステップＳ５２で求めた類似領域２３１の音データの最大振幅の方が大きい場合に（Ｓ５３のＹｅｓ）、ステップＳ５１，Ｓ５２で求めた２つの最大振幅の比だけ、一時バッファ２２４に格納された補間用データ全体の振幅を下げる（Ｓ５４）。すなわち、補間用データの振幅を、未送信データの振幅に合わせて調整する。未送信データの最大振幅の方が大きい場合には（Ｓ５３のＮｏ）、振幅の調整は行わない。
以上の後、元の処理に戻る。

以上のような振幅調整を行うと、未送信データに係る音と、補間用データに係る音とが、より滑らかに繋がって聞こえるようにすることができる。すなわち、補間箇所で出力音が聞き手に与える違和感を低減することができる。
この効果は，ステップＳ５３の判断がなくても、すなわち、未送信データと類似領域２３１の音データのどちらの最大振幅が大きいかに関わらず振幅調整を行っても、ある程度は得ることができる。しかし、例えば音楽でよくある減衰音は、途中で音量が大きくなる箇所があると人の耳に目立って聞こえる一方、途中からより小さな音量に減衰してしまっても、それほど不自然に聞こえない。このため、類似領域２３１の音データの方が最大振幅が大きい場合のみ、補間用データの振幅を下げる調整を行う方が、より聞き手に違和感を感じさせないような結果が得られる。

次に、図１１及び図１２に、図７のステップＳ１３で実行するパケット到着時の処理のフローチャートを示す。この処理について、図１３及び図１４も参照しつつ説明する。
この処理において、ＣＰＵ１０１はまず、前回のパケットと連続するパケットが到着したか、または初回のパケットが到着したかのどちらかであるか否かを判断する。これらのどちらかであれば（Ｓ６１のＹｅｓ）、補間処理は不要と判断する。これは、図１３（ａ）に示すように、オーディオバッファ２２１に対し、第ｎパケットのデータの直後に第（ｎ＋１）パケットのデータを書き込める場合である。初回のパケットである場合には、補間処理を行うことなくオーディオバッファ２２１の先頭に音データを書き込める。

通常状態ではステップＳ６１はＹｅｓになるはずである。この場合、ＣＰＵ１０１は、到着したパケットに含まれる音データを、オーディオバッファ２２１の最新の音データの直後に書き込む（Ｓ６２）。また、補間バッファ２２２の音データを古い方から１パケット分削除し（Ｓ６３）、到着したパケットに含まれる音データを、補間バッファ２２２の最新の音データの直後に書き込んで（Ｓ６４）、元の処理に戻る。
ステップＳ６２で書き込むデータとステップＳ６４で書き込むデータとは同じものである。また、ステップＳ６４の書き込みにより、同時にステップＳ６３を実行できるようにする構成を取り得ることは、図４の説明で述べた通りである。以上のステップＳ６２乃至Ｓ６４の処理は、図４の書き込み側の動作と対応するものである。

一方、パケットの欠落が発生する等してステップＳ６１でＮｏの場合、ＣＰＵ１０１は補間処理の必要性について検討する。まず、ＣＰＵ１０１は、パケットの欠落が発生しており、かつ、オーディオバッファ２２１の未送信データの後端（最新のサンプル）が、以前に到着したパケットの音データである、という条件が満たされるか否か判断する（Ｓ６５）。

ここでＹｅｓとなるのは、図１３（ｂ）に示すように、第ｎパケットの次に第（ｎ＋ｋ）パケット（ｋは２以上の自然数）が到着したが、第ｎパケットの音データをオーディオバッファ２２１に書き込んだ後、補間処理が行われていない場合である。この場合、補間処理を行って、第ｎパケットの音データと第（ｎ＋ｋ）パケットの音データとの間を、補間用データで埋める必要がある。

そこで、この場合、ＣＰＵ１０１はまず、オーディオバッファ２２１中で、到着したパケットの音データを本来格納すべき位置を算出する（Ｓ６６）。この位置は、１パケット当たりのサンプル数が一定であれば、現在の書き込みポインタの位置から、１パケット当たりのサンプル数のｋだけ後ろにずらした位置となる。また、上述したように、各パケットにタイムスタンプを付す場合、そのタイムスタンプが示す時刻に基づき、現在の書き込みポインタの位置から何サンプル分だけ後ろにずらした位置とすればよいかを算出できる。

次に、ＣＰＵ１０１は、図８のステップＳ２７乃至Ｓ３０と同様に、補間バッファ２２２あるいはバックアップバッファ２２３に格納された補間用データの中から、オーディオバッファ２２１の最新のＢ４サンプルの音データと似た類似領域をサーチする（Ｓ６７）。Ｂ４は、次のステップＳ６８でクロスフェードさせる範囲のサンプル数であり、サーチの精度も考慮して適宜定めればよい。

次に、ＣＰＵ１０１は、ステップＳ６７で発見した類似領域以降の補間バッファ２２２又はバックアップバッファ２２３の音データ（補間用データ）を、オーディオバッファ２２１に格納された未送信データの最新のＢ４サンプルとクロスフェードさせつつ、パケットの欠落による抜けた音データを埋められるだけオーディオバッファ２２１に書き込む（Ｓ６８）。この補間処理は一回限りなので一時バッファ２２４は利用しない。なお、類似部分がみつからなければステップＳ６８の処理は実行できないが、類似部分以降の音データのサンプル数が足りない場合には、データがある範囲でステップＳ６８の書き込みを行う。

そして、ＣＰＵ１０１は、ステップＳ６８で十分なサンプル数を書き込めたか否か判断する（Ｓ６９）。ここでＹｅｓであれば、補間処理を適切に実行できたと判断し、ＣＰＵ１０１は、到着したパケットの音データを、ステップＳ６８で書き込んだ音データの末尾とクロスフェードさせつつ、オーディオバッファ２２１のうち当該パケットの音データを本来格納すべき位置に書き込む（Ｓ７０）。本来格納すべき位置とは、パケットロスがなかったとした場合に格納すべき位置である。以上でオーディオバッファ２２１への書き込みは完了である。

その後、ＣＰＵ１０１は、パケットの欠落により補間バッファ２２２中の補間用データの連続性が保証できなくなったため、補間バッファ２２２の音データをバックアップバッファ２２３にコピーすると共に、補間バッファ２２２をクリアする（Ｓ７１）。この処理は、図６と対応するものである。ステップＳ６７及びＳ６８での補間処理は、まだ連続性が保証できている状態の補間用データを用いて行ったことになる。

また、ＣＰＵ１０１は、一時バッファ２２４もクリアする（Ｓ７２）。これは、ステップＳ７０の処理により、未送信データの末尾が、前回の補間処理による補間用データではなくなり、一時バッファ２２４のデータを次回の補間処理に利用できなくなったためである。その後、処理はステップＳ６３に進み、補間バッファ２２２への書き込みを行って元の処理に戻る。

一方、ステップＳ６９でＮｏの場合、図１２のステップＳ７５に進んで更なる補間処理を試みる。
また、ステップＳ６５でＮｏの場合、処理は図１２のステップＳ７３に進む。ここでは、ＣＰＵ１０１は、パケットの欠落が発生しており、かつ、オーディオバッファ２２１の未送信データの後端が、以前の補間処理で書き込まれた補間用データである、という条件が満たされるか否か判断する（Ｓ７３）。補間処理においてどのアドレス範囲に補間用データを書き込んだかを記録しておけば、それを参照してステップＳ７３の判断を行うことができる。

ここでＹｅｓとなるのは、前回受信したパケットの音データをオーディオバッファ２２１に書き込んだ後で補間処理を行った場合である。この場合には、補間処理を行って、音データの隙間を補間用データで埋めたり、逆に余分な補間用データを取り除いたりする必要がある。
いずれにせよ、ＣＰＵ１０１は、ステップＳ７３でＹｅｓの場合、まず到着したパケットの音データを本来格納すべき位置を算出する（Ｓ７４）。この処理は、ステップＳ６６と同じものである。

その後、ＣＰＵ１０１は、補間用データが格納されている範囲と今回到着した第（ｎ＋ｋ）パケットを書き込むべき位置との位置関係に応じた処理を行う（Ｓ７５の分岐）。この位置関係には図１４（ａ）～図１４（ｄ）に示す４通りが想定される。
すなわち、図１４（ａ）に示すように、ドットハッチングで示した補間用データとパケットの音データの格納位置との間に隙間があるケース、図１４（ｂ）に示すように、補間用データと上記格納位置とがちょうど隣り合うケース、図１４（ｃ）に示すように、補間用データと上記格納位置とが一部重なるケース、図１４（ｄ）に示すように、上記格納位置が補間用データ内に包含されるケースである。図１１のステップＳ６９からステップＳ７５に進んだ場合には、このうち図１４（ａ）のケースになると考えられる。

各ケースにおいて実行される処理について説明すると、補間用データと格納位置との間に隙間があるケースでは、ＣＰＵ１０１は、図１１のステップＳ６７乃至Ｓ７０と同じ処理を実行する（Ｓ７６）。この場合、オーディオバッファ２２１の最新のＢ４サンプルの音データはパケット由来の音データではなく補間用データであるが、処理としてはステップＳ６７乃至Ｓ７０と同じでよい。この処理により、今回到着したパケットの音データをオーディオバッファ２２１に書き込むと共に、既に格納されている補間用データとの間に生じる隙間を、更なる補間用データにより埋めることができる。

また、補間用データと格納位置とがちょうど隣り合うケースでは、ＣＰＵ１０１は、補間用データの後端をフェードアウトさせ、その直後から、今回到着したパケットの音データがフェードインするように、オーディオバッファ２２１を書き換える（Ｓ７７）。この場合、補間用データとパケットの音データとが重複する箇所がないため、クロスフェードができないので、フェードインフェードアウトを用いたものである。
また、補間用データと格納位置とが一部重なるケースでは、ＣＰＵ１０１は、今回到着したパケットの音データを、既にオーディオバッファ２２１に格納されている補間用データとクロスフェードさせつつ、ステップＳ７４で求めた本来の格納位置へ書き込む（Ｓ７８）。

また、格納位置が補間用データ内に包含されるケースでは、ＣＰＵ１０１は、今回到着したパケットの音データを、既にオーディオバッファ２２１に格納されている補間用データとクロスフェードさせつつ、ステップＳ７４で求めた本来の格納位置へ書き込み、今回到着したパケットの音データより後ろにある補間用データを削除する（Ｓ７９）。既に格納されている補間用データは、以前のパケットの音データに基づき補間したものと想定されるため、今回到着したパケットの音データの後ろに繋げるデータとしては不適当と考えられるためである。

ＣＰＵ１０１は、以上のステップＳ７６乃至Ｓ７９のいずれかの処理の後、図１１のステップＳ７２の場合と同様、図１１のステップＳ７１へ進む。すなわち、補間バッファ２２２のバックアップバッファ２２３へのコピーと、補間バッファ２２２及び一時バッファ２２４のクリアとを行う（Ｓ７１，Ｓ７２）。
また、ステップＳ７３でＮｏの場合には、過去のパケットが後から届いた等の場合が考えられるが、この場合にはエラー処理を行って（Ｓ８０）、オーディオバッファ２２１や補間バッファ２２２への書き込みは行わずに図１１及び図１２の処理を終了する。

以上の処理により、受信した音データを受信順にオーディオバッファ２２１及び補間バッファ２２２に書き込む音データ保存手順の処理と、パケットの欠落を検出した場合に補間バッファ２２２のバックアップとクリアを行うバッファ管理手順の処理と、パケットの欠落箇所を埋めるための補間処理とを実行することができる。

〔変形例：図１５乃至図１７〕
以上で実施形態の説明を終了するが、装置の具体的な構成、具体的な処理の手順、取り扱う音データの形式やサンプル数、通信の方式などが、上述の実施形態で説明したものに限られないことはもちろんである。
また、この発明の実施形態は、図３に示した各部を全て備えているものに限られることもない。

例えば、図１５には、一時バッファ２２４を備えない例を示している。この例では、図５の補間動作において、図５（ｂ）の時点で、補間バッファ２２２からオーディオバッファ２２１へ、直接補間用データのコピーを行う。この構成では、補間処理を行う度に類似領域２３１のサーチを行うことになるが、十分な処理能力のあるハードウェアを用いれば、大きな遅れなくこの処理を実行可能である。

また、図１６には、バックアップバッファ２２３を備えない例を示している。この例では、パケットの欠落を検出した場合、補間バッファ２２２の内容を特段バックアップせずにクリアする。このようにすると、クリア後少しの間は補間処理に支障を来すが、パケットの欠落が希な環境であれば、補間処理に支障を来す時間は少なく、このことが音出力に与える影響は小さい。

また、図１７には、バックアップバッファ２２３と一時バッファ２２４のいずれも備えない例を示している。この例では、図１５の例で説明した変形と図１６の例で説明した変形の双方を適用することになる。
また、これらの他、図１０に示した振幅調整処理も、必須ではなく、この処理を省略することも可能である。

また、上述した実施形態では、オーディオバッファ２２１が１つである例について説明した。しかし、音データ処理装置が受信するパケットに複数チャンネル分の音データが含まれ、それらをチャンネル毎に用意されたオーディオバッファ２２１に格納して出力する装置においても、この発明は適用可能である。この場合、補間バッファ２２２、バックアップバッファ２２３及び一時バッファ２２４も、チャンネル毎に設け、チャンネル毎に補間動作を行えばよい。また、チャンネル毎に、図８及び図９の処理におけるＢ２、Ｂ３及び、図１１の処理におけるＢ４の値が異なっていてもよい。

また、上述した実施形態では、この発明を汎用コンピュータにより実現する例について説明したが、専用ハードウェアを用いて実現してもよいことはもちろんである。また、ストリーミング配信される音や音声付き動画を再生する場合だけでなく、電話回線やインターネット回線を通じて音声通信（通話）や画像付きの音声通信を行う場合における音データの受信及び出力にも、この発明を適用可能である。

また、出力される音データあるいは音信号の用途は、スピーカ等の発音装置による音出力に限られず、記録や、さらに他の装置への転送に用いる場合でも、本発明を適用可能である。
また、上述した実施形態の音データ処理装置の機能は、任意に複数の装置に分散して設けることもできる。
また、以上述べてきた構成及び変形例は、矛盾しない範囲で適宜組み合わせて適用することも可能である。

以上の説明から明らかなように、この発明を利用すれば、音データを受信して出力する場合に、出力すべき音データを適切なタイミングで受信できなくてもユーザにあまり違和感を与えることなく代替の音データを出力する動作を、確実性よく行うことができる。従って、処理能力の低いハードウェアを用いても、品質の良い音データを出力することが可能になる。

１００：ＰＣ（音データ処理装置）、１０１：ＣＰＵ、１０２：フラッシュメモリ、１０３：ＲＡＭ、１０４：通信Ｉ／Ｆ、１０５：表示器、１０６：操作子、１０７：音信号出力部、１０８：システムバス、１２０：制御部、１２１：ネットワークドライバ、１２２：オーディオドライバ、２００：音データ処理部、２１１：受信部、２１２：保存部、２１３：出力部、２１４：補間部、２１５：バッファ管理部、２２１：オーディオバッファ、２２２：補間バッファ、２２３：バックアップバッファ、２２４：一時バッファ、２３１：類似領域

Claims (17)

1. コンピュータに、
   音データを受信して該受信した音データを第１バッファに格納する受信手順と、
   前記受信手順で受信した音データを第２バッファに格納する手順と、
   所定の要求を検出した場合に前記第１バッファに格納されている音データを出力する出力手順と、
   前記受信手順において音データの受信の欠落が発生したことを検出した場合に、前記第２バッファに格納されている音データのうち、前記出力手順による出力がまだされていない未出力の音データと似た部分に続く音データを選択して、その選択した箇所の音データを前記未出力の音データの直後に書き込む第１書込手順と
   を実行させるためのプログラムであって、
   前記第１書込手順において、前記未出力の音データと似た部分を、前記第１バッファに格納されているデータのうち新しい方の、前記未出力の音データの量に応じた範囲のデータである比較用データに基づき、前記第２バッファをサーチして特定することを特徴とするプログラム。
2. 請求項１に記載のプログラムであって、
   前記第１書込手順において、前記未出力の音データの量が所定の閾値よりも多い場合、前記第２バッファに格納されている音データのうち、前記未出力の音データの新しい方から所定サンプル数分を前記比較用データとすることを特徴とするプログラム。
3. 請求項１又は２に記載のプログラムであって、
   前記第１書込手順において、前記未出力の音データの量が所定の閾値よりも少ない場合、前記第２バッファに格納されている音データのうち、前記第１バッファに格納されている既に送信済みの音データと前記未出力の音データとを繋げた音データを前記比較用データとすることを特徴とするプログラム。
4. 請求項１乃至３のいずれか一項に記載のプログラムであって、
   前記所定の記憶領域は、音データを格納するための第２バッファを備え、
   前記コンピュータに、
   前記受信手順で受信した音データを前記第２バッファに格納する手順と、
   前記第１バッファに格納されている未出力の音データの量が所定の閾値以下になったことを検出した場合に、前記第２バッファに格納されている音データから前記未出力の音データに続けるべき箇所を選択して、その選択した箇所の音データを前記第１バッファの最新の音データの直後に書き込む第２書込手順と
   をさらに実行させるためのプログラム。
5. 請求項４に記載のプログラムであって、
   前記所定の記憶領域は、音データを格納するための第３バッファを備え、
   前記コンピュータに、
   前記受信手順において音データの受信の欠落が発生したことを検出した場合に、前記第２バッファに格納されている音データを前記第３バッファにコピーするコピー手順
   をさらに実行させるためのプログラム。
6. 請求項５に記載のプログラムであって、
   前記コピー手順は、前記第２バッファに格納されている前記音データを前記第３バッファにコピーすると共に、前記第２バッファをクリアする手順であることを特徴とするプログラム。
7. 請求項５又は６に記載のプログラムであって、
   前記第２書込手順は、前記第２バッファに格納されている音データから前記未出力の音データに続けるべき箇所を選択できない場合に、前記第３バッファに格納されている音データから前記未出力の音データに続けるべき箇所を選択して、その選択した箇所の音データを前記第１バッファの最新の音データの直後に書き込む手順であることを特徴とするプログラム。
8. 請求項４乃至７のいずれか一項に記載のプログラムであって、
   前記記憶領域は、音データを格納するための一時バッファを備え、
   前記第２書込手順は、前記第１バッファに格納されている未出力の音データの量が所定の閾値以下になったことを検出した場合に、前記一時バッファに所定量以上の未使用の音データが記憶されていなければ、前記未出力の音データに続けるべき箇所の音データを前記一時バッファに書き込んだ後、前記一時バッファに格納されている音データを前記所定量だけ前記第１バッファの最新の音データの直後に書き込む手順であることを特徴とするプログラム。
9. 請求項４乃至７のいずれか一項に記載のプログラムであって、
   前記記憶領域は、音データを格納するための一時バッファを備え、
   前記第２書込手順は、前記第１バッファに格納されている未出力の音データの量が所定の閾値以下になったことを検出した場合に、前記一時バッファに所定量以上の未使用の音データが記憶されていなければ、前記未出力の音データに続けるべき箇所の音データを前記第１バッファの最新の音データの直後に書き込むことに代えて、前記未出力の音データに続けるべき箇所の音データを前記一時バッファに書き込んだ後、前記一時バッファに格納されている音データを前記所定量だけ前記第１バッファの最新の音データの直後に書き込む手順であることを特徴とするプログラム。
10. 請求項８又は９に記載のプログラムであって、
    前記第２書込手順は、前記第１バッファに格納されている未出力の音データの量が前記所定の閾値以下になったことを検出した場合に、前記一時バッファに前記所定量以上の未使用の音データが記憶されていれば、前記一時バッファに格納されている前回の書き込みの続きの音データを、前記所定量だけ前記第１バッファの最新の音データの直後に書き込む手順であることを特徴とするプログラム。
11. 請求項８又は９に記載のプログラムであって、
    前記第２書込手順は、前記第１バッファに格納されている未出力の音データの量が前記所定の閾値以下になったことを検出した場合に、前記一時バッファに前記所定量以上の未使用の音データが記憶されていれば、前記第２バッファに格納されている音データから前記未出力の音データに続けるべき箇所を選択することに代えて、前記一時バッファに格納されている前回の書き込みの続きの音データを、前記未出力の音データに続けるべき箇所として前記所定量だけ前記第１バッファの最新の音データの直後に書き込む手順であることを特徴とするプログラム。
12. 請求項４乃至１１のいずれか一項に記載のプログラムであって、
    前記第２書込手順は、前記第１バッファに音データを書き込む場合に、該書き込もうとする音データの振幅を、前記未出力の音データの振幅に合わせる振幅調整を行う手順であることを特徴とするプログラム。
13. 請求項１乃至１２のいずれか一項に記載のプログラムであって、
    前記受信手順は、音データの受信の欠落が発生し、その後欠落箇所の後の音データを受信した場合に、その受信した音データを、前記第１バッファの、前記欠落がなかったとした場合にその音データを書き込むべき位置へ書き込む手順であることを特徴とするプログラム。
14. 請求項１３に記載のプログラムであって、
    前記記憶領域は、音データを格納するための第２バッファを備え、
    前記コンピュータに、
    前記受信手順で受信した音データを前記第２バッファに格納する手順と、
    前記欠落箇所の後の音データが書き込まれる位置が、前記未出力の音データの末尾よりも後ろである場合に、前記第２バッファに格納されている音データから前記未出力の音データに続けるべき箇所を選択して、その箇所の音データを前記第１バッファの最新の音データの直後に書き込む手順とをさらに実行させるためのプログラム。
15. 請求項１４に記載のプログラムであって、
    前記受信手順は、前記欠落箇所の後の音データを前記第１バッファに書き込む場合、前記第１バッファの該書き込んだ音データよりも後ろに、前記第２バッファから選択されて前記第１バッファに書き込まれた音データがあれば、その音データを削除する手順を含むことを特徴とするプログラム。
16. 音データを受信して該受信した音データを第１バッファに格納する受信部と、
    前記受信部が受信した音データを第２バッファに格納する格納部と、
    所定の要求を検出した場合に前記第１バッファに格納されている音データを出力する出力部と、
    前記受信部が音データの受信の欠落が発生したことを検出した場合に、前記第２バッファに格納されている音データのうち、前記出力部による出力がまだされていない未出力の音データと似た部分に続く音データを選択して、その選択した箇所の音データを前記未出力の音データの直後に書き込む書込部とを備え、
    前記書込部は、前記未出力の音データと似た部分を、前記第１バッファに格納されているデータのうち新しい方の、前記未出力の音データの量に応じた範囲のデータである比較用データに基づき、前記第２バッファをサーチして特定することを特徴とする音データ処理装置。
17. 音データ処理装置が、
    音データを受信して該受信した音データを第１バッファに格納する受信手順と、
    前記受信手順で受信した音データを第２バッファに格納する手順と、
    所定の要求を検出した場合に前記第１バッファに格納されている音データを出力する出力手順と、
    前記受信手順で音データの受信の欠落が発生したことを検出した場合に、前記第２バッファに格納されている音データのうち、前記出力手順による出力がまだされていない未出力の音データと似た部分に続く音データを選択して、その選択した箇所の音データを前記未出力の音データの直後に書き込む書込手順とを実行し、
    前記書込手順において、前記未出力の音データと似た部分を、前記第１バッファに格納されているデータのうち新しい方の、前記未出力の音データの量に応じた範囲のデータである比較用データに基づき、前記第２バッファをサーチして特定することを特徴とする音データ処理方法。

Images