JP2005148565A - オーディオ再生装置およびオーディオ配信システム - Google Patents

Abstract

【課題】サーバ装置からネットワークにストリーミング配信されるオーディオデータを複数のクライアント装置で同期して再生することができるようにしたオーディオ配信システムを提供する。
【解決手段】クライアント装置２において、サーバ装置１からストリーミング配信されるオーディオデータのバッファ量が目標値を維持できるように読出速度を制御する。サーバ装置１からストリーミング配信されるオーディオデータの配信レートと各クライアント装置２の再生レートとを一致させることができ、全てのクライアント装置の再生を同期させることができる。
【選択図】 図１

Description

この発明は、ＬＡＮ等のネットワークを介してオーディオデータを配信し、サーバ装置およびクライアント装置で音楽等のオーディオコンテンツを再生するオーディオ配信システムに関する。

家族全員のオーディオデータ（音楽コレクション）を１つのサーバ装置に記憶するとともに、各部屋にクライアント装置を設置してサーバ装置とネットワークを介して接続することにより、家のどの部屋でもサーバ装置に記憶しているオーディオデータを自由に聴くことができるようにしたシステムが実用化されている。
"ミュージックキャストカタログ"、［online］、平成１５年８月、ヤマハ株式会社、［平成１５年１１月１１日検索］、インターネット＜URL：http://www.yamaha.co.jp/product/av/prd/musiccast/index.html＞

上記システムは、複数のクライアント装置でサーバ装置に蓄積されたオーディオデータを各部屋で自由に聴くことができるが、たとえば、パーティのときなど、全部の部屋で同じ曲を一斉に流すなどのブロードキャスト機能を備えていなかった。

サーバ装置がネットワークへストリーミング出力するオーディオデータを各クライアントが受信して再生することは可能であるが、各クライアント装置において、再生開始タイミングを完全に同期させることは困難であるとともに、クロック発振回路の発振周波数のばらつきにより、オーディオデータの再生速度にばらつきが生じ、オーディオデータを再生している間に各クライアント装置間で再生箇所にずれが生じてしまうという問題点があった。

このずれを解決するためには、ネットワークにＮＴＰサーバを組み込んで各クライアント装置の時計の絶対時刻を同期させることが考えられるが、システム構成が複雑になりコストアップにつながるという問題点があった。また、各クライアント装置のクロック発振回路の精度を向上させることも考えられるが、クライアント装置のコストアップにつながるうえ、精度の向上にも限度があって各クライアント装置間で完全に曲の進行を同期させることは不可能であった。

この発明は、サーバ装置からネットワークにストリーミング出力されたオーディオデータを複数のクライアント装置で同期して再生することができるようにしたオーディオ再生装置およびオーディオ配信システムを提供することを目的とする。

この発明は、ネットワーク経由でオーディオデータをストリーミング受信する手段と、受信したオーディオデータをバッファするバッファ手段と、バッファ手段からオーディオデータを読み出して再生する再生手段と、前記バッファ手段のバッファ量を所定の目標値に維持するよう、前記バッファ量の前記目標値からの過不足に応じて前記再生手段の再生速度を制御する再生速度制御手段と、を備えたことを特徴とする。

この発明では、ネットワーク経由でストリーミング配信されてくるオーディオデータの配信速度に再生速度を同期させる。すなわち再生スタート前にオーディオデータを目標値までバッファし、バッファ量がこの目標値を維持するように再生速度を制御する。これにより、オーディオ再生装置の基本クロックがストリーミング配信元のサーバ装置のデータ読出速度と異なっていても、この再生速度制御によってこれらを一致させることができる。

ネットワーク上に複数のオーディオ再生装置が接続されている場合でも、同一のオーディオデータの配信速度に全てのオーディオ再生装置の再生速度が同期するため、曲再生を同期して行うことができる。

なお、微視的にみれば、各クライアント装置でバッファ量が異なる場合があるが、巨視的にみればバッファ量を目標値に維持することで、ネットワークを介して配信されるオーディオデータに再生速度を同期させることができる。

再生速度の制御がバタバタしたものにならないように、バッファ量の過不足を表すパラメータをフィルタ処理して時定数（慣性）を持たせ、このフィルタ処理されたパラメータで再生速度（クロック周波数）を制御するようにすればよい。

