JP3786039B2

JP3786039B2 - 通信装置及び方法

Info

Publication number: JP3786039B2
Application number: JP2002072600A
Authority: JP
Inventors: 菊池　　健; 祐二小池
Original assignee: Yamaha Corp
Current assignee: Yamaha Corp
Priority date: 2002-03-15
Filing date: 2002-03-15
Publication date: 2006-06-14
Anticipated expiration: 2018-03-27
Also published as: JP2002278546A

Description

【０００１】
【発明の属する技術分野】
本発明は、通信技術に関し、特に時間情報を通信する通信技術に関する。
【０００２】
【従来の技術】
電子楽器間の通信の統一規格として、ＭＩＤＩ（musical instrument digital interface）規格がある。ＭＩＤＩ規格のインターフェイスを備えた電子楽器は、ＭＩＤＩ用ケーブルを用いて、他の電子楽器と接続することができる。電子楽器は、ＭＩＤＩ用ケーブルを介して、ＭＩＤＩデータを通信することができる。例えば、一つの電子楽器は、演奏者が演奏した情報をＭＩＤＩデータとして送信し、他の電子楽器は、当該ＭＩＤＩデータを受信し、楽音を発音することができる。一つの電子楽器で演奏すると、他の電子楽器でリアルタイムに発音することができる。
【０００３】
また、複数の汎用コンピュータを接続する通信ネットワークでは、種々の情報を通信することができる。例えば、コンピュータに接続されているハードディスク等にオーディオデータ（生の楽音情報）やＭＩＤＩデータ等の情報を一度蓄積しておき、通信ネットワークを介して、当該情報を送信する。他のコンピュータは、当該情報を受信して、ハードディスク等の記憶装置に記憶する。汎用の通信ネットワークは、情報の通信を行うのみであり、ＭＩＤＩとは性質を異にする。
【０００４】
ＭＩＤＩ規格は、電子楽器間のリアルタイム通信を可能にするが、長距離の通信及び多数ノード間の通信に適していない。一方、汎用通信ネットワークは、長距離の通信及び多数ノード間の通信に適しているが、電子楽器間のリアルタイム通信を考慮したものではない。
【０００５】
【発明が解決しようとする課題】
汎用ネットワークにおいて、時間情報を通信する場合を考える。送信装置と受信装置は、汎用ネットワークに接続され、それぞれが独自のタイマを有し、日付や時刻の時間情報を生成することができる。送信装置のタイマと受信装置のタイマは、通常、同期がとれていなので、両装置が生成する時間情報は必ずしも一致せず、ずれることがある。
【０００６】
送信装置が生成した時間情報を受信装置に送信すると、その時間情報は、受信装置が生成した時間情報と必ずしも一致していない。両者の時間情報が一致していない場合に、受信装置が、その時間情報に応じて、データの処理を行うと、種々の不都合が生じることがある。
【０００７】
また、汎用ネットワークは、長距離通信を行ったり、その通信経路が種々変化したりする場合があるので、各パケット毎の通信時間は一定とは限らない。この通信時間の変化は、受信装置が送信装置から受信した時間情報に応じて処理をする際に悪影響を及ぼすことがある。
【０００８】
本発明の目的は、時間情報を通信する際に時間情報の信頼性を高めることができる通信装置又は通信方法を提供することである。
【０００９】
【課題を解決するための手段】
本発明の一観点によれば、通信装置は、演奏データと、該演奏データに付加された該演奏データの処理タイミングに関する第１の時間情報とを外部から受信する受信手段と、前記第１の時間情報とは非同期な所定の周期でなるシステムクロックと、前記システムクロックに基づき、前記第１の時間情報とは独立した第２の時間情報を生成する時間情報生成手段と、前記受信が前記外部からの最初の受信である場合に、前記第２の時間情報を初期化する時間情報初期化手段と、前記第１の時間情報と第２の時間情報との所定以上の時間差を検出する時間差検出手段と、前記所定以上の時間差を検出したことに応じて前記第２の時間情報を修正する修正手段と、前記受信した第１の時間情報と前記生成した第２の時間情報とに基づいて、前記第１の時間情報と前記第２の時間情報との差が所定値に達したときに、前記受信した演奏データを処理する演奏データ処理手段とを有する。
【００１０】
第１の時間情報は、外部の送信装置により生成され、送信されたものを受信する。第２の時間情報は、時間情報生成手段が生成する。第１の時間情報と第２の時間情報とは、必ずしも同期がとれていない。第１の時間情報と第２の時間情報との時間差を検出し、その時間差に応じて第２の時間情報を修正することにより、第１の時間情報と第２の時間情報とのずれを修復することができる。
【００１１】
【発明の実施の形態】
図２は、楽音情報及び画像情報の通信ネットワークを示す図である。
【００１２】
演奏会場１には、ＭＩＤＩ楽器２、音声入力装置１２、カメラ４、エンコーダー３、５、及びルータ６が備えられる。音声入力装置１２は、例えばマイクロフォンである。演奏会場１では、演奏者がＭＩＤＩ楽器２を演奏し、歌手がその演奏にあわせて音声入力装置１２に向かって歌う。また、音声入力装置１２を生ドラムや生ピアノやエレキギターのそばに置いて、それらの音を音声入力装置１２に入力してもよい。
【００１３】
ＭＩＤＩ楽器２は、演奏者の演奏操作に応じてＭＩＤＩデータを生成し、エンコーダー３に供給する。音声入力装置１２は、歌手の歌声又はドラムの音等を電気信号に変換してアナログ形式のオーディオ信号（音声信号）を生成し、リアルタイムでエンコーダー３に供給する。エンコーダー３は、アナログ形式のオーディオ信号をデジタル形式のオーディオデータ（音声データ）に変換し、ＭＩＤＩデータ及びオーディオデータを所定のデータ形式で、ルータ６を介してインターネット上にパケット送信する。データ形式は、後に図４（Ａ）、（Ｂ）を参照しながら説明する。
【００１４】
カメラ４は、演奏者が演奏している様子を撮影し、その様子を画像データとしてエンコーダー５に供給する。エンコーダー５は、画像データを所定のデータ形式で、ルータ６を介してインターネット上にパケット送信する。
【００１５】
ルータ６は、以下に示すインターネットを介して、ＭＩＤＩデータ、オーディオデータ及び画像データを送信する。当該データは、電話回線又は専用回線を通り、ルータ６からサーバ７に供給され、さらに複数のＷＷＷ（world wide web）サーバ８に供給される。ＷＷＷサーバ８は、いわゆるプロバイダである。
【００１６】
ユーザは、ホームコンピュータ９をＷＷＷサーバ８に接続することにより、インターネットを使用することができる。ホームコンピュータ９は、インターネットを使用し、ＭＩＤＩデータ、オーディオデータ及び画像データを受信することができる。ホームコンピュータ９は、ディスプレイ装置とＭＩＤＩ音源を有し、ＭＩＤＩ音源は音声出力装置１１に接続される。
【００１７】
画像データは、ディスプレイ装置に表示される。ＭＩＤＩデータは、ＭＩＤＩ音源で楽音信号に変換され、音声出力装置１１で発音される。オーディオデータは、デジタル形式からアナログ形式に変換されて、音声出力装置１１で発音される。ホームコンピュータ９は、ＭＩＤＩデータとオーディオデータの同期をとって、両データに応じて音声出力装置１１で発音させる。演奏会場１の演奏音や歌声と同等の音が音声出力装置１１からリアルタイムで発音される。
【００１８】
また、ホームコンピュータ９の外部に、ＭＩＤＩ音源１０を接続すれば、ホームコンピュータ９は、ＭＩＤＩ音源１０に楽音信号を生成させ、音声出力装置１１から発音させることができる。
【００１９】
なお、音楽の演奏において、ユーザにとっては、画像データよりもＭＩＤＩデータ及びオーディオデータの方が重要な情報であるので、画像データよりもＭＩＤＩデータ及びオーディオデータを優先して処理を行う。画像データは、画質が悪く、コマ数が少なくてもさほど気にならないが、ＭＩＤＩデータ及びオーディオデータに基づく楽音信号は高品質が要求される。なお、スポーツの中継等の場合は、画像と音との関係が逆になる。
【００２０】
ユーザは、演奏会場１に赴かなくても、自宅にいながらディスプレイ装置で演奏会場１の模様を見ながら、リアルタイムで演奏音及び歌声を聴くことができる。また、自宅のホームコンピュータ９をインターネットに接続すれば、誰でも演奏音及び歌声を聴くことができる。例えば、演奏会場１でコンサートを行った場合には、不特定多数人が自宅でそのコンサートを楽しむことができる。
【００２１】
演奏会場からＭＩＤＩデータを自宅に送信することにより、演奏者が複数のユーザのそれぞれの自宅で電子楽器を演奏しているかのような状況を作り出すことができる。ＭＩＤＩデータの通信は、雑音により音質を下げることはない。
【００２２】
図３は、送信端であるエンコーダー３と受信端であるホームコンピュータ９を示す。以下、両者の関係を説明するため、便宜的にエンコーダー３をサーバ３と呼び、ホームコンピュータ９をクライアント９と呼ぶ。
【００２３】
サーバ３とクライアント９は、インターネットのデジタル回線により接続される。サーバ３は、ＭＩＤＩ楽器２からＭＩＤＩデータを受け、音声入力装置１２からアナログ形式のオーディオ信号を受ける。デジタル形式に変換されたオーディオデータ及びＭＩＤＩデータは、サーバ３からクライアント９に送信される。クライアント９は、ＭＩＤＩ音源１０にＭＩＤＩデータを出力し、音声出力装置１１にアナログ形式に変換されたオーディオ信号を出力する。ＭＩＤＩ音源１０は、ＭＩＤＩデータを受け、アナログ形式の楽音信号を生成して音声出力装置１１に出力する。音声出力装置１１は、アナログ形式のオーディオ信号及び楽音信号を受けて発音する。
【００２４】
図４（Ａ）は、サーバ３が送信するＭＩＤＩデータパケット４９の構造を示す。
【００２５】
ＭＩＤＩデータパケット４９は、ヘッダ５１とＭＩＤＩデータ４４とフッタ５２を有する。ヘッダ５１は、時間情報を表すタイムスタンプ４１、パケットの順番を示すシーケンスナンバ５３、当該パケットがＭＩＤＩデータであることを示す識別子（ＩＤ）４２、当該パケットのサイズ４３を有する。
【００２６】
タイムスタンプ４１は、パケット内のＭＩＤＩデータ４４の送信時刻を表すと共に、演奏時刻、録音時刻、再生時刻をも表す。サーバ３は、自己のシステムクロック（タイマ）が生成する時間情報に応じて、タイムスタンプ４１を生成する。
【００２７】
シーケンスナンバ５３は、パケット単位で付与される順番を表す番号である。クライアント９は、通信エラーによりデータの順序が入れ替わった場合でも、パケットを所定時間だけバッファリングした後、バッファ内のデータをシーケンスナンバ５３に従ってソート処理することにより、通信エラーをリカバリすることができる。
【００２８】
識別子４２は、ＭＩＤＩデータパケットやオーディオデータパケットや画像データパケット等のパケットの種類を表すことが可能である。ここでは、ＭＩＤＩデータ４４を送信するので、ＭＩＤＩデータパケットを表すものとなる。
【００２９】
ＭＩＤＩデータ４４は、スタンダードＭＩＤＩファイルフォーマットに準拠したものであり、デルタタイム（インターバル）とＭＩＤＩイベントを１組にしたデータの列である。デルタタイムは、直前のＭＩＤＩイベントと当該ＭＩＤＩイベントの間の時間間隔を表す。ただし、デルタタイムが０であるときには、デルタタイムを省略することができる。
【００３０】
フッタ５２は、データの終了を表すデータを有する。ヘッダ５１又はフッタ５２に、チェックサムを含ませてもよい。チェックサムは、例えばＭＩＤＩデータ４４の合計値である。この場合、サーバ３は、当該合計値を計算し、チェックサムとしてパケット中に付与する。クライアント９は、当該合計値を計算し、チェックサムの値と合っていれば、通信エラーがないことを確認することができる。
【００３１】
図４（Ｂ）は、サーバ３が送信するオーディオデータパケット５０の構造を示す。
【００３２】
オーディオデータパケット５０は、ヘッダ５１とデジタルオーディオデータ４８とフッタ５２を有する。デジタルオーディオデータ４８は、音声入力装置１２（図３）から生成されたデータを、Ａ／Ｄ変換し、圧縮したデータである。
【００３３】
ヘッダ５１は、ＭＩＤＩデータパケットの場合と同様に、タイムスタンプ４１、シーケンスナンバ５３、当該パケットがオーディオデータであることを示す識別子（ＩＤ）４２、当該パケットのサイズ４３を有する。タイムスタンプ４１は、ＭＩＤＩデータパケットの場合と同様に、パケット内のオーディオデータ４８の送信時刻等を表す。
【００３４】
次に、タイムスタンプと通信時間との関係を説明する。パケット内には、タイムスタンプが含まれている。クライアント９は、このタイムスタンプに応じて、ＭＩＤＩデータ等の処理を行えばよい。
【００３５】
しかし、インターネット等では、パケット毎に通信時間が異なる場合がある。すなわち、あるパケットは通信時間が長く、他のパケットは通信時間が短い場合がある。これは、長距離通信の場合や通信経路がパケット毎に変化する場合に顕著に現れる。
【００３６】
また、通信エラーにより、送信時のパケットの順番と受信時のパケットの順番が異なることがある。すなわち、パケットの通信順序の入替えが発生することがある。
【００３７】
クライアント９は、受信データをバッファにバッファリングし、タイムスタンプの時刻から所定時間（例えば３秒）経過後に、バッファ内のデータの処理を開始する。
【００３８】
バッファ内にデータをバッファリングすることにより、パケット毎の通信時間の相違を吸収することができる。また、上記のシーケンスナンバ５３（図４（Ａ）、（Ｂ））に応じて、パケット内のデータをソート処理することにより、パケットの順序を正常なものに戻すことができる。
【００３９】
次に、サーバ３のシステムクロックとクライアント９のシステムクロックとのずれによる影響を説明する。サーバ３のシステムクロックとクライアント９のシステムクロックは、それぞれ独自に時間情報を生成し、両者は同期がとれていない。したがって、両者のシステムクロックが生成する時間情報は時間経過と共にずれていくことがある。これは、一般の時計に誤差があるのと同じである。
【００４０】
例えば、クライアント９のシステムクロックがサーバ３のものよりも進んだ場合を考える。当初は、３秒経過後にバッファ内のデータを取り出していても、徐々にその時間が短くなり、やがては受信したデータを直ちに取り出して、処理するようになってしまう。この場合、一定時間だけバッファリングする機能を失うことになる。
【００４１】
次に、クライアント９のシステムクロックがサーバ３のものよりも遅れた場合を考える。当初は、３秒経過後にバッファ内のデータを取り出していても、徐々にその時間が長くなり、時間の経過と共にバッファ内のデータ量が増加して行く。バッファの容量が小さい場合には、バッファからデータが溢れて、データを失う事態も起こりえる。
【００４２】
以上の弊害を除去するため、クライアント９のシステムクロックをサーバ３のものに合わせる（同期させる）ための修正を行う。具体的には、クライアント９のシステムクロックが生成するタイムスタンプを、サーバ３のシステムクロックが生成するタイムスタンプに一致させる。その詳細を、以下説明する。
【００４３】
図１（Ａ）は、サーバのタイムスタンプとクライアントのタイムスタンプがずれる過程を示すタイムチャートである。横軸は、時間を示す。
【００４４】
サーバは、送信開始時に、タイムスタンプを０分にして、そのタイムスタンプを含んだパケットＰ０をクライアントに送信する。サーバのシステムクロックは、その後、そのタイムスタンプを順次カウントアップする。
【００４５】
クライアントは、０分のタイムスタンプを含むパケットＰ０を受信すると、その時点で、クライアントのタイムスタンプを０分にリセットする。クライアントのシステムクロックは、その後、当該タイムスタンプを順次カウントアップする。サーバのタイムスタンプとクライアントのタイムスタンプは、同期がとれていない。
【００４６】
ここで、クライアントのタイムスタンプがサーバのものよりも進む場合を考える。例えば、サーバのタイムスタンプが１５分の時、クライアントのタイムスタンプが１５分３００ｍ秒であるとする。クライアントのタイムスタンプの進みは、３００ｍ秒である。
【００４７】
サーバが、１５分経過後に、１５分のタイムスタンプを含むパケットＰ１をクライアントに送信するとする。クライアントは、パケットＰ１を受信した時点で、両者のタイムスタンプを比較し、自己のタイムスタンプが３００ｍ秒進んでいることを認識することができる。
【００４８】
図１（Ｂ）は、タイムスタンプの修正方法を示すタイムチャートである。横軸は時間である。図１（Ａ）の１５分の時点を時刻Ｔ１とする。
【００４９】
時刻Ｔ１の時点で、クライアントのタイムスタンプは、サーバのものよりも３００ｍ秒進んでいる。クライアントは、自己のタイムスタンプが例えば３００ｍ秒以上進んだことを所定データ数以上認識した時点で、タイムスタンプの修正処理を開始する。この際、タイムスタンプのずれを一気に修正するのではなく、以下の方法により、徐々に修正していく。
【００５０】
時刻Ｔ１では、３００ｍ秒のずれがある。時刻Ｔ１から、５秒経過後の時刻Ｔ２までの間に１００ｍ秒だけクライアントのタイムスタンプを修正する。時刻Ｔ２では、２００ｍ秒のずれがある。続いて、時刻Ｔ２から、５秒経過後の時刻Ｔ３までの間に再び１００ｍ秒修正する。時刻Ｔ３では、１００ｍ秒のずれがある。時刻Ｔ３から、５秒経過後の時刻Ｔ４までの間に再び１００ｍ秒修正する。時刻Ｔ４では、ずれがなくなる。以上で、タイムスタンプの修正処理が終了する。タイムスタンプの修正は、約１５秒かけて、１００ｍ秒ずつ３回に分けて行う。
【００５１】
図５は、図３の具体的なハードウエア構成を示す図である。サーバ３とクライアント９は、共に汎用コンピュータ又はパーソナルコンピュータ等を用いることができる。
【００５２】
サーバ３とクライアント９は、基本的に同じ構成である。両者の構成を説明する。バス２１には、ＣＰＵ２２、ＲＡＭ２４、外部記憶装置２５、外部に対してＭＩＤＩデータを送受信するためのＭＩＤＩインターフェイス２６、サウンドカード２７、ＲＯＭ２８、表示装置２９、キーボードやスイッチやマウス等の入力手段３０、インターネットを行うための通信インターフェイス３１が接続されている。
【００５３】
サウンドカード２７は、バッファ２７ａとコーデック回路２７ｂを有する。バッファ２７は、外部に対して入力又は出力するためのデータをバッファリングする。コーデック回路２７ｂは、Ａ／Ｄ変換器及びＤ／Ａ変換器を有し、アナログ形式とデジタル形式の両者間の変換を行うことができる。さらに、コーデック回路２７ｂは、圧縮／伸張回路を有し、データの圧縮及び伸張を行うことができる。データは、圧縮された状態で、インターネット通信される。
【００５４】
外部記憶装置２５は、例えばハードディスクドライブ、フロッピー（登録商標）ディスクドライブ、ＣＤ−ＲＯＭドライブ、光磁気ディスクドライブ等であり、ＭＩＤＩデータ、オーディオデータ、画像データ又はコンピュータプログラム等を記憶することができる。
【００５５】
ＲＯＭ２８は、コンピュータプログラム及び各種パラメータを記憶することができる。ＲＡＭ２４は、バッファやレジスタ等のワーキングエリアを有し、外部記憶装置２５に記憶されている内容をコピーして記憶することができる。
【００５６】
ＣＰＵ２２は、ＲＯＭ２８又はＲＡＭ２４に記憶されているコンピュータプログラムに従って、各種演算又は処理を行う。ＣＰＵ２２は、システムクロック２３から時間情報を得て、タイマ割り込み処理を行うことができる。サーバ３のシステムクロック２３は、サーバのタイムスタンプを生成し、クライアント９のシステムクロック２３は、クライアントのタイムスタンプを生成する。
【００５７】
インターネット回線３２には、サーバ３の通信インターフェイス３１及びクライアント９の通信インターフェイス３１が接続される。通信インターフェイス３１は、インターネットにより、ＭＩＤＩデータ、オーディオデータ及び画像データを送受信するためのインターフェイスである。サーバ３とクライアント９は、インターネット回線３２により接続される。
【００５８】
まず、サーバ３について説明する。ＭＩＤＩインターフェイス２６には、ＭＩＤＩ楽器２が接続され、サウンドカード２７には、音声入力装置１２が接続される。ＭＩＤＩ楽器２は、演奏者の演奏操作に応じてＭＩＤＩデータを生成し、ＭＩＤＩインターフェイス２６に出力する。音声入力装置１２は、演奏会場における音声を入力し、アナログ形式のオーディオ信号をサウンドカード２７に出力する。サウンドカード２７は、アナログ形式のオーディオ信号をバッファ２７ａにバッファリングし、コーデック回路２７ｂでアナログ形式のオーディオ信号をデジタル形式のオーディオデータに変換し、そのデータを圧縮する。
【００５９】
次に、クライアント９について説明する。図３に示すように、ＭＩＤＩインターフェイス２６には、ＭＩＤＩ音源１０が接続され、サウンドカード２７には、音声出力装置１１が接続される。ＣＰＵ２２は、通信インターフェイス３１を介して、インターネット回線３２上からＭＩＤＩデータとオーディオデータと画像データを受信する。
【００６０】
図６に示すように、クライアント９のＲＡＭ２４は、受信バッファ２４ａ、パケット内のタイムスタンプ（サーバのタイムスタンプ）を格納するレジスタ２４ｂ、自己のタイムスタンプ（クライアントのタイムスタンプ）を格納するレジスタ２４ｃ、タイムスタンプのずれの大きさを表すずれ検出カウンタ値を格納するレジスタ２４ｄを有する。
【００６１】
通信インターフェイス３１は、インターネット用インターフェイスの他、イーサネット（登録商標）用インターフェイス、ＩＥＥＥ１３９４規格のデジタル通信インターフェイス、ＲＳ−２３２Ｃ用インターフェイスでもよく、種々のネットワークに接続することができる。
【００６２】
サーバ３は、ＭＩＤＩデータ等を送信するためのコンピュータプログラムを記憶する。クライアント９は、ＭＩＤＩデータ等を受信したり、タイムスタンプを修正するためのコンピュータプログラムを記憶したりする。コンピュータプログラムや各種パラメータ等を外部記憶装置２５に記憶させておき、それをＲＡＭ２４に読み込むことにより、コンピュータプログラム等の追加やバージョンアップ等が容易に行える。
【００６３】
ＣＤ−ＲＯＭ（コンパクトディスク−リード・オンリィ・メモリ）ドライブは、ＣＤ−ＲＯＭに記憶されているコンピュータプログラム等を読み出す装置である。読み出したコンピュータプログラム等は、ハードディスクにストアされる。コンピュータプログラムの新規インストールやバージョンアップ等が容易に行える。
【００６４】
通信インターフェイス３１はＬＡＮ（ローカルエリアネットワーク）やインターネット、電話回路等の通信ネットワーク３２に接続されており、該通信ネットワーク３２を介して、コンピュータ３３と接続される。外部記憶装置２５内に上記のコンピュータプログラム等が記憶されていない場合、コンピュータ３３からコンピュータプログラム等をダウンロードすることができる。サーバ３又はクライアント９は、通信インターフェイス３１及び通信ネットワーク３２を介してコンピュータ３３へコンピュータプログラム等のダウンロードを要求するコマンドを送信する。コンピュータ３３は、このコマンドを受け、要求されたコンピュータプログラム等を、通信ネットワーク３２を介してサーバ３又はクライアント９へ配信する。サーバ３又はクライアント９が通信インターフェイス３１を介して、コンピュータプログラム等を受信して外部記憶装置２５に蓄積することにより、ダウンロードが完了する。
【００６５】
なお、本実施例は、本実施例に対応するコンピュータプログラム等をインストールした市販のパーソナルコンピュータ等によって、実施させるようにしてもよい。その場合には、本実施例に対応するコンピュータプログラム等を、ＣＤ−ＲＯＭやフロッピディスク等の、コンピュータが読み込むことができる記憶媒体に記憶させた状態で、ユーザーに提供してもよい。そのパーソナルコンピュータ等が、ＬＡＮ、インターネット、電話回線等の通信ネットワークに接続されている場合には、通信ネットワークを介して、コンピュータプログラムや各種データ等をパーソナルコンピュータ等に提供してもよい。
【００６６】
また、サーバ３又はクライアント９は、パーソナルコンピュータの他、電子楽器、ゲーム機、カラオケ装置、テレビ等の形態として適用してもよい。
【００６７】
図７〜図９に、サーバが行う処理のフローチャートを示す。図７は、サーバが行うオーディオデータの送信処理を示すフローチャートである。
【００６８】
ステップＳＡ１では、音声入力装置１２（図２）からオーディオデータを受信する。
【００６９】
ステップＳＡ２では、受信したオーディオデータをアナログ形式からデジタル形式に変換する。具体的には、所定のサンプリングレートで、オーディオデータのサンプリングを行い、デジタル形式のオーディオデータを生成する。
【００７０】
ステップＳＡ３では、デジタル形式のオーディオデータを圧縮し、データ量を削減する。ステップＳＡ２のＡ／Ｄ変換及びステップＳＡ３の圧縮処理は、コーデック回路２７ｂ（図５）で行うことができる。
【００７１】
ステップＳＡ４では、圧縮したデータに、タイムスタンプを付与して、パケット化する。このパケットは、図４（Ｂ）に示す構造である。タイムスタンプの生成方法は、後に図９を参照しながら説明する。このタイムスタンプは、サーバのタイムスタンプである。
【００７２】
ステップＳＡ５では、当該パケットをインターネットにより送信する。以上で、オーディオデータの送信処理が終了する。
【００７３】
図８は、サーバが行うＭＩＤＩデータの送信処理を示すフローチャートである。
【００７４】
ステップＳＢ１では、ＭＩＤＩ楽器２（図２）からＭＩＤＩデータを受信する。
【００７５】
ステップＳＢ２では、受信したＭＩＤＩデータに、タイムスタンプを付与して、パケット化する。このパケットは、図４（Ａ）に示す構造である。タイムスタンプの生成方法は、後に図９を参照しながら説明する。このタイムスタンプも、サーバのタイムスタンプである。
【００７６】
ステップＳＢ３では、当該パケットをインターネットにより送信する。以上で、ＭＩＤＩデータの送信処理が終了する。
【００７７】
図９は、サーバがタイムスタンプを生成する処理を示すフローチャートである。この処理は、上記のパケットを送信する際に必要とされる処理であり、必ずしもタイマ割り込みにより定期的に行う必要はない。
【００７８】
ステップＳＣ１では、演奏開始時における最初のパケット作成であるか否か、すなわち、最初に送信するパケットであるか否かをチェックする。最初のパケットであるときには、ｙｅｓの矢印に従い、ステップＳＣ２へ進む。最初のパケットでないときには、ｎｏの矢印に従い、ステップＳＣ４へ進む。
【００７９】
ステップＳＣ２では、サーバのシステムクロックの値を読み出し、記憶部（ＲＡＭ２４）に演奏開始時刻として記憶する。
【００８０】
ステップＳＣ３では、サーバのタイムスタンプの値を０にクリアする。すなわち、タイムスタンプは、演奏開始時（送信開始時）に０に設定される。以上により、タイムスタンプ生成の処理を終了する。
【００８１】
次に、パケットが最初のパケットでない場合を説明する。この場合、上記のように、ステップＳＣ１からステップＳＣ４へ進む。
【００８２】
ステップＳＣ４では、サーバのシステムクロックの値を読み出す。この値は、パケットの送信時刻に相当する。
【００８３】
ステップＳＣ５では、記憶部（例えばＲＡＭ２４）に記憶されている演奏開始時刻を読み出す。演奏開始時刻は、上記のステップＳＣ２にて、既に記録されている。
【００８４】
ステップＳＣ６では、ステップＳＣ４で読み出したシステムクロックの値から、ステップＳＣ５で読み出した演奏開始時刻を減算し、その値をタイムスタンプとする。タイムスタンプは、演奏開始時を０としたときの時間情報であり、サーバのシステムクロックによりカウントアップされる。以上により、タイムスタンプ生成の処理を終了する。なお、タイムスタンプは、タイマ割り込みによるカウンタにより生成してもよい。
【００８５】
図１０〜図１４に、クライアントが行う処理のフローチャートを示す。図１０は、クライアントの受信処理を示すフローチャートである。
【００８６】
ステップＳＤ１では、パケットを受信する。ステップＳＤ２では、受信したパケットが最初のパケットであるか否かを判断し、最初のパケットであれば、クライアントのタイムスタンプの値を０にクリアする。最初のパケット内には、サーバのタイムスタンプとして０が含まれている。パケット内のタイムスタンプとクライアントのタイムスタンプは、共に０になる。
【００８７】
図１１に示すように、クライアントのタイムスタンプは、クライアントのタイマ割り込み処理により生成される。ステップＳＥ１では、クライアントのシステムクロックに同期してタイムスタンプをカウントアップする。タイムスタンプは、システムクロックと同じタイミングで増加する。なお、クライアントのタイムスタンプは、図９のサーバのタイムスタンプ生成処理と同様な方法により生成してもよい。
【００８８】
図１０に戻り、ステップＳＤ３では、パケット内のタイムスタンプを取得する。パケット内のタイムスタンプは、サーバが生成するものであり、演奏開始時からの時間に相当する。当該パケットが最初のパケットであれば、タイムスタンプは０である。
【００８９】
ステップＳＤ４では、クライアントのタイムスタンプを取得する。このタイムスタンプは、上記の図１１の処理によりカウントアップされる。
【００９０】
ステップＳＤ５では、ステップＳＤ３で取得したパケット内のタイムスタンプとステップＳＤ４で取得したクライアントのタイムスタンプを比較し、両者のずれ量を求める。
【００９１】
ステップＳＤ６では、ずれ量が許容範囲内であるか否かをチェックする。クライアントとサーバのシステムクロックにずれがない場合にも、通信状況により、わずかなタイムスタンプのずれが生じることがあるので、そのようなずれを除外するため、上記のずれ量に許容範囲を設けている。この許容範囲（設定修正時間）に相当する値はクライアント側で任意に設定できるものであっても構わない。
【００９２】
ずれ量が許容範囲を超えているときには、ｎｏの矢印に従い、ステップＳＤ８へ進む。ずれ量が許容範囲内であるときには、ｙｅｓの矢印に従い、ステップＳＤ７へ進む。
【００９３】
ステップＳＤ８では、ずれ量が許容範囲を超えているので、ずれ検出カウンタ２４ｄ（図６）の値を以下のように調整する。クライアントのタイムスタンプが遅れていれば、ずれ検出カウンタの値を増加させる。逆に、クライアントのタイムスタンプが進んでいれば、ずれ検出カウンタの値を減少させる。ずれ検出カウンタの値は、初期時が０であり、正値であれば遅れを示し、負値であれば進みを示す。
【００９４】
パケットを受信する度に、タイムスタンプのずれ量が判別され、ずれ検出カウンタがカウントを行う。ずれ検出カウンタは、許容範囲（設定修正時間）を越えたずれの回数（累算値）を示す。ずれ検出カウンタの値が所定値を超えると、後に示す図１３の処理でタイムスタンプが修正されることになる。その後、ステップＳＤ９へ進む。
【００９５】
一方、ステップＳＤ７では、ずれ量が許容範囲内であるので、ずれ検出カウンタの絶対値をカウントダウンする。例えば、ずれ検出カウンタが５であれば４にし、−５であれば−４にする。
【００９６】
タイムスタンプのずれは一時的な場合がある。つまり、前回はずれが発生したが、今回はずれが発生しない場合がある。その場合は、タイムスタンプのずれがなくなったと判断し、ずれ検出カウンタの絶対値をカウントダウンする。この場合、ずれ検出カウンタは、０にリミットされる。その後、ステップＳＤ９へ進む。
【００９７】
ステップＳＤ９では、上記で受信したパケットをデータの種類に応じて、異なるバッファにバッファリングする。データの種類は、オーディオデータ、ＭＩＤＩデータ、画像データであり、データＩＤ４２（図４（Ａ）、（Ｂ））により判断される。以上で、クライアントの受信処理が終了する。
【００９８】
図１２は、クライアントが行う再生処理を示すフローチャートである。ステップＳＦ１では、データの種類毎のバッファ（例えばＭＩＤＩデータ用バッファやオーディオデータ用バッファ等）を定期的に検索し、各バッファ内にデータが存在するか否かをチェックする。存在するときには、そのデータをバッファから読み出す。
【００９９】
ステップＳＦ２では、現在のクライアントのタイムスタンプを取得する。当該タイムスタンプは、上記の図１１の処理でカウントアップされる。
【０１００】
ステップＳＦ３では、ステップＳＦ１で読み出したデータに対応するパケット内のタイムスタンプ（サーバのタイムスタンプ）を取得する。
【０１０１】
ステップＳＦ４では、ステップＳＦ２で取得したクライアントのタイムスタンプとステップＳＦ３で取得したパケット内のタイムスタンプを比較し、両者の差をディレイ時間として求める。
【０１０２】
ステップＳＦ５では、当該ディレイ時間が所定値に達したか否かをチェックする。このディレイ時間は、バッファ内にデータを蓄積する時間に相当し、例えば３秒である。
【０１０３】
ディレイ時間が所定値に達したときには、ｙｅｓの矢印に従い、ステップＳＦ６へ進み、当該データを再生する処理を行う。ディレイ時間が所定値に達していないときには、ｎｏの矢印に従い、処理を終了し、ディレイ時間が所定値に達するまでデータの再生を行わない。以上により、クライアントの再生処理を終了する。
【０１０４】
上記のように、一定時間（例えば３秒）だけデータをバッファ内に蓄積し、その後にデータの再生を行うことにより、各パケット毎の通信時間の相違（ずれ）やパケットの通信順序の入替えによる悪影響を防止することができる。
【０１０５】
図１３は、クライアントのタイムスタンプのずれを検出する処理を示すフローチャートである。このフローに相当する処理は定期的に起動されても良いし、図１０のＳＤ８の処理後ＳＤ９の前に挿入して起動されても構わない。
【０１０６】
ステップＳＧ１では、ずれ検出カウンタが所定値を超えたか否かをチェックする。ずれ検出カウンタは、許容範囲（設定修正時間）を越えたずれの回数（累算）をカウントするものであり、図１０のステップＳＤ８でカウントされる。ずれの回数が所定値を超えていれば、そのずれは一時的なずれではなく、タイムスタンプを修正する必要がある。
【０１０７】
所定値を超えたときには、ｙｅｓの矢印に従い、ステップＳＧ２へ進み、タイムスタンプのずれの修正の準備を行う。一方、所定値を超えないときには、ずれが一時的なものであるとして、タイムスタンプのずれの修正を行わずに、ｎｏの矢印に従い、処理を終了する。
【０１０８】
ステップＳＧ２では、ずれ検出カウンタ値をタイムスタンプ補正モジュールへ引渡し、ずれ検出カウンタをクリアする。タイムスタンプ補正モジュールは、後に示す図１４の処理に相当する。
【０１０９】
ステップＳＧ３では、タイムスタンプ補正モジュールに起動がかかるように処理する。例えば、起動用フラグを用いて、このフラグがセットされたときに当該モジュールが起動するようにしてもよいし、当該モジュールを直接呼び出（コール）してもよい。以上により、タイムスタンプのずれ検出処理が終了する。
【０１１０】
図１４は、クライアントのタイムスタンプ補正モジュールの処理を示すフローチャートである。ステップＳＨ１では、ステップＳＧ２で引数として渡されたずれ検出カウンタ値を取得する。
【０１１１】
ステップＳＨ２では、ずれ検出カウンタ値を基に、クライアントのタイムスタンプが遅れているか又は進んでいるかを判断する。例えば、ずれ検出カウンタ値が正値であれば遅れであり、負値であれば進みである。
【０１１２】
次に、遅れか進みかにより、クライアントのタイムスタンプを修正する時間方向を決定する。クライアントのタイムスタンプが遅れているときには、前記クライアントのタイムスタンプを加算する方向（進む方向）に修正し、進んでいる時には減算する方向（遅らせる方向）に修正するように決定する。
【０１１３】
ステップＳＨ３では、設定修正時間に応じて、補正値をテーブル等から取得し、補正値レジスタにセットする。例えば、前記設定修正時間が３００ｍ秒であれば、補正値レジスタに３をセットする。
【０１１４】
ステップＳＨ４では、補正値レジスタの値が０であるか否かをチェックする。０でないときには、ｎｏの矢印に従い、ステップＳＨ５へ進む。
【０１１５】
ステップＳＨ５では、所定値をタイムスタンプに加算又は減算する。所定値は、補正値の１目盛りに対応する修正時間であり、例えば１００ｍ秒（図１（Ｂ））である。加算又は減算は、上記のステップＳＨ２の決定に従い、いずれかが行われる。
【０１１６】
ステップＳＨ６では、補正値から所定値を減算する。所定値は、例えば１である。その後、所定時間経過後に、ステップＳＨ４へ戻る。所定時間は、例えば５秒（図１（Ｂ））である。
【０１１７】
ステップＳＨ４では、再び補正値レジスタが０か否かをチェックする。０でなければ、上記のステップＳＨ５及びＳＨ６の処理を繰り返す。補正値レジスタが０になれば、処理を終了する。
【０１１８】
補正値レジスタが０になるまで、ステップＳＨ４、ＳＨ５、ＳＨ６を含むステップＳＨ１０の処理は、定期的（例えば５秒間隔）に行われる。
【０１１９】
以上のように、タイムスタンプが所定値（例えば３００ｍ秒）以上ずれていることが所定回数以上検出されると、所定時間（例えば５秒）おきに所定時間（例えば１００ｍ秒）づつタイムスタンプを修正する。３００ｍ秒のずれを一度に修正するのではなく、１５秒の時間をかけて徐々に１００ｍ秒ずつ３回に分けてタイムスタンプのずれを滑らかに修正する。これにより、データの再生速度が急激に変化することを防止し、滑らかな再生を行うことができる。
【０１２０】
パケットのタイムスタンプとクライアントのタイムスタンプとの差が所定値を超えたときに再生処理により発音されるので（図１２のステップＳＦ５、ＳＦ６）、上記のタイムスタンプの修正を行っても、途中の音の発音が省略されることはない。
【０１２１】
本実施例によれば、クライアントは、受信したデータをバッファ内に所定時間（例えば３秒）だけ格納した後に、データの再生処理を行う。これにより、各パケット毎に通信時間が異なる場合やパケットの通信順序が入れ替わった場合にも、適切な再生時間かつ適切なデータ順序で再生することができる。
【０１２２】
クライアントのタイムスタンプが進んだ場合には、バッファ内にデータを蓄積（バッファリング）する時間が次第に短くなり、最終的には蓄積する時間が０になってしまい、データをバッファリングする上記の機能が失われてしまう。
【０１２３】
逆に、クライアントのタイムスタンプが遅れた場合には、バッファ内に蓄積するデータ量が次第に増加する。バッファ容量が少ない場合には、やがてバッファ内のデータが溢れてしまい、データが失われることがある。
【０１２４】
クライアントは、クライアントのタイムスタンプがずれた（進んだり遅れたりした）ことを検出した場合には、そのタイムスタンプを修正することができる。これにより、上記の問題点を解消することができる。その際、ずれが大きいときには、一度に修正するのではなく、複数回に分けて少しずつ修正する。これにより、タイムスタンプを修正する際にも、データを滑らかに再生することができる。
【０１２５】
なお、本実施例は、オーディオデータ及びＭＩＤＩデータ等をインターネットで通信する場合に限定されない。例えば、ＩＥＥＥ１３９４規格のデジタルシリアル通信や通信衛星等の他の通信にも適用することができる。
【０１２６】
以上実施例に沿って本発明を説明したが、本発明はこれらに制限されるものではない。例えば、種々の変更、改良、組合せ等が可能なことは当業者に自明であろう。
【０１２７】
【発明の効果】
以上説明したように、本発明によれば、外部から受信する第１の時間情報と自己が生成する第２の時間情報との同期がとれていなくても、第１の時間情報と第２の時間情報との時間差を検出し、その時間差に応じて第２の時間情報を修正することができる。第１の時間情報と第２の時間情報との間にずれが発生しても、そのずれを修正することができるので、そのずれによる弊害を防止することができる。
【図面の簡単な説明】
【図１】図１（Ａ）はタイムスタンプのずれの発生を示すタイムチャートであり、図１（Ｂ）はタイムスタンプの修正を示すタイムチャートである。
【図２】楽音情報及び画像情報の通信ネットワークを示す図である。
【図３】送信端であるエンコーダー（サーバ）と受信端であるホームコンピュータ（クライアント）の接続を示す図である。
【図４】図４（Ａ）はＭＩＤＩデータパケットの構造を示し、図４（Ｂ）はオーディオデータパケットの構造を示す図である。
【図５】サーバ及びクライアントのハードウエアの構成を示す図である。
【図６】クライアントのＲＡＭを示す図である。
【図７】サーバが行うオーディオデータの処理を示すフローチャートである。
【図８】サーバが行うＭＩＤＩデータの処理を示すフローチャートである。
【図９】サーバが行うタイムスタンプの生成処理を示すフローチャートである。
【図１０】クライアントが行う受信処理を示すフローチャートである。
【図１１】クライアントが行うタイムスタンプの生成処理を示すフローチャートである。
【図１２】クライアントが行う再生処理を示すフローチャートである。
【図１３】クライアントが行うタイムスタンプのずれ検出処理を示すフローチャートである。
【図１４】クライアントが行うタイムスタンプ補正モジュールの処理を示すフローチャートである。
【符号の説明】
１演奏会場、２ＭＩＤＩ楽器、３エンコーダー（サーバ）、４カメラ、５エンコーダー、６ルータ、７サーバ、８ＷＷＷサーバ、９ホームコンピュータ（クライアント）、１０ＭＩＤＩ音源、１１音声出力装置、１２音声入力装置、２１バス、２２ＣＰＵ、２３システムクロック、２４ＲＡＭ、２５外部記憶装置、２６ＭＩＤＩインターフェイス、２７サウンドカード、２７ａバッファ、２７ｂコーデック回路、２８ＲＯＭ、２９表示装置、３０入力手段、３１通信インターフェイス、３２通信ネットワーク、３３コンピュータ、４１タイムスタンプ、４２識別子（ＩＤ）、４３パケットサイズ、４４ＭＩＤＩデータ、４５，４７ＭＩＤＩイベント、４６デルタタイム、４８デジタルオーディオデータ、４９ＭＩＤＩデータパケット、５０オーディオデータパケット、５１ヘッダ、５２フッタ、５３シーケンスナンバ

