JP2004094683A - サーバ、通信方法及び観客端末 - Google Patents
サーバ、通信方法及び観客端末 Download PDFInfo
- Publication number
- JP2004094683A JP2004094683A JP2002256011A JP2002256011A JP2004094683A JP 2004094683 A JP2004094683 A JP 2004094683A JP 2002256011 A JP2002256011 A JP 2002256011A JP 2002256011 A JP2002256011 A JP 2002256011A JP 2004094683 A JP2004094683 A JP 2004094683A
- Authority
- JP
- Japan
- Prior art keywords
- data
- terminal
- audience
- performance
- voice
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Landscapes
- Reverberation, Karaoke And Other Acoustics (AREA)
- Electrophonic Musical Instruments (AREA)
- Telephonic Communication Services (AREA)
Abstract
【課題】複数の装置から送信される音声データを受信し、これらの音声データをリアルタイムに合成・出力する通信システムにおいて、合成後の音声データを出力する際に、当該合成音声に対する観客の反応をリアルタイムに反映して出力することである。
【解決手段】演者端末２０は、入力される演奏音声のデータを、他の演者端末２０及び管理サーバ１０へ送信するとともに、他の演者端末２０の演奏データ及び観客端末４０の観客データと同期させて出力する。また、観客端末４０は、入力される観客音声のデータを管理サーバ１０へ送信するとともに、管理サーバ１０からストリーミング配信された合奏データを再生する。そして、管理サーバ１０は、各観客端末４０から受信した観客データを各演者端末２０へ配信するとともに、これらの観客データ及び各演者端末２０の演奏データを同期させて合成した合奏データを、観客端末４０へストリーミング配信する。
【選択図】 図１
【解決手段】演者端末２０は、入力される演奏音声のデータを、他の演者端末２０及び管理サーバ１０へ送信するとともに、他の演者端末２０の演奏データ及び観客端末４０の観客データと同期させて出力する。また、観客端末４０は、入力される観客音声のデータを管理サーバ１０へ送信するとともに、管理サーバ１０からストリーミング配信された合奏データを再生する。そして、管理サーバ１０は、各観客端末４０から受信した観客データを各演者端末２０へ配信するとともに、これらの観客データ及び各演者端末２０の演奏データを同期させて合成した合奏データを、観客端末４０へストリーミング配信する。
【選択図】 図１
Description
【０００１】
【発明の属する技術分野】
本発明は、サーバ、通信方法及び観客端末に関する。
【０００２】
【従来の技術】
従来、複数の装置間をネットワークで結び、各装置からの入力音声をリアルタイムに受信するとともに、これらの音声を各装置で再生させる通信システムとして、特開平１１−２１９１７４号公報に開示されているネットワーク演奏システムがある。
【０００３】
このネットワーク演奏システムにおいては、複数の端末装置それぞれが、入力された演奏パート（以下、適宜、単に「パート」という。）の音声データをＭＩＤＩファイルに変換し、インターネットを介してサーバへ送信する。そして、サーバが、各端末装置から受信した各パートの音声データに基づいて合奏データを生成し、各端末装置へ送信している。
【０００４】
【発明が解決しようとする課題】
ところで、上述のような通信システムにおいては、各装置間の距離に起因する時間遅延の問題が発生する。即ち、ネットワークとしてインターネットを利用するといった場合には、各装置間の距離が遠くなるにつれ、物理的な距離や介在するサーバの存在、通信プロトコルといった様々な要因から、受信データの時間遅延の発生は避け難いものとなり、リアルタイムの合奏を行うには不充分である。また、音声データをＭＩＤＩ形式で送信する方法では、楽曲１曲分の音声データをまとめてＭＩＤＩファイルとする必要上、リアルタイムの合奏はさらに困難になる。
【０００５】
また、演奏に参加している端末装置のみを合奏データの送信対象としているため、実際のライブ演奏のように、より多くの観客の前で演奏したい、観客の反応をリアルタイムに反映させることができなかった。
【０００６】
本発明の課題は、複数の装置から送信される音声データを同期して合成し、その合成された音声データを観客に送信できるようにすることである。
【０００７】
【課題を解決するための手段】
上記課題を解決するために、請求項１記載の発明は、
複数の演者端末複数と観客端末とに通信接続されたサーバ（例えば、図１の管理サーバ１０）において、
音声データ及び予め定められている同期調整データ（例えば、図４の送信端末識別番号及びパケット番号）を含む通信データを、前記複数の演者端末それぞれから受信する第１受信手段（例えば、図７の通信装置１４、図１５のステップＳ２７、図１９のステップＳ２１１〜Ｓ２１６）と、
この第１受信手段により受信された複数の通信データそれぞれに含まれる音声データを、当該通信データに含まれる同期調整データに従って同期して合成し、合成音声データを作成する合成音声作成手段（例えば、図７の管理サーバ；ＣＰＵ１１、図２２のステップＳ２４１〜Ｓ２４８）と、
この合成音声作成手段により作成された合成音声データを、前記観客端末に送信する合成音声送信手段（例えば、図７の通信装置１４、図２２のステップＳ２４９）と、
を備えることを特徴としている。
【０００８】
また、請求項５記載の発明は、
複数の演者端末と観客端末とに通信接続されたサーバにおける通信方法であって、
音声データ及び予め定められている同期調整データを含む通信データを、前記複数の演者端末それぞれから受信する第１受信工程（例えば、図１９のステップＳ２１１〜Ｓ２１６）と、
この第１受信工程において受信された複数の通信データそれぞれに含まれる音声データを、当該通信データに含まれる同期調整データに従って同期して合成し、合成音声データを作成する合成音声作成工程（例えば、図２２のステップＳ２４１〜Ｓ２４８）と、
この合成音声作成工程にて作成された合成音声データを、前記観客端末に送信する合成音声送信工程（例えば、図２２のステップＳ２４９）と、
を含むことを特徴としている。
【０００９】
この請求項１又は５記載の発明によれば、各演者端末から受信した音声データを、それぞれに対応する同期調整データに基づいて同期させた合成音声データを作成するとともに、作成した合成音声データを観客端末に配信することができる。従って、各演者端末の間の距離に影響されることなく、リアルタイムな合成音声の再生を実現することができる。
【００１０】
また、請求項２記載の発明のように、
請求項１記載のサーバにおいて、
前記観客端末から音声データを受信する第２受信手段（例えば、図７の通信装置１４；図２０のステップＳ２２１〜Ｓ２２５）を更に備え、
前記合成音声作成手段は、前記第１受信手段により受信される複数の通信データそれぞれに含まれる音声データを同期して合成するとともに、前記第２受信手段により受信された音声データを更に合成することにより、合成音声データを作成することとしても良い。
【００１１】
この請求項２記載の発明によれば、演者端末より受信した音声データに、観客端末より受信した音声データを、更に合成した音声合成データを作成し、観客端末に送信することができる。従って、例えば複数の演者端末にて入力された演奏音声をリアルタイムに合成しつつ、合奏音声として出力するネットワーク演奏システムで観客は、合奏に対する自身の反応が反映された合奏音声を聴くことができ、実際のライブ演奏のように、観客として参加しているかのような状態を体験することができる。
【００１２】
また、請求項３記載の発明のように、
請求項１又は２に記載のサーバにおいて、
前記観客端末から音声データを受信する第２受信手段（例えば、図７の通信装置１４；図２０のステップＳ２２１〜Ｓ２２５）と、
この第２受信手段により受信された音声データに、予め定められている同期調整データを付加して通信データを作成する作成手段（例えば、図７の管理サーバ；ＣＰＵ１１；２０のステップＳ２３１〜Ｓ２３８）と、
この作成手段により作成された通信データを、前記複数の演者端末それぞれに送信する送信手段（例えば、図７の通信装置１４；図２１のステップＳ２３９）と、
を更に備えることとしても良い。
【００１３】
この請求項３記載の発明によれば、観客端末より受信した音声データに、同期調整データを付加し、演者端末に送信することができる。即ち、演者端末においては、観客端末が発信した音声データを、上記合成音声データと同期させて再生することができる。従って、例えば演奏者は、複数の演者端末にて入力された演奏音声をリアルタイムに聴くことができるとともに、当該合奏に対する観客の反応をリアルタイムに聴くことができる。このため、実際のライブ演奏のように、多くの観客の前で演奏しているかのような状態を体験することができる。
【００１４】
尚ここで、請求項４に記載の発明のように、請求項２又は３に記載のサーバにおいて、前記合成音声作成手段は、前記第１受信手段により受信された音声データの合成を、前記第２受信手段により受信された音声データの合成に優先して実行する（例えば、図１８のステップＳ２０２〜Ｓ２０５）こととしても良い。
【００１５】
この請求項４に記載の発明によれば、演者端末から受信した音声データに対する処理を、観客端末から受信した音声データに対する処理に優先して実行することができる。従って、観客端末から受信した音声データの多少に関わらず、演者端末から受信した音声データを、遅延無く且つ正確に同期して合成した合成音声データを生成することができる。
【００１６】
また、請求項６記載の発明は、
請求項２〜４の何れか一項に記載のサーバに通信接続された観客端末（例えば、図１の観客端末４０）であって、
音声入力手段（例えば、図１４のマルチプレクサ４６に接続されるマイクロフォン）と、
前記サーバから送信される合成音声データを受信する合成音声受信手段（例えば、図１４の通信装置５３：図２７のステップＳ４２１〜Ｓ４２８）と、
この合成音声受信手段により受信された合成音声データを再生する再生手段（例えば、図１４の観客端末；ＣＰＵ４１及び観客端末；ＤＳＰ４２；図２７のステップＳ４２９〜Ｓ４３１）と、
この再生手段による再生の際に、前記音声入力手段により入力された音声を音声データとして前記サーバに送信する音声送信手段（例えば、図１４の通信装置５３；図６（ｃ）のステップＣ１〜Ｃ２、図２６のステップＳ４０１〜Ｓ４１１）と、
を備えることを特徴としている。
【００１７】
この請求項６記載の発明によれば、サーバから受信した合成音声データを再生するとともに、入力された音声の音声データをサーバに送信することができる。従って、例えば利用者は、複数の演者端末にて入力された演奏音声をリアルタイムに聴くことができるとともに、合奏に対する自身の反応がリアルタイムに反映された合奏音声を聴くことができる。このため、実際のライブ演奏のように、観客として参加しているかのような状態を体験することができる。
【００１８】
また、請求項７記載の発明は、請求項１記載のサーバであって、
前記合成音声送信手段によって送信された合成音声データの前記観客端末での再生の際に、前記観客端末において入力された観客音声データを受信する観客音声データ受信手段（例えば、図７の通信装置１４、図７の管理サーバ；ＣＰＵ１１、図６（ｂ）のステップＡ１、図２０の観客データ受信処理）と、
この観客音声データ受信手段により受信された観客音声データと、前記合成音声作成手段により合成された合成音声データとをさらに合成する観客音声データ合成手段（例えば、図７の管理サーバ；ＣＰＵ１１、管理サーバ；ＤＳＰ２１、図２１のステップＳ２３１〜Ｓ２３８、図２２のステップＳ２４１〜Ｓ２４４８）と、
をさらに備えることを特徴としている。
【００１９】
この請求項７記載の発明によれば、観客端末で合成音声データが再生される際に、当該観客端末から入力される観客音声データと、合成音声データとを更に合成することができる。従って、演奏音声と、その演奏音声に反応した観客の音声とが重畳するように合成されるため、例えば、合成された音声データを再生することにより、ライブの臨場感を得ることができる。
【００２０】
【発明の実施の形態】
以下、図面を参照し、発明の実施の形態を詳細に説明する。尚、以下においては、本発明を適用した演奏システムを例にとって説明するが、本発明の適用はこれに限らない。
【００２１】
ここで演奏システムとは、インターネットを介して接続された複数の演者端末が、それぞれに割り当てられたパートで、同時にある曲目の演奏（即ち、合奏）を行うシステムである。この時、演者端末においては、利用者によって入力されたパートの演奏音声と、他の演者端末において入力されたパートの演奏音声と、インターネットを介して接続された観客端末において入力された、拍手や歓声等の観客音声とが合成された合奏音声が、出力される。尚、各演者端末に割り当てるパートは、それぞれ異なるものであっても良いし、複数の演者端末で同一のパートを割り当てることとしても良い。
【００２２】
図１は、本実施の形態における演奏システム１の構成を示す図である。
同図によれば、演奏システム１は、管理サーバ１０、複数の演者端末２０及び複数の観客端末４０より構成される。そして、これらの機器は、インターネットＮに接続されている。尚、同図においては、３台の演者端末２０及び２台の観客端末４０が示されているが、勿論、これは何台であっても構わない。
【００２３】
管理サーバ１０は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）、記憶装置、通信装置等がシステムバスを介して接続される周知のサーバ装置により実現される。また、管理サーバ１０は、Ｗｅｂページ用ファイルを提供するＷｅｂサーバ機能、ストリーミングデータを配信するストリーミングサーバ機能及び各種データを複数機器に同時配信するマルチキャストサーバ機能を有している。尚、管理サーバ１０を複数のサーバ装置とし、それぞれが各サーバ機能を分担することとしても良い。
【００２４】
演者端末２０及び観客端末４０は、ＣＰＵ、ＲＡＭ、記憶装置、入力装置、表示装置、通信装置等がシステムバスを介して接続される、周知のＰＣ（ＰｅｒｓｏｎａｌＣｏｍｐｕｔｅｒ）により実現される。また、観客端末４０には、配信されるストリーミングデータを再生するためのストリーミング再生ソフトが、インストールされている。
【００２５】
図２は、演奏システム１における各機器の間のデータの流れを示す図である。同図（ａ）は、合奏前の様子を、同図（ｂ）は、合奏中の様子を、それぞれ示している。尚、これらのデータは、適宜暗号化され、インターネットＮを介して送受信される。
【００２６】
同図（ａ）によれば、演者端末２０は、利用者の指示入力に応じた演奏条件データを、管理サーバ１０へ送信する。この演奏条件データには、利用者が演奏を希望する曲目、パート及び日時のデータが含まれる。従って、管理サーバ１０は、各演者端末２０から送信される演奏条件データを受信する（図２（ａ）中▲１▼）。
【００２７】
また、管理サーバ１０は、これらの演奏条件データに基づき、合奏に参加する演者端末２０を特定する。そして、特定した各演者端末２０に対して、当該合奏の予定を示す合奏予定データを送信する。この合奏予定データには、当該合奏を予定する日時、曲目及び参加する演者端末２０を示すデータが含まれている。従って、合奏に参加予定の各演者端末２０は、管理サーバ１０から送信される合奏予定データを受信する（図２（ａ）中▲２▼）。
【００２８】
また、管理サーバ１０は、観客端末４０の要求に応じて、現在予定されている全ての合奏に関する合奏予定データを送信する。従って、観客端末４０は、管理サーバ１０から送信される合奏予定データを受信する（同図（ａ）中▲３▼）。
【００２９】
また、観客端末４０は、上記受信した合奏予定データに基づき、利用者の指示入力に応じた参加予定データを、管理サーバ１０へ送信する。この参加予定データには、上記現在予定されている全ての合奏の内、観客端末４０の利用者が観客として参加を希望する合奏を指定するデータが含まれている。従って、管理サーバ１０は、各観客端末４０から送信される参加予定データを受信する（図（ａ）中▲４▼）。
【００３０】
一方、同図（ｂ）によれば、合奏が予定された日時となると、管理サーバ１０は、当該合奏に参加予定の演者端末２０及び観客端末４０それぞれに対して、演奏開始を指示する（同図（ｂ）中▲１▼）。
【００３１】
そして、管理サーバ１０から演奏開始が指示された演者端末２０は、先に受信した合奏予定データに基づき、当該合奏に参加する他の演者端末２０との演奏データ（利用者により入力された演奏音声のデータ）の送受信を行うとともに、管理サーバ１０から送信される合成観客データを受信し、合奏を実現する（同図（ｂ）中▲２▼、▲３▼）。具体的には、演者端末２０は、利用者により入力された演奏音声に応じた演奏データと、他の演者端末２０より受信した演奏データと、管理サーバ１０から受信した合成観客データとを合成し、合奏音声として出力する。
【００３２】
また、管理サーバ１０から演奏開始が指示された観客端末４０は、利用者により入力された観客音声のデータ（以下、適宜「観客データ」という。）を、管理サーバ１０へ送信する。それとともに、管理サーバ１０からストリーミング配信される合奏データを受信し、この合奏データに基づく合奏音声を出力する（同図（ｂ）中▲４▼、▲５▼）。
【００３３】
一方、管理サーバ１０は、各観客端末４０から受信した観客データを合成し、合成観客データとして各演者端末２０へ送信する（同図（ｂ）中▲３▼）。それととともに、各演者端末２０から受信した演奏データと、上記合成観客データとを合成し、合奏データとして、各観客端末４０へストリーミング配信する（同図（ｂ）中▲４▼）。
【００３４】
また、本実施の形態においては、通信プロトコルとして、ＵＤＰ／ＩＰが採用されている。即ち、インターネットＮを経由した管理サーバ１０、演者端末２０及び観客端末４０の間のデータ通信は、各機器に割り当てられたＩＰアドレスに基づくＩＰパケットの送受信によって、実現される。
【００３５】
具体的には、合奏中における各種データの送受信（同図（ｂ）参照）は、マルチキャストＩＰアドレス、詳細には、合奏に参加している演者端末２０をグループ化した演者用マルチキャストＩＰアドレス及び当該合奏に観客として参加している観客端末４０をグループ化した観客用マルチキャストＩＰアドレスに基づき、実現される。
【００３６】
即ち、演者端末２０は、当該演者端末２０自身の演奏データを、演者用マルチキャストＩＰアドレス宛に送信する。そして、管理サーバ１０は、この演者用マルチキャストＩＰアドレス宛に送信された演奏データを、当該演者用マルチキャストＩＰアドレスによってグループ化された他の演者端末２０へ一斉配信する（同図（ｂ）中▲２▼）。
【００３７】
また、管理サーバ１０は、合成観客データを、演者用マルチキャストＩＰアドレスによってグループ化された各演者端末２０へ一斉配信するとともに（同図（ｂ）中▲３▼）、合奏データを、観客用マルチキャストＩＰアドレスによってグループ化された観客端末４０へ一斉配信する（同図（ｂ）中▲４▼）。
【００３８】
図３は、ＩＰパケットに含まれるＩＰヘッダのフォーマットを示す図である。同図によれば、ＩＰヘッダは、準拠しているＩＰ規格のバージョン（即ち“６”）、当該ＩＰパケットの優先度、通信帯域の予約を保証するためのフローラベル、実データの大きさを示すペイロード長、後続ヘッダのＩＤを示すネクストヘッダ、ルータによる中継限界数を示すホップリミット、送信元の機器のＩＰアドレスを示す送信元ＩＰアドレス及び宛先の機器のＩＰアドレスを示す宛先ＩＰアドレスより構成される。
【００３９】
また、図４は、ＩＰパケットに含まれる実データ（ペイロード部）のデータ構成を示す図である。尚、同図においては、合奏時に管理サーバ１０と演者端末２０との間で送受信される演奏データについてのデータ構成を示している。
同図によれば、ＩＰパケットに含まれる実データは、指示ヘッダ及び音声データより構成される。
【００４０】
指示ヘッダには、データ識別、送信元の機器を示す送信端末識別番号、上記送信元の機器から送信された何番目のＩＰパケットであるかを示すパケット番号、音声データの記録方式（符号化方式）を示す音声記録方式（即ち、“ＰＣＭ”）、その際のパラメータであるサンプリングレート（サンプリング周波数）、ビット数（量子化ビット数）、ビットレート、そして音声データに対するエフェクトを示すエフェクト条件が含まれている。
【００４１】
ここで、送信端末識別番号及びパケット番号を合わせて、「同期調整データ」という。この同期調整データは、後述のように、演奏データを同期合成するために用いられる。
【００４２】
データ識別とは、演奏システム１で送受信される当該ＩＰパケットの種類を示すものであり、具体的には、“演奏データ”であるか否かを示す。
【００４３】
エフェクトとは、音声データに対して付加する音響効果を意味しており、例えば、エコーやリバーブ（残響）、トーンコントロールの度合、音量バランスの変更、ステレオ化の有無等が該当する。
【００４４】
また、音声データは、アナログ信号である演奏音声を、ＰＣＭ（Ｐｕｌｓｅ Ｃｏｄｅ Ｍｏｄｕｌａｔｉｏｎ）方式によってデジタル信号に変換したデータであり、１つのＩＰパケットにつき、５１２サンプリング分のデータが含まれる。即ち、演奏データは、管理サーバ１０と演者端末２０との間で、５１２サンプリング分を単位としてやり取りされる。以下、この１パケット分（即ち、５１２サンプリング分）の音声データを、適宜「音声データパケット」という。
【００４５】
一方、合奏時に管理サーバ１０と観客端末４０との間で送受信される観客データ及び合奏データについては、次の点で上記演奏データと異なる。即ち、音声データには、１つのＩＰパケットにつき、１０２４サンプリング分のデータが含まれる。また、この音声データは、ＭＰ３方式に従って圧縮・符号化されたデータである。即ち、観客データ及び合奏データは、管理サーバ１０と観客端末４０との間で、１０２４サンプリング分を単位としてやり取りされる。以下、この１パケット分（即ち、１０２４サンプリング分）の音声データについて、適宜「音声データパケット」という。
【００４６】
図５は、演奏システム１における通信プロトコルのスタックを示す図である。同図によれば、通信プロトコルは、下位層から順に、イーサネット（登録商標）層（ＰＰＰｏｖｅｒＥｔｈｅｒ）、ＩＰ層（ネットワーク層）、ＵＤＰ層（トランスポート層）及びアプリケーション層（ＡＰＩを含む）より構成される。
【００４７】
即ち、ある機器が他の機器から受信したＩＰパケットは、イーサネット（登録商標）層を介してＩＰ層へ渡され、このＩＰ層にて、暗号解読処理がなされる。その後、ＵＤＰ層を経由して、アプリケーション層に渡される。アプリケーション層では、ＩＰパケットの実データに含まれる音声データが、音声データパケットとして、指示ヘッダとともに抜き出される。
【００４８】
また、利用者により入力された演奏音声や観客音声等の音声データは、アプリケーション層において音声データパケットに変換され、続いて、ＵＤＰ層、ＩＰ層へ渡される。そして、ＩＰ層にて暗号化処理がなされるとともに、ＩＰパケット化される。生成されたＩＰパケットは、イーサネット（登録商標）層を経由し、外部の他の機器へ送信される。
【００４９】
ここで、ＩＰ層にて実現されるデータの暗号／復号化について説明する。
暗号化とは、インターネット等のネットワークを通じて文書や画像等のデジタルデータをやりとりする際に、通信途中で第三者に盗み見られたり改ざんされることを防ぐため、予め定められた規則に従ってデータを変換し、解読が極めて困難な状態にすることである。そして、暗号化されたデータを元に戻し、解読可能な状態にすることを復号化という。
【００５０】
また、一般に、暗号／復号化には、暗号表にあたる「鍵」を使用するが、対になる２つの鍵を使う公開鍵暗号方式と、どちらにも同じ鍵を用いる共通鍵暗号方式とがある。前者にはＲＳＡ、ＥｌＧａｍａｌ暗号、楕円曲線暗号等があり、後者には米国政府標準のＤＥＳやＩＤＥＡ、ＦＥＡＬ、ＭＩＳＴＹ等があり、本実施の形態では上記の何れを使うこととしても良い。
【００５１】
次に、管理サーバ１０、演者端末２０及び観客端末４０の内部構成について、図７〜図１４を参照して説明する。
【００５２】
図７は、管理サーバの構成を示すブロック図である。
同図によれば、管理サーバ１０は、管理サーバ；ＣＰＵ１１、記憶装置１２、ＲＡＭ１３及び通信装置１４により構成され、各部は、システムバス１５によりデータ通信可能に接続されている。
【００５３】
管理サーバ；ＣＰＵ１１は、記憶装置１２に記憶される各種処理プログラムに基づいて、管理サーバ１０を構成する各部を集中制御する。具体的には、通信装置１４から入力される信号に応答して、記憶装置１２に記憶されている処理プログラムを読み出してＲＡＭ１３に一時記憶させるとともに、係る処理プログラムに基づく処理を実行して、管理サーバ１０を機能させる。その際、管理サーバ；ＣＰＵ１１は、処理結果をＲＡＭ１３内の所定領域に格納するとともに、必要に応じて、その処理結果を通信装置１４から外部機器へ送信する。
【００５４】
また、管理サーバ；ＣＰＵ１１は、本実施の形態の特徴的な処理として、後述する合奏処理（図１５参照）、データ受信処理（図１８参照）、演奏データ受信処理（図１９参照）、観客データ受信処理（図２０参照）、合成観客データ送信処理（図２１参照）及び合奏データ生成処理（図２２参照）を実行する。
【００５５】
具体的には、合奏処理において、管理サーバ；ＣＰＵ１１は、演者端末２０から送信される演奏条件データを受信すると、受信した演奏条件データを、ＲＡＭ１３内の演奏条件データ格納領域１３ａに格納する。そして、この演奏条件データに適合するデータを、演奏条件データ格納領域１３ａに格納されているデータの内から検索し、合奏に参加可能な演者端末２０を特定する。
【００５６】
それとともに、管理サーバ；ＣＰＵ１１は、上記特定した演者端末２０をグループ化した演者用マルチキャストＩＰアドレス及び観客として参加することとなる観客端末４０をグループ化する観客用マルチキャストＩＰアドレスを設定する。
【００５７】
そして、これら設定した演者用マルチキャストＩＰアドレス及び観客用マルチキャストＩＰアドレスを含む合奏予定データを、ＲＡＭ１３内の合奏予定データ格納領域１３ｂに格納するとともに、上記特定した各演者端末２０に対して、この合奏予定データを送信する。
【００５８】
また、管理サーバ；ＣＰＵ１１は、観客端末４０の要求に応じ、合奏予定データ格納領域１３ｂに格納されている合奏予定データを、当該観客端末４０に送信するとともに、観客端末４０から送信される参加予定データを受信し、受信した参加予定データを、合奏予定データ格納領域１３ｂに格納する。
【００５９】
更に、管理サーバ；ＣＰＵ１１は、合奏を予定している日時の所定時間前となると、当該合奏に参加予定の演者端末２０及び観客端末４０に対して、演奏開始を指示する。
【００６０】
データ受信処理において、管理サーバ；ＣＰＵ１１は、受信したデータ、即ち入力されたＩＰパケットが演奏データであるか観客データであるかを判定するとともに、演奏データであると判定した場合には、観客データ受信処理（図２０参照）に優先して演奏データ受信処理（図１９参照）を実行する。
【００６１】
演奏データ受信処理において、管理サーバ；ＣＰＵ１１は、各演者端末２０から受信した演奏データ、即ちＩＰパケットから５１２サンプリング分の音声データを抜き出し、所定の音響効果処理を行った後、送信元である演者端末２０毎に、演奏データバッファ１３ｃに格納する。
【００６２】
観客データ受信処理において、管理サーバ；ＣＰＵ１１は、各観客端末４０から受信した観客データ、即ちＩＰパケットから１０２４サンプリング分の音声データを抜き出し、ＭＰ３フォーマットからＰＣＭフォーマットに変換した後、観客データバッファ１３ｄに格納する。
【００６３】
合成観客データ送信処理において、管理サーバ；ＣＰＵ１１は、所定時間毎に、観客データバッファ１３ｄに格納されている音声データパケットを読み出して音合成した後、所定の音響効果処理を行う。そして、この合成後の音声データパケットを、合成観客データバッファ１３ｅに格納するとともにＩＰパケット化し、合成観客データとして、各演者端末２０へ送信する。
【００６４】
また、合奏データ生成処理において、管理サーバ；ＣＰＵ１１は、演奏データバッファ１３ｃに格納されている音声データパケットの内、所定のパケット番号のものを全て読み出して音合成（同期合成）する。それとともに、合成観客データバッファ１３ｅに格納されている音声データパケットを読み出して、上記同期合成後の音声データパケットと音合成する。そして、この合成後の音声データパケットをＩＰパケット化し、合奏データとして、各観客端末４０へ送信する。
【００６５】
図８は、管理サーバ；ＣＰＵ１１が、演奏データに対して行う処理の概念を示す図である。尚、同図においては、管理サーバ１０が、３台の他の演者端末２０（以下、それぞれを、適宜「演者端末Ａ」、「演者端末Ｂ」及び「演者端末Ｂ」という。）から送信される演奏データを受信する場合について、示している。
【００６６】
管理サーバ１０が受信する演奏データは、上述のように、ＩＰパケットとして管理サーバ；ＣＰＵ１１へ入力される。同図においては、このＩＰパケットを簡略し、送信端末識別番号とパケット番号とから構成される同期調整データ及び音声データのみで表しているともに、管理サーバ；ＣＰＵ１１への入力順に、図中左より示している。
【００６７】
また、送信端末識別番号“Ａ”は演者端末Ａを、送信端末識別番号“Ｂ”は演者端末Ｂを、そして送信端末識別番号“Ｃ”は送信端末Ｃを、それぞれ示している。
【００６８】
そして、音声データ“データＡｈ”は、演者端末Ａから受信したパケット番号“ｈ”のＩＰパケットの音声データパケットを、音声データ“データＢｉ”は、演者端末Ｂから受信したパケット番号“ｉ”のＩＰパケットの音声データパケットを、そして音声データ“データＣｊ”は、演者端末Ｃより受信したパケット番号“ｊ”のＩＰパケットの音声データパケットを、それぞれ示している。
【００６９】
同図（ａ）によれば、管理サーバ；ＣＰＵ１１は、入力されたＩＰパケットから音声データを抜き出す。そして、この音声データを１つの音声データパケットとし、付加されている端末識別番号に従って送信元の演者端末２０毎に振り分けるとともに、パケット番号に従って並べ替える。即ち、同図（ａ）においては、図中上から、演者端末Ａ、Ｂ、Ｃの順に振り分けた様子を示している。
【００７０】
次いで、同図（ｂ）によれば、管理サーバ；ＣＰＵ１１は、これらの音声データパケットそれぞれに対し、指定されたエフェクト条件に基づいた音響効果処理を行う。即ち、エコーやリバーブ、トーンコントロール等のエフェクトを、指定された度合で付加するとともに、指定されたＬ／Ｒ比のステレオデータに変換する。
【００７１】
例えば、音声データ“データＡ０”に対し、所定のエフェクトを付加するとともに、指定されたＬ／Ｒ比のステレオデータ、即ちＬチャネルの音声データ“データＡ０Ｌ”及びＲチャネルの音声データ“データＡ０Ｒ”を生成する。
【００７２】
また、音声データ“データＢ０”及び“データＣ０”についても同様に、所定のエフェクトを付加し、指定されたＬ／Ｒ比で、Ｌチャネルの音声データ“データＢ０Ｌ”及び“データＣ０Ｌ”、そしてＲチャネルの音声データ“データＢ０Ｒ”及び“データＣ０Ｒ”を、それぞれ生成する。
【００７３】
その後、同図（ｃ）によれば、管理サーバ；ＣＰＵ１１は、これらの音声データパケットを合成し、合成演奏データを生成する。具体的には、これらの音声データパケットの内、パケット番号が同一のもの同士を、チャネル毎に合成する。
【００７４】
例えば、パケット番号“０”については、音声データ“データＡ０Ｌ”、“データＢ０Ｌ”及び“データＣ０Ｌ”を合成し、Ｌチャネルの音声データ“データＡ０Ｌ＋Ｂ０Ｌ＋Ｃ０Ｌ”を生成するとともに、音声データ“データＡ０Ｒ”、“データＢ０Ｒ”及び“データＣ０Ｌ”を合成し、Ｒチャネルの音声データ“データＡ０Ｒ＋Ｂ０Ｒ＋Ｃ０Ｒ”を生成する。
【００７５】
また、パケット番号“１”についても同様に、音声データ“データＡ１Ｌ”、“データＢ１Ｌ”及び“データＣ１Ｌ”を合成し、Ｌチャネルの音声データ“データＡ１Ｌ＋Ｂ１Ｌ＋Ｃ１Ｌ”を生成するとともに、音声データ“データＡ１Ｒ”、“データＢ１Ｒ”及び“データＣ１Ｒ”を合成し、Ｒチャネルの音声データ“データＡ１Ｒ＋Ｂ１Ｒ＋Ｃ１Ｒ”を生成する。
【００７６】
図９は、管理サーバ；ＣＰＵ１１が、観客データに対して行う処理の概念を示す図である。尚、同図においては、管理サーバ１０が、２台の観客端末４０（以下、それぞれを、適宜「観客端末ａ」及び「観客端末ｂ」という。）から送信される観客データを受信する場合について、示している。
【００７７】
管理サーバ１０が受信する観客データは、上述のように、ＩＰパケットとして管理サーバ；ＣＰＵ１１へ入力される。同図においては、このＩＰパケットを簡略し、音声データのみで表しているとともに、管理サーバ；ＣＰＵ１１への入力順に、図中左より示している。
【００７８】
また、音声データ“データａｈ”は、観客端末ａから受信したｈ番目の音声データパケットを、そして、音声データ“データｂｉ”は、観客端末ｂから受信したｉ番目の音声データパケットを、それぞれ示している。
【００７９】
同図（ａ）によれば、管理サーバ；ＣＰＵ１１は、所定時間の間に入力されたＩＰパケットそれぞれから音声データを抜き出すとともに、これらの音声データを１組のデータとする。即ち、同図（ａ）においては、音声データ“データａ０”及び“データａ１”を１組に、音声データ“データｂ０”、“データｂ２”及び“データａ２”を１組とした様子を示している。
【００８０】
次いで、同図（ｂ）によれば、管理サーバ；ＣＰＵ１１は、これらの音声データパケットを、上記組毎に合成する。即ち、音声データ“データａ０”及び“データａ１”を合成し、音声データ“データａ０＋ａ１”を生成する。また、音声データ“データｂ０”、“データｂ２”及び“データａ２”を合成し、音声データ“データｂ０＋ｂ２＋ａ２”を生成する。
【００８１】
その後、同図（ｃ）によれば、管理サーバ；ＣＰＵ１１は、合成後の音声データパケットそれぞれに対し、指定されたエフェクト条件に基づいた音響効果処理を行い、合成観客データを生成する。即ち、エコーやリバーブ、トーンコントロール等のエフェクトを、指定された度合で付加するとともに、指定されたＬ／Ｒ比のステレオデータに変換する。
【００８２】
例えば、音声データ“データａ０＋ａ１”に対し、所定のエフェクトを付加するとともに、指定されたＬ／Ｒ比のステレオデータ、即ち、Ｌチャネルの音声データ“データａ０Ｌ＋ａ１Ｌ”及びＲチャネルの音声データ“データａ０Ｒ＋ａ１Ｒ”を生成する。
【００８３】
また、音声データ“データｂ１＋ｂ２＋ａ２”についても同様に、所定のエフェクトを付加し、指定されたＬ／Ｒ比で、Ｌチャネルの音声データ“データｂ１Ｌ＋ｂ２Ｌ＋ａ２Ｌ”及びＲチャネルの音声データ“データｂ１Ｒ＋ｂ２Ｒ＋ａ２Ｒ”を生成する。
【００８４】
このように、各演奏データを合成した合成演奏データ（即ち、図８（ｃ）の状態）及び各観客データを合成した合成観客データ（即ち、図９（ｃ）の状態）を生成すると、管理サーバ；ＣＰＵ１１は、生成した合成観客データを演者端末２０へ送信する。それとともに、上記合成演奏データ及び合成観客データを合成して合奏データを生成し、観客端末４０へ送信する。
【００８５】
図７において、記憶装置１２は、ハードディスク等により構成されるものであり、管理サーバ１０の動作に係る各種処理プログラムや、本実施の形態の機能を実現するためのプログラム（具体的には、合奏プログラム１２ａ、データ受信プログラム１２ｂ、演奏データ受信プログラム１２ｃ、観客データ受信プログラム１２ｄ、合成観客データ送信プログラム１２ｅ及び合奏データ生成プログラム１２ｆ）及びこれらのプログラムの実行に係る処理データ等を記憶する。
【００８６】
ＲＡＭ１３は、管理サーバ；ＣＰＵ１１により実行される各プログラムを実行するためのプログラムエリア（不図示）、入力指示や入力データ、上記プログラムが実行される際に生じる処理結果等を一時的に格納するワークメモリエリアを備えている。また、このワークメモリエリアには、演奏条件データ格納領域１３ａ、合奏予定データ格納領域１３ｂ、演奏データバッファ１３ｃ、観客データバッファ１３ｄ及び合成観客データバッファ１３ｅが形成される。
【００８７】
演奏条件データ格納領域１３ａは、演者端末２０から受信した演奏条件データが格納される領域であり、図１０に、そのデータ構成を示す。
図１０は、演奏条件データ格納領域１３ａに格納されるデータの構成を示す図である。
同図によれば、演奏条件データ格納領域１３ａには、演奏を希望する曲目、パート及び日時を含む演奏条件とＩＰアドレスとが対応付けて格納される。また、この演奏条件は、演者端末２０から受信した演奏条件データに該当する。
【００８８】
即ち、演奏条件データ格納領域１３ａには、演者端末２０から演奏条件データ及びＩＰアドレスを受信する毎に、これらのデータが対応付けられて追加格納される。そして、管理サーバ；ＣＰＵ１１により互いに適合するものが検索され、合奏予定データが生成されると、該当するデータが、演奏条件データ格納領域１３ａから削除される。
【００８９】
合奏予定データ格納領域１３ｂは、合奏予定データが格納される領域であり、図１１に、そのデータ構成を示す。
図１１は、合奏予定データ格納領域に格納されるデータの構成を示す図である。
同図によれば、合奏予定データ格納領域１３ｂには、予定している合奏毎に、日時、曲目、各パートに割り当てられた演者端末２０のＩＰアドレス、演者用マルチキャストＩＰアドレス、観客として参加予定の観客端末４０のＩＰアドレス及び観客用マルチキャストＩＰアドレスが、対応付けて格納される。
【００９０】
即ち、観客端末４０から演奏予定データを受信する毎に、ともに受信したＩＰアドレスが、該当する観客端末４０のＩＰアドレスとして追加格納される。また、これらのデータは、合奏を予定する日時が現在時刻に近い順に格納されている。
【００９１】
演奏データバッファ１３ｃは、演者端末２０から受信した演奏データが格納される領域である。具体的には、図８（ｂ）に示すように、送信元の演者端末２０毎に、管理サーバ；ＣＰＵ１１によって音響効果処理が行われた音声データパケットが、パケット番号に従って格納される。
【００９２】
観客データバッファ１３ｄは、観客端末４０から受信した観客データが格納される領域である。具体的には、図９（ａ）に示すように、送受信した音声データパケットが、その受信順に格納される。
【００９３】
合成観客データバッファ１３ｅは、合成観客データが格納される領域である。具体的には、図９（ｃ）に示すように、管理サーバ；ＣＰＵ１１によって音響効果処理が行われた音声データパケットが、その生成順に格納される。
【００９４】
図７において、通信装置１４は、インターネットＮを介して他の機器とのデータ通信を行うためのインターフェースであり、ルータ等により構成される
【００９５】
図１２は、演者端末２０の構成を示すブロック図である。
同図によれば演者端末２０は、演者端末；ＣＰＵ２１、演者端末；ＤＳＰ２２、記憶装置２３、ＲＡＭ２４、入力装置２５、マルチプレクサ２６、サンプルホールド回路２７、Ａ／Ｄ（Ａｎａｌｏｇ−Ｄｉｇｉｔａｌ）変換回路２８、Ｄ／Ａ（Ｄｉｇｉｔａｌ−Ａｎａｌｏｇ）変換回路２９、アンプ３０、表示駆動回路３１、表示装置３２及び通信装置３３より構成される。
【００９６】
演者端末；ＣＰＵ２１は、記憶装置２３に記憶される各種処理プログラムに基づいて、演者端末２０を構成する各部を集中制御する。具体的には、入力装置２５、或いは通信装置３３から入力される信号に応答して、記憶装置２３に記憶されている処理プログラムを読み出してＲＡＭ２４に一時記憶させるとともに、係る処理プログラムに基づく処理を実行して、演者端末２０を機能させる。その際、演者端末；ＣＰＵ２１は、処理結果をＲＡＭ２４内の所定領域に格納するとともに、必要に応じて、その処理結果を、表示装置３２に表示するとともに、通信装置３３から外部機器へ送信する。
【００９７】
また、演者端末；ＣＰＵ２１は、本実施の形態の特徴的な処理として、後述する合奏処理（図１５参照）、リンク確立処理処理（図１７参照）演奏データ送信処理（図２３参照）及び演奏／合成観客データ受信処理（図２４参照）を実行する。
【００９８】
具体的には、合奏処理において、演者端末；ＣＰＵ２１は、利用者の入力指示に応じた演奏条件データを、当該演者端末２０のＩＰアドレスとともに、管理サーバ１０へ送信する。それとともに、管理サーバ１０から送信される合奏予定データを受信する。
【００９９】
そして、管理サーバ１０より演奏開始を指示されると、演者端末；ＣＰＵ２１は、リンク確立処理、次いで演奏処理を実行する。また、この演奏処理において、演者端末；ＣＰＵ２１は、演奏データ送信処理（図２３参照）、及び演奏／合成観客データ受信処理（図２４参照）を実行するともに、演者端末；ＤＳＰ２２に、後述する演奏データ送信処理（図２３参照）、演奏／合成観客データ受信処理（図２４参照）及び合奏音声出力処理（図２５参照）を実行させる。
【０１００】
リンク確立処理において、演者端末；ＣＰＵ２１は、管理サーバ１０から受信した合奏予定データに基づき、合奏に参加する他の演者端末２０に対して、利用者により入力された接続条件を送信（提示）する。それとともに、この接続条件と、他の演者端末２０から受信した接続条件とを照合し、当該合奏における接続条件を決定する。
【０１０１】
ここで、接続条件には、通信条件及びエフェクト条件が含まれる。
通信条件とは、演者端末２０及び管理サーバ１０の間のデータ通信に関する条件であり、具体的には、入力された演奏音声の符号化方式（サンプリング周波数や量子化ビット数等のパラメータを含む）や、これらの機器の間でデータ通信を行う際の接続レート（伝送速度）等が該当する。そして、この通信条件は、各演者端末２０や管理サーバ１０のスペック等に応じて設定可能な条件の内から、利用者の指示により、或いは最適なものが自動的に決定される。
【０１０２】
また、エフェクト条件とは、上述のように、演奏音声に対する音響効果に関する条件であり、具体的には、エコーやリバーブ（残響）、トーンコントロールの度合、音量バランス、ステレオ化の有無やそのＬ／Ｒ比等が該当する。そして、このエフェクト条件は、想定する演奏場所（例えば、コンサートホールや野外ステージ、ライブハウス等）に応じて、合奏音声に施すエコーやリバーブ（残響）、トーンコントロール等の度合が決定されたり、或いは想定するステージ上における各パートの位置（例えば、中央にボーカル、右にギター、左にベース等）に応じて、当該各パートの音声の音量バランスや、ステレオ音声として出力する際の左右バランス（Ｌ／Ｒ比）が決定される。
【０１０３】
演奏データ送信処理において、演者端末；ＣＰＵ２１は、演者端末；ＤＳＰ２２から入力される音声データパケットをＩＰパケット化し、演奏データとして、管理サーバ１０及び他の演者端末２０へ送信する。
【０１０４】
また、演奏／合成観客データ受信処理において、演者端末；ＣＰＵ２１は、各演者端末２０から受信した演奏データ、或いは管理サーバ１０から受信した合成観客データ、即ちＩＰパケットから音声データを抜き出し、１つの音声データパケットとして、演者端末；ＤＳＰ２２へ出力する。
【０１０５】
図１２において、演者端末；ＤＳＰ２２は、デジタルデータの高速処理に特化したプロセッサである。また、演者端末；ＤＳＰ２２は、本実施の形態の特徴的な処理として、後述する演奏データ送信処理（図２３参照）、演奏／合成観客データ受信処理（図２４参照）及び合奏音声出力処理（図２５参照）を実行する。
【０１０６】
具体的には、演奏データ送信処理において、演者端末；ＤＳＰ２２は、サンプリング周期毎に、Ｄ／Ａ変換回路２９から入力される音声データを入力バッファ２４ａに格納するとともに、５１２サンプリング分の音声データを１つの音声データパケットとして、演者端末；ＣＰＵ２１へ出力する。それとともに、この音声データパケットに対して所定の音響効果処理を行った後、演奏データバッファ２４ｂに格納する。
【０１０７】
演奏／合成観客データ受信処理において、演者端末；ＤＳＰ２２は、演者端末；ＣＰＵ２１から入力された音声データパケットが演奏データであれば、所定の音響効果処理を行った後、演奏データバッファ２４ｂに格納する。一方、演者端末；ＣＰＵ２１から入力された音声データパケットが合成観客データであれば、合成観客データバッファ２４ｃに格納する。
【０１０８】
また、合奏音声出力処理において、演者端末；ＤＳＰ２２は、演奏データバッファ２４ｂに格納されている音声データパケットの内、所定のパケット番号のものを読み出して音合成（同期合成）する。それとともに、合成観客データバッファ２４ｃに格納されている音声データパケットを読み出して、上記同期合成後の音声データパケットと音合成する。そして、この合成後の音声データパケットを、Ｄ／Ａ変換回路２９へ出力する。
【０１０９】
図１３は、演者端末；ＣＰＵ２１及び演者端末；ＤＳＰ２２が、演奏データに対して行う処理の概念を示す図である。尚、同図においては、演者端末２０（以下、適宜「演者端末Ａ」という。）が、２台の他の演者端末２０（以下、それぞれを、適宜「演者端末Ｂ」及び「演者端末Ｃ」という。）から送信される演奏データを受信する場合について、示している。
【０１１０】
演者端末２０が受信する演奏データは、上述のように、ＩＰパケットとして演者端末；ＣＰＵ２１へ入力される。同図においては、このＩＰパケットを簡略し、送信端末識別番号及びパケット番号より構成される同期調整データ及び音声データのみで表しているとともに、演者端末；ＣＰＵ２１への入力順に、図中左より示している。
【０１１１】
また、送信端末識別番号“Ａ”は演者端末Ａ自身を、送信端末識別番号“Ｂ”は演者端末Ｂを、そして送信端末識別番号“Ｃ”は演者端末Ｃを、それぞれ示している。
【０１１２】
また、音声データ“データＡｈ”は、演者端末Ａ自身に入力されたパケット番号“ｈ”のＩＰパケットの音声データパケットを、音声データ“データＢｉ”は、演者端末Ｂから受信したパケット番号“ｉ”のＩＰパケットの音声データパケットを、そして、音声データ“データＣｊ”は、演者端末Ｃから受信したパケット番号“ｊ”のＩＰパケットの音声データパケットを、それぞれ示している。
【０１１３】
同図（ａ）によれば、演者端末；ＣＰＵ２１は、入力されたＩＰパケットから音声データを抜き出す。そして、この音声データを１つの音声データパケットとし、付加されている端末識別番号に従って送信元の演者端末２０毎に振り分けるとともに、パケット番号に従って並べ替える。即ち、同図（ａ）においては、図中上から、演者端末Ａ、Ｂ、Ｃの順に振り分けた様子を示している。
【０１１４】
次いで、同図（ｂ）によれば、演者端末；ＤＳＰ２２は、これらの音声データパケットそれぞれに対し、指定されたエフェクト条件に基づいた音響効果処理を行う。即ち、エコーやリバーブ、トーンコントロール等のエフェクトを、指定された度合で付加するとともに、指定されたＬ／Ｒ比のステレオデータに変換する。
【０１１５】
例えば、音声データ“データＡ０”に対し、所定のエフェクトを付加するとともに、指定されたＬ／Ｒ比のステレオデータ、即ち、Ｌチャネルの音声データ“データＡ０Ｌ”及びＲチャネルの音声データ“データＡ０Ｒ”を生成する。
【０１１６】
また、音声データ“データＢ０”及び“データＣ０”についても同様に、所定のエフェクトを付加し、指定されたＬ／Ｒ比で、Ｌチャネルの音声データ“データＢ０Ｌ”及び“データＣ０Ｌ”、そしてＲチャネルの音声データ“データＢ０Ｒ”及び“データＣ０Ｒ”を、それぞれ生成する。
【０１１７】
その後、同図（ｃ）によれば、演者端末；ＤＳＰ２２は、これらの音声データパケットを合成し、合成演奏データを生成する。具体的には、これらの音声データパケットの内、パケット番号が同一のもの同士を、チャネル毎に合成する。
【０１１８】
例えば、パケット番号“０”については、音声データ“データＡ０Ｌ”、“データＢ０Ｌ”及び“データＣ０Ｌ”を合成し、Ｌチャネルの音声データ“データＡ０Ｌ＋Ｂ０Ｌ＋Ｃ０Ｌ”を生成するとともに、音声データ“データＡ０Ｒ”、“データＢ０Ｒ”及び“データＣ０Ｌ”を合成し、Ｒチャネルの音声データ“データＡ０Ｒ＋Ｂ０Ｒ＋Ｃ０Ｒ”を生成する。
【０１１９】
また、パケット番号“１”についても同様に、音声データ“データＡ０Ｌ”、“データＢ０Ｌ”及び“データＣ０Ｌ”を合成し、Ｌチャネルの音声データ“データＡ０Ｌ＋Ｂ０Ｌ＋Ｃ０Ｌ”を生成するとともに、音声データ“データＡ０Ｒ”、“データＢ０Ｒ”、及び“データＣ０Ｌ”を合成し、Ｒチャネルの音声データ“データＡ０Ｒ＋Ｂ０Ｒ＋Ｃ０Ｒ”を生成する。
【０１２０】
このように、各演奏データを合成した合成演奏データ（即ち、同図（ｃ）の状態）を生成すると、演者端末；ＤＳＰ２２は、この合成演奏データと、管理サーバ１０から受信した合成観客データとを合成し、合奏データを生成する。尚、ここで生成された合奏データは、Ｄ／Ａ変換回路２９へ出力された後、アンプ３０にて増幅され、合奏音声として出力される。
【０１２１】
図１２において、記憶装置２３は、演者端末２０の動作に係る各種処理プログラムや、本実施の形態の機能を実現するためのプログラム（具体的には、合奏プログラム２３ａ、リンク確立プログラム２３ｂ、演奏データ送信プログラム２３ｃ、演奏／合成観客データ受信プログラム２３ｄ、合奏音声出力プログラム２３ｅ）及びこれらのプログラムの実行に係る処理データ等を記憶する。
【０１２２】
ＲＡＭ２４は、演者端末；ＣＰＵ２１により実行される各プログラムを実行するためのプログラムエリア（不図示）、入力指示や入力データ、上記プログラムが実行される際に生じる処理結果等を一時的に格納するワークメモリエリアを備えている。また、このワークメモリエリアには、入力バッファ２４ａ、演奏データバッファ２４ｂ及び合成観客データバッファ２４ｃが形成される。
【０１２３】
入力バッファ２４ａは、利用者によって入力された演奏音声のデータ（演奏データ）が格納される領域であり、詳細には、５１２サンプリング分の音声データを格納する領域が、確保されている。
【０１２４】
演奏データバッファ２４ｂは、演者端末２０自身の演奏データ及び他の演者端末２０から受信した演奏データが格納される領域である。具体的には、図１３（ｂ）に示すように、演者端末；ＤＳＰ２２によって音響効果処理が行われた音声データパケットが、演者端末２０毎に、パケット番号に従って格納される。
【０１２５】
合成観客データバッファ２４ｃは、管理サーバ１０から受信した合成観客データが格納される領域である。具体的には、図９（ｃ）に示すように、管理サーバ１０にて音響効果処理が行われた音声データパケットが、その受信順に格納される。
【０１２６】
入力装置２５は、演者端末２０の利用者が、演奏を希望する条件や、他の演者端末２０との接続条件等を入力するためのものであり、文字キーや数字キー、各種機能キーを備えたキーボード又はタッチパネル、或いはマウスやトラックボール、トラック・パッド、ポインティング・スティック等のポインティングデバイス等により構成される。そして、これらの操作に応じた操作信号を、演者端末；ＣＰＵ２１へ出力する。
【０１２７】
マルチプレクサ２６は、複数の入力信号の内から１つの信号を選択し、出力する回路である。また、このマルチプレクサ２６の入力側には、マイクロフォンや電子楽器等に接続されており、演者端末；ＤＳＰ２２から入力される指示信号（選択信号）に従って、入力される演奏音声の一つを選択し、サンプルホールド回路２７へ出力する。
【０１２８】
サンプルホールド回路２７は、演者端末；ＤＳＰ２２から入力されるクロック信号の入力タイミングに従い、マルチプレクサ２６から入力される音声信号（アナログ信号）を、一時的に保持（ホールド）するとともに、Ａ／Ｄ変換回路２８へ出力する。
【０１２９】
Ａ／Ｄ変換回路２８は、サンプルホールド回路２７から入力されるアナログ信号をデジタル信号に変換する回路であり、得られたデジタル信号を演者端末；ＤＳＰ２２へ出力する。
【０１３０】
Ｄ／Ａ変換回路２９は、演者端末；ＤＳＰ２２から入力されるデジタル信号をアナログ信号に変換する回路であり、得られたアナログ信号をアンプ３０へ出力する。
【０１３１】
アンプ３０は、Ｄ／Ａ変換回路２９から入力されるアナログ信号を所定レベルに増幅し、増幅後の信号を、外部接続されたスピーカ（不図示）へ出力する。
【０１３２】
表示駆動回路３１は、演者端末；ＣＰＵ２１から入力される表示信号に基づいて表示装置３２を駆動し、各種表示画面を表示させる回路である。また、表示装置３２は、ＣＲＴ（Ｃａｔｈｏｄｅ Ｒａｙ Ｔｕｂｅ）やＬＣＤ（Ｌｉｑｕｉｄ Ｃｒｙｓｔａｌ Ｄｉｓｐｌａｙ）等により構成され、演者端末；ＣＰＵ２１から入力される表示信号に従った表示画面を表示する。
【０１３３】
通信装置３３は、インターネットＮを介して他の機器とのデータ通信を行うためのインターフェースであり、ルータ等により構成される。
【０１３４】
図１４は、観客端末４０の構成を示すブロック図である。
同図によれば、観客端末４０は、観客端末；ＣＰＵ４１、観客端末；ＤＳＰ４２、記憶装置４３、ＲＡＭ４４、入力装置４５、マルチプレクサ４６、サンプルホールド回路４７、Ａ／Ｄ変換回路４８、Ｄ／Ａ変換回路４９、アンプ５０、表示駆動回路５１、表示装置５２及び通信装置５３より構成される。
【０１３５】
観客端末；ＣＰＵ４１は、記憶装置４３に記憶される各種処理プログラムに基づいて、観客端末４０を構成する各部を集中制御する。具体的には、入力装置４５、或いは通信装置５３から入力される信号に応答して、記憶装置４３に記憶されている処理プログラムを読み出してＲＡＭ４４に一時記憶させるとともに、係る処理プログラムに基づく処理を実行して、観客端末４０を機能させる。その際、観客端末；ＣＰＵ４１は、処理結果をＲＡＭ４４内の所定領域に格納するとともに、必要に応じて、その処理結果を、表示装置５２に表示するとともに、通信装置５３から外部機器へ送信する。
【０１３６】
また、観客端末；ＣＰＵ４１は、本実施の形態の特徴的な処理として、後述する合奏処理（図１５参照）、観客データ送信処理（図２６参照）及び合奏音声再生処理（図２７参照）を実行する。
【０１３７】
具体的には、合奏処理において、観客端末；ＣＰＵ４１は、管理サーバ１０から送信される演奏予定データを受信する。そして、この演奏予定データに基づき、利用者の入力指示に応じた参加予定データを、当該観客端末４０のＩＰアドレスとともに、管理サーバ１０へ送信する。その後、管理サーバ１０より演奏開始を指示されると、観客端末；ＣＰＵ４１は、演奏処理を実行する。
【０１３８】
この演奏処理において、観客端末；ＣＰＵ４１は、後述する観客データ送信処理（図２６参照）及び合奏音声再生処理（図２７参照）を実行するとともに、観客端末；ＤＳＰ４２に、観客データ送信処理（図２６参照）及び合奏音声再生処理（図２７参照）を実行させる。
【０１３９】
観客データ送信処理において、観客端末；ＣＰＵ４１は、観客端末；ＤＳＰ４２から入力される音声データパケットをＩＰパケット化し、観客データとして、管理サーバ１０へ送信する。
【０１４０】
また、合奏音声再生処理において、観客端末；ＣＰＵ４１は、管理サーバ１０から受信した合奏データ、即ちＩＰパケットから音声データを抜き出し、１つの音声データパケットとして、観客端末；ＤＳＰ４２へ出力する。
【０１４１】
観客端末；ＤＳＰ４２は、デジタルデータの高速処理に特化したプロセッサである。また、観客端末；ＤＳＰ４２は、本実施の形態の特徴的な処理として、後述する観客データ送信処理（図２６参照）及び合奏音声再生処理（図２７参照）を実行する。
【０１４２】
具体的には、観客データ送信処理において、観客端末；ＤＳＰ４２は、サンプリング周期毎に、Ｄ／Ａ変換回路４９から入力される音声データを入力バッファ４４ａに格納するとともに、５１２サンプリング分の音声データを１つの音声データパケットとして、観客端末；ＣＰＵ４１へ出力する。
【０１４３】
また、合奏音声再生処理において、観客端末；ＤＳＰ４２は、観客端末；ＣＰＵ４１から入力される音声データパケットを、その受信順に合奏データバッファ４４ｂに格納する。そして、所定時間毎に、合奏データバッファ４４ｂに格納されている音声データパケットを、その格納順に読み出し、Ｄ／Ａ変換回路４９へ出力する。
【０１４４】
図１４において、記憶装置４３は、観客端末４０の動作に係る各種処理プログラムや、本実施の形態の機能を実現するためのプログラム（具体的には、合奏プログラム４３ａ、観客データ送信プログラム４３ｂ、合奏音声再生プログラム４３ｃ）及びこれらのプログラムの実行に係る処理データ等を記憶する。
【０１４５】
ＲＡＭ４４は、観客端末；ＣＰＵ４１により実行される各プログラムを実行するためのプログラムエリア（不図示）、入力指示や入力データ、上記プログラムが実行される際に生じる処理結果等を一時的に格納するワークメモリエリアを備えている。また、このワークメモリエリアには、入力バッファ４４ａ及び合奏データバッファ４４ｂが形成される。
【０１４６】
入力バッファ４４ａは、利用者によって入力された観客音声のデータ（観客データ）が格納される領域であり、詳細には、５１２サンプリング分の音声データが格納される領域が確保されている。
【０１４７】
合奏データバッファ４４ｂは、ストリーミング配信用のバッファであり、管理サーバ１０から受信した合奏データが格納される領域である。具体的には、管理サーバ１０にて合成・音響効果処理が行われた音声データパケットが、その受信順に格納される。
【０１４８】
入力装置４５は、観客端末４０の利用者が、観客として参加を希望する演奏の指定等を入力するためのものであり、文字キーや数字キー、各種機能キーを備えたキーボード又はタッチパネル、或いはマウスやトラックボール、トラック・パッド、ポインティング・スティック等のポインティングデバイス等により構成される。そして、これらの操作に応じた操作信号を、観客端末；ＣＰＵ４１へ出力する。
【０１４９】
マルチプレクサ４６は、複数の入力信号の内から１つの信号を選択し、出力する回路である。また、このマルチプレクサ４６の入力側には、マイクロフォンが接続されており、観客端末；ＤＳＰ４２から入力される指示信号（選択信号）に従って、入力される観客音声の一つを選択し、サンプルホールド回路４７へ出力する。
【０１５０】
サンプルホールド回路４７は、観客端末；ＤＳＰ４２から入力されるクロック信号の入力タイミングに従い、マルチプレクサ４６から入力される音声信号（アナログ信号）を一時的に保持（ホールド）するとともに、Ａ／Ｄ変換回路４８へ出力する。
【０１５１】
Ａ／Ｄ変換回路４８は、サンプルホールド回路４７から入力されるアナログ信号をデジタル信号に変換する回路であり、得られたデジタル信号を観客端末；ＤＳＰ４２へ出力する。
【０１５２】
Ｄ／Ａ変換回路４９は、観客端末；ＤＳＰ４２から入力されるデジタル信号をアナログ信号に変換する回路であり、得られたアナログ信号をアンプ５０へ出力する。
【０１５３】
アンプ５０は、Ｄ／Ａ変換回路４９から入力されるアナログ信号を所定レベルに増幅し、増幅後の信号を、外部接続されたスピーカ（不図示）へ出力する。
【０１５４】
表示駆動回路５１は、観客端末；ＣＰＵ４１から入力される表示信号に基づいて表示装置５２を駆動し、各種表示画面を表示させる回路である。また、表示装置５２は、ＣＲＴやＬＣＤ等により構成され、観客端末；ＣＰＵ４１から入力される表示信号に従った表示画面を表示する。
【０１５５】
通信装置５３は、インターネットＮを介して他の機器とのデータ通信を行うためのインターフェースであり、ルータ等により構成される。
【０１５６】
次に、演奏システム１の動作を、図１５〜図２７を参照して説明する。
【０１５７】
図１５は、合奏処理を示すフローチャートである。
この合奏処理は、管理サーバ１０の管理サーバ；ＣＰＵ１１、演者端末２０の演者端末；ＣＰＵ２１及び観客端末４０の観客端末；ＣＰＵ４１により、それぞれ、記憶装置１２に記憶された合奏プログラム１２ａ、記憶装置２２に記憶された合奏プログラム２２ａ及び記憶装置４２に記憶された合奏プログラム４２ａに従って、実行される処理である。
【０１５８】
同図によれば、演者端末２０において、演者端末；ＣＰＵ２１は、利用者からの入力指示に従い、管理サーバ１０が提供するＷｅｂサイトへアクセスし（ステップＳ１１）、この管理サーバ１０から送信されるＨＰ情報（Ｗｅｂページを表示させるための情報）を受信する（ステップＳ１２）。そして、このＨＰ情報に基づいて、表示装置３２に、合奏参加登録画面（不図示）を表示する。
【０１５９】
次いで、演奏参加登録画面上の入力フォーマットに従って、利用者により演奏を希望する曲目やパート、日時を含む演奏条件データが入力されると（ステップＳ１３）、演者端末；ＣＰＵ２１は、この演奏条件データ及び演者端末２０のＩＰアドレスを、演奏参加登録要請とともに、管理サーバ１０へ送信する（ステップＳ１４）。
【０１６０】
一方、管理サーバ１０において、演者端末２０から、演奏参加登録要請とともに送信される演奏条件データ及びＩＰアドレスを受信すると（ステップＳ１５）、管理サーバ；ＣＰＵ１１は、この演奏条件データ及びＩＰアドレスを対応付けて、ＲＡＭ１３内の演奏条件データ格納領域１３ａに追加格納する。
【０１６１】
そして、管理サーバ；ＣＰＵ１１は、演奏条件データ格納領域１３ａに格納されているデータの内から、受信した演奏条件データに適合するデータを検索し、合奏に参加可能な演者端末２０を特定する（ステップＳ１６）。具体的には、演奏を希望する曲目及び日時が一致し、且つパートが異なるデータを検索する。
【０１６２】
合奏に参加可能な演者端末２０を特定すると、管理サーバ；ＣＰＵ１１は、特定した演者端末２０をグループ化した演者用マルチキャストＩＰアドレス及び観客として参加する観客端末４０をグループ化する観客用マルチキャストＩＰアドレスを設定する。そして、これらの演者用マルチキャストＩＰアドレス及び観客用マルチキャストＩＰアドレスととともに、合奏を予定する日時、曲目、参加する演者端末２０のＩＰアドレスを対応付けて、ＲＡＭ１３内の合奏予定データ格納領域１３ｂに、詳細には、合奏予定日時が現在時刻に最も近い順に並ぶ位置に追加格納する。
【０１６３】
それとともに、管理サーバ；ＣＰＵ１１は、上記特定した各演者端末２０に対し、当該合奏を予定する日時、曲目、割り当てたパート、演者用マルチキャストＩＰアドレスを含む合奏予定データを送信する（ステップＳ１７）。即ち、各演者端末２０は、参加することとなる合奏に関する演奏予定データ、即ち、合奏を予定する日時や曲目、演者用マルチキャストＩＰアドレス（演奏データの送信先となる。）を受信する（ステップＳ１８）。
【０１６４】
また、観客端末４０において、観客端末；ＣＰＵ４１は、利用者からの入力指示に従い、管理サーバ１０が提供するＷｅｂサイトへアクセスし（ステップＳ１９）、この管理サーバ１０から送信される合奏予定データを受信する（ステップＳ２０、Ｓ２１）。そして、この合奏予定データに基づいて、表示装置５２に、演奏予定画面（不図示）を表示する。
【０１６５】
次いで、この演奏予定画面上の入力フォーマットに従って、利用者により観客として参加を希望する合奏が指定されると（ステップＳ２２）、観客端末；ＣＰＵ４１は、指定された合奏を示す参加予定データ及び当該観客端末４０のＩＰアドレスを、管理サーバ１０へ送信する（ステップＳ２３）。
【０１６６】
一方、管理サーバ１０において、演者端末２０から送信される参加予定データ及びＩＰアドレスを受信すると（ステップＳ２４）、管理サーバ；ＣＰＵ１１は、受信したＩＰアドレスを、指定された合奏に対応する観客用マルチキャストＩＰアドレスによってグループ化された観客端末４０のＩＰアドレスとして、ＲＡＭ１３内の合奏予定データ格納領域１３ｂに格納する。
【０１６７】
また、管理サーバ１０において、管理サーバ；ＣＰＵ１１は、随時、合奏予定データ格納領域１３ｂの先頭に格納されている合奏予定日時と、現在時刻とを比較している。そして、合奏予定日時の所定時間前となると（ステップＳ２５：ＹＥＳ）、管理サーバ；ＣＰＵ１１は、当該合奏に参加予定の演者端末２０及び観客端末４０の全てに対し、その旨を通知し、例えば図１６に示す演奏開始指示画面を表示させる（ステップＳ２６）。そして、合奏開始日時となったことを確認すると、管理サーバ；ＣＰＵ１１は、後述の演奏処理を実行することで、当該合奏に係る処理を開始する（ステップＳ２７）。
【０１６８】
また、演者端末２０においては、管理サーバ１０より合奏予定日時の所定時間前である旨が通知されると（ステップＳ２８）、演者端末；ＣＰＵ２１は、後述のリンク確立処理（図１７参照）を実行することで、当該合奏に参加予定の他の演者端末２０と、接続条件の提示・照合を行うとともに、直接通信リンクを確立する（ステップＳ２９）。その後、合奏予定日時となったことを確認すると、演者端末；ＣＰＵ２１は、後述の演奏処理を実行することで、当該合奏に係る処理を開始する（ステップＳ３０）。
【０１６９】
一方、観客端末４０においては、管理サーバ１０より演奏開始日時の所定時間前である旨が通知されと（ステップＳ３１）、観客端末；ＣＰＵ４１は、合奏予定日時となったことを確認した後、後述の演奏処理を実行することで、当該合奏に、観客として参加する（ステップＳ３２）。
【０１７０】
そして、各機器（管理サーバ１０、各演者端末２０及び各観客端末４０）の全てにおける演奏処理が終了すると、当該合奏は終了となる。
【０１７１】
図１５のステップＳ２９にて実行されるリンク確立処理について、説明する。図１７は、リンク確立処理を示すフローチャートである。このリンク確立処理は、演者端末２０の演者端末；ＣＰＵ２１により、記憶装置２３に記憶されたリンク確立プログラム２３ｂに従って実行される。
【０１７２】
同図によれば、演者端末；ＣＰＵ２１は、利用者からの入力指示に従った接続条件を、他の演者端末２０に送信（提示）するとともに、他の演者端末２０から受信した接続条件と照合する（ステップＳ１０１）。尚、ここで照合される接続条件は、上述のように、通信条件及びエフェクト条件が含まれるものである。
【０１７３】
照合の結果、他の演者端末２０の接続条件との合意が得られないと判断した場合（ステップＳ１０２：ＮＯ）、演者端末；ＣＰＵ２１は、合意されていない接続条件の内容を、代替案の候補とともに表示装置３２に表示させる（ステップＳ１０３）。
【０１７４】
そして、これらの代替案から選択された内容を、新たな接続条件として他の演者端末２０に再送信（再提示）するとともに、他の演者端末２０から再送信（再提示）される接続条件との照合を行う（ステップＳ１０４）。
【０１７５】
その結果、接続条件の合意が得られたと判断した場合には（ステップＳ１０２：ＹＥＳ）、演者端末；ＣＰＵ２１は、合意した接続条件、詳細には、少なくとも演者端末２０自身に関する接続条件を、ＲＡＭ２４に記憶しておく。
以上の処理を行うと、演者端末；ＣＰＵ２１は、本リンク確立処理を終了する。
【０１７６】
図１５のステップＳ２７にて実行される演奏処理について説明する。この演奏処理において、管理サーバ１０は、データ受信処理（図１８参照）、合成観客データの演者端末への送信処理（図２１参照）及び合奏データ生成・観客端末への送信処理（図２２参照）の３つの処理を並行して実行する。図６（ａ）に、この管理サーバ１０が行う演奏処理の概略フローを示す。管理サーバ１０は、データ受信処理（図１８参照）（ステップＡ１）と、合成観客データの演者端末への送信処理（図２１参照）（ステップＡ２）と、合奏データ生成・観客端末への送信処理（図２２参照）（ステップＡ３）とを、演奏が終了するまで繰り返し行う（ステップＡ４）。
【０１７７】
図１８は、データ受信処理（管理サーバ）を示すフローチャートである。このデータ受信処理は、管理サーバ１０の管理サーバ；ＣＰＵ１１により、記憶装置１２に記憶されたデータ受信プログラム１２ｂに従って実行される処理である。
【０１７８】
同図によれば、通信装置１４からＩＰパケットが入力されると（ステップＳ２０１：ＹＥＳ）、管理サーバ；ＣＰＵ１１は、このＩＰパケットが演奏データであり、且つ観客データ受信処理を現在実行中であるか否かを判定する（ステップＳ２０２）。
【０１７９】
判定の結果、入力されたＩＰパケットが演奏データであり、且つ観客データ受信処理を現在実行中である場合には（ステップＳ２０２：ＹＥＳ）、管理サーバ；ＣＰＵ１１は、現在実行中の観客データ受信処理を一時中断し（ステップＳ２０３）、続いて、後述する演奏データ受信処理を実行する（ステップＳ２０４）。
【０１８０】
そして、演奏データ受信処理を終了すると、管理サーバ；ＣＰＵ１１は、ステップＳ２０３にて一時中断していた観客データ受信処理の実行を再開する（ステップＳ２０５）。
【０１８１】
一方、ステップＳ２０２において、判定条件を満たさない場合、具体的には、入力されたＩＰパケットが観客データである、或いは観客データ受信処理を現在実行中でない場合には（ステップＳ２０２：ＮＯ）、管理サーバ；ＣＰＵ１１は、入力されたＩＰパケットが演奏データであるか否かを判定する（ステップＳ２０６）。
【０１８２】
判定の結果、このＩＰパケットが演奏データである場合（ステップＳ２０６：ＹＥＳ）、管理サーバ；ＣＰＵ１１は、続いて、後述する演奏データ受信処理を実行する（ステップＳ２０７）。一方、演奏データでない、即ち観客データである場合には（ステップＳ２０６：ＮＯ）、管理サーバ；ＣＰＵ１１は、続いて、後述する観客データ受信処理を実行する（ステップＳ２０８）。
以上の処理を終了すると、ＣＵＰ１１は、本データ受信処理を終了する。
【０１８３】
図１９は、演奏データ受信処理（管理サーバ）を示すフローチャートである。この演奏データ受信処理は、図１８のステップＳ２０４或いはステップＳ２０７において、管理サーバ１０の管理サーバ；ＣＰＵ１１により、記憶装置１２に記憶された演奏データ受信プログラム１２ｃに従って実行される処理である。
【０１８４】
同図によれば、管理サーバ；ＣＰＵ１１は、通信装置１４からＩＰパケットが入力されると、このＩＰパケットに対して、暗号解読処理を含むＩＰ層プロトコル処理（ステップＳ２１１）及びＵＤＰ層プロトコル処理を行う（ステップＳ２１２）。そして、アプリケーション層処理により、このＩＰパケットから音声データ及び指示ヘッダを抜き出す（ステップＳ２１３）。
【０１８５】
次いで、管理サーバ；ＣＰＵ１１は、抜き出した音声データを、指示ヘッダに含まれる音声記録方式（即ち、ＰＣＭ方式）に従ってデコードするとともに（ステップＳ２１４）、図８を参照して説明したように指示ヘッダに含まれるエフェクト条件に従って音響効果処理を行った後（ステップＳ２１５）、演奏データバッファ１３ｃの所定領域に格納する（ステップＳ２１６）。
その後、管理サーバ；ＣＰＵ１１は、本演奏データ受信処理を終了する。
【０１８６】
図２０は、観客データ受信処理（管理サーバ）を示すフローチャートである。この観客データ受信処理は、図１８のステップＳ２０８において、管理サーバ１０の管理サーバ；ＣＰＵ１１により、記憶装置１２に記憶された観客データ受信プログラム１２ｄに従って実行される処理である。
【０１８７】
同図によれば、通信装置１４からＩＰパケットが入力されると、管理サーバ；ＣＰＵ１１は、このＩＰパケットに対して、暗号解読処理を含むＩＰ層プロトコル処理（ステップＳ２２１）及びＵＤＰ層プロトコル処理を行う（ステップＳ２２２）。そして、アプリケーション層処理により、このＩＰパケットから音声データ及び指示ヘッダを抜き出す（ステップＳ２２３）。
【０１８８】
次いで、管理サーバ；ＣＰＵ１１は、抜き出した音声データを、図９を参照して説明したように、指示ヘッダに含まれる音声記録方式（即ち、ＰＣＭ方式）に従ってデコードするとともに（ステップＳ２２４）、観客データバッファ１３ｄ内の所定領域、即ち、当該音声データパケットの送信元である観客端末４０に対応する領域に、パケット番号に従って格納する（ステップＳ２２５）。
以上の処理を行うと、管理サーバ；ＣＰＵ１１は、本観客データ受信処理を終了する。
【０１８９】
図２１は、合成観客データ送信処理（管理サーバ）を示すフローチャートである。この合成観客データ送信処理は、管理サーバ１０の管理サーバ；ＣＰＵ１１により、記憶装置１２に記憶された合成観客データ送信プログラム１２ｅに従って実行される処理である。
【０１９０】
同図によれば、本処理の開始した後、所定の観客音声合成周期が経過すると（ステップＳ２３１：ＹＥＳ）、管理サーバ；ＣＰＵ１１は、観客データバッファ１３ｄから、格納されている音声データパケットを読み出す（ステップＳ２３２）。
【０１９１】
そして、図９を参照して説明したように、これら読み出した音声データパケットを音合成し（ステップＳ２３３）、所定の音響効果処理を行った後（ステップＳ２３４）、処理後のデータを、合成観客データバッファ１３ｅに格納する（ステップＳ２３５）。
【０１９２】
次いで、管理サーバ；ＣＰＵ１１は、ステップＳ２３４にて音響効果処理を行った音声データパケットを、ＰＣＭ方式でエンコードした後（ステップＳ２３６）、ＵＤＰ層プロトコル処理（ステップＳ２３７）、暗号化処理を含むＩＰ層プロトコル処理を行い、ＩＰパケットを生成する（ステップＳ２３８）。但しこの時、管理サーバ；ＣＰＵ１１は、演者用マルチキャストＩＰアドレスを、ＩＰヘッダの宛先ＩＰアドレスに設定する。
【０１９３】
そして、生成したＩＰパケットを、通信装置１４から、演奏者用マルチキャストＩＰアドレスによりグループ化されている各演者端末２０へ、一斉配信する（ステップＳ２３９）。
【０１９４】
その後、管理サーバ；ＣＰＵ１１は、本処理の終了が指示されているか否かを判定する（ステップＳ２４０）。判定の結果、終了を指示されていない場合には（ステップＳ２４０：ＮＯ）、管理サーバ；ＣＰＵ１１は、ステップＳ２３１へ移行し、更に観客音声合成周期を経過後、同様の処理を繰り返す（ステップＳ２３１〜Ｓ２４０）。そして、ステップＳ２４０において、本処理の終了が指示されていると判定した場合には（ステップＳ２４０：ＹＥＳ）、管理サーバ；ＣＰＵ１１は、本観客データ受信処理を終了する。
【０１９５】
図２２は、合奏データ生成処理（管理サーバ）を示すフローチャートである。この合奏データ生成処理は、管理サーバ１０の管理サーバ；ＣＰＵ１１により、記憶装置１２に記憶された合奏データ生成プログラム１２ｆに従って実行される処理である。
【０１９６】
同図によれば、管理サーバ；ＣＰＵ１１は、演奏データバッファ１３ｃを参照し、各演者端末２０に対応する、所定のパケット番号の音声データパケットが全て格納されていることを確認すると（ステップＳ２４１：ＹＥＳ）、当該パケット番号の音声データパケットを、演奏データバッファ１３ｃから読み出す（ステップＳ２４２）。そして、図８を参照して説明したように、読み出した音声データパケットを音合成（同期合成）する（ステップＳ２４３）。
【０１９７】
それとともに、管理サーバ；ＣＰＵ１１は、合成観客データバッファ１３ｅから１つの音声データパケットを、その格納順に読み出し（ステップＳ２４４）、読み出した音声データパケットと、ステップＳ２４３にて同期合成した音声データパケットとを、チャネル毎に音合成する（ステップＳ２４５）。
【０１９８】
次いで、管理サーバ；ＣＰＵ１１は、合成した音声データパケットを、ＭＰ３方式に従ってエンコード（圧縮を含む）した後（ステップＳ２４６）、ＵＤＰ層プロトコル処理（ステップＳ２４７）、暗号化処理を含むＩＰ層プロトコル処理を行い、ＩＰパケットを生成する（ステップＳ２４８）。但しこの時、管理サーバ；ＣＰＵ１１は、観客用マルチキャストＩＰアドレスを、ＩＰヘッダの宛先ＩＰアドレスに設定する。
【０１９９】
そして、管理サーバ；ＣＰＵ１１は、生成したＩＰパケットを通信装置１４へ出力し、観客用マルチキャストＩＰアドレスによりグループ化されている各観客端末４０へ、一斉配信する（ステップＳ２４９）。
【０２００】
その後、管理サーバ；ＣＰＵ１１は、本処理の終了が指示されているか否かを判定する（ステップＳ２５０）。判定の結果、終了を指示されていない場合には（ステップＳ２５０：ＮＯ）、管理サーバ；ＣＰＵ１１は、ステップＳ２４１へ移行し、次のパケット番号の音声データパケットに対して同様の処理を繰り返す（ステップＳ２４１〜Ｓ２５０）。そして、ステップＳ２５０において、本処理の終了が指示されていると判定した場合には（ステップＳ２５０：ＹＥＳ）、管理サーバ；ＣＰＵ１１は、本合奏データ生成処理を終了する。
【０２０１】
以上のように、データ受信処理、合成観客データ送信処理及び合奏データ生成処理を終了すると、管理サーバ；ＣＰＵ１１は、１５のステップＳ２７における演奏処理を終了する。
【０２０２】
次に、図１５のステップＳ３０にて実行される演奏処理について説明する。この演奏処理において、演者端末２０は、演奏データ送信処理（図２３参照）、演奏／合成観客データ受信処理（図２４参照）及び合成音声出力処理（図２５参照）の３つの処理を並行して実行する。図６（ｂ）に、演者端末２０が行う演奏処理の概略フローを示す。演者端末２０は、当該演者が担当するパートの音声・映像情報を入力して（ステップＢ１）、演奏データ送信処理（図２３参照）と、演奏／合成観客データ受信処理（図２４参照）と、合成音声出力処理（図２５参照）とを、演奏が終了するまで繰り返し行う（ステップＢ５）。
【０２０３】
図２３は、演奏データ送信処理（演者端末）を示すフローチャートである。この演奏データ送信処理は、演者端末２０の演者端末；ＣＰＵ１１及び演者端末；ＤＳＰ２２により、記憶装置２３に記憶された演奏データ送信プログラム２３ｃに従って実行される処理である。
【０２０４】
同図によれば、本処理を開始した後、所定のサンプリング周期が経過すると（ステップＳ３０１：ＹＥＳ）、演者端末；ＤＳＰ２２は、Ａ／Ｄ変換回路２８から出力される音声データを取込み（ステップＳ３０２）、取込んだ音声データを、入力バッファ２４ａへ格納する（ステップＳ３０３）。尚、ここでサンプリング周期とは、アナログ信号である演奏音声をデジタル信号に符号化する際の周期であり、図１５のステップＳ２９（リンク確立処理）において合意された接続条件に含まれるものである。
【０２０５】
次いで、演者端末；ＤＳＰ２２は、５１２サンプリング分、即ち１パケット分の音声データの取込みを行ったか否かを判定し（ステップＳ３０４）、行っていないと判定した場合には（ステップＳ３０４：ＮＯ）、ステップＳ３０１へ移行し、更にサンプリング周期を経過後、同様の処理を繰り返す（ステップＳ３０１〜Ｓ３０４）。
【０２０６】
このように、サンプリング周期毎に音声データの取込みを繰り返し、１パケット分（即ち、５１２サンプリング分）の音声データの取り込みを行ったと判定すると（ステップＳ３０４：ＹＥＳ）、演者端末；ＤＳＰ２２は、続いて、入力バッファ２４ａに格納されている１パケット分（即ち、５１２サンプリング分）の音声データを読み出す（ステップＳ３０５）。
【０２０７】
そして、読み出した音声データに対して指定された音響効果処理を行った後（ステップＳ３０６）、１つの音声データパケットとして演奏データバッファ２４ｂの所定領域、具体的には、当該演者端末２０に対応する領域に格納する（ステップＳ３０７）。
【０２０８】
それとともに、演者端末；ＤＳＰ２２は、ステップＳ３０５にて読み出した音声データを、ＭＰ３方式に従ってエンコード（圧縮を含む）した後（ステップＳ３０８）、演者端末；ＣＰＵ２１へ出力する（ステップＳ３０９）。その後、演者端末；ＤＳＰ２２は、ステップＳ３０１へ移行し、次の１パケット分の音声データに対して、同様の処理を繰り返す（ステップＳ３０１〜Ｓ３０９）。
【０２０９】
一方、演者端末；ＣＰＵ２１は、演者端末；ＤＳＰ２２から音声データパケットが入力されると（ステップＳ３１０）、この音声データパケットに、同期調整データ、即ち演者端末２０自身を識別する送信端末識別番号及び音声データパケットが入力された順を示すパケット番号を付加するとともに（ステップＳ３１１）、ＵＤＰ層プロトコル処理（ステップＳ３１２）、暗号化処理を含むＩＰ層プロトコル処理を行い、ＩＰパケットを生成する（ステップＳ３１３）。但し、この時、演者端末；ＣＰＵ２１は、演者用マルチキャストＩＰアドレス及び管理サーバ１０のＩＰアドレスを、ＩＰヘッダの宛先ＩＰアドレスに設定する。
【０２１０】
そして、演者端末；ＣＰＵ２１は、生成したＩＰパケットを、通信装置３３へ出力し、演者用マルチキャストＩＰアドレスによりグループ化された他の演者端末２０及び管理サーバ１０へ送信する（ステップＳ３１４）。
【０２１１】
その後、演者端末；ＣＰＵ２１は、本処理の終了が指示されているか否かを判定する（ステップＳ３１５）。判定の結果、終了を指示されていない場合には（ステップＳ３１５：ＮＯ）、演者端末；ＣＰＵ２１は、ステップＳ３１０へ移行し、続いて入力される音声データに対して同様の処理を繰り返す（ステップＳ３１０〜Ｓ３１５）。そして、ステップＳ３１５において、本処理の終了が指示されていると判定した場合には（ステップＳ３１５：ＹＥＳ）、演者端末；ＣＰＵ２１は、本演奏データ送信処理を終了する。
【０２１２】
図２４は、演奏／合成観客データ受信処理を示すフローチャートである。この演奏／合成観客データ受信処理は、演者端末２０の演者端末；ＣＰＵ２１及び演者端末；ＤＳＰ２２により、記憶装置２３に記憶された演奏／合成観客データ受信プログラム２３ｄに従って実行される処理である。
【０２１３】
同図によれば、他の演者端末２０から演奏データ或いは管理サーバ１０から合成観客データを受信する、即ち、通信装置３３からＩＰパケットが入力されると（ステップＳ３２１：ＹＥＳ）、演者端末；ＣＰＵ２１は、入力されたＩＰパケットに対して、暗号解読処理を含むＩＰ層プロトコル処理（ステップＳ３２２）及びＵＤＰ層プロトコル処理を行うとともに（ステップＳ３２３）、アプリケーション層処理により、このＩＰパケットから音声データ及び指示ヘッダを抜き出し、１つの音声データパケットとして、指示ヘッダとともに演者端末；ＤＳＰ２２へ出力する（ステップＳ３２４）。
【０２１４】
その後、演者端末；ＣＰＵ２１は、本処理の終了が指示されているか否かを判定する（ステップＳ３２５）。判定の結果、終了を指示されていない場合には（ステップＳ３２５：ＮＯ）、演者端末；ＣＰＵ２１は、ステップＳ３２１へ移行し、続いて入力されるＩＰパケットに対して、同様の処理を繰り返す（ステップＳ３２１〜Ｓ３２５）。そして、本処理の終了が指示されていると判定した場合には、演者端末；ＣＰＵ２１は（ステップＳ２３５：ＹＥＳ）、本演奏／合成観客データ受信処理を終了する。
【０２１５】
一方、演者端末；ＤＳＰ２２は、演者端末；ＣＰＵ２１から音声データパケットが入力されると（ステップＳ３２６）、入力された音声データパケットに対し、指示ヘッダに含まれる音声記録方式（即ち、ＰＣＭ方式）に従ってデコードする（ステップＳ３２７）。
【０２１６】
そして、指示ヘッダに含まれるデータ識別より、この音声データパケットが演奏データであると判定した場合には（ステップＳ３２８：ＹＥＳ）、当該音声データパケットに対し、指示ヘッダに含まれるエフェクト条件に従って音響効果処理を行う（ステップＳ３２９）。その後、演奏データバッファ２４ｂの所定領域、即ち、当該音声データパケットの送信元である演者端末２０に対応する領域に、パケット番号に従って格納する（ステップＳ３３０）。
【０２１７】
また、ステップＳ３２８において、入力された音声データパケットが合成観客データであると判定した場合には（ステップＳ３２８：ＮＯ）、演者端末；ＣＰＵ２１は、この音声データパケットを合成観客データバッファ２４ｃに、受信順に格納する（ステップＳ３３１）。
【０２１８】
このように、音声データパケットを演奏データバッファ２４ｂ、或いは合成観客データバッファ２４ｃに格納すると、演者端末；ＤＳＰ２２は、ステップＳ３２６へ移行し、続いて入力される音声データパケットに対して、同様の処理を繰り返す（ステップＳ３２６〜Ｓ３３１）。
【０２１９】
図２５は、合奏音声出力処理（演者端末）を示すフローチャートである。この合奏音声出力処理は、演者端末２０の演者端末；ＤＳＰ２２により、記憶装置２３に記憶された合奏音声出力プログラム２３ｅに従って実行される処理である。
【０２２０】
同図によれば、本処理を開始した後、所定の再生サンプリング周期が経過すると（ステップＳ３４１：ＹＥＳ）、演者端末；ＤＳＰ２２は、演奏データバッファ２４ｂから、所定のパケット番号の音声データを読み出す（ステップＳ３４２）。そして、図１３を参照して説明したように、読み出した音声データを、チャネル毎に音合成（同期合成）する（ステップＳ３４３）。尚、ここで再生サンプリング周期とは、符号化されている音声データを復号化する際のサンプリング周期であり、各演者端末２０毎に固有の値である。
【０２２１】
それとともに、演者端末；ＤＳＰ２２は、合成観客データバッファ２４ｃから１つの音声データパケットを、その格納順に読み出す（ステップＳ３４４）。そして、読み出した音声データと、ステップＳ３４３にて同期合成した音声データとを、チャネル毎に音合成する（ステップＳ３４５）。
【０２２２】
次いで、演者端末；ＤＳＰ２２は、合成後の音声データの出力レベルを調整した後、Ｄ／Ａ変換回路２９へ出力する（ステップＳ３４６）。ここでＤ／Ａ変換回路２９に入力された音声データは、アナログ信号に変換された後、アンプ３０にて増幅され、合奏音声として出力される。
【０２２３】
その後、演者端末；ＤＳＰ２２は、本処理の終了が指示されているか否かを判定する（ステップＳ３４７）。判定の結果、終了が指示されていない場合には（ステップＳ３４７：ＮＯ）、演者端末；ＤＳＰ２２は、ステップＳ３４１へ移行し、更に再生サンプリング周期を経過後、次の音声データに対して、同様の処理を繰り返す（ステップＳ３４１〜Ｓ３４７）。そして、ステップＳ３４７において、本処理の終了が指示されている判定した場合には（ステップＳ３４７：ＹＥＳ）、演者端末；ＤＳＰ２２は、本合奏音声出力処理を終了する。
【０２２４】
以上のように、演奏データ送信処理、演奏／合成観客データ受信処理及び合成音声出力処理を終了すると、ＣＰＵ２２は、図１５のステップＳ３０における演奏処理を終了する。
【０２２５】
次に、図１５のステップＳ３２にて実行される演奏処理について説明する。この演奏処理において、観客端末４０は、観客データ送信処理（図２６参照）及び合奏音声再生処理（図２７参照）の２つの処理を並行して実行する。図６（ｃ）に、観客端末４０が行う演奏処理の概略フローを示す。観客端末４０は、観客の音声を入力すると（ステップＣ１）、観客データ送信処理（図２６参照）と、合奏音声再生処理（図２７参照）とを、演奏が終了するまで繰り返し行う（ステップＣ４）。
【０２２６】
図２６は、観客データ送信処理を示すフローチャートである。この観客データ送信処理は、観客端末４０の観客端末；ＣＰＵ４１及び観客端末；ＤＳＰ４２により、記憶装置４３に記憶された観客データ送信プログラム４３ｂに従って実行される処理である。
【０２２７】
同図によれば、本処理を開始した後、サンプリング周期が経過すると（ステップＳ４０１：ＹＥＳ）、観客端末；ＤＳＰ４２は、Ａ／Ｄ変換回路４８から出力される音声データを取込み（ステップＳ４０２）、取込んだ音声データを、入力バッファ４４ａへ格納する（ステップＳ４０３）。
【０２２８】
次いで、観客端末；ＤＳＰ４２は、１パケット分（即ち、１０２４サンプリング分）の音声データの取込みを行ったか否かを判定し（ステップＳ４０４）、行っていないと判定した場合には（ステップＳ４０４：ＮＯ）、ステップＳ４０１へ移行し、更にサンプリング周期を経過後、同様の処理を繰り返す（ステップＳ４０１〜Ｓ４０４）。
【０２２９】
このように、サンプリング周期毎に音声データの取込みを繰り返し、１パケット部分（即ち、１０２４サンプリング分）の音声データの取込みを行ったと判定すると（ステップＳ４０４：ＹＥＳ）、観客端末；ＤＳＰ４２は、続いて、入力バッファ４４ａに格納されている１パケット分（即ち、１０２４サンプリング分）の音声データを読み出す（ステップＳ４０５）。
【０２３０】
そして、観客端末；ＤＳＰ４２は、読み出した音声データに対し、ＭＰ３方式に従ってエンコード（圧縮を含む）した後（ステップＳ４０６）、１つの音声データパケットとして、観客端末；ＣＰＵ４１へ出力する（ステップＳ４０７）。その後、観客端末；ＤＳＰ４２は、ステップＳ４０１へ移行し、更に１パケット分の音声データを取込み、同様の処理を繰り返す（ステップＳ４０１〜Ｓ４０７）。
【０２３１】
一方、観客端末；ＣＰＵ４１は、観客端末；ＤＳＰ４２から音声データパケットが入力されると（ステップＳ４０８）、ＵＤＰ層プロトコル処理（ステップＳ４０９）、暗号化処理を含むＩＰ層プロトコル処理を行い、ＩＰパケットを生成する（ステップＳ４１０）。但し、この時、観客端末；ＣＰＵ４１は、管理サーバ１０のＩＰアドレスを、ＩＰヘッダの宛先ＩＰアドレスに設定する。そして、観客端末；ＣＰＵ４１は、生成したＩＰパケットを通信装置５３へ出力し、管理サーバ１０へ送信する（ステップＳ４１１）。
【０２３２】
その後、観客端末；ＣＰＵ４１は、本処理の終了が指示されているか否かを判定する（ステップＳ４１２）。判定の結果、終了を指示されていない場合には（ステップＳ４１２：ＮＯ）、観客端末；ＣＰＵ４１は、ステップＳ４０８へ移行し、続いて入力される音声データパケットに対して同様の処理を繰り返す（ステップＳ４０８〜Ｓ４１２）。そして、ステップＳ４１２において、本処理の終了が指示されていると判定した場合には（ステップＳ４１２：ＹＥＳ）、観客端末；ＣＰＵ４１は、本観客データ送信処理を終了する。
【０２３３】
図２７は、合奏音声再生処理を示すフローチャートである。この合奏音声再生処理は、観客端末４０の観客端末；ＣＰＵ４１及び観客端末；ＤＳＰ４２により、記憶装置４３に記憶された合奏音声再生プログラム４３ｃに従って実行される処理である。
【０２３４】
同図によれば、管理サーバ１０から合奏データを受信する、即ち、通信装置５３からＩＰパケットが入力されると（ステップＳ４２１：ＹＥＳ）、観客端末；ＣＰＵ４１は、入力されたＩＰパケットに対して、暗号解読処理を含むＩＰ層プロトコル処理（ステップＳ４２２）及びＵＤＰ層プロトコル処理を行うとともに（ステップＳ４２３）、アプリケーション層処理により、このＩＰパケットから音声データを抜き出し、音声データパケットとして、観客端末；ＤＳＰ４２へ出力する（ステップＳ４２４）。
【０２３５】
その後、観客端末；ＣＰＵ４１は、本処理の終了が指示されているか否かを判定する（ステップＳ４２５）。判定の結果、終了を指示されていない場合には（ステップＳ４２５：ＮＯ）、観客端末；ＣＰＵ４１は、ステップＳ４２１へ移行し、続いて入力されるＩＰパケットに対して、同様の処理を繰り返す（ステップＳ４２１〜Ｓ４２５）。
そして、ステップＳ４２５において、本処理の終了が指示されていると判定した場合には（ステップＳ４２５：ＹＥＳ）、観客端末；ＣＰＵ４１は、本合奏音声再生処理を終了する。
【０２３６】
一方、観客端末；ＤＳＰ４２は、観客端末；ＣＰＵ４１から音声データパケットが入力されると（ステップＳ４２６）、入力された音声データパケットを、指定された音声記録方式（即ち、ＭＰ３方式）に従ってデコードした後（ステップＳ４２７）、合奏データバッファ４４ｂに格納する（ステップＳ４２８）。
【０２３７】
その後、観客端末；ＤＳＰ４２は、基準時間を経過したか否かを判定する（ステップＳ４２９）。尚、この基準時間とは、ストリーミングデータの再生に先立ち、一定量のストリーミングデータを合奏データバッファ４４ｂに蓄積するための時間であり、本処理の開始から、この基準時間が経過した後、再生バッフ４４ｂに格納されている音声データパケットが順次読み出し・再生される。即ち、観客端末４０において、合奏音声の出力は、基準時間だけ遅れて開始されることになる。
【０２３８】
判定の結果、基準時間を経過していない場合には（ステップＳ４２９：ＮＯ）、観客端末；ＤＳＰ４２は、ステップＳ４２６へ移行し、続いて入力される音声データパケットに対して同様の処理を繰り返す（ステップＳ４２６〜Ｓ４２９）。
【０２３９】
一方、基準時間を経過したと判定した場合には（ステップＳ４２９：ＹＥＳ）、観客端末；ＤＳＰ４２は、合奏データバッファ４４ｂから、先頭の音声データパケットを読み出す。そして、読み出した音声データの出力レベルを調整した後、Ｄ／Ａ変換回路４９へ出力する（ステップＳ４３１）。ここでＤ／Ａ変換回路４９に入力された音声データは、アナログ信号に変換された後、アンプ５０にて増幅され、合奏音声として出力される。
【０２４０】
その後、観客端末；ＤＳＰ４２は、ステップＳ４２６へ移行し、続いて入力される音声データパケットに対して、同様の処理を繰り返す（ステップＳ４２６〜Ｓ４３１）。
【０２４１】
以上のように、観客データ送信処理、合成音声再生処理を終了すると、観客端末；ＣＰＵ４１は、図１５のステップＳ３２における演奏処理を終了する。
【０２４２】
以上のように構成することで、インターネットＮを介して接続された複数の演者端末２０それぞれにおいて、入力された演奏音声のデータと、他の演者端末２０から受信した演奏データとを、パケット番号に従って合成・出力することが可能となる。即ち、各演者端末２０の間の距離に関わらず、これらの演者端末２における演奏音声を正確に同期させた、リアルタイムな合奏を実現することができる。
【０２４３】
また、観客端末４０においてこの合奏音声を出力するとともに、演者端末２０において、観客端末４０において入力された観客音声のデータを、上記合奏音声とともに再生することで、ネットワークを利用した演奏システムにおいて、観客の反応をリアルタイムに反映させることができる。
【０２４４】
更に、管理サーバ１０と演者端末２０との間のデータのやり取りを、ＰＣＭ形式のＩＰパケットにより実現することで、各演者端末２０においては、他の演者端末２０からの演奏データをリアルタイムで受信し、合奏音声を出力することができる。一方、管理サーバ１０と観客端末４０との間のデータのやり取りを、ＭＰ３形式のＩＰパケットにより実現することで、各観客端末４０においては、負荷の小さい処理で合奏音声を再生することができる。
【０２４５】
尚、本発明の適用は、上記実施の形態に限定されることなく、本発明の趣旨を逸脱しない範囲で適宜変更可能である。例えば、上記実施の形態においては、説明の簡明のため、演者端末２０と観客端末４０とを別個の端末としたが、同一の端末装置としても良い。
【０２４６】
この場合、管理サーバ１０は、図１５のステップＳ１２、或いはＳ２０において、端末装置の要求に応じて、演奏条件データ格納領域１３ａ、或いは合奏予定データ格納領域１３ｂに格納されているデータを、当該端末装置へ送信する。そして、端末装置は、これらの受信データに基づき、例えば図２６に示すように、現在、実行が決定している合奏及び他に参加する演者端末１０を募集している合奏の一覧を表示する。そして、端末装置の利用者は、これらの一覧の内から、演奏、或いは観客としての参加を希望する合奏を選択する。
更に、この時、図中下部に示されているように、利用者により指定された曲目や演奏者等に該当するデータを検索し、表示することとしてもよい。
【０２４７】
【発明の効果】
請求項１又は５記載の発明によれば、各演者端末から受信した音声データを、それぞれに対応する同期調整データに基づいて同期させた合成音声データを作成するとともに、作成した合成音声データを観客端末に配信することができる。従って、各演者端末の間の距離に影響されることなく、リアルタイムな合成音声の再生を実現することができる。
【０２４８】
請求項２記載の発明によれば、演者端末より受信した音声データに、観客端末より受信した音声データを、更に合成した音声合成データを作成し、観客端末に送信することができる。
【０２４９】
請求項３記載の発明によれば、観客端末より受信した音声データに、同期調整データを付加し、演者端末に送信することができる。即ち、演者端末においては、観客端末が発信した音声データを、上記合成音声データと同期させて再生することができる。
【０２５０】
請求項４記載の発明によれば、演者端末から受信した音声データに対する処理を、観客端末から受信した音声データに対する処理に優先して実行することができる。
【０２５１】
請求項６記載の発明によれば、サーバから受信した合成音声データを再生するとともに、入力された音声の音声データをサーバに送信することができる。
【０２５２】
請求項７記載の発明によれば、観客端末で合成音声データが再生される際に、当該観客端末から入力される観客音声データと、合成音声データとを更に合成することができる。
【図面の簡単な説明】
【図１】本実施の形態の演奏システムの構成を示す図である。
【図２】演奏システムにおけるデータの流れを示す図である。
【図３】ＩＰパケットのＩＰヘッダのフォーマットを示す図である。
【図４】ＩＰパケットの実データの構成を示す図である。
【図５】演奏システムにおける通信プロトコルのスタックを示す図である。
【図６】管理サーバ、演者端末及び観客端末それぞれが行う演奏処理の概略フローを示す図である。
【図７】管理サーバの内部構成を示す図である。
【図８】管理サーバにおける演奏データに対する処理の概念を示す図である。
【図９】管理サーバにおける観客データに対する処理の概念を示す図である。
【図１０】演奏条件データ格納領域に格納されるデータの構成を示す図である。
【図１１】合奏予定データ格納領域に格納されるデータの構成を示す図である。
【図１２】演者端末の内部構成を示す図である。
【図１３】演者端末における演奏データに対する処理の概念を示す図である。
【図１４】観客端末の内部構成を示す図である。
【図１５】合奏処理を示すフローチャートである。
【図１６】演奏開始指示画面を示す図である。
【図１７】リンク確立処理を示すフローチャートである。
【図１８】データ受信処理（管理サーバ）を示すフローチャートである。
【図１９】演奏データ受信処理（管理サーバ）を示すフローチャートである。
【図２０】観客データ受信処理（管理サーバ）を示すフローチャートである。
【図２１】合成観客データ送信処理（管理サーバ）を示すフローチャートである。
【図２２】合奏データ生成処理（管理サーバ）を示すフローチャートである。
【図２３】演奏データ送信処理（演者端末）を示すフローチャートである。
【図２４】演奏／合成観客データ受信処理（演者端末）を示すフローチャートである。
【図２５】合奏音声出力処理（演者端末）を示すフローチャートである。
【図２６】観客データ送信処理（観客端末）を示すフローチャートである。
【図２７】合奏音声再生処理を示すフローチャートである。
【図２８】演者端末と観客端末とを同一機器とした場合の表示画面例である、
【符号の説明】
１ 演奏システム
１０ 管理サーバ
１１ ＣＰＵ
１２ 記憶装置
１２ａ 合奏プログラム
１２ｂ データ受信プログラム
１２ｃ 演奏データ受信プログラム
１２ｄ 観客データ受信プログラム
１２ｅ 合成観客データ送信プログラム
１２ｆ 合奏データ生成プログラム
１３ ＲＡＭ
１３ａ 演奏条件データ格納領域
１３ｂ 合奏予定データ格納領域
１３ｃ 演奏データバッファ
１３ｄ 観客データバッファ
１３ｅ 合成観客データバッファ
１４ 通信装置
２０ 演者端末
２１ ＣＰＵ
２２ ＤＳＰ
２３ 記憶装置
２３ａ 合奏プログラム
２３ｂ リンク確立プログラム
２３ｃ 演奏データ送信プログラム
２３ｄ 演奏／合成観客データ受信プログラム
２３ｅ 合奏音声出力プログラム
２４ ＲＡＭ
２４ａ 入力バッファ
２４ｂ 演奏データバッファ
２４ｃ 合成観客データバッファ
２５ 入力装置
２６ マルチプレクサ
２７ サンプルホールド回路
２８ Ａ／Ｄ変換回路
２９ Ｄ／Ａ変換回路
３０ アンプ
３１ 表示駆動回路
３２ 表示装置
３３ 通信装置
４０ 観客端末
４１ ＣＰＵ
４２ ＤＳＰ
４３ 記憶装置
４３ａ 合奏プログラム
４３ｂ 観客データ送信プログラム
４３ｃ 合奏音声再生プログラム
４４ ＲＡＭ
４４ａ 入力バッファ
４４ｂ 合奏データバッファ
４５ 入力装置
４６ マルチプレクサ
４７ サンプルホールド回路
４８ Ａ／Ｄ変換回路
４９ Ｄ／Ａ変換回路
５０ アンプ
５１ 表示駆動回路
５２ 表示装置
５３ 通信装置
Ｎ インターネット
【発明の属する技術分野】
本発明は、サーバ、通信方法及び観客端末に関する。
【０００２】
【従来の技術】
従来、複数の装置間をネットワークで結び、各装置からの入力音声をリアルタイムに受信するとともに、これらの音声を各装置で再生させる通信システムとして、特開平１１−２１９１７４号公報に開示されているネットワーク演奏システムがある。
【０００３】
このネットワーク演奏システムにおいては、複数の端末装置それぞれが、入力された演奏パート（以下、適宜、単に「パート」という。）の音声データをＭＩＤＩファイルに変換し、インターネットを介してサーバへ送信する。そして、サーバが、各端末装置から受信した各パートの音声データに基づいて合奏データを生成し、各端末装置へ送信している。
【０００４】
【発明が解決しようとする課題】
ところで、上述のような通信システムにおいては、各装置間の距離に起因する時間遅延の問題が発生する。即ち、ネットワークとしてインターネットを利用するといった場合には、各装置間の距離が遠くなるにつれ、物理的な距離や介在するサーバの存在、通信プロトコルといった様々な要因から、受信データの時間遅延の発生は避け難いものとなり、リアルタイムの合奏を行うには不充分である。また、音声データをＭＩＤＩ形式で送信する方法では、楽曲１曲分の音声データをまとめてＭＩＤＩファイルとする必要上、リアルタイムの合奏はさらに困難になる。
【０００５】
また、演奏に参加している端末装置のみを合奏データの送信対象としているため、実際のライブ演奏のように、より多くの観客の前で演奏したい、観客の反応をリアルタイムに反映させることができなかった。
【０００６】
本発明の課題は、複数の装置から送信される音声データを同期して合成し、その合成された音声データを観客に送信できるようにすることである。
【０００７】
【課題を解決するための手段】
上記課題を解決するために、請求項１記載の発明は、
複数の演者端末複数と観客端末とに通信接続されたサーバ（例えば、図１の管理サーバ１０）において、
音声データ及び予め定められている同期調整データ（例えば、図４の送信端末識別番号及びパケット番号）を含む通信データを、前記複数の演者端末それぞれから受信する第１受信手段（例えば、図７の通信装置１４、図１５のステップＳ２７、図１９のステップＳ２１１〜Ｓ２１６）と、
この第１受信手段により受信された複数の通信データそれぞれに含まれる音声データを、当該通信データに含まれる同期調整データに従って同期して合成し、合成音声データを作成する合成音声作成手段（例えば、図７の管理サーバ；ＣＰＵ１１、図２２のステップＳ２４１〜Ｓ２４８）と、
この合成音声作成手段により作成された合成音声データを、前記観客端末に送信する合成音声送信手段（例えば、図７の通信装置１４、図２２のステップＳ２４９）と、
を備えることを特徴としている。
【０００８】
また、請求項５記載の発明は、
複数の演者端末と観客端末とに通信接続されたサーバにおける通信方法であって、
音声データ及び予め定められている同期調整データを含む通信データを、前記複数の演者端末それぞれから受信する第１受信工程（例えば、図１９のステップＳ２１１〜Ｓ２１６）と、
この第１受信工程において受信された複数の通信データそれぞれに含まれる音声データを、当該通信データに含まれる同期調整データに従って同期して合成し、合成音声データを作成する合成音声作成工程（例えば、図２２のステップＳ２４１〜Ｓ２４８）と、
この合成音声作成工程にて作成された合成音声データを、前記観客端末に送信する合成音声送信工程（例えば、図２２のステップＳ２４９）と、
を含むことを特徴としている。
【０００９】
この請求項１又は５記載の発明によれば、各演者端末から受信した音声データを、それぞれに対応する同期調整データに基づいて同期させた合成音声データを作成するとともに、作成した合成音声データを観客端末に配信することができる。従って、各演者端末の間の距離に影響されることなく、リアルタイムな合成音声の再生を実現することができる。
【００１０】
また、請求項２記載の発明のように、
請求項１記載のサーバにおいて、
前記観客端末から音声データを受信する第２受信手段（例えば、図７の通信装置１４；図２０のステップＳ２２１〜Ｓ２２５）を更に備え、
前記合成音声作成手段は、前記第１受信手段により受信される複数の通信データそれぞれに含まれる音声データを同期して合成するとともに、前記第２受信手段により受信された音声データを更に合成することにより、合成音声データを作成することとしても良い。
【００１１】
この請求項２記載の発明によれば、演者端末より受信した音声データに、観客端末より受信した音声データを、更に合成した音声合成データを作成し、観客端末に送信することができる。従って、例えば複数の演者端末にて入力された演奏音声をリアルタイムに合成しつつ、合奏音声として出力するネットワーク演奏システムで観客は、合奏に対する自身の反応が反映された合奏音声を聴くことができ、実際のライブ演奏のように、観客として参加しているかのような状態を体験することができる。
【００１２】
また、請求項３記載の発明のように、
請求項１又は２に記載のサーバにおいて、
前記観客端末から音声データを受信する第２受信手段（例えば、図７の通信装置１４；図２０のステップＳ２２１〜Ｓ２２５）と、
この第２受信手段により受信された音声データに、予め定められている同期調整データを付加して通信データを作成する作成手段（例えば、図７の管理サーバ；ＣＰＵ１１；２０のステップＳ２３１〜Ｓ２３８）と、
この作成手段により作成された通信データを、前記複数の演者端末それぞれに送信する送信手段（例えば、図７の通信装置１４；図２１のステップＳ２３９）と、
を更に備えることとしても良い。
【００１３】
この請求項３記載の発明によれば、観客端末より受信した音声データに、同期調整データを付加し、演者端末に送信することができる。即ち、演者端末においては、観客端末が発信した音声データを、上記合成音声データと同期させて再生することができる。従って、例えば演奏者は、複数の演者端末にて入力された演奏音声をリアルタイムに聴くことができるとともに、当該合奏に対する観客の反応をリアルタイムに聴くことができる。このため、実際のライブ演奏のように、多くの観客の前で演奏しているかのような状態を体験することができる。
【００１４】
尚ここで、請求項４に記載の発明のように、請求項２又は３に記載のサーバにおいて、前記合成音声作成手段は、前記第１受信手段により受信された音声データの合成を、前記第２受信手段により受信された音声データの合成に優先して実行する（例えば、図１８のステップＳ２０２〜Ｓ２０５）こととしても良い。
【００１５】
この請求項４に記載の発明によれば、演者端末から受信した音声データに対する処理を、観客端末から受信した音声データに対する処理に優先して実行することができる。従って、観客端末から受信した音声データの多少に関わらず、演者端末から受信した音声データを、遅延無く且つ正確に同期して合成した合成音声データを生成することができる。
【００１６】
また、請求項６記載の発明は、
請求項２〜４の何れか一項に記載のサーバに通信接続された観客端末（例えば、図１の観客端末４０）であって、
音声入力手段（例えば、図１４のマルチプレクサ４６に接続されるマイクロフォン）と、
前記サーバから送信される合成音声データを受信する合成音声受信手段（例えば、図１４の通信装置５３：図２７のステップＳ４２１〜Ｓ４２８）と、
この合成音声受信手段により受信された合成音声データを再生する再生手段（例えば、図１４の観客端末；ＣＰＵ４１及び観客端末；ＤＳＰ４２；図２７のステップＳ４２９〜Ｓ４３１）と、
この再生手段による再生の際に、前記音声入力手段により入力された音声を音声データとして前記サーバに送信する音声送信手段（例えば、図１４の通信装置５３；図６（ｃ）のステップＣ１〜Ｃ２、図２６のステップＳ４０１〜Ｓ４１１）と、
を備えることを特徴としている。
【００１７】
この請求項６記載の発明によれば、サーバから受信した合成音声データを再生するとともに、入力された音声の音声データをサーバに送信することができる。従って、例えば利用者は、複数の演者端末にて入力された演奏音声をリアルタイムに聴くことができるとともに、合奏に対する自身の反応がリアルタイムに反映された合奏音声を聴くことができる。このため、実際のライブ演奏のように、観客として参加しているかのような状態を体験することができる。
【００１８】
また、請求項７記載の発明は、請求項１記載のサーバであって、
前記合成音声送信手段によって送信された合成音声データの前記観客端末での再生の際に、前記観客端末において入力された観客音声データを受信する観客音声データ受信手段（例えば、図７の通信装置１４、図７の管理サーバ；ＣＰＵ１１、図６（ｂ）のステップＡ１、図２０の観客データ受信処理）と、
この観客音声データ受信手段により受信された観客音声データと、前記合成音声作成手段により合成された合成音声データとをさらに合成する観客音声データ合成手段（例えば、図７の管理サーバ；ＣＰＵ１１、管理サーバ；ＤＳＰ２１、図２１のステップＳ２３１〜Ｓ２３８、図２２のステップＳ２４１〜Ｓ２４４８）と、
をさらに備えることを特徴としている。
【００１９】
この請求項７記載の発明によれば、観客端末で合成音声データが再生される際に、当該観客端末から入力される観客音声データと、合成音声データとを更に合成することができる。従って、演奏音声と、その演奏音声に反応した観客の音声とが重畳するように合成されるため、例えば、合成された音声データを再生することにより、ライブの臨場感を得ることができる。
【００２０】
【発明の実施の形態】
以下、図面を参照し、発明の実施の形態を詳細に説明する。尚、以下においては、本発明を適用した演奏システムを例にとって説明するが、本発明の適用はこれに限らない。
【００２１】
ここで演奏システムとは、インターネットを介して接続された複数の演者端末が、それぞれに割り当てられたパートで、同時にある曲目の演奏（即ち、合奏）を行うシステムである。この時、演者端末においては、利用者によって入力されたパートの演奏音声と、他の演者端末において入力されたパートの演奏音声と、インターネットを介して接続された観客端末において入力された、拍手や歓声等の観客音声とが合成された合奏音声が、出力される。尚、各演者端末に割り当てるパートは、それぞれ異なるものであっても良いし、複数の演者端末で同一のパートを割り当てることとしても良い。
【００２２】
図１は、本実施の形態における演奏システム１の構成を示す図である。
同図によれば、演奏システム１は、管理サーバ１０、複数の演者端末２０及び複数の観客端末４０より構成される。そして、これらの機器は、インターネットＮに接続されている。尚、同図においては、３台の演者端末２０及び２台の観客端末４０が示されているが、勿論、これは何台であっても構わない。
【００２３】
管理サーバ１０は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）、記憶装置、通信装置等がシステムバスを介して接続される周知のサーバ装置により実現される。また、管理サーバ１０は、Ｗｅｂページ用ファイルを提供するＷｅｂサーバ機能、ストリーミングデータを配信するストリーミングサーバ機能及び各種データを複数機器に同時配信するマルチキャストサーバ機能を有している。尚、管理サーバ１０を複数のサーバ装置とし、それぞれが各サーバ機能を分担することとしても良い。
【００２４】
演者端末２０及び観客端末４０は、ＣＰＵ、ＲＡＭ、記憶装置、入力装置、表示装置、通信装置等がシステムバスを介して接続される、周知のＰＣ（ＰｅｒｓｏｎａｌＣｏｍｐｕｔｅｒ）により実現される。また、観客端末４０には、配信されるストリーミングデータを再生するためのストリーミング再生ソフトが、インストールされている。
【００２５】
図２は、演奏システム１における各機器の間のデータの流れを示す図である。同図（ａ）は、合奏前の様子を、同図（ｂ）は、合奏中の様子を、それぞれ示している。尚、これらのデータは、適宜暗号化され、インターネットＮを介して送受信される。
【００２６】
同図（ａ）によれば、演者端末２０は、利用者の指示入力に応じた演奏条件データを、管理サーバ１０へ送信する。この演奏条件データには、利用者が演奏を希望する曲目、パート及び日時のデータが含まれる。従って、管理サーバ１０は、各演者端末２０から送信される演奏条件データを受信する（図２（ａ）中▲１▼）。
【００２７】
また、管理サーバ１０は、これらの演奏条件データに基づき、合奏に参加する演者端末２０を特定する。そして、特定した各演者端末２０に対して、当該合奏の予定を示す合奏予定データを送信する。この合奏予定データには、当該合奏を予定する日時、曲目及び参加する演者端末２０を示すデータが含まれている。従って、合奏に参加予定の各演者端末２０は、管理サーバ１０から送信される合奏予定データを受信する（図２（ａ）中▲２▼）。
【００２８】
また、管理サーバ１０は、観客端末４０の要求に応じて、現在予定されている全ての合奏に関する合奏予定データを送信する。従って、観客端末４０は、管理サーバ１０から送信される合奏予定データを受信する（同図（ａ）中▲３▼）。
【００２９】
また、観客端末４０は、上記受信した合奏予定データに基づき、利用者の指示入力に応じた参加予定データを、管理サーバ１０へ送信する。この参加予定データには、上記現在予定されている全ての合奏の内、観客端末４０の利用者が観客として参加を希望する合奏を指定するデータが含まれている。従って、管理サーバ１０は、各観客端末４０から送信される参加予定データを受信する（図（ａ）中▲４▼）。
【００３０】
一方、同図（ｂ）によれば、合奏が予定された日時となると、管理サーバ１０は、当該合奏に参加予定の演者端末２０及び観客端末４０それぞれに対して、演奏開始を指示する（同図（ｂ）中▲１▼）。
【００３１】
そして、管理サーバ１０から演奏開始が指示された演者端末２０は、先に受信した合奏予定データに基づき、当該合奏に参加する他の演者端末２０との演奏データ（利用者により入力された演奏音声のデータ）の送受信を行うとともに、管理サーバ１０から送信される合成観客データを受信し、合奏を実現する（同図（ｂ）中▲２▼、▲３▼）。具体的には、演者端末２０は、利用者により入力された演奏音声に応じた演奏データと、他の演者端末２０より受信した演奏データと、管理サーバ１０から受信した合成観客データとを合成し、合奏音声として出力する。
【００３２】
また、管理サーバ１０から演奏開始が指示された観客端末４０は、利用者により入力された観客音声のデータ（以下、適宜「観客データ」という。）を、管理サーバ１０へ送信する。それとともに、管理サーバ１０からストリーミング配信される合奏データを受信し、この合奏データに基づく合奏音声を出力する（同図（ｂ）中▲４▼、▲５▼）。
【００３３】
一方、管理サーバ１０は、各観客端末４０から受信した観客データを合成し、合成観客データとして各演者端末２０へ送信する（同図（ｂ）中▲３▼）。それととともに、各演者端末２０から受信した演奏データと、上記合成観客データとを合成し、合奏データとして、各観客端末４０へストリーミング配信する（同図（ｂ）中▲４▼）。
【００３４】
また、本実施の形態においては、通信プロトコルとして、ＵＤＰ／ＩＰが採用されている。即ち、インターネットＮを経由した管理サーバ１０、演者端末２０及び観客端末４０の間のデータ通信は、各機器に割り当てられたＩＰアドレスに基づくＩＰパケットの送受信によって、実現される。
【００３５】
具体的には、合奏中における各種データの送受信（同図（ｂ）参照）は、マルチキャストＩＰアドレス、詳細には、合奏に参加している演者端末２０をグループ化した演者用マルチキャストＩＰアドレス及び当該合奏に観客として参加している観客端末４０をグループ化した観客用マルチキャストＩＰアドレスに基づき、実現される。
【００３６】
即ち、演者端末２０は、当該演者端末２０自身の演奏データを、演者用マルチキャストＩＰアドレス宛に送信する。そして、管理サーバ１０は、この演者用マルチキャストＩＰアドレス宛に送信された演奏データを、当該演者用マルチキャストＩＰアドレスによってグループ化された他の演者端末２０へ一斉配信する（同図（ｂ）中▲２▼）。
【００３７】
また、管理サーバ１０は、合成観客データを、演者用マルチキャストＩＰアドレスによってグループ化された各演者端末２０へ一斉配信するとともに（同図（ｂ）中▲３▼）、合奏データを、観客用マルチキャストＩＰアドレスによってグループ化された観客端末４０へ一斉配信する（同図（ｂ）中▲４▼）。
【００３８】
図３は、ＩＰパケットに含まれるＩＰヘッダのフォーマットを示す図である。同図によれば、ＩＰヘッダは、準拠しているＩＰ規格のバージョン（即ち“６”）、当該ＩＰパケットの優先度、通信帯域の予約を保証するためのフローラベル、実データの大きさを示すペイロード長、後続ヘッダのＩＤを示すネクストヘッダ、ルータによる中継限界数を示すホップリミット、送信元の機器のＩＰアドレスを示す送信元ＩＰアドレス及び宛先の機器のＩＰアドレスを示す宛先ＩＰアドレスより構成される。
【００３９】
また、図４は、ＩＰパケットに含まれる実データ（ペイロード部）のデータ構成を示す図である。尚、同図においては、合奏時に管理サーバ１０と演者端末２０との間で送受信される演奏データについてのデータ構成を示している。
同図によれば、ＩＰパケットに含まれる実データは、指示ヘッダ及び音声データより構成される。
【００４０】
指示ヘッダには、データ識別、送信元の機器を示す送信端末識別番号、上記送信元の機器から送信された何番目のＩＰパケットであるかを示すパケット番号、音声データの記録方式（符号化方式）を示す音声記録方式（即ち、“ＰＣＭ”）、その際のパラメータであるサンプリングレート（サンプリング周波数）、ビット数（量子化ビット数）、ビットレート、そして音声データに対するエフェクトを示すエフェクト条件が含まれている。
【００４１】
ここで、送信端末識別番号及びパケット番号を合わせて、「同期調整データ」という。この同期調整データは、後述のように、演奏データを同期合成するために用いられる。
【００４２】
データ識別とは、演奏システム１で送受信される当該ＩＰパケットの種類を示すものであり、具体的には、“演奏データ”であるか否かを示す。
【００４３】
エフェクトとは、音声データに対して付加する音響効果を意味しており、例えば、エコーやリバーブ（残響）、トーンコントロールの度合、音量バランスの変更、ステレオ化の有無等が該当する。
【００４４】
また、音声データは、アナログ信号である演奏音声を、ＰＣＭ（Ｐｕｌｓｅ Ｃｏｄｅ Ｍｏｄｕｌａｔｉｏｎ）方式によってデジタル信号に変換したデータであり、１つのＩＰパケットにつき、５１２サンプリング分のデータが含まれる。即ち、演奏データは、管理サーバ１０と演者端末２０との間で、５１２サンプリング分を単位としてやり取りされる。以下、この１パケット分（即ち、５１２サンプリング分）の音声データを、適宜「音声データパケット」という。
【００４５】
一方、合奏時に管理サーバ１０と観客端末４０との間で送受信される観客データ及び合奏データについては、次の点で上記演奏データと異なる。即ち、音声データには、１つのＩＰパケットにつき、１０２４サンプリング分のデータが含まれる。また、この音声データは、ＭＰ３方式に従って圧縮・符号化されたデータである。即ち、観客データ及び合奏データは、管理サーバ１０と観客端末４０との間で、１０２４サンプリング分を単位としてやり取りされる。以下、この１パケット分（即ち、１０２４サンプリング分）の音声データについて、適宜「音声データパケット」という。
【００４６】
図５は、演奏システム１における通信プロトコルのスタックを示す図である。同図によれば、通信プロトコルは、下位層から順に、イーサネット（登録商標）層（ＰＰＰｏｖｅｒＥｔｈｅｒ）、ＩＰ層（ネットワーク層）、ＵＤＰ層（トランスポート層）及びアプリケーション層（ＡＰＩを含む）より構成される。
【００４７】
即ち、ある機器が他の機器から受信したＩＰパケットは、イーサネット（登録商標）層を介してＩＰ層へ渡され、このＩＰ層にて、暗号解読処理がなされる。その後、ＵＤＰ層を経由して、アプリケーション層に渡される。アプリケーション層では、ＩＰパケットの実データに含まれる音声データが、音声データパケットとして、指示ヘッダとともに抜き出される。
【００４８】
また、利用者により入力された演奏音声や観客音声等の音声データは、アプリケーション層において音声データパケットに変換され、続いて、ＵＤＰ層、ＩＰ層へ渡される。そして、ＩＰ層にて暗号化処理がなされるとともに、ＩＰパケット化される。生成されたＩＰパケットは、イーサネット（登録商標）層を経由し、外部の他の機器へ送信される。
【００４９】
ここで、ＩＰ層にて実現されるデータの暗号／復号化について説明する。
暗号化とは、インターネット等のネットワークを通じて文書や画像等のデジタルデータをやりとりする際に、通信途中で第三者に盗み見られたり改ざんされることを防ぐため、予め定められた規則に従ってデータを変換し、解読が極めて困難な状態にすることである。そして、暗号化されたデータを元に戻し、解読可能な状態にすることを復号化という。
【００５０】
また、一般に、暗号／復号化には、暗号表にあたる「鍵」を使用するが、対になる２つの鍵を使う公開鍵暗号方式と、どちらにも同じ鍵を用いる共通鍵暗号方式とがある。前者にはＲＳＡ、ＥｌＧａｍａｌ暗号、楕円曲線暗号等があり、後者には米国政府標準のＤＥＳやＩＤＥＡ、ＦＥＡＬ、ＭＩＳＴＹ等があり、本実施の形態では上記の何れを使うこととしても良い。
【００５１】
次に、管理サーバ１０、演者端末２０及び観客端末４０の内部構成について、図７〜図１４を参照して説明する。
【００５２】
図７は、管理サーバの構成を示すブロック図である。
同図によれば、管理サーバ１０は、管理サーバ；ＣＰＵ１１、記憶装置１２、ＲＡＭ１３及び通信装置１４により構成され、各部は、システムバス１５によりデータ通信可能に接続されている。
【００５３】
管理サーバ；ＣＰＵ１１は、記憶装置１２に記憶される各種処理プログラムに基づいて、管理サーバ１０を構成する各部を集中制御する。具体的には、通信装置１４から入力される信号に応答して、記憶装置１２に記憶されている処理プログラムを読み出してＲＡＭ１３に一時記憶させるとともに、係る処理プログラムに基づく処理を実行して、管理サーバ１０を機能させる。その際、管理サーバ；ＣＰＵ１１は、処理結果をＲＡＭ１３内の所定領域に格納するとともに、必要に応じて、その処理結果を通信装置１４から外部機器へ送信する。
【００５４】
また、管理サーバ；ＣＰＵ１１は、本実施の形態の特徴的な処理として、後述する合奏処理（図１５参照）、データ受信処理（図１８参照）、演奏データ受信処理（図１９参照）、観客データ受信処理（図２０参照）、合成観客データ送信処理（図２１参照）及び合奏データ生成処理（図２２参照）を実行する。
【００５５】
具体的には、合奏処理において、管理サーバ；ＣＰＵ１１は、演者端末２０から送信される演奏条件データを受信すると、受信した演奏条件データを、ＲＡＭ１３内の演奏条件データ格納領域１３ａに格納する。そして、この演奏条件データに適合するデータを、演奏条件データ格納領域１３ａに格納されているデータの内から検索し、合奏に参加可能な演者端末２０を特定する。
【００５６】
それとともに、管理サーバ；ＣＰＵ１１は、上記特定した演者端末２０をグループ化した演者用マルチキャストＩＰアドレス及び観客として参加することとなる観客端末４０をグループ化する観客用マルチキャストＩＰアドレスを設定する。
【００５７】
そして、これら設定した演者用マルチキャストＩＰアドレス及び観客用マルチキャストＩＰアドレスを含む合奏予定データを、ＲＡＭ１３内の合奏予定データ格納領域１３ｂに格納するとともに、上記特定した各演者端末２０に対して、この合奏予定データを送信する。
【００５８】
また、管理サーバ；ＣＰＵ１１は、観客端末４０の要求に応じ、合奏予定データ格納領域１３ｂに格納されている合奏予定データを、当該観客端末４０に送信するとともに、観客端末４０から送信される参加予定データを受信し、受信した参加予定データを、合奏予定データ格納領域１３ｂに格納する。
【００５９】
更に、管理サーバ；ＣＰＵ１１は、合奏を予定している日時の所定時間前となると、当該合奏に参加予定の演者端末２０及び観客端末４０に対して、演奏開始を指示する。
【００６０】
データ受信処理において、管理サーバ；ＣＰＵ１１は、受信したデータ、即ち入力されたＩＰパケットが演奏データであるか観客データであるかを判定するとともに、演奏データであると判定した場合には、観客データ受信処理（図２０参照）に優先して演奏データ受信処理（図１９参照）を実行する。
【００６１】
演奏データ受信処理において、管理サーバ；ＣＰＵ１１は、各演者端末２０から受信した演奏データ、即ちＩＰパケットから５１２サンプリング分の音声データを抜き出し、所定の音響効果処理を行った後、送信元である演者端末２０毎に、演奏データバッファ１３ｃに格納する。
【００６２】
観客データ受信処理において、管理サーバ；ＣＰＵ１１は、各観客端末４０から受信した観客データ、即ちＩＰパケットから１０２４サンプリング分の音声データを抜き出し、ＭＰ３フォーマットからＰＣＭフォーマットに変換した後、観客データバッファ１３ｄに格納する。
【００６３】
合成観客データ送信処理において、管理サーバ；ＣＰＵ１１は、所定時間毎に、観客データバッファ１３ｄに格納されている音声データパケットを読み出して音合成した後、所定の音響効果処理を行う。そして、この合成後の音声データパケットを、合成観客データバッファ１３ｅに格納するとともにＩＰパケット化し、合成観客データとして、各演者端末２０へ送信する。
【００６４】
また、合奏データ生成処理において、管理サーバ；ＣＰＵ１１は、演奏データバッファ１３ｃに格納されている音声データパケットの内、所定のパケット番号のものを全て読み出して音合成（同期合成）する。それとともに、合成観客データバッファ１３ｅに格納されている音声データパケットを読み出して、上記同期合成後の音声データパケットと音合成する。そして、この合成後の音声データパケットをＩＰパケット化し、合奏データとして、各観客端末４０へ送信する。
【００６５】
図８は、管理サーバ；ＣＰＵ１１が、演奏データに対して行う処理の概念を示す図である。尚、同図においては、管理サーバ１０が、３台の他の演者端末２０（以下、それぞれを、適宜「演者端末Ａ」、「演者端末Ｂ」及び「演者端末Ｂ」という。）から送信される演奏データを受信する場合について、示している。
【００６６】
管理サーバ１０が受信する演奏データは、上述のように、ＩＰパケットとして管理サーバ；ＣＰＵ１１へ入力される。同図においては、このＩＰパケットを簡略し、送信端末識別番号とパケット番号とから構成される同期調整データ及び音声データのみで表しているともに、管理サーバ；ＣＰＵ１１への入力順に、図中左より示している。
【００６７】
また、送信端末識別番号“Ａ”は演者端末Ａを、送信端末識別番号“Ｂ”は演者端末Ｂを、そして送信端末識別番号“Ｃ”は送信端末Ｃを、それぞれ示している。
【００６８】
そして、音声データ“データＡｈ”は、演者端末Ａから受信したパケット番号“ｈ”のＩＰパケットの音声データパケットを、音声データ“データＢｉ”は、演者端末Ｂから受信したパケット番号“ｉ”のＩＰパケットの音声データパケットを、そして音声データ“データＣｊ”は、演者端末Ｃより受信したパケット番号“ｊ”のＩＰパケットの音声データパケットを、それぞれ示している。
【００６９】
同図（ａ）によれば、管理サーバ；ＣＰＵ１１は、入力されたＩＰパケットから音声データを抜き出す。そして、この音声データを１つの音声データパケットとし、付加されている端末識別番号に従って送信元の演者端末２０毎に振り分けるとともに、パケット番号に従って並べ替える。即ち、同図（ａ）においては、図中上から、演者端末Ａ、Ｂ、Ｃの順に振り分けた様子を示している。
【００７０】
次いで、同図（ｂ）によれば、管理サーバ；ＣＰＵ１１は、これらの音声データパケットそれぞれに対し、指定されたエフェクト条件に基づいた音響効果処理を行う。即ち、エコーやリバーブ、トーンコントロール等のエフェクトを、指定された度合で付加するとともに、指定されたＬ／Ｒ比のステレオデータに変換する。
【００７１】
例えば、音声データ“データＡ０”に対し、所定のエフェクトを付加するとともに、指定されたＬ／Ｒ比のステレオデータ、即ちＬチャネルの音声データ“データＡ０Ｌ”及びＲチャネルの音声データ“データＡ０Ｒ”を生成する。
【００７２】
また、音声データ“データＢ０”及び“データＣ０”についても同様に、所定のエフェクトを付加し、指定されたＬ／Ｒ比で、Ｌチャネルの音声データ“データＢ０Ｌ”及び“データＣ０Ｌ”、そしてＲチャネルの音声データ“データＢ０Ｒ”及び“データＣ０Ｒ”を、それぞれ生成する。
【００７３】
その後、同図（ｃ）によれば、管理サーバ；ＣＰＵ１１は、これらの音声データパケットを合成し、合成演奏データを生成する。具体的には、これらの音声データパケットの内、パケット番号が同一のもの同士を、チャネル毎に合成する。
【００７４】
例えば、パケット番号“０”については、音声データ“データＡ０Ｌ”、“データＢ０Ｌ”及び“データＣ０Ｌ”を合成し、Ｌチャネルの音声データ“データＡ０Ｌ＋Ｂ０Ｌ＋Ｃ０Ｌ”を生成するとともに、音声データ“データＡ０Ｒ”、“データＢ０Ｒ”及び“データＣ０Ｌ”を合成し、Ｒチャネルの音声データ“データＡ０Ｒ＋Ｂ０Ｒ＋Ｃ０Ｒ”を生成する。
【００７５】
また、パケット番号“１”についても同様に、音声データ“データＡ１Ｌ”、“データＢ１Ｌ”及び“データＣ１Ｌ”を合成し、Ｌチャネルの音声データ“データＡ１Ｌ＋Ｂ１Ｌ＋Ｃ１Ｌ”を生成するとともに、音声データ“データＡ１Ｒ”、“データＢ１Ｒ”及び“データＣ１Ｒ”を合成し、Ｒチャネルの音声データ“データＡ１Ｒ＋Ｂ１Ｒ＋Ｃ１Ｒ”を生成する。
【００７６】
図９は、管理サーバ；ＣＰＵ１１が、観客データに対して行う処理の概念を示す図である。尚、同図においては、管理サーバ１０が、２台の観客端末４０（以下、それぞれを、適宜「観客端末ａ」及び「観客端末ｂ」という。）から送信される観客データを受信する場合について、示している。
【００７７】
管理サーバ１０が受信する観客データは、上述のように、ＩＰパケットとして管理サーバ；ＣＰＵ１１へ入力される。同図においては、このＩＰパケットを簡略し、音声データのみで表しているとともに、管理サーバ；ＣＰＵ１１への入力順に、図中左より示している。
【００７８】
また、音声データ“データａｈ”は、観客端末ａから受信したｈ番目の音声データパケットを、そして、音声データ“データｂｉ”は、観客端末ｂから受信したｉ番目の音声データパケットを、それぞれ示している。
【００７９】
同図（ａ）によれば、管理サーバ；ＣＰＵ１１は、所定時間の間に入力されたＩＰパケットそれぞれから音声データを抜き出すとともに、これらの音声データを１組のデータとする。即ち、同図（ａ）においては、音声データ“データａ０”及び“データａ１”を１組に、音声データ“データｂ０”、“データｂ２”及び“データａ２”を１組とした様子を示している。
【００８０】
次いで、同図（ｂ）によれば、管理サーバ；ＣＰＵ１１は、これらの音声データパケットを、上記組毎に合成する。即ち、音声データ“データａ０”及び“データａ１”を合成し、音声データ“データａ０＋ａ１”を生成する。また、音声データ“データｂ０”、“データｂ２”及び“データａ２”を合成し、音声データ“データｂ０＋ｂ２＋ａ２”を生成する。
【００８１】
その後、同図（ｃ）によれば、管理サーバ；ＣＰＵ１１は、合成後の音声データパケットそれぞれに対し、指定されたエフェクト条件に基づいた音響効果処理を行い、合成観客データを生成する。即ち、エコーやリバーブ、トーンコントロール等のエフェクトを、指定された度合で付加するとともに、指定されたＬ／Ｒ比のステレオデータに変換する。
【００８２】
例えば、音声データ“データａ０＋ａ１”に対し、所定のエフェクトを付加するとともに、指定されたＬ／Ｒ比のステレオデータ、即ち、Ｌチャネルの音声データ“データａ０Ｌ＋ａ１Ｌ”及びＲチャネルの音声データ“データａ０Ｒ＋ａ１Ｒ”を生成する。
【００８３】
また、音声データ“データｂ１＋ｂ２＋ａ２”についても同様に、所定のエフェクトを付加し、指定されたＬ／Ｒ比で、Ｌチャネルの音声データ“データｂ１Ｌ＋ｂ２Ｌ＋ａ２Ｌ”及びＲチャネルの音声データ“データｂ１Ｒ＋ｂ２Ｒ＋ａ２Ｒ”を生成する。
【００８４】
このように、各演奏データを合成した合成演奏データ（即ち、図８（ｃ）の状態）及び各観客データを合成した合成観客データ（即ち、図９（ｃ）の状態）を生成すると、管理サーバ；ＣＰＵ１１は、生成した合成観客データを演者端末２０へ送信する。それとともに、上記合成演奏データ及び合成観客データを合成して合奏データを生成し、観客端末４０へ送信する。
【００８５】
図７において、記憶装置１２は、ハードディスク等により構成されるものであり、管理サーバ１０の動作に係る各種処理プログラムや、本実施の形態の機能を実現するためのプログラム（具体的には、合奏プログラム１２ａ、データ受信プログラム１２ｂ、演奏データ受信プログラム１２ｃ、観客データ受信プログラム１２ｄ、合成観客データ送信プログラム１２ｅ及び合奏データ生成プログラム１２ｆ）及びこれらのプログラムの実行に係る処理データ等を記憶する。
【００８６】
ＲＡＭ１３は、管理サーバ；ＣＰＵ１１により実行される各プログラムを実行するためのプログラムエリア（不図示）、入力指示や入力データ、上記プログラムが実行される際に生じる処理結果等を一時的に格納するワークメモリエリアを備えている。また、このワークメモリエリアには、演奏条件データ格納領域１３ａ、合奏予定データ格納領域１３ｂ、演奏データバッファ１３ｃ、観客データバッファ１３ｄ及び合成観客データバッファ１３ｅが形成される。
【００８７】
演奏条件データ格納領域１３ａは、演者端末２０から受信した演奏条件データが格納される領域であり、図１０に、そのデータ構成を示す。
図１０は、演奏条件データ格納領域１３ａに格納されるデータの構成を示す図である。
同図によれば、演奏条件データ格納領域１３ａには、演奏を希望する曲目、パート及び日時を含む演奏条件とＩＰアドレスとが対応付けて格納される。また、この演奏条件は、演者端末２０から受信した演奏条件データに該当する。
【００８８】
即ち、演奏条件データ格納領域１３ａには、演者端末２０から演奏条件データ及びＩＰアドレスを受信する毎に、これらのデータが対応付けられて追加格納される。そして、管理サーバ；ＣＰＵ１１により互いに適合するものが検索され、合奏予定データが生成されると、該当するデータが、演奏条件データ格納領域１３ａから削除される。
【００８９】
合奏予定データ格納領域１３ｂは、合奏予定データが格納される領域であり、図１１に、そのデータ構成を示す。
図１１は、合奏予定データ格納領域に格納されるデータの構成を示す図である。
同図によれば、合奏予定データ格納領域１３ｂには、予定している合奏毎に、日時、曲目、各パートに割り当てられた演者端末２０のＩＰアドレス、演者用マルチキャストＩＰアドレス、観客として参加予定の観客端末４０のＩＰアドレス及び観客用マルチキャストＩＰアドレスが、対応付けて格納される。
【００９０】
即ち、観客端末４０から演奏予定データを受信する毎に、ともに受信したＩＰアドレスが、該当する観客端末４０のＩＰアドレスとして追加格納される。また、これらのデータは、合奏を予定する日時が現在時刻に近い順に格納されている。
【００９１】
演奏データバッファ１３ｃは、演者端末２０から受信した演奏データが格納される領域である。具体的には、図８（ｂ）に示すように、送信元の演者端末２０毎に、管理サーバ；ＣＰＵ１１によって音響効果処理が行われた音声データパケットが、パケット番号に従って格納される。
【００９２】
観客データバッファ１３ｄは、観客端末４０から受信した観客データが格納される領域である。具体的には、図９（ａ）に示すように、送受信した音声データパケットが、その受信順に格納される。
【００９３】
合成観客データバッファ１３ｅは、合成観客データが格納される領域である。具体的には、図９（ｃ）に示すように、管理サーバ；ＣＰＵ１１によって音響効果処理が行われた音声データパケットが、その生成順に格納される。
【００９４】
図７において、通信装置１４は、インターネットＮを介して他の機器とのデータ通信を行うためのインターフェースであり、ルータ等により構成される
【００９５】
図１２は、演者端末２０の構成を示すブロック図である。
同図によれば演者端末２０は、演者端末；ＣＰＵ２１、演者端末；ＤＳＰ２２、記憶装置２３、ＲＡＭ２４、入力装置２５、マルチプレクサ２６、サンプルホールド回路２７、Ａ／Ｄ（Ａｎａｌｏｇ−Ｄｉｇｉｔａｌ）変換回路２８、Ｄ／Ａ（Ｄｉｇｉｔａｌ−Ａｎａｌｏｇ）変換回路２９、アンプ３０、表示駆動回路３１、表示装置３２及び通信装置３３より構成される。
【００９６】
演者端末；ＣＰＵ２１は、記憶装置２３に記憶される各種処理プログラムに基づいて、演者端末２０を構成する各部を集中制御する。具体的には、入力装置２５、或いは通信装置３３から入力される信号に応答して、記憶装置２３に記憶されている処理プログラムを読み出してＲＡＭ２４に一時記憶させるとともに、係る処理プログラムに基づく処理を実行して、演者端末２０を機能させる。その際、演者端末；ＣＰＵ２１は、処理結果をＲＡＭ２４内の所定領域に格納するとともに、必要に応じて、その処理結果を、表示装置３２に表示するとともに、通信装置３３から外部機器へ送信する。
【００９７】
また、演者端末；ＣＰＵ２１は、本実施の形態の特徴的な処理として、後述する合奏処理（図１５参照）、リンク確立処理処理（図１７参照）演奏データ送信処理（図２３参照）及び演奏／合成観客データ受信処理（図２４参照）を実行する。
【００９８】
具体的には、合奏処理において、演者端末；ＣＰＵ２１は、利用者の入力指示に応じた演奏条件データを、当該演者端末２０のＩＰアドレスとともに、管理サーバ１０へ送信する。それとともに、管理サーバ１０から送信される合奏予定データを受信する。
【００９９】
そして、管理サーバ１０より演奏開始を指示されると、演者端末；ＣＰＵ２１は、リンク確立処理、次いで演奏処理を実行する。また、この演奏処理において、演者端末；ＣＰＵ２１は、演奏データ送信処理（図２３参照）、及び演奏／合成観客データ受信処理（図２４参照）を実行するともに、演者端末；ＤＳＰ２２に、後述する演奏データ送信処理（図２３参照）、演奏／合成観客データ受信処理（図２４参照）及び合奏音声出力処理（図２５参照）を実行させる。
【０１００】
リンク確立処理において、演者端末；ＣＰＵ２１は、管理サーバ１０から受信した合奏予定データに基づき、合奏に参加する他の演者端末２０に対して、利用者により入力された接続条件を送信（提示）する。それとともに、この接続条件と、他の演者端末２０から受信した接続条件とを照合し、当該合奏における接続条件を決定する。
【０１０１】
ここで、接続条件には、通信条件及びエフェクト条件が含まれる。
通信条件とは、演者端末２０及び管理サーバ１０の間のデータ通信に関する条件であり、具体的には、入力された演奏音声の符号化方式（サンプリング周波数や量子化ビット数等のパラメータを含む）や、これらの機器の間でデータ通信を行う際の接続レート（伝送速度）等が該当する。そして、この通信条件は、各演者端末２０や管理サーバ１０のスペック等に応じて設定可能な条件の内から、利用者の指示により、或いは最適なものが自動的に決定される。
【０１０２】
また、エフェクト条件とは、上述のように、演奏音声に対する音響効果に関する条件であり、具体的には、エコーやリバーブ（残響）、トーンコントロールの度合、音量バランス、ステレオ化の有無やそのＬ／Ｒ比等が該当する。そして、このエフェクト条件は、想定する演奏場所（例えば、コンサートホールや野外ステージ、ライブハウス等）に応じて、合奏音声に施すエコーやリバーブ（残響）、トーンコントロール等の度合が決定されたり、或いは想定するステージ上における各パートの位置（例えば、中央にボーカル、右にギター、左にベース等）に応じて、当該各パートの音声の音量バランスや、ステレオ音声として出力する際の左右バランス（Ｌ／Ｒ比）が決定される。
【０１０３】
演奏データ送信処理において、演者端末；ＣＰＵ２１は、演者端末；ＤＳＰ２２から入力される音声データパケットをＩＰパケット化し、演奏データとして、管理サーバ１０及び他の演者端末２０へ送信する。
【０１０４】
また、演奏／合成観客データ受信処理において、演者端末；ＣＰＵ２１は、各演者端末２０から受信した演奏データ、或いは管理サーバ１０から受信した合成観客データ、即ちＩＰパケットから音声データを抜き出し、１つの音声データパケットとして、演者端末；ＤＳＰ２２へ出力する。
【０１０５】
図１２において、演者端末；ＤＳＰ２２は、デジタルデータの高速処理に特化したプロセッサである。また、演者端末；ＤＳＰ２２は、本実施の形態の特徴的な処理として、後述する演奏データ送信処理（図２３参照）、演奏／合成観客データ受信処理（図２４参照）及び合奏音声出力処理（図２５参照）を実行する。
【０１０６】
具体的には、演奏データ送信処理において、演者端末；ＤＳＰ２２は、サンプリング周期毎に、Ｄ／Ａ変換回路２９から入力される音声データを入力バッファ２４ａに格納するとともに、５１２サンプリング分の音声データを１つの音声データパケットとして、演者端末；ＣＰＵ２１へ出力する。それとともに、この音声データパケットに対して所定の音響効果処理を行った後、演奏データバッファ２４ｂに格納する。
【０１０７】
演奏／合成観客データ受信処理において、演者端末；ＤＳＰ２２は、演者端末；ＣＰＵ２１から入力された音声データパケットが演奏データであれば、所定の音響効果処理を行った後、演奏データバッファ２４ｂに格納する。一方、演者端末；ＣＰＵ２１から入力された音声データパケットが合成観客データであれば、合成観客データバッファ２４ｃに格納する。
【０１０８】
また、合奏音声出力処理において、演者端末；ＤＳＰ２２は、演奏データバッファ２４ｂに格納されている音声データパケットの内、所定のパケット番号のものを読み出して音合成（同期合成）する。それとともに、合成観客データバッファ２４ｃに格納されている音声データパケットを読み出して、上記同期合成後の音声データパケットと音合成する。そして、この合成後の音声データパケットを、Ｄ／Ａ変換回路２９へ出力する。
【０１０９】
図１３は、演者端末；ＣＰＵ２１及び演者端末；ＤＳＰ２２が、演奏データに対して行う処理の概念を示す図である。尚、同図においては、演者端末２０（以下、適宜「演者端末Ａ」という。）が、２台の他の演者端末２０（以下、それぞれを、適宜「演者端末Ｂ」及び「演者端末Ｃ」という。）から送信される演奏データを受信する場合について、示している。
【０１１０】
演者端末２０が受信する演奏データは、上述のように、ＩＰパケットとして演者端末；ＣＰＵ２１へ入力される。同図においては、このＩＰパケットを簡略し、送信端末識別番号及びパケット番号より構成される同期調整データ及び音声データのみで表しているとともに、演者端末；ＣＰＵ２１への入力順に、図中左より示している。
【０１１１】
また、送信端末識別番号“Ａ”は演者端末Ａ自身を、送信端末識別番号“Ｂ”は演者端末Ｂを、そして送信端末識別番号“Ｃ”は演者端末Ｃを、それぞれ示している。
【０１１２】
また、音声データ“データＡｈ”は、演者端末Ａ自身に入力されたパケット番号“ｈ”のＩＰパケットの音声データパケットを、音声データ“データＢｉ”は、演者端末Ｂから受信したパケット番号“ｉ”のＩＰパケットの音声データパケットを、そして、音声データ“データＣｊ”は、演者端末Ｃから受信したパケット番号“ｊ”のＩＰパケットの音声データパケットを、それぞれ示している。
【０１１３】
同図（ａ）によれば、演者端末；ＣＰＵ２１は、入力されたＩＰパケットから音声データを抜き出す。そして、この音声データを１つの音声データパケットとし、付加されている端末識別番号に従って送信元の演者端末２０毎に振り分けるとともに、パケット番号に従って並べ替える。即ち、同図（ａ）においては、図中上から、演者端末Ａ、Ｂ、Ｃの順に振り分けた様子を示している。
【０１１４】
次いで、同図（ｂ）によれば、演者端末；ＤＳＰ２２は、これらの音声データパケットそれぞれに対し、指定されたエフェクト条件に基づいた音響効果処理を行う。即ち、エコーやリバーブ、トーンコントロール等のエフェクトを、指定された度合で付加するとともに、指定されたＬ／Ｒ比のステレオデータに変換する。
【０１１５】
例えば、音声データ“データＡ０”に対し、所定のエフェクトを付加するとともに、指定されたＬ／Ｒ比のステレオデータ、即ち、Ｌチャネルの音声データ“データＡ０Ｌ”及びＲチャネルの音声データ“データＡ０Ｒ”を生成する。
【０１１６】
また、音声データ“データＢ０”及び“データＣ０”についても同様に、所定のエフェクトを付加し、指定されたＬ／Ｒ比で、Ｌチャネルの音声データ“データＢ０Ｌ”及び“データＣ０Ｌ”、そしてＲチャネルの音声データ“データＢ０Ｒ”及び“データＣ０Ｒ”を、それぞれ生成する。
【０１１７】
その後、同図（ｃ）によれば、演者端末；ＤＳＰ２２は、これらの音声データパケットを合成し、合成演奏データを生成する。具体的には、これらの音声データパケットの内、パケット番号が同一のもの同士を、チャネル毎に合成する。
【０１１８】
例えば、パケット番号“０”については、音声データ“データＡ０Ｌ”、“データＢ０Ｌ”及び“データＣ０Ｌ”を合成し、Ｌチャネルの音声データ“データＡ０Ｌ＋Ｂ０Ｌ＋Ｃ０Ｌ”を生成するとともに、音声データ“データＡ０Ｒ”、“データＢ０Ｒ”及び“データＣ０Ｌ”を合成し、Ｒチャネルの音声データ“データＡ０Ｒ＋Ｂ０Ｒ＋Ｃ０Ｒ”を生成する。
【０１１９】
また、パケット番号“１”についても同様に、音声データ“データＡ０Ｌ”、“データＢ０Ｌ”及び“データＣ０Ｌ”を合成し、Ｌチャネルの音声データ“データＡ０Ｌ＋Ｂ０Ｌ＋Ｃ０Ｌ”を生成するとともに、音声データ“データＡ０Ｒ”、“データＢ０Ｒ”、及び“データＣ０Ｌ”を合成し、Ｒチャネルの音声データ“データＡ０Ｒ＋Ｂ０Ｒ＋Ｃ０Ｒ”を生成する。
【０１２０】
このように、各演奏データを合成した合成演奏データ（即ち、同図（ｃ）の状態）を生成すると、演者端末；ＤＳＰ２２は、この合成演奏データと、管理サーバ１０から受信した合成観客データとを合成し、合奏データを生成する。尚、ここで生成された合奏データは、Ｄ／Ａ変換回路２９へ出力された後、アンプ３０にて増幅され、合奏音声として出力される。
【０１２１】
図１２において、記憶装置２３は、演者端末２０の動作に係る各種処理プログラムや、本実施の形態の機能を実現するためのプログラム（具体的には、合奏プログラム２３ａ、リンク確立プログラム２３ｂ、演奏データ送信プログラム２３ｃ、演奏／合成観客データ受信プログラム２３ｄ、合奏音声出力プログラム２３ｅ）及びこれらのプログラムの実行に係る処理データ等を記憶する。
【０１２２】
ＲＡＭ２４は、演者端末；ＣＰＵ２１により実行される各プログラムを実行するためのプログラムエリア（不図示）、入力指示や入力データ、上記プログラムが実行される際に生じる処理結果等を一時的に格納するワークメモリエリアを備えている。また、このワークメモリエリアには、入力バッファ２４ａ、演奏データバッファ２４ｂ及び合成観客データバッファ２４ｃが形成される。
【０１２３】
入力バッファ２４ａは、利用者によって入力された演奏音声のデータ（演奏データ）が格納される領域であり、詳細には、５１２サンプリング分の音声データを格納する領域が、確保されている。
【０１２４】
演奏データバッファ２４ｂは、演者端末２０自身の演奏データ及び他の演者端末２０から受信した演奏データが格納される領域である。具体的には、図１３（ｂ）に示すように、演者端末；ＤＳＰ２２によって音響効果処理が行われた音声データパケットが、演者端末２０毎に、パケット番号に従って格納される。
【０１２５】
合成観客データバッファ２４ｃは、管理サーバ１０から受信した合成観客データが格納される領域である。具体的には、図９（ｃ）に示すように、管理サーバ１０にて音響効果処理が行われた音声データパケットが、その受信順に格納される。
【０１２６】
入力装置２５は、演者端末２０の利用者が、演奏を希望する条件や、他の演者端末２０との接続条件等を入力するためのものであり、文字キーや数字キー、各種機能キーを備えたキーボード又はタッチパネル、或いはマウスやトラックボール、トラック・パッド、ポインティング・スティック等のポインティングデバイス等により構成される。そして、これらの操作に応じた操作信号を、演者端末；ＣＰＵ２１へ出力する。
【０１２７】
マルチプレクサ２６は、複数の入力信号の内から１つの信号を選択し、出力する回路である。また、このマルチプレクサ２６の入力側には、マイクロフォンや電子楽器等に接続されており、演者端末；ＤＳＰ２２から入力される指示信号（選択信号）に従って、入力される演奏音声の一つを選択し、サンプルホールド回路２７へ出力する。
【０１２８】
サンプルホールド回路２７は、演者端末；ＤＳＰ２２から入力されるクロック信号の入力タイミングに従い、マルチプレクサ２６から入力される音声信号（アナログ信号）を、一時的に保持（ホールド）するとともに、Ａ／Ｄ変換回路２８へ出力する。
【０１２９】
Ａ／Ｄ変換回路２８は、サンプルホールド回路２７から入力されるアナログ信号をデジタル信号に変換する回路であり、得られたデジタル信号を演者端末；ＤＳＰ２２へ出力する。
【０１３０】
Ｄ／Ａ変換回路２９は、演者端末；ＤＳＰ２２から入力されるデジタル信号をアナログ信号に変換する回路であり、得られたアナログ信号をアンプ３０へ出力する。
【０１３１】
アンプ３０は、Ｄ／Ａ変換回路２９から入力されるアナログ信号を所定レベルに増幅し、増幅後の信号を、外部接続されたスピーカ（不図示）へ出力する。
【０１３２】
表示駆動回路３１は、演者端末；ＣＰＵ２１から入力される表示信号に基づいて表示装置３２を駆動し、各種表示画面を表示させる回路である。また、表示装置３２は、ＣＲＴ（Ｃａｔｈｏｄｅ Ｒａｙ Ｔｕｂｅ）やＬＣＤ（Ｌｉｑｕｉｄ Ｃｒｙｓｔａｌ Ｄｉｓｐｌａｙ）等により構成され、演者端末；ＣＰＵ２１から入力される表示信号に従った表示画面を表示する。
【０１３３】
通信装置３３は、インターネットＮを介して他の機器とのデータ通信を行うためのインターフェースであり、ルータ等により構成される。
【０１３４】
図１４は、観客端末４０の構成を示すブロック図である。
同図によれば、観客端末４０は、観客端末；ＣＰＵ４１、観客端末；ＤＳＰ４２、記憶装置４３、ＲＡＭ４４、入力装置４５、マルチプレクサ４６、サンプルホールド回路４７、Ａ／Ｄ変換回路４８、Ｄ／Ａ変換回路４９、アンプ５０、表示駆動回路５１、表示装置５２及び通信装置５３より構成される。
【０１３５】
観客端末；ＣＰＵ４１は、記憶装置４３に記憶される各種処理プログラムに基づいて、観客端末４０を構成する各部を集中制御する。具体的には、入力装置４５、或いは通信装置５３から入力される信号に応答して、記憶装置４３に記憶されている処理プログラムを読み出してＲＡＭ４４に一時記憶させるとともに、係る処理プログラムに基づく処理を実行して、観客端末４０を機能させる。その際、観客端末；ＣＰＵ４１は、処理結果をＲＡＭ４４内の所定領域に格納するとともに、必要に応じて、その処理結果を、表示装置５２に表示するとともに、通信装置５３から外部機器へ送信する。
【０１３６】
また、観客端末；ＣＰＵ４１は、本実施の形態の特徴的な処理として、後述する合奏処理（図１５参照）、観客データ送信処理（図２６参照）及び合奏音声再生処理（図２７参照）を実行する。
【０１３７】
具体的には、合奏処理において、観客端末；ＣＰＵ４１は、管理サーバ１０から送信される演奏予定データを受信する。そして、この演奏予定データに基づき、利用者の入力指示に応じた参加予定データを、当該観客端末４０のＩＰアドレスとともに、管理サーバ１０へ送信する。その後、管理サーバ１０より演奏開始を指示されると、観客端末；ＣＰＵ４１は、演奏処理を実行する。
【０１３８】
この演奏処理において、観客端末；ＣＰＵ４１は、後述する観客データ送信処理（図２６参照）及び合奏音声再生処理（図２７参照）を実行するとともに、観客端末；ＤＳＰ４２に、観客データ送信処理（図２６参照）及び合奏音声再生処理（図２７参照）を実行させる。
【０１３９】
観客データ送信処理において、観客端末；ＣＰＵ４１は、観客端末；ＤＳＰ４２から入力される音声データパケットをＩＰパケット化し、観客データとして、管理サーバ１０へ送信する。
【０１４０】
また、合奏音声再生処理において、観客端末；ＣＰＵ４１は、管理サーバ１０から受信した合奏データ、即ちＩＰパケットから音声データを抜き出し、１つの音声データパケットとして、観客端末；ＤＳＰ４２へ出力する。
【０１４１】
観客端末；ＤＳＰ４２は、デジタルデータの高速処理に特化したプロセッサである。また、観客端末；ＤＳＰ４２は、本実施の形態の特徴的な処理として、後述する観客データ送信処理（図２６参照）及び合奏音声再生処理（図２７参照）を実行する。
【０１４２】
具体的には、観客データ送信処理において、観客端末；ＤＳＰ４２は、サンプリング周期毎に、Ｄ／Ａ変換回路４９から入力される音声データを入力バッファ４４ａに格納するとともに、５１２サンプリング分の音声データを１つの音声データパケットとして、観客端末；ＣＰＵ４１へ出力する。
【０１４３】
また、合奏音声再生処理において、観客端末；ＤＳＰ４２は、観客端末；ＣＰＵ４１から入力される音声データパケットを、その受信順に合奏データバッファ４４ｂに格納する。そして、所定時間毎に、合奏データバッファ４４ｂに格納されている音声データパケットを、その格納順に読み出し、Ｄ／Ａ変換回路４９へ出力する。
【０１４４】
図１４において、記憶装置４３は、観客端末４０の動作に係る各種処理プログラムや、本実施の形態の機能を実現するためのプログラム（具体的には、合奏プログラム４３ａ、観客データ送信プログラム４３ｂ、合奏音声再生プログラム４３ｃ）及びこれらのプログラムの実行に係る処理データ等を記憶する。
【０１４５】
ＲＡＭ４４は、観客端末；ＣＰＵ４１により実行される各プログラムを実行するためのプログラムエリア（不図示）、入力指示や入力データ、上記プログラムが実行される際に生じる処理結果等を一時的に格納するワークメモリエリアを備えている。また、このワークメモリエリアには、入力バッファ４４ａ及び合奏データバッファ４４ｂが形成される。
【０１４６】
入力バッファ４４ａは、利用者によって入力された観客音声のデータ（観客データ）が格納される領域であり、詳細には、５１２サンプリング分の音声データが格納される領域が確保されている。
【０１４７】
合奏データバッファ４４ｂは、ストリーミング配信用のバッファであり、管理サーバ１０から受信した合奏データが格納される領域である。具体的には、管理サーバ１０にて合成・音響効果処理が行われた音声データパケットが、その受信順に格納される。
【０１４８】
入力装置４５は、観客端末４０の利用者が、観客として参加を希望する演奏の指定等を入力するためのものであり、文字キーや数字キー、各種機能キーを備えたキーボード又はタッチパネル、或いはマウスやトラックボール、トラック・パッド、ポインティング・スティック等のポインティングデバイス等により構成される。そして、これらの操作に応じた操作信号を、観客端末；ＣＰＵ４１へ出力する。
【０１４９】
マルチプレクサ４６は、複数の入力信号の内から１つの信号を選択し、出力する回路である。また、このマルチプレクサ４６の入力側には、マイクロフォンが接続されており、観客端末；ＤＳＰ４２から入力される指示信号（選択信号）に従って、入力される観客音声の一つを選択し、サンプルホールド回路４７へ出力する。
【０１５０】
サンプルホールド回路４７は、観客端末；ＤＳＰ４２から入力されるクロック信号の入力タイミングに従い、マルチプレクサ４６から入力される音声信号（アナログ信号）を一時的に保持（ホールド）するとともに、Ａ／Ｄ変換回路４８へ出力する。
【０１５１】
Ａ／Ｄ変換回路４８は、サンプルホールド回路４７から入力されるアナログ信号をデジタル信号に変換する回路であり、得られたデジタル信号を観客端末；ＤＳＰ４２へ出力する。
【０１５２】
Ｄ／Ａ変換回路４９は、観客端末；ＤＳＰ４２から入力されるデジタル信号をアナログ信号に変換する回路であり、得られたアナログ信号をアンプ５０へ出力する。
【０１５３】
アンプ５０は、Ｄ／Ａ変換回路４９から入力されるアナログ信号を所定レベルに増幅し、増幅後の信号を、外部接続されたスピーカ（不図示）へ出力する。
【０１５４】
表示駆動回路５１は、観客端末；ＣＰＵ４１から入力される表示信号に基づいて表示装置５２を駆動し、各種表示画面を表示させる回路である。また、表示装置５２は、ＣＲＴやＬＣＤ等により構成され、観客端末；ＣＰＵ４１から入力される表示信号に従った表示画面を表示する。
【０１５５】
通信装置５３は、インターネットＮを介して他の機器とのデータ通信を行うためのインターフェースであり、ルータ等により構成される。
【０１５６】
次に、演奏システム１の動作を、図１５〜図２７を参照して説明する。
【０１５７】
図１５は、合奏処理を示すフローチャートである。
この合奏処理は、管理サーバ１０の管理サーバ；ＣＰＵ１１、演者端末２０の演者端末；ＣＰＵ２１及び観客端末４０の観客端末；ＣＰＵ４１により、それぞれ、記憶装置１２に記憶された合奏プログラム１２ａ、記憶装置２２に記憶された合奏プログラム２２ａ及び記憶装置４２に記憶された合奏プログラム４２ａに従って、実行される処理である。
【０１５８】
同図によれば、演者端末２０において、演者端末；ＣＰＵ２１は、利用者からの入力指示に従い、管理サーバ１０が提供するＷｅｂサイトへアクセスし（ステップＳ１１）、この管理サーバ１０から送信されるＨＰ情報（Ｗｅｂページを表示させるための情報）を受信する（ステップＳ１２）。そして、このＨＰ情報に基づいて、表示装置３２に、合奏参加登録画面（不図示）を表示する。
【０１５９】
次いで、演奏参加登録画面上の入力フォーマットに従って、利用者により演奏を希望する曲目やパート、日時を含む演奏条件データが入力されると（ステップＳ１３）、演者端末；ＣＰＵ２１は、この演奏条件データ及び演者端末２０のＩＰアドレスを、演奏参加登録要請とともに、管理サーバ１０へ送信する（ステップＳ１４）。
【０１６０】
一方、管理サーバ１０において、演者端末２０から、演奏参加登録要請とともに送信される演奏条件データ及びＩＰアドレスを受信すると（ステップＳ１５）、管理サーバ；ＣＰＵ１１は、この演奏条件データ及びＩＰアドレスを対応付けて、ＲＡＭ１３内の演奏条件データ格納領域１３ａに追加格納する。
【０１６１】
そして、管理サーバ；ＣＰＵ１１は、演奏条件データ格納領域１３ａに格納されているデータの内から、受信した演奏条件データに適合するデータを検索し、合奏に参加可能な演者端末２０を特定する（ステップＳ１６）。具体的には、演奏を希望する曲目及び日時が一致し、且つパートが異なるデータを検索する。
【０１６２】
合奏に参加可能な演者端末２０を特定すると、管理サーバ；ＣＰＵ１１は、特定した演者端末２０をグループ化した演者用マルチキャストＩＰアドレス及び観客として参加する観客端末４０をグループ化する観客用マルチキャストＩＰアドレスを設定する。そして、これらの演者用マルチキャストＩＰアドレス及び観客用マルチキャストＩＰアドレスととともに、合奏を予定する日時、曲目、参加する演者端末２０のＩＰアドレスを対応付けて、ＲＡＭ１３内の合奏予定データ格納領域１３ｂに、詳細には、合奏予定日時が現在時刻に最も近い順に並ぶ位置に追加格納する。
【０１６３】
それとともに、管理サーバ；ＣＰＵ１１は、上記特定した各演者端末２０に対し、当該合奏を予定する日時、曲目、割り当てたパート、演者用マルチキャストＩＰアドレスを含む合奏予定データを送信する（ステップＳ１７）。即ち、各演者端末２０は、参加することとなる合奏に関する演奏予定データ、即ち、合奏を予定する日時や曲目、演者用マルチキャストＩＰアドレス（演奏データの送信先となる。）を受信する（ステップＳ１８）。
【０１６４】
また、観客端末４０において、観客端末；ＣＰＵ４１は、利用者からの入力指示に従い、管理サーバ１０が提供するＷｅｂサイトへアクセスし（ステップＳ１９）、この管理サーバ１０から送信される合奏予定データを受信する（ステップＳ２０、Ｓ２１）。そして、この合奏予定データに基づいて、表示装置５２に、演奏予定画面（不図示）を表示する。
【０１６５】
次いで、この演奏予定画面上の入力フォーマットに従って、利用者により観客として参加を希望する合奏が指定されると（ステップＳ２２）、観客端末；ＣＰＵ４１は、指定された合奏を示す参加予定データ及び当該観客端末４０のＩＰアドレスを、管理サーバ１０へ送信する（ステップＳ２３）。
【０１６６】
一方、管理サーバ１０において、演者端末２０から送信される参加予定データ及びＩＰアドレスを受信すると（ステップＳ２４）、管理サーバ；ＣＰＵ１１は、受信したＩＰアドレスを、指定された合奏に対応する観客用マルチキャストＩＰアドレスによってグループ化された観客端末４０のＩＰアドレスとして、ＲＡＭ１３内の合奏予定データ格納領域１３ｂに格納する。
【０１６７】
また、管理サーバ１０において、管理サーバ；ＣＰＵ１１は、随時、合奏予定データ格納領域１３ｂの先頭に格納されている合奏予定日時と、現在時刻とを比較している。そして、合奏予定日時の所定時間前となると（ステップＳ２５：ＹＥＳ）、管理サーバ；ＣＰＵ１１は、当該合奏に参加予定の演者端末２０及び観客端末４０の全てに対し、その旨を通知し、例えば図１６に示す演奏開始指示画面を表示させる（ステップＳ２６）。そして、合奏開始日時となったことを確認すると、管理サーバ；ＣＰＵ１１は、後述の演奏処理を実行することで、当該合奏に係る処理を開始する（ステップＳ２７）。
【０１６８】
また、演者端末２０においては、管理サーバ１０より合奏予定日時の所定時間前である旨が通知されると（ステップＳ２８）、演者端末；ＣＰＵ２１は、後述のリンク確立処理（図１７参照）を実行することで、当該合奏に参加予定の他の演者端末２０と、接続条件の提示・照合を行うとともに、直接通信リンクを確立する（ステップＳ２９）。その後、合奏予定日時となったことを確認すると、演者端末；ＣＰＵ２１は、後述の演奏処理を実行することで、当該合奏に係る処理を開始する（ステップＳ３０）。
【０１６９】
一方、観客端末４０においては、管理サーバ１０より演奏開始日時の所定時間前である旨が通知されと（ステップＳ３１）、観客端末；ＣＰＵ４１は、合奏予定日時となったことを確認した後、後述の演奏処理を実行することで、当該合奏に、観客として参加する（ステップＳ３２）。
【０１７０】
そして、各機器（管理サーバ１０、各演者端末２０及び各観客端末４０）の全てにおける演奏処理が終了すると、当該合奏は終了となる。
【０１７１】
図１５のステップＳ２９にて実行されるリンク確立処理について、説明する。図１７は、リンク確立処理を示すフローチャートである。このリンク確立処理は、演者端末２０の演者端末；ＣＰＵ２１により、記憶装置２３に記憶されたリンク確立プログラム２３ｂに従って実行される。
【０１７２】
同図によれば、演者端末；ＣＰＵ２１は、利用者からの入力指示に従った接続条件を、他の演者端末２０に送信（提示）するとともに、他の演者端末２０から受信した接続条件と照合する（ステップＳ１０１）。尚、ここで照合される接続条件は、上述のように、通信条件及びエフェクト条件が含まれるものである。
【０１７３】
照合の結果、他の演者端末２０の接続条件との合意が得られないと判断した場合（ステップＳ１０２：ＮＯ）、演者端末；ＣＰＵ２１は、合意されていない接続条件の内容を、代替案の候補とともに表示装置３２に表示させる（ステップＳ１０３）。
【０１７４】
そして、これらの代替案から選択された内容を、新たな接続条件として他の演者端末２０に再送信（再提示）するとともに、他の演者端末２０から再送信（再提示）される接続条件との照合を行う（ステップＳ１０４）。
【０１７５】
その結果、接続条件の合意が得られたと判断した場合には（ステップＳ１０２：ＹＥＳ）、演者端末；ＣＰＵ２１は、合意した接続条件、詳細には、少なくとも演者端末２０自身に関する接続条件を、ＲＡＭ２４に記憶しておく。
以上の処理を行うと、演者端末；ＣＰＵ２１は、本リンク確立処理を終了する。
【０１７６】
図１５のステップＳ２７にて実行される演奏処理について説明する。この演奏処理において、管理サーバ１０は、データ受信処理（図１８参照）、合成観客データの演者端末への送信処理（図２１参照）及び合奏データ生成・観客端末への送信処理（図２２参照）の３つの処理を並行して実行する。図６（ａ）に、この管理サーバ１０が行う演奏処理の概略フローを示す。管理サーバ１０は、データ受信処理（図１８参照）（ステップＡ１）と、合成観客データの演者端末への送信処理（図２１参照）（ステップＡ２）と、合奏データ生成・観客端末への送信処理（図２２参照）（ステップＡ３）とを、演奏が終了するまで繰り返し行う（ステップＡ４）。
【０１７７】
図１８は、データ受信処理（管理サーバ）を示すフローチャートである。このデータ受信処理は、管理サーバ１０の管理サーバ；ＣＰＵ１１により、記憶装置１２に記憶されたデータ受信プログラム１２ｂに従って実行される処理である。
【０１７８】
同図によれば、通信装置１４からＩＰパケットが入力されると（ステップＳ２０１：ＹＥＳ）、管理サーバ；ＣＰＵ１１は、このＩＰパケットが演奏データであり、且つ観客データ受信処理を現在実行中であるか否かを判定する（ステップＳ２０２）。
【０１７９】
判定の結果、入力されたＩＰパケットが演奏データであり、且つ観客データ受信処理を現在実行中である場合には（ステップＳ２０２：ＹＥＳ）、管理サーバ；ＣＰＵ１１は、現在実行中の観客データ受信処理を一時中断し（ステップＳ２０３）、続いて、後述する演奏データ受信処理を実行する（ステップＳ２０４）。
【０１８０】
そして、演奏データ受信処理を終了すると、管理サーバ；ＣＰＵ１１は、ステップＳ２０３にて一時中断していた観客データ受信処理の実行を再開する（ステップＳ２０５）。
【０１８１】
一方、ステップＳ２０２において、判定条件を満たさない場合、具体的には、入力されたＩＰパケットが観客データである、或いは観客データ受信処理を現在実行中でない場合には（ステップＳ２０２：ＮＯ）、管理サーバ；ＣＰＵ１１は、入力されたＩＰパケットが演奏データであるか否かを判定する（ステップＳ２０６）。
【０１８２】
判定の結果、このＩＰパケットが演奏データである場合（ステップＳ２０６：ＹＥＳ）、管理サーバ；ＣＰＵ１１は、続いて、後述する演奏データ受信処理を実行する（ステップＳ２０７）。一方、演奏データでない、即ち観客データである場合には（ステップＳ２０６：ＮＯ）、管理サーバ；ＣＰＵ１１は、続いて、後述する観客データ受信処理を実行する（ステップＳ２０８）。
以上の処理を終了すると、ＣＵＰ１１は、本データ受信処理を終了する。
【０１８３】
図１９は、演奏データ受信処理（管理サーバ）を示すフローチャートである。この演奏データ受信処理は、図１８のステップＳ２０４或いはステップＳ２０７において、管理サーバ１０の管理サーバ；ＣＰＵ１１により、記憶装置１２に記憶された演奏データ受信プログラム１２ｃに従って実行される処理である。
【０１８４】
同図によれば、管理サーバ；ＣＰＵ１１は、通信装置１４からＩＰパケットが入力されると、このＩＰパケットに対して、暗号解読処理を含むＩＰ層プロトコル処理（ステップＳ２１１）及びＵＤＰ層プロトコル処理を行う（ステップＳ２１２）。そして、アプリケーション層処理により、このＩＰパケットから音声データ及び指示ヘッダを抜き出す（ステップＳ２１３）。
【０１８５】
次いで、管理サーバ；ＣＰＵ１１は、抜き出した音声データを、指示ヘッダに含まれる音声記録方式（即ち、ＰＣＭ方式）に従ってデコードするとともに（ステップＳ２１４）、図８を参照して説明したように指示ヘッダに含まれるエフェクト条件に従って音響効果処理を行った後（ステップＳ２１５）、演奏データバッファ１３ｃの所定領域に格納する（ステップＳ２１６）。
その後、管理サーバ；ＣＰＵ１１は、本演奏データ受信処理を終了する。
【０１８６】
図２０は、観客データ受信処理（管理サーバ）を示すフローチャートである。この観客データ受信処理は、図１８のステップＳ２０８において、管理サーバ１０の管理サーバ；ＣＰＵ１１により、記憶装置１２に記憶された観客データ受信プログラム１２ｄに従って実行される処理である。
【０１８７】
同図によれば、通信装置１４からＩＰパケットが入力されると、管理サーバ；ＣＰＵ１１は、このＩＰパケットに対して、暗号解読処理を含むＩＰ層プロトコル処理（ステップＳ２２１）及びＵＤＰ層プロトコル処理を行う（ステップＳ２２２）。そして、アプリケーション層処理により、このＩＰパケットから音声データ及び指示ヘッダを抜き出す（ステップＳ２２３）。
【０１８８】
次いで、管理サーバ；ＣＰＵ１１は、抜き出した音声データを、図９を参照して説明したように、指示ヘッダに含まれる音声記録方式（即ち、ＰＣＭ方式）に従ってデコードするとともに（ステップＳ２２４）、観客データバッファ１３ｄ内の所定領域、即ち、当該音声データパケットの送信元である観客端末４０に対応する領域に、パケット番号に従って格納する（ステップＳ２２５）。
以上の処理を行うと、管理サーバ；ＣＰＵ１１は、本観客データ受信処理を終了する。
【０１８９】
図２１は、合成観客データ送信処理（管理サーバ）を示すフローチャートである。この合成観客データ送信処理は、管理サーバ１０の管理サーバ；ＣＰＵ１１により、記憶装置１２に記憶された合成観客データ送信プログラム１２ｅに従って実行される処理である。
【０１９０】
同図によれば、本処理の開始した後、所定の観客音声合成周期が経過すると（ステップＳ２３１：ＹＥＳ）、管理サーバ；ＣＰＵ１１は、観客データバッファ１３ｄから、格納されている音声データパケットを読み出す（ステップＳ２３２）。
【０１９１】
そして、図９を参照して説明したように、これら読み出した音声データパケットを音合成し（ステップＳ２３３）、所定の音響効果処理を行った後（ステップＳ２３４）、処理後のデータを、合成観客データバッファ１３ｅに格納する（ステップＳ２３５）。
【０１９２】
次いで、管理サーバ；ＣＰＵ１１は、ステップＳ２３４にて音響効果処理を行った音声データパケットを、ＰＣＭ方式でエンコードした後（ステップＳ２３６）、ＵＤＰ層プロトコル処理（ステップＳ２３７）、暗号化処理を含むＩＰ層プロトコル処理を行い、ＩＰパケットを生成する（ステップＳ２３８）。但しこの時、管理サーバ；ＣＰＵ１１は、演者用マルチキャストＩＰアドレスを、ＩＰヘッダの宛先ＩＰアドレスに設定する。
【０１９３】
そして、生成したＩＰパケットを、通信装置１４から、演奏者用マルチキャストＩＰアドレスによりグループ化されている各演者端末２０へ、一斉配信する（ステップＳ２３９）。
【０１９４】
その後、管理サーバ；ＣＰＵ１１は、本処理の終了が指示されているか否かを判定する（ステップＳ２４０）。判定の結果、終了を指示されていない場合には（ステップＳ２４０：ＮＯ）、管理サーバ；ＣＰＵ１１は、ステップＳ２３１へ移行し、更に観客音声合成周期を経過後、同様の処理を繰り返す（ステップＳ２３１〜Ｓ２４０）。そして、ステップＳ２４０において、本処理の終了が指示されていると判定した場合には（ステップＳ２４０：ＹＥＳ）、管理サーバ；ＣＰＵ１１は、本観客データ受信処理を終了する。
【０１９５】
図２２は、合奏データ生成処理（管理サーバ）を示すフローチャートである。この合奏データ生成処理は、管理サーバ１０の管理サーバ；ＣＰＵ１１により、記憶装置１２に記憶された合奏データ生成プログラム１２ｆに従って実行される処理である。
【０１９６】
同図によれば、管理サーバ；ＣＰＵ１１は、演奏データバッファ１３ｃを参照し、各演者端末２０に対応する、所定のパケット番号の音声データパケットが全て格納されていることを確認すると（ステップＳ２４１：ＹＥＳ）、当該パケット番号の音声データパケットを、演奏データバッファ１３ｃから読み出す（ステップＳ２４２）。そして、図８を参照して説明したように、読み出した音声データパケットを音合成（同期合成）する（ステップＳ２４３）。
【０１９７】
それとともに、管理サーバ；ＣＰＵ１１は、合成観客データバッファ１３ｅから１つの音声データパケットを、その格納順に読み出し（ステップＳ２４４）、読み出した音声データパケットと、ステップＳ２４３にて同期合成した音声データパケットとを、チャネル毎に音合成する（ステップＳ２４５）。
【０１９８】
次いで、管理サーバ；ＣＰＵ１１は、合成した音声データパケットを、ＭＰ３方式に従ってエンコード（圧縮を含む）した後（ステップＳ２４６）、ＵＤＰ層プロトコル処理（ステップＳ２４７）、暗号化処理を含むＩＰ層プロトコル処理を行い、ＩＰパケットを生成する（ステップＳ２４８）。但しこの時、管理サーバ；ＣＰＵ１１は、観客用マルチキャストＩＰアドレスを、ＩＰヘッダの宛先ＩＰアドレスに設定する。
【０１９９】
そして、管理サーバ；ＣＰＵ１１は、生成したＩＰパケットを通信装置１４へ出力し、観客用マルチキャストＩＰアドレスによりグループ化されている各観客端末４０へ、一斉配信する（ステップＳ２４９）。
【０２００】
その後、管理サーバ；ＣＰＵ１１は、本処理の終了が指示されているか否かを判定する（ステップＳ２５０）。判定の結果、終了を指示されていない場合には（ステップＳ２５０：ＮＯ）、管理サーバ；ＣＰＵ１１は、ステップＳ２４１へ移行し、次のパケット番号の音声データパケットに対して同様の処理を繰り返す（ステップＳ２４１〜Ｓ２５０）。そして、ステップＳ２５０において、本処理の終了が指示されていると判定した場合には（ステップＳ２５０：ＹＥＳ）、管理サーバ；ＣＰＵ１１は、本合奏データ生成処理を終了する。
【０２０１】
以上のように、データ受信処理、合成観客データ送信処理及び合奏データ生成処理を終了すると、管理サーバ；ＣＰＵ１１は、１５のステップＳ２７における演奏処理を終了する。
【０２０２】
次に、図１５のステップＳ３０にて実行される演奏処理について説明する。この演奏処理において、演者端末２０は、演奏データ送信処理（図２３参照）、演奏／合成観客データ受信処理（図２４参照）及び合成音声出力処理（図２５参照）の３つの処理を並行して実行する。図６（ｂ）に、演者端末２０が行う演奏処理の概略フローを示す。演者端末２０は、当該演者が担当するパートの音声・映像情報を入力して（ステップＢ１）、演奏データ送信処理（図２３参照）と、演奏／合成観客データ受信処理（図２４参照）と、合成音声出力処理（図２５参照）とを、演奏が終了するまで繰り返し行う（ステップＢ５）。
【０２０３】
図２３は、演奏データ送信処理（演者端末）を示すフローチャートである。この演奏データ送信処理は、演者端末２０の演者端末；ＣＰＵ１１及び演者端末；ＤＳＰ２２により、記憶装置２３に記憶された演奏データ送信プログラム２３ｃに従って実行される処理である。
【０２０４】
同図によれば、本処理を開始した後、所定のサンプリング周期が経過すると（ステップＳ３０１：ＹＥＳ）、演者端末；ＤＳＰ２２は、Ａ／Ｄ変換回路２８から出力される音声データを取込み（ステップＳ３０２）、取込んだ音声データを、入力バッファ２４ａへ格納する（ステップＳ３０３）。尚、ここでサンプリング周期とは、アナログ信号である演奏音声をデジタル信号に符号化する際の周期であり、図１５のステップＳ２９（リンク確立処理）において合意された接続条件に含まれるものである。
【０２０５】
次いで、演者端末；ＤＳＰ２２は、５１２サンプリング分、即ち１パケット分の音声データの取込みを行ったか否かを判定し（ステップＳ３０４）、行っていないと判定した場合には（ステップＳ３０４：ＮＯ）、ステップＳ３０１へ移行し、更にサンプリング周期を経過後、同様の処理を繰り返す（ステップＳ３０１〜Ｓ３０４）。
【０２０６】
このように、サンプリング周期毎に音声データの取込みを繰り返し、１パケット分（即ち、５１２サンプリング分）の音声データの取り込みを行ったと判定すると（ステップＳ３０４：ＹＥＳ）、演者端末；ＤＳＰ２２は、続いて、入力バッファ２４ａに格納されている１パケット分（即ち、５１２サンプリング分）の音声データを読み出す（ステップＳ３０５）。
【０２０７】
そして、読み出した音声データに対して指定された音響効果処理を行った後（ステップＳ３０６）、１つの音声データパケットとして演奏データバッファ２４ｂの所定領域、具体的には、当該演者端末２０に対応する領域に格納する（ステップＳ３０７）。
【０２０８】
それとともに、演者端末；ＤＳＰ２２は、ステップＳ３０５にて読み出した音声データを、ＭＰ３方式に従ってエンコード（圧縮を含む）した後（ステップＳ３０８）、演者端末；ＣＰＵ２１へ出力する（ステップＳ３０９）。その後、演者端末；ＤＳＰ２２は、ステップＳ３０１へ移行し、次の１パケット分の音声データに対して、同様の処理を繰り返す（ステップＳ３０１〜Ｓ３０９）。
【０２０９】
一方、演者端末；ＣＰＵ２１は、演者端末；ＤＳＰ２２から音声データパケットが入力されると（ステップＳ３１０）、この音声データパケットに、同期調整データ、即ち演者端末２０自身を識別する送信端末識別番号及び音声データパケットが入力された順を示すパケット番号を付加するとともに（ステップＳ３１１）、ＵＤＰ層プロトコル処理（ステップＳ３１２）、暗号化処理を含むＩＰ層プロトコル処理を行い、ＩＰパケットを生成する（ステップＳ３１３）。但し、この時、演者端末；ＣＰＵ２１は、演者用マルチキャストＩＰアドレス及び管理サーバ１０のＩＰアドレスを、ＩＰヘッダの宛先ＩＰアドレスに設定する。
【０２１０】
そして、演者端末；ＣＰＵ２１は、生成したＩＰパケットを、通信装置３３へ出力し、演者用マルチキャストＩＰアドレスによりグループ化された他の演者端末２０及び管理サーバ１０へ送信する（ステップＳ３１４）。
【０２１１】
その後、演者端末；ＣＰＵ２１は、本処理の終了が指示されているか否かを判定する（ステップＳ３１５）。判定の結果、終了を指示されていない場合には（ステップＳ３１５：ＮＯ）、演者端末；ＣＰＵ２１は、ステップＳ３１０へ移行し、続いて入力される音声データに対して同様の処理を繰り返す（ステップＳ３１０〜Ｓ３１５）。そして、ステップＳ３１５において、本処理の終了が指示されていると判定した場合には（ステップＳ３１５：ＹＥＳ）、演者端末；ＣＰＵ２１は、本演奏データ送信処理を終了する。
【０２１２】
図２４は、演奏／合成観客データ受信処理を示すフローチャートである。この演奏／合成観客データ受信処理は、演者端末２０の演者端末；ＣＰＵ２１及び演者端末；ＤＳＰ２２により、記憶装置２３に記憶された演奏／合成観客データ受信プログラム２３ｄに従って実行される処理である。
【０２１３】
同図によれば、他の演者端末２０から演奏データ或いは管理サーバ１０から合成観客データを受信する、即ち、通信装置３３からＩＰパケットが入力されると（ステップＳ３２１：ＹＥＳ）、演者端末；ＣＰＵ２１は、入力されたＩＰパケットに対して、暗号解読処理を含むＩＰ層プロトコル処理（ステップＳ３２２）及びＵＤＰ層プロトコル処理を行うとともに（ステップＳ３２３）、アプリケーション層処理により、このＩＰパケットから音声データ及び指示ヘッダを抜き出し、１つの音声データパケットとして、指示ヘッダとともに演者端末；ＤＳＰ２２へ出力する（ステップＳ３２４）。
【０２１４】
その後、演者端末；ＣＰＵ２１は、本処理の終了が指示されているか否かを判定する（ステップＳ３２５）。判定の結果、終了を指示されていない場合には（ステップＳ３２５：ＮＯ）、演者端末；ＣＰＵ２１は、ステップＳ３２１へ移行し、続いて入力されるＩＰパケットに対して、同様の処理を繰り返す（ステップＳ３２１〜Ｓ３２５）。そして、本処理の終了が指示されていると判定した場合には、演者端末；ＣＰＵ２１は（ステップＳ２３５：ＹＥＳ）、本演奏／合成観客データ受信処理を終了する。
【０２１５】
一方、演者端末；ＤＳＰ２２は、演者端末；ＣＰＵ２１から音声データパケットが入力されると（ステップＳ３２６）、入力された音声データパケットに対し、指示ヘッダに含まれる音声記録方式（即ち、ＰＣＭ方式）に従ってデコードする（ステップＳ３２７）。
【０２１６】
そして、指示ヘッダに含まれるデータ識別より、この音声データパケットが演奏データであると判定した場合には（ステップＳ３２８：ＹＥＳ）、当該音声データパケットに対し、指示ヘッダに含まれるエフェクト条件に従って音響効果処理を行う（ステップＳ３２９）。その後、演奏データバッファ２４ｂの所定領域、即ち、当該音声データパケットの送信元である演者端末２０に対応する領域に、パケット番号に従って格納する（ステップＳ３３０）。
【０２１７】
また、ステップＳ３２８において、入力された音声データパケットが合成観客データであると判定した場合には（ステップＳ３２８：ＮＯ）、演者端末；ＣＰＵ２１は、この音声データパケットを合成観客データバッファ２４ｃに、受信順に格納する（ステップＳ３３１）。
【０２１８】
このように、音声データパケットを演奏データバッファ２４ｂ、或いは合成観客データバッファ２４ｃに格納すると、演者端末；ＤＳＰ２２は、ステップＳ３２６へ移行し、続いて入力される音声データパケットに対して、同様の処理を繰り返す（ステップＳ３２６〜Ｓ３３１）。
【０２１９】
図２５は、合奏音声出力処理（演者端末）を示すフローチャートである。この合奏音声出力処理は、演者端末２０の演者端末；ＤＳＰ２２により、記憶装置２３に記憶された合奏音声出力プログラム２３ｅに従って実行される処理である。
【０２２０】
同図によれば、本処理を開始した後、所定の再生サンプリング周期が経過すると（ステップＳ３４１：ＹＥＳ）、演者端末；ＤＳＰ２２は、演奏データバッファ２４ｂから、所定のパケット番号の音声データを読み出す（ステップＳ３４２）。そして、図１３を参照して説明したように、読み出した音声データを、チャネル毎に音合成（同期合成）する（ステップＳ３４３）。尚、ここで再生サンプリング周期とは、符号化されている音声データを復号化する際のサンプリング周期であり、各演者端末２０毎に固有の値である。
【０２２１】
それとともに、演者端末；ＤＳＰ２２は、合成観客データバッファ２４ｃから１つの音声データパケットを、その格納順に読み出す（ステップＳ３４４）。そして、読み出した音声データと、ステップＳ３４３にて同期合成した音声データとを、チャネル毎に音合成する（ステップＳ３４５）。
【０２２２】
次いで、演者端末；ＤＳＰ２２は、合成後の音声データの出力レベルを調整した後、Ｄ／Ａ変換回路２９へ出力する（ステップＳ３４６）。ここでＤ／Ａ変換回路２９に入力された音声データは、アナログ信号に変換された後、アンプ３０にて増幅され、合奏音声として出力される。
【０２２３】
その後、演者端末；ＤＳＰ２２は、本処理の終了が指示されているか否かを判定する（ステップＳ３４７）。判定の結果、終了が指示されていない場合には（ステップＳ３４７：ＮＯ）、演者端末；ＤＳＰ２２は、ステップＳ３４１へ移行し、更に再生サンプリング周期を経過後、次の音声データに対して、同様の処理を繰り返す（ステップＳ３４１〜Ｓ３４７）。そして、ステップＳ３４７において、本処理の終了が指示されている判定した場合には（ステップＳ３４７：ＹＥＳ）、演者端末；ＤＳＰ２２は、本合奏音声出力処理を終了する。
【０２２４】
以上のように、演奏データ送信処理、演奏／合成観客データ受信処理及び合成音声出力処理を終了すると、ＣＰＵ２２は、図１５のステップＳ３０における演奏処理を終了する。
【０２２５】
次に、図１５のステップＳ３２にて実行される演奏処理について説明する。この演奏処理において、観客端末４０は、観客データ送信処理（図２６参照）及び合奏音声再生処理（図２７参照）の２つの処理を並行して実行する。図６（ｃ）に、観客端末４０が行う演奏処理の概略フローを示す。観客端末４０は、観客の音声を入力すると（ステップＣ１）、観客データ送信処理（図２６参照）と、合奏音声再生処理（図２７参照）とを、演奏が終了するまで繰り返し行う（ステップＣ４）。
【０２２６】
図２６は、観客データ送信処理を示すフローチャートである。この観客データ送信処理は、観客端末４０の観客端末；ＣＰＵ４１及び観客端末；ＤＳＰ４２により、記憶装置４３に記憶された観客データ送信プログラム４３ｂに従って実行される処理である。
【０２２７】
同図によれば、本処理を開始した後、サンプリング周期が経過すると（ステップＳ４０１：ＹＥＳ）、観客端末；ＤＳＰ４２は、Ａ／Ｄ変換回路４８から出力される音声データを取込み（ステップＳ４０２）、取込んだ音声データを、入力バッファ４４ａへ格納する（ステップＳ４０３）。
【０２２８】
次いで、観客端末；ＤＳＰ４２は、１パケット分（即ち、１０２４サンプリング分）の音声データの取込みを行ったか否かを判定し（ステップＳ４０４）、行っていないと判定した場合には（ステップＳ４０４：ＮＯ）、ステップＳ４０１へ移行し、更にサンプリング周期を経過後、同様の処理を繰り返す（ステップＳ４０１〜Ｓ４０４）。
【０２２９】
このように、サンプリング周期毎に音声データの取込みを繰り返し、１パケット部分（即ち、１０２４サンプリング分）の音声データの取込みを行ったと判定すると（ステップＳ４０４：ＹＥＳ）、観客端末；ＤＳＰ４２は、続いて、入力バッファ４４ａに格納されている１パケット分（即ち、１０２４サンプリング分）の音声データを読み出す（ステップＳ４０５）。
【０２３０】
そして、観客端末；ＤＳＰ４２は、読み出した音声データに対し、ＭＰ３方式に従ってエンコード（圧縮を含む）した後（ステップＳ４０６）、１つの音声データパケットとして、観客端末；ＣＰＵ４１へ出力する（ステップＳ４０７）。その後、観客端末；ＤＳＰ４２は、ステップＳ４０１へ移行し、更に１パケット分の音声データを取込み、同様の処理を繰り返す（ステップＳ４０１〜Ｓ４０７）。
【０２３１】
一方、観客端末；ＣＰＵ４１は、観客端末；ＤＳＰ４２から音声データパケットが入力されると（ステップＳ４０８）、ＵＤＰ層プロトコル処理（ステップＳ４０９）、暗号化処理を含むＩＰ層プロトコル処理を行い、ＩＰパケットを生成する（ステップＳ４１０）。但し、この時、観客端末；ＣＰＵ４１は、管理サーバ１０のＩＰアドレスを、ＩＰヘッダの宛先ＩＰアドレスに設定する。そして、観客端末；ＣＰＵ４１は、生成したＩＰパケットを通信装置５３へ出力し、管理サーバ１０へ送信する（ステップＳ４１１）。
【０２３２】
その後、観客端末；ＣＰＵ４１は、本処理の終了が指示されているか否かを判定する（ステップＳ４１２）。判定の結果、終了を指示されていない場合には（ステップＳ４１２：ＮＯ）、観客端末；ＣＰＵ４１は、ステップＳ４０８へ移行し、続いて入力される音声データパケットに対して同様の処理を繰り返す（ステップＳ４０８〜Ｓ４１２）。そして、ステップＳ４１２において、本処理の終了が指示されていると判定した場合には（ステップＳ４１２：ＹＥＳ）、観客端末；ＣＰＵ４１は、本観客データ送信処理を終了する。
【０２３３】
図２７は、合奏音声再生処理を示すフローチャートである。この合奏音声再生処理は、観客端末４０の観客端末；ＣＰＵ４１及び観客端末；ＤＳＰ４２により、記憶装置４３に記憶された合奏音声再生プログラム４３ｃに従って実行される処理である。
【０２３４】
同図によれば、管理サーバ１０から合奏データを受信する、即ち、通信装置５３からＩＰパケットが入力されると（ステップＳ４２１：ＹＥＳ）、観客端末；ＣＰＵ４１は、入力されたＩＰパケットに対して、暗号解読処理を含むＩＰ層プロトコル処理（ステップＳ４２２）及びＵＤＰ層プロトコル処理を行うとともに（ステップＳ４２３）、アプリケーション層処理により、このＩＰパケットから音声データを抜き出し、音声データパケットとして、観客端末；ＤＳＰ４２へ出力する（ステップＳ４２４）。
【０２３５】
その後、観客端末；ＣＰＵ４１は、本処理の終了が指示されているか否かを判定する（ステップＳ４２５）。判定の結果、終了を指示されていない場合には（ステップＳ４２５：ＮＯ）、観客端末；ＣＰＵ４１は、ステップＳ４２１へ移行し、続いて入力されるＩＰパケットに対して、同様の処理を繰り返す（ステップＳ４２１〜Ｓ４２５）。
そして、ステップＳ４２５において、本処理の終了が指示されていると判定した場合には（ステップＳ４２５：ＹＥＳ）、観客端末；ＣＰＵ４１は、本合奏音声再生処理を終了する。
【０２３６】
一方、観客端末；ＤＳＰ４２は、観客端末；ＣＰＵ４１から音声データパケットが入力されると（ステップＳ４２６）、入力された音声データパケットを、指定された音声記録方式（即ち、ＭＰ３方式）に従ってデコードした後（ステップＳ４２７）、合奏データバッファ４４ｂに格納する（ステップＳ４２８）。
【０２３７】
その後、観客端末；ＤＳＰ４２は、基準時間を経過したか否かを判定する（ステップＳ４２９）。尚、この基準時間とは、ストリーミングデータの再生に先立ち、一定量のストリーミングデータを合奏データバッファ４４ｂに蓄積するための時間であり、本処理の開始から、この基準時間が経過した後、再生バッフ４４ｂに格納されている音声データパケットが順次読み出し・再生される。即ち、観客端末４０において、合奏音声の出力は、基準時間だけ遅れて開始されることになる。
【０２３８】
判定の結果、基準時間を経過していない場合には（ステップＳ４２９：ＮＯ）、観客端末；ＤＳＰ４２は、ステップＳ４２６へ移行し、続いて入力される音声データパケットに対して同様の処理を繰り返す（ステップＳ４２６〜Ｓ４２９）。
【０２３９】
一方、基準時間を経過したと判定した場合には（ステップＳ４２９：ＹＥＳ）、観客端末；ＤＳＰ４２は、合奏データバッファ４４ｂから、先頭の音声データパケットを読み出す。そして、読み出した音声データの出力レベルを調整した後、Ｄ／Ａ変換回路４９へ出力する（ステップＳ４３１）。ここでＤ／Ａ変換回路４９に入力された音声データは、アナログ信号に変換された後、アンプ５０にて増幅され、合奏音声として出力される。
【０２４０】
その後、観客端末；ＤＳＰ４２は、ステップＳ４２６へ移行し、続いて入力される音声データパケットに対して、同様の処理を繰り返す（ステップＳ４２６〜Ｓ４３１）。
【０２４１】
以上のように、観客データ送信処理、合成音声再生処理を終了すると、観客端末；ＣＰＵ４１は、図１５のステップＳ３２における演奏処理を終了する。
【０２４２】
以上のように構成することで、インターネットＮを介して接続された複数の演者端末２０それぞれにおいて、入力された演奏音声のデータと、他の演者端末２０から受信した演奏データとを、パケット番号に従って合成・出力することが可能となる。即ち、各演者端末２０の間の距離に関わらず、これらの演者端末２における演奏音声を正確に同期させた、リアルタイムな合奏を実現することができる。
【０２４３】
また、観客端末４０においてこの合奏音声を出力するとともに、演者端末２０において、観客端末４０において入力された観客音声のデータを、上記合奏音声とともに再生することで、ネットワークを利用した演奏システムにおいて、観客の反応をリアルタイムに反映させることができる。
【０２４４】
更に、管理サーバ１０と演者端末２０との間のデータのやり取りを、ＰＣＭ形式のＩＰパケットにより実現することで、各演者端末２０においては、他の演者端末２０からの演奏データをリアルタイムで受信し、合奏音声を出力することができる。一方、管理サーバ１０と観客端末４０との間のデータのやり取りを、ＭＰ３形式のＩＰパケットにより実現することで、各観客端末４０においては、負荷の小さい処理で合奏音声を再生することができる。
【０２４５】
尚、本発明の適用は、上記実施の形態に限定されることなく、本発明の趣旨を逸脱しない範囲で適宜変更可能である。例えば、上記実施の形態においては、説明の簡明のため、演者端末２０と観客端末４０とを別個の端末としたが、同一の端末装置としても良い。
【０２４６】
この場合、管理サーバ１０は、図１５のステップＳ１２、或いはＳ２０において、端末装置の要求に応じて、演奏条件データ格納領域１３ａ、或いは合奏予定データ格納領域１３ｂに格納されているデータを、当該端末装置へ送信する。そして、端末装置は、これらの受信データに基づき、例えば図２６に示すように、現在、実行が決定している合奏及び他に参加する演者端末１０を募集している合奏の一覧を表示する。そして、端末装置の利用者は、これらの一覧の内から、演奏、或いは観客としての参加を希望する合奏を選択する。
更に、この時、図中下部に示されているように、利用者により指定された曲目や演奏者等に該当するデータを検索し、表示することとしてもよい。
【０２４７】
【発明の効果】
請求項１又は５記載の発明によれば、各演者端末から受信した音声データを、それぞれに対応する同期調整データに基づいて同期させた合成音声データを作成するとともに、作成した合成音声データを観客端末に配信することができる。従って、各演者端末の間の距離に影響されることなく、リアルタイムな合成音声の再生を実現することができる。
【０２４８】
請求項２記載の発明によれば、演者端末より受信した音声データに、観客端末より受信した音声データを、更に合成した音声合成データを作成し、観客端末に送信することができる。
【０２４９】
請求項３記載の発明によれば、観客端末より受信した音声データに、同期調整データを付加し、演者端末に送信することができる。即ち、演者端末においては、観客端末が発信した音声データを、上記合成音声データと同期させて再生することができる。
【０２５０】
請求項４記載の発明によれば、演者端末から受信した音声データに対する処理を、観客端末から受信した音声データに対する処理に優先して実行することができる。
【０２５１】
請求項６記載の発明によれば、サーバから受信した合成音声データを再生するとともに、入力された音声の音声データをサーバに送信することができる。
【０２５２】
請求項７記載の発明によれば、観客端末で合成音声データが再生される際に、当該観客端末から入力される観客音声データと、合成音声データとを更に合成することができる。
【図面の簡単な説明】
【図１】本実施の形態の演奏システムの構成を示す図である。
【図２】演奏システムにおけるデータの流れを示す図である。
【図３】ＩＰパケットのＩＰヘッダのフォーマットを示す図である。
【図４】ＩＰパケットの実データの構成を示す図である。
【図５】演奏システムにおける通信プロトコルのスタックを示す図である。
【図６】管理サーバ、演者端末及び観客端末それぞれが行う演奏処理の概略フローを示す図である。
【図７】管理サーバの内部構成を示す図である。
【図８】管理サーバにおける演奏データに対する処理の概念を示す図である。
【図９】管理サーバにおける観客データに対する処理の概念を示す図である。
【図１０】演奏条件データ格納領域に格納されるデータの構成を示す図である。
【図１１】合奏予定データ格納領域に格納されるデータの構成を示す図である。
【図１２】演者端末の内部構成を示す図である。
【図１３】演者端末における演奏データに対する処理の概念を示す図である。
【図１４】観客端末の内部構成を示す図である。
【図１５】合奏処理を示すフローチャートである。
【図１６】演奏開始指示画面を示す図である。
【図１７】リンク確立処理を示すフローチャートである。
【図１８】データ受信処理（管理サーバ）を示すフローチャートである。
【図１９】演奏データ受信処理（管理サーバ）を示すフローチャートである。
【図２０】観客データ受信処理（管理サーバ）を示すフローチャートである。
【図２１】合成観客データ送信処理（管理サーバ）を示すフローチャートである。
【図２２】合奏データ生成処理（管理サーバ）を示すフローチャートである。
【図２３】演奏データ送信処理（演者端末）を示すフローチャートである。
【図２４】演奏／合成観客データ受信処理（演者端末）を示すフローチャートである。
【図２５】合奏音声出力処理（演者端末）を示すフローチャートである。
【図２６】観客データ送信処理（観客端末）を示すフローチャートである。
【図２７】合奏音声再生処理を示すフローチャートである。
【図２８】演者端末と観客端末とを同一機器とした場合の表示画面例である、
【符号の説明】
１ 演奏システム
１０ 管理サーバ
１１ ＣＰＵ
１２ 記憶装置
１２ａ 合奏プログラム
１２ｂ データ受信プログラム
１２ｃ 演奏データ受信プログラム
１２ｄ 観客データ受信プログラム
１２ｅ 合成観客データ送信プログラム
１２ｆ 合奏データ生成プログラム
１３ ＲＡＭ
１３ａ 演奏条件データ格納領域
１３ｂ 合奏予定データ格納領域
１３ｃ 演奏データバッファ
１３ｄ 観客データバッファ
１３ｅ 合成観客データバッファ
１４ 通信装置
２０ 演者端末
２１ ＣＰＵ
２２ ＤＳＰ
２３ 記憶装置
２３ａ 合奏プログラム
２３ｂ リンク確立プログラム
２３ｃ 演奏データ送信プログラム
２３ｄ 演奏／合成観客データ受信プログラム
２３ｅ 合奏音声出力プログラム
２４ ＲＡＭ
２４ａ 入力バッファ
２４ｂ 演奏データバッファ
２４ｃ 合成観客データバッファ
２５ 入力装置
２６ マルチプレクサ
２７ サンプルホールド回路
２８ Ａ／Ｄ変換回路
２９ Ｄ／Ａ変換回路
３０ アンプ
３１ 表示駆動回路
３２ 表示装置
３３ 通信装置
４０ 観客端末
４１ ＣＰＵ
４２ ＤＳＰ
４３ 記憶装置
４３ａ 合奏プログラム
４３ｂ 観客データ送信プログラム
４３ｃ 合奏音声再生プログラム
４４ ＲＡＭ
４４ａ 入力バッファ
４４ｂ 合奏データバッファ
４５ 入力装置
４６ マルチプレクサ
４７ サンプルホールド回路
４８ Ａ／Ｄ変換回路
４９ Ｄ／Ａ変換回路
５０ アンプ
５１ 表示駆動回路
５２ 表示装置
５３ 通信装置
Ｎ インターネット
Claims (7)
- 複数の演者端末と観客端末とに通信接続されたサーバにおいて、
音声データ及び予め定められている同期調整データを含む通信データを、前記複数の演者端末それぞれから受信する第１受信手段と、
この第１受信手段により受信された複数の通信データそれぞれに含まれる音声データを、当該通信データに含まれる同期調整データに従って同期して合成し、合成音声データを作成する合成音声作成手段と、
この合成音声作成手段により作成された合成音声データを、前記観客端末に送信する合成音声送信手段と、
を備えることを特徴とするサーバ。 - 前記観客端末から音声データを受信する第２受信手段を更に備え、
前記合成音声作成手段は、前記第１受信手段により受信された複数の通信データそれぞれに含まれる音声データを同期して合成するとともに、前記第２受信手段により受信された音声データを更に合成することにより、合成音声データを作成することを特徴とする請求項１記載のサーバ。 - 前記観客端末から音声データを受信する第２受信手段と、
この第２受信手段により受信された音声データに、予め定められている同期調整データを付加して通信データを作成する作成手段と、
この作成手段により作成された通信データを、前記複数の演者端末それぞれに送信する送信手段と、
を更に備えることを特徴とする請求項１又は２に記載のサーバ。 - 前記合成音声作成手段は、前記第１受信手段により受信された音声データの合成を、前記第２受信手段により受信された音声データの合成に優先して実行することを特徴とする請求項２又は３に記載のサーバ。
- 複数の演者端末と観客端末とに通信接続されたサーバにおける通信方法であって、
音声データ及び予め定められている同期調整データを含む通信データを、前記複数の演者端末それぞれから受信する第１受信工程と、
この第１受信工程において受信された複数の通信データそれぞれに含まれる音声データを、当該通信データに含まれる同期調整データに従って同期して合成し、合成音声データを作成する合成音声作成工程と、
この合成音声作成工程にて作成された合成音声データを、前記観客端末に送信する合成音声送信工程と、
を含むことを特徴とする通信方法。 - 複数の演者端末と通信接続されたサーバに、さらに通信接続された観客端末において、
前記複数の演者端末夫々から受信した通信データから、当該通信データに含まれる同期調整データに従って、当該通信データに含まれる音声データが夫々同期して合成された合成音声データを、前記サーバから受信する合成音声受信手段と、
音声入力手段と、
前記合成音声受信手段により受信された合成音声データを再生する再生手段と、
この再生手段による再生の際に、前記音声入力手段により入力された音声を音声データとして前記サーバに送信する音声送信手段と、
を備えることを特徴とする観客端末。 - 前記合成音声送信手段によって送信された合成音声データの前記観客端末での再生の際に、前記観客端末において入力された観客音声データを受信する観客音声データ受信手段と、
この観客音声データ受信手段により受信された観客音声データと、前記合成音声作成手段により合成された合成音声データとをさらに合成する観客音声データ合成手段と、
をさらに備えることを特徴とする請求項１記載のサーバ。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002256011A JP2004094683A (ja) | 2002-08-30 | 2002-08-30 | サーバ、通信方法及び観客端末 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002256011A JP2004094683A (ja) | 2002-08-30 | 2002-08-30 | サーバ、通信方法及び観客端末 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| JP2004094683A true JP2004094683A (ja) | 2004-03-25 |
Family
ID=32061346
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2002256011A Pending JP2004094683A (ja) | 2002-08-30 | 2002-08-30 | サーバ、通信方法及び観客端末 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP2004094683A (ja) |
Cited By (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2006065010A (ja) * | 2004-08-27 | 2006-03-09 | Casio Comput Co Ltd | 仮想ライブ演奏の支援システムおよび仮想ライブ演奏の支援処理プログラム |
| JP2010237442A (ja) * | 2009-03-31 | 2010-10-21 | Yamaha Corp | 音響効果付与システム |
| JP2011123462A (ja) * | 2009-11-16 | 2011-06-23 | Yamaha Corp | 音響処理装置 |
| WO2013021881A1 (ja) * | 2011-08-08 | 2013-02-14 | アイキューブド研究所株式会社 | 情報システム、情報再現装置、情報生成方法、および記録媒体 |
| WO2021235048A1 (ja) * | 2020-05-19 | 2021-11-25 | 憲保 池田 | 無観客ライブ配信方法及びシステム |
| JP2022028570A (ja) * | 2020-08-03 | 2022-02-16 | 株式会社デザインＭプラス | 記録データ再生方法およびシステム |
| CN116114014A (zh) * | 2020-10-01 | 2023-05-12 | 雅马哈株式会社 | 信号处理系统、信号处理装置以及信号处理方法 |
-
2002
- 2002-08-30 JP JP2002256011A patent/JP2004094683A/ja active Pending
Cited By (14)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2006065010A (ja) * | 2004-08-27 | 2006-03-09 | Casio Comput Co Ltd | 仮想ライブ演奏の支援システムおよび仮想ライブ演奏の支援処理プログラム |
| JP4655550B2 (ja) * | 2004-08-27 | 2011-03-23 | カシオ計算機株式会社 | 仮想ライブ演奏の支援システムおよび仮想ライブ演奏の支援処理プログラム |
| JP2010237442A (ja) * | 2009-03-31 | 2010-10-21 | Yamaha Corp | 音響効果付与システム |
| JP2011123462A (ja) * | 2009-11-16 | 2011-06-23 | Yamaha Corp | 音響処理装置 |
| CN103733249A (zh) * | 2011-08-08 | 2014-04-16 | I<sup>3</sup>研究所股份有限公司 | 信息系统、信息再现装置、信息生成方法及记录介质 |
| JP2013037524A (ja) * | 2011-08-08 | 2013-02-21 | I-Cubed Research Center Inc | 情報システム、情報再現装置、情報生成方法、およびプログラム |
| WO2013021881A1 (ja) * | 2011-08-08 | 2013-02-14 | アイキューブド研究所株式会社 | 情報システム、情報再現装置、情報生成方法、および記録媒体 |
| CN103733249B (zh) * | 2011-08-08 | 2016-04-06 | I<sup>3</sup>研究所股份有限公司 | 信息系统、信息再现装置、信息生成方法及记录介质 |
| US9979766B2 (en) | 2011-08-08 | 2018-05-22 | I-Cubed Reserach Center Inc. | System and method for reproducing source information |
| WO2021235048A1 (ja) * | 2020-05-19 | 2021-11-25 | 憲保 池田 | 無観客ライブ配信方法及びシステム |
| JP2021182696A (ja) * | 2020-05-19 | 2021-11-25 | 憲保 池田 | 双方向放送方法及びシステム |
| CN115668956A (zh) * | 2020-05-19 | 2023-01-31 | 池田宪保 | 无观众现场表演配送方法以及系统 |
| JP2022028570A (ja) * | 2020-08-03 | 2022-02-16 | 株式会社デザインＭプラス | 記録データ再生方法およびシステム |
| CN116114014A (zh) * | 2020-10-01 | 2023-05-12 | 雅马哈株式会社 | 信号处理系统、信号处理装置以及信号处理方法 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP4423790B2 (ja) | 実演システム、ネットワークを介した実演方法 | |
| JP4559050B2 (ja) | メディアデータパケットの同期再生 | |
| JP3242028B2 (ja) | データ送受信方法およびシステム | |
| JP5729393B2 (ja) | 演奏システム | |
| US20070255816A1 (en) | System and method for processing data signals | |
| WO2012093497A1 (ja) | 自動演奏装置 | |
| US20080201424A1 (en) | Method and apparatus for a virtual concert utilizing audio collaboration via a global computer network | |
| Carôt et al. | Network music performance-problems, approaches and perspectives | |
| JP2004094683A (ja) | サーバ、通信方法及び観客端末 | |
| JP2006215460A (ja) | カラオケ音声送受信システムおよびその方法 | |
| CN102394860A (zh) | 信号传送系统、方法、电脑程序产品及电脑可读取储存媒体 | |
| JP5109496B2 (ja) | データ配信装置、データ配信方法およびプログラム | |
| JP2003255935A (ja) | 再生切替装置及びプログラム | |
| KR20210108715A (ko) | 네트워크에 기반한 합동 공연을 제공하는 장치 및 그 방법 | |
| US6525253B1 (en) | Transmission of musical tone information | |
| JP4422656B2 (ja) | ネットワークを用いた遠隔多地点合奏システム | |
| JP2004093975A (ja) | 通信端末及びプログラム | |
| CN109413476A (zh) | 一种音视频与钢琴动作同步直播方法及系统 | |
| JP2011197344A (ja) | サーバ | |
| JP2008304821A (ja) | 楽曲合奏公開システム | |
| JP2022552893A (ja) | ワイヤレスｍｉｄｉヘッドセット | |
| JP2002062884A (ja) | データ送受信方法、送受信端末、およびデータ送受信方法に係るプログラムを記憶した記憶媒体 | |
| JP4543586B2 (ja) | 音声再生装置及び音声再生方法 | |
| JP2003085068A (ja) | ライブ情報提供サーバ、情報通信端末、ライブ情報提供システムおよびライブ情報提供方法 | |
| JPH11284588A (ja) | 通信装置、通信方法及びプログラムを記録した媒体 |