この発明は、前記再生速度制御手段は、バッファ量の過不足が大きくなった場合でも、予め定められた再生速度の上限および下限の範囲で前記再生速度を制御することを特徴とする。

バッファ量が極端に増加した場合や極端に減少した場合でも、大きく再生速度を変化させると、ユーザが聴感上分かる程度の周波数変化を生じてしまう。そこで、極端なバッファ変化があった場合でも、所定の範囲内で再生速度を制御して徐々に過不足を解消するようにしている。

上記再生速度の上限、下限の設定は、再生速度制御用のパラメータの上限，下限の設定で代えることも可能である（後述の実施形態では、パラメータの上限，下限を定めている）。

この発明は、前記再生速度制御手段は、前記バッファ手段のバッファ量の不足が所定値以上になったとき、再生手段の再生を停止して、前記バッファ手段に前記目標値以上のデータがバッファされるまで再生を停止することを特徴とする。

バッファ量の不足が大きくなった状態は、オーディオデータの再生位置が他のクライアント装置やサーバ装置と大きくずれている状態であるため、この状態で再生を継続するのは好ましくない。したがって、このような場合には、再生を一旦停止してバッファをやり直し、他の装置と同期して再生できる状態にもどしてから再生を再開するようにしている。

この発明のオーディオ配信システムは、オーディオデータをネットワークにストリーミング出力するサーバ装置と、クライアント装置である、複数の上記オーディオ再生装置と、を備えたことを特徴とする。

この構成のオーディオ配信システムでは、サーバ装置がネットワーク上にストリーミング出力するオーディオデータを全てのクライアント装置が同期して再生することができる。

この発明は、前記サーバ装置が、オーディオデータを前記ネットワークにストリーミング出力するとともに、前記クライアント装置におけるバッファ量の目標値分、および、サーバ装置からクライアント装置への伝送遅延時間分のデータをバッファしたのち再生することを特徴とする。

この発明では、ネットワーク上にオーディオデータを出力したのち、クライアント装置がこのオーディオデータを受信して再生出力するまでの間の遅れ時間分だけ、サーバ装置においてもオーディオデータをバッファして再生出力するため、クライアント装置同士のみならず、サーバ装置もクライアント装置と同期してオーディオデータを再生することができる。

以上のようにこの発明によれば、サーバ装置がネットワーク上にストリーミング出力したオーディオデータを複数のオーディオ再生装置（クライアント装置）で同時に再生する場合に、ハードウェア的な改良（ＮＴＰサーバやクロック発振回路の精度向上）を加えることなく、オーディオ再生装置（クライアント装置）において、（サーバ装置から）ストリーミング配信されるオーディオデータのバッファ量が目標値を維持できるように読出速度を制御するという処理を行うのみで、ストリーミング配信されるオーディオデータの配信レートとオーディオ再生装置の再生レートとを一致させることができ、複数のオーディオ再生装置がネットワークに接続されている場合であてっも、全てのオーディオ再生装置の再生速度・再生位置を同期させることができる。

図１は、この発明の実施形態であるオーディオ配信システムの構成を示す図である。このオーディオ配信システムでは、サーバ装置１がＬＡＮ３を介して複数のクライアント装置２に接続されている。サーバ装置１にはスピーカシステム４が接続され、各クライアント装置２にはスピーカシステム５が接続されている。サーバ装置１は、ハードディスク等のストレージを内蔵しており、デジタル化されたオーディオデータ（曲データ）を多数記憶している。

通常の再生モードでは、各クライアント装置２において、ユーザが、サーバ装置１に記憶されているオーディオデータ（曲）のなかから自由に選曲してサーバ装置１および他のクライアント装置２から独立して再生することができる。また、サーバ装置１においても、独自に選曲した曲を再生することができる。選曲は、図示しない赤外線リモコンを用いて行う。

また、ブロードキャストモードでは、サーバ装置１において選曲された曲が、全てのクライアント装置２に配信され、全てのクライアント装置２で同じ曲が同期して再生される。
この実施形態では、このブロードキャストモードについて説明する。

図２は、サーバ装置１およびクライアント装置２の信号経路系のブロック図である。サーバ装置１は、オーディオデータをリニアＰＣＭで蓄積記憶しているハードディスク１０を備えている。ＦＩＦＯ１１は、ハードディスク１０からの読み出しをコントロールするためのバッファである。