Claims

演奏データと、該演奏データに付加された該演奏データの処理タイミングに関する第１の時間情報とを外部から受信する受信手段と、
前記第１の時間情報とは非同期な所定の周期でなるシステムクロックと、
前記システムクロックに基づき、前記第１の時間情報とは独立した第２の時間情報を生成する時間情報生成手段と、
前記受信が前記外部からの最初の受信である場合に、前記第２の時間情報を初期化する時間情報初期化手段と、
前記第１の時間情報と第２の時間情報との所定以上の時間差を検出する時間差検出手段と、
前記所定以上の時間差を検出したことに応じて前記第２の時間情報を修正する修正手段と、
前記受信した第１の時間情報と前記生成した第２の時間情報とに基づいて、前記第１の時間情報と前記第２の時間情報との差が所定値に達したときに、前記受信した演奏データを処理する演奏データ処理手段と
を有する通信装置。
さらに、前記時間差検出手段が所定以上の時間差を検出した回数を計測する計測手段を有し、
前記修正手段は、前記計測回数が所定回数に達したときに前記第２の時間情報を修正する請求項１記載の通信装置。
前記計測手段は、前記第１の時間情報に対する前記第２の時間情報の進みまたは遅れ状態に応じて前記回数の値を減少または増加させる請求項２記載の通信装置。
演奏データと、該演奏データに付加された該演奏データの処理タイミングに関する第１の時間情報とを外部から受信する受信工程と、
前記第１の時間情報とは非同期な所定の周期でなるシステムクロックに基づき、前記第１の時間情報とは独立した第２の時間情報を生成する時間情報生成工程と、
前記受信が前記外部からの最初の受信である場合に、前記第２の時間情報を初期化する時間情報初期化工程と、
前記第１の時間情報と第２の時間情報との所定以上の時間差を検出する時間差検出工程と、
前記所定以上の時間差を検出したことに応じて前記第２の時間情報を修正する修正工程と、
前記受信した第１の時間情報と前記生成した第２の時間情報とに基づいて、前記第１の時間情報と前記第２の時間情報との差が所定値に達したときに、前記受信した演奏データを処理する演奏データ処理工程と
を有する通信方法。
さらに、前記時間差検出工程が所定以上の時間差を検出した回数を計測する計測工程を有し、
前記修正工程は、前記計測回数が所定回数に達したときに前記第２の時間情報を修正する請求項４記載の通信方法。
前記計測工程は、前記第１の時間情報に対する前記第２の時間情報の進みまたは遅れ状態に応じて前記回数の値を減少または増加させる請求項５記載の通信方法。