ブロードキャストモードにおいてリクエストされた曲のオーディオデータは、このサーバ装置のサンプリングクロックに応じて読み出され、エンコーダ１２に入力される。エンコーダ１２は、このオーディオデータをＭＰ３圧縮してネットワークインタフェース１３に入力する。ネットワークインタフェース１３は、このＭＰ３圧縮されたオーディオデータをＬＡＮ３に送出する。

ネットワークインタフェース１３は、５００ｍｓ毎に５００ｍｓ分のオーディオデータをパケット化してＬＡＮ３に送出する。

また、サーバ装置１自身も、このＬＡＮ３上に送出したオーディオデータを再生する。このため、バッファ手段（ＦＩＦＯ（２）１５、バッファ１６、ＦＩＦＯ（３）１７）で、クライアント装置２におけるバッファ量および伝送遅延量分のオーディオデータをバッファし、クライアント装置２における再生タイミングと同じタイミングになるようにデータを遅延してオーディオ出力回路１８に入力する。オーディオ出力回路１８は、このオーディオデータをＤＡ変換するとともに、増幅してスピーカシステム４に出力する。

なお、上記バッファ手段がバッファするデータ量は約２秒程度の再生時間に相当するものであるが、リニアＰＣＭデータであるため、バッファ１６としてはハードディスクを用いている。

このバッファは、上記のように、サーバ装置１における再生タイミングをクライアント装置２における再生遅れに一致させるためのものであり、クライアント装置２におけるバッファ量および伝送遅延に応じて決定すればよい。伝送遅延としては、エンコーダ１２、デコーダ２３のスループットなどである。

一方、クライアント装置２は、ＣＰＵ２０、ＶＣＸＯ（電圧制御水晶発振回路）２１、バッファ２２、デコーダ（ＤＳＰ）２３、ネットワークインタフェース２４およびオーディオ出力回路２５を備えている。ネットワークインタフェース２４は、ＬＡＮ３に接続されており、前記サーバ装置１が出力する（ＭＰ３圧縮された）オーディオデータを受信する。

なお、サーバ装置１からクライアント装置２へのオーディオデータの送信手順は、再送制御を含むものとする。たとえばＴＣＰプロトコルを用いる。後述するようにバッファ２２において約２秒間のオーディオデータをバッファするようにしているため、ＴＣＰ手順で再送処理を行ってもバッファアンダランが発生したりデータの順序が入れかわったりする危険性は殆どない。なお、上位レイヤで再送制御をするのであれはＵＤＰを用いてもよい。

ネットワークインタフェース２４が受信したオーディオデータはバッファ２２に入力される。バッファは、約２秒程度のオーディオデータをバッファする。バッファ２２は、２秒分のオーディオデータを蓄積し、古いデータから順にデコーダ２３によって読み出される。バッファ２２が蓄積するデータ量はＣＰＵ２０によって監視・制御される。なお、バッファ２２は、ＭＰ３圧縮されたデータをバッファするため、上記サーバ装置１のバッファ１６と異なり半導体メモリでも十分に対応することができる。

デコーダ２３は、バッファ２２から読み出したＭＰ３のオーディオデータをリニアＰＣＭにデコードするとともに、アナログ信号に変換してオーディオ出力回路２５に出力する。オーディオ出力回路２５は、このオーディオ信号を増幅してスピーカシステム５に出力する。

このクライアント装置２において、ＣＰＵ２０はバッファ２２のバッファ量を監視している。そして、バッファ量が一定（目標値）に維持されるようにデコーダ２３にクロック信号を供給しているＶＣＸＯ２１のクロック周波数を制御して、バッファ２２からの読出量を制御している。このＶＣＸＯ２１のクロック周波数の制御は、ユーザが聴感的に周波数変動を感じない範囲内で行われる。

このように、バッファ２２のバッファ量を一定値（目標値）に維持することにより、クライアント装置における再生速度および再生位置をサーバ装置１のデータ出力速度および出力タイミングに同期させることができる。すなわち、時間軸で微視的にみれば、バッファ量は常に変動しているが、巨視的にみれば、サーバ装置１が正確なクロック信号に基づいてオーディオデータを定期的に送出しているのであるから、バッファ量を平均的に一定量に維持することにより、再生の同期をとることが可能になる。

図３はバッファ２２に蓄積されるオーディオデータの量（バッファ残量）とクロック制御パラメータとの関係を説明する図である。ＣＰＵ２０は、バッファ２２の残量が目標値になるように再生速度制御パラメータを決定する。

ＣＰＵ２０は、曲の再生中は、５００ｍｓ毎に上記パケット群を受信し、受信毎にバッファ残量をチェックする。曲スタート時には、曲の再生を行わずに、バッファ２２にオーディオデータを蓄積してゆき、目標値から所定量超えたバッファ値Ｂ０までオーディオデータをバッファしたとき（Ｔ０）、このオーディオデータの再生を開始する。なお、Ｂ０はバッファ目標値からデコーダの初期消費量分だけ超えた量である。また、バッファの目標値は、一定の再生時間（２秒間）×ＭＰ３のビットレートで決定される。

そして、これ以後は、約５００ｍｓ毎にチェックされるバッファ残量Ｂｎに応じてパラメータｄｎが決定され、このｄｎに応じてＶＣＸＯ２１が制御されて再生速度（クロック周波数）が決定される。

まず、Ｔ１ではバッファ残量が目標値よりも少ないＢ１であるため、目標値との差分（に対応する値）をパラメータｄ１として出力する。このパラメータｄ１により、ＶＣＸＯ２１においては、クロックが遅くなるように制御される。

Ｔ２においては、バッファ量Ｂ２と目標値との差分は制御の上限（１６０ｋｂｐｓでエンコードした場合、＋３００Ｂ）を超える量であるため、パラメータｄ２としては制御の上限値である＋３００Ｂ（に対応する値）を出力する。このパラメータｄ２により、ＶＣＸＯ２１においては、クロックが早くなるように制御される。

Ｔ３においては、バッファ残量Ｂ３と目標値との差分は、＋側の制御範囲内であるため、この差分（に対応する値）をパラメータｄ３として出力する。

次に、パケット群を受信したタイミングＴ４においては、Ｔ３からの時間経過が正規の時間間隔５００ｍｓの＋１０％（５０ｍｓ）を超えて遅れたため、このときのバッファ残量チェック結果は不正確であるとして採用せず、前回のバッファ残量に基づくパラメータをそのままパラメータｄ４として用いる。

さらに次のパケット群を受信したタイミングＴ５においても、Ｔ４からの時間経過が正規の時間間隔５００ｍｓの−１０％よりも短い間隔であったため、このときのバッファ残量チェック結果（ｄ５）は採用せず、前回（この場合には前々回）のバッファ残量に基づくパラメータをそのままパラメータｄ５として用いる。

Ｔ６においては、Ｔ５からの時間経過が正規の時間間隔５００ｍｓの±１０％の範囲に入っているため、バッファ残量チェック結果は信頼できる値であるとし、このバッファ残量と目標値との差分が制御範囲内であるため、この差分（に対応する値）をパラメータｄ６として出力する。

また、Ｔ７においては、パケット群の到着時刻は許容時間範囲内であるが、バッファ残量Ｂ７と目標値との差分が制御の下限値（−３００Ｂ）を下回っているため、この下限値−３００Ｂ（に対応する値）をパラメータｄ７として出力する。

このように、バッファ残量Ｂｎが目標値から±３００Ｂの範囲（制御範囲）内の場合には、その差分値に応じてパラメータｄｎを決定して出力するが、バッファ残量が上記制御範囲から上または下に外れたときは、制御範囲の上限値または下限値に基づいてパラメータを決定して出力する。これは、クロック周波数の変動が大きくなりすぎて、ユーザの聴感上でも周波数変動が分かるほどにならないようにするためである。

また、上記のようにサーバ装置１は、パケット群を５００ｍｓ毎に送信するが、伝送遅延などでクライアント装置２への到達時刻は変動する。今回のパケット到来時刻（パケット群のうち先頭のパケットが到来した時刻）の直前のパケット到来時刻からの時間差が５００ｍｓの±１０％（±５０ｍｓ）以内であれば、正常な到来時刻であるとして上記パケット残量のチェックを有効にして、このチェック結果に基づくパラメータｄｎを決定するが、パケット群の到来時刻が上記許容範囲を超えていた場合には、時間ずれが大きいとして、そのときのパケット残量のチェック値は採用しない。これにより、到来時間ずれによる誤った制御を防止している。

上記の目標値および処理手順は、図１に示した複数のクライアント装置２において同様に設定されている。これにより、各クライアント装置におけるバッファ量がほぼ同じに維持され、各クライアントにおいて、同じオーディオデータについて同じ再生速度で同じ再生位置を再生することができる。

すなわち、各クライアント装置２におけるＶＣＸＯ２１のデフォルト発振周波数のばらつきをバッファ残量制御によって吸収し、全てのクライアント装置２が同じクロック周波数で同期してオーディオデータを再生することができるようになる。

図４は、ＣＰＵ２０が実行するフィルタ処理を説明する機能ブロック図である。上記のように、バッファ２２の残量と目標値との差分（に基づく値）がＶＣＸ０２１の周波数を制御するためのパラメータとして用いられるが、このパラメータを直接ＶＣＸＯ２１に入力したのでは、クロック周波数が不連続にバタバタと変化してしまいユーザに聴感的に不自然に感じられるおそれがある。そこで、この差分（パラメータ）をフィルタ処理し、時定数（慣性）を持たせてＶＣＸＯに入力するようにしている。

同図のフィルタでは、今回のパラメータに係数Ａを乗算したものと前回のパラメータ（Ｚの出力）に係数Ｂを乗算したものを加算して今回ＶＣＸＯ２１に入力する再生速度制御パラメータとしている。

図４のフィルタ処理によって時定数（慣性）を持たされたパラメータによる制御形態の例を図５，図６に示す。この図では、パケット群が正確に５００ｍｓ毎に到来している状態で説明している。
図５は、クライアント装置２における再生速度が、サーバ装置１の読出速度よりも早い場合のバッファ残量の変化およびクロック周波数の変化を示している。最初は、再生速度が早いために、バッファ２２に蓄積されるデータ量よりも消費（再生）されるデータ量のほうが多く、バッファ残量は徐々に減少してゆく。しかし、徐々にＶＣＸＯ２２が発振するクロック周波数が低く制御されて再生速度が低下し、読出量が少なくなってゆくため、バッファ残量の減少が止まって徐々に目標値に向けて増加してゆく。

また、図６は、クライアント装置２における再生速度が、サーバ装置１の読出速度よりも遅い場合のバッファ残量の変化およびクロック周波数の変化を示している。最初は、再生速度が遅いために、バッファ２２に蓄積されるデータ量よりも消費（再生）されるデータ量のほうが少なく、バッファ残量が徐々に増加してゆく。しかし、徐々にＶＣＸＯ２２が発振するクロック周波数が高く制御されて再生速度が速くなり、読出量が多くなってゆくため、バッファ残量の増加が停止し、そののち徐々に目標値に向けて減少してゆく。

このように、図４のフィルタ処理をしたパラメータをＶＣＸＯ２１に入力することにより、なだらかに、かつ慣性をもってクロック周波数を制御することができ、バッファ残量をなだらかに目標値に収束させることができる。

なお、上の説明では、バッファ残量を目標値に収束・維持させることでクロック周波数のばらつきを吸収することができる旨を説明したが、各クライアント装置２における再生スタートタイミングのずれも、このバッファ残量を目標値に収束させることで解消することができる。

図７は、ブロードキャストモード時におけるクライアント装置２の動作を示すフローチャートである。ブロードキャストモードによる再生がスタートすると、まず、再生せずにオーディオデータの受信のみ行い、バッファ２２にＢ０までオーディオデータをバッファする。このバッファが完了すると（ｓ１）、デコーダ２３にバッファ２２にバッファしたオーディオデータの読み出しを指示して、再生を開始させる（ｓ２）。

そして、新たなパケット群が到着すると（ｓ３）、前回のパケットの到着時刻からの時間差が５００ｍｓからどの程度ずれているかをチェックするとともに（ｓ４）、このパケット群をバッファしたときのバッファ残量をチェックする（ｓ５）。

そして、正常動作においては、上記検出されたバッファ残量を制御範囲に丸め込み（ｓ８）、このバッファ残量（に基づくパラメータ）を図４のフィルタに入力して再生速度制御パラメータを算出する（ｓ１０）。上記丸め込み処理は、再生速度が過度に変動しないように、バッファ残量が目標値から±３００Ｂ（１６０ｋｂｐｓの場合）以上ずれた場合にバッファ残量の値を±３００Ｂに丸め込む処理である。そして、フィルタから出力された再生速度制御パラメータをＶＣＸＯ２１に設定する（ｓ１１）。

一方、パケットの到来時刻が直前のパケットの到来時刻から５００ｍｓの基準間隔よりも±１０％以上ずれていた場合には、今回のバッファ残量のチェック結果を採用せず前回のバッファ残量値を再度設定して（ｓ９）、ｓ１０の再生速度制御パラメータ算出処理に進む。同じバッファ残量値が複数回入力されても、出力される再生速度制御パラメータはフィルタの時定数によって変動する。

ただし、バッファ残量が目標値よりも２ｋＢ（１６０ｋｂｐｓでエンコードした場合）以上不足した状態が３０秒以上継続していた場合には（ｓ６，ｓ１２）、大きく同期がずれた再生をこれ以上継続するのは好ましくないと判断し、再生を中止して（ｓ１３）ｓ１にもどり、バッファ２２へのオーディオデータの蓄積をやり直す。

なお、ブロードキャストモードにおいて、各クライアント装置２は、個別にブロードキャストモードから抜けることができ、別の曲（オーディオデータ）をサーバ装置１にリクエストして再生することができるものとする。

したがって、上記実施形態の説明において、ブロードキャスト配信を受けるクライアント装置は、ＬＡＮ３に接続されている全てのクライアント装置である必要はなく、そのうちの１または複数のクライアント装置であればよい。

すなわち、この発明は、ブロードキャスト配信を受けているクライアント装置相互間およびクライアント装置２とサーバ装置１との再生同期をとることが目的である。

この発明の実施形態であるオーディオ配信システムの構成図 この発明の実施形態であるサーバ装置およびクライアント装置のブロック図 クライアント装置におけるバッファ残量とクロック周波数の変化を示す図 クライアント装置において実行れるフィルタ処理を説明する図 クライアント装置におけるバッファ残量とクロック周波数の変化を示す図 クライアント装置におけるバッファ残量とクロック周波数の変化を示す図 クライアント装置の動作を示すフローチャート

符号の説明

１…サーバ装置
２…クライアント装置
３…ＬＡＮ
４，５…スピーカシステム
１０…ハードディスク
１２…エンコーダ
１３…ネットワークインタフェース
１５，１７…ＦＩＦＯ
１６…バッファ
２０…ＣＰＵ
２１…ＶＣＸＯ
２２…バッファ
２３…デコーダ
２４…ネットワークインタフェース

Claims (5)

1. ネットワーク経由でオーディオデータをストリーミング受信する手段と、
   受信したオーディオデータをバッファするバッファ手段と、
   バッファ手段からオーディオデータを読み出して再生する再生手段と、
   前記バッファ手段のバッファ量を所定の目標値に維持するよう、前記バッファ量の前記目標値からの過不足に応じて前記再生手段の再生速度を制御する再生速度制御手段と、
   を備えたオーディオ再生装置。
2. 前記再生速度制御手段は、バッファ量の過不足が大きくなった場合でも、予め定められた再生速度の上限および下限の範囲で前記再生速度を制御する請求項１に記載のオーディオ再生装置。
3. 前記再生速度制御手段は、前記バッファ手段のバッファ量の不足が所定値以上になったとき、再生手段の再生を停止して、前記バッファ手段に前記目標値以上のデータがバッファされるまで再生を停止する請求項１または請求項２に記載のオーディオ再生装置。
4. オーディオデータをネットワークにストリーミング出力するサーバ装置と、
   クライアント装置である、複数の、請求項１、請求項２または請求項３に記載のオーディオ再生装置と、
   を備えたオーディオ配信システム。
5. 前記サーバ装置は、オーディオデータを前記ネットワークにストリーミング出力するとともに、前記クライアント装置におけるバッファ量の目標値分、および、サーバ装置からクライアント装置への伝送遅延時間分のデータをバッファしたのち再生する請求項４に記載のオーディオ配信システム。

Images