JP2022041553A - 通信制御方法 - Google Patents
通信制御方法 Download PDFInfo
- Publication number
- JP2022041553A JP2022041553A JP2020146821A JP2020146821A JP2022041553A JP 2022041553 A JP2022041553 A JP 2022041553A JP 2020146821 A JP2020146821 A JP 2020146821A JP 2020146821 A JP2020146821 A JP 2020146821A JP 2022041553 A JP2022041553 A JP 2022041553A
- Authority
- JP
- Japan
- Prior art keywords
- communication
- terminal
- data
- feature amount
- sound
- 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
- 238000004891 communication Methods 0.000 title claims abstract description 600
- 238000000034 method Methods 0.000 title claims abstract description 180
- 230000005540 biological transmission Effects 0.000 claims abstract description 32
- 230000002123 temporal effect Effects 0.000 claims description 9
- 230000008569 process Effects 0.000 description 23
- 238000010586 diagram Methods 0.000 description 8
- 239000011295 pitch Substances 0.000 description 8
- 230000001360 synchronised effect Effects 0.000 description 8
- 238000001514 detection method Methods 0.000 description 7
- 230000006870 function Effects 0.000 description 6
- 230000008859 change Effects 0.000 description 4
- 230000004048 modification Effects 0.000 description 4
- 238000012986 modification Methods 0.000 description 4
- 230000003287 optical effect Effects 0.000 description 4
- 230000001934 delay Effects 0.000 description 2
- 230000003111 delayed effect Effects 0.000 description 2
- 239000004973 liquid crystal related substance Substances 0.000 description 2
- 239000004065 semiconductor Substances 0.000 description 2
- 230000006835 compression Effects 0.000 description 1
- 238000007906 compression Methods 0.000 description 1
- 239000000470 constituent Substances 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 238000003384 imaging method Methods 0.000 description 1
- 230000004044 response Effects 0.000 description 1
- 238000005070 sampling Methods 0.000 description 1
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/104—Peer-to-peer [P2P] networks
- H04L67/1074—Peer-to-peer [P2P] networks for supporting data block transmission mechanisms
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/14—Session management
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F18/00—Pattern recognition
- G06F18/20—Analysing
- G06F18/24—Classification techniques
- G06F18/243—Classification techniques relating to the number of classes
- G06F18/24323—Tree-organised classifiers
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L5/00—Arrangements affording multiple use of the transmission path
- H04L5/003—Arrangements for allocating sub-channels of the transmission path
- H04L5/0048—Allocation of pilot signals, i.e. of signals known to the receiver
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/40—Support for services or applications
- H04L65/403—Arrangements for multi-party communication, e.g. for conferences
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/60—Network streaming of media packets
- H04L65/65—Network streaming protocols, e.g. real-time transport protocol [RTP] or real-time control protocol [RTCP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/60—Network streaming of media packets
- H04L65/75—Media network packet handling
- H04L65/752—Media network packet handling adapting media to network capabilities
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/80—Responding to QoS
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/104—Peer-to-peer [P2P] networks
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06V—IMAGE OR VIDEO RECOGNITION OR UNDERSTANDING
- G06V10/00—Arrangements for image or video recognition or understanding
- G06V10/70—Arrangements for image or video recognition or understanding using pattern recognition or machine learning
- G06V10/764—Arrangements for image or video recognition or understanding using pattern recognition or machine learning using classification, e.g. of video objects
Landscapes
- Engineering & Computer Science (AREA)
- Signal Processing (AREA)
- Computer Networks & Wireless Communication (AREA)
- Multimedia (AREA)
- Theoretical Computer Science (AREA)
- Data Mining & Analysis (AREA)
- Bioinformatics & Computational Biology (AREA)
- Bioinformatics & Cheminformatics (AREA)
- Evolutionary Computation (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Computer Vision & Pattern Recognition (AREA)
- Evolutionary Biology (AREA)
- Artificial Intelligence (AREA)
- Life Sciences & Earth Sciences (AREA)
- Electrophonic Musical Instruments (AREA)
- Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
- Computer And Data Communications (AREA)
- Communication Control (AREA)
Abstract
【課題】複数の通信拠点間の状況に応じて、通信方式を切り替えること【解決手段】一実施形態における通信制御方法は、第1通信方式により第1端末から送信される第1ストリーミングデータにおける第1特徴量と、第1通信方式により第2端末から送信される第2ストリーミングデータにおける第2特徴量との比較結果を取得し、比較結果に基づいて第1特徴量と第2特徴量とが第1関係を有する場合に、第1端末と第2端末との間において第1通信方式により送信される通信制御対象のストリーミングデータを、第1通信方式による送信から第1通信方式とは異なる第2通信方式による送信に切り替えるための第1切替信号を、第1端末および第2端末に送信することを含む。【選択図】図4
Description
本発明は、通信を制御する技術に関する。
楽器が演奏される複数の通信拠点がネットワークを介して接続されることにより、離れた場所においても合奏を可能とする技術が開発されている。ネットワーク接続により生じる通信遅延は、合奏を困難にする。したがって、通信遅延を小さくする環境を構築することが望ましいが、通信遅延を無くすことはできない。そのため、通信遅延が存在する前提において遅延の影響を少なくするための技術が、例えば特許文献1に開示されている。
複数の通信拠点間(複数の通信端末間)での通信をリアルタイムに行う方法は、例えばPeer to Peer型通信(以下、P2P型通信という)およびクライアントサーバ型通信を含む。P2P型通信は、各通信拠点の通信端末が対等に接続する方式である。クライアントサーバ型通信は、各通信拠点の通信端末がサーバを介して接続する方式である。このような通信方式の違いにより、P2P型通信では、通信遅延を小さくすることができるが、通信端末の処理負荷および通信量が増加しやすい。一方、クライアントサーバ型通信では、通信端末の負荷および通信量の増加を抑えることができるが、通信遅延が大きくなる。このようなサーバは、例えば、SFU(Selective Forwarding Unit)およびMCU(Multipoint Control Unit)という機能を有する。
上述した合奏においては通信遅延を非常に小さくする必要がある。そのため、合奏を行うときの通信方法は、P2P型通信を用いることが望ましい。しかしながら、通信端末における処理負荷が大きくなると、その処理負荷のために結果的に遅延が大きくなってしまったり、通信端末における他の処理へ影響を及ぼしたりする可能性がある。一方、各通信拠点の状況によって、必ずしもP2P型通信を用いなくてもよいこともあり得る。
本発明の目的の一つは、複数の通信拠点間の状況に応じて、通信方式を切り替えることにある。
本発明の一実施形態によれば、第1通信方式により第1端末から送信される第1ストリーミングデータにおける第1特徴量と、前記第1通信方式により第2端末から送信される第2ストリーミングデータにおける第2特徴量との比較結果を取得し、前記比較結果に基づいて前記第1特徴量と前記第2特徴量とが第1関係を有する場合に、前記第1端末と前記第2端末との間において前記第1通信方式により送信される通信制御対象のストリーミングデータを、前記第1通信方式による送信から当該第1通信方式とは異なる第2通信方式による送信に切り替えるための第1切替信号を、前記第1端末および前記第2端末に送信する、通信制御方法が提供される。
本発明によれば、複数の通信拠点間の状況に応じて、通信方式を切り替えることができる。
以下、本発明の一実施形態における通信システムについて、図面を参照しながら詳細に説明する。以下に示す実施形態は本発明の実施形態の一例であって、本発明はこれらの実施形態に限定して解釈されるものではない。なお、本実施形態で参照する図面において、同一部分または同様な機能を有する部分には同一の符号または類似の符号(数字の後にA、B等を付しただけの符号)を付し、その繰り返しの説明は省略する場合がある。
[1.通信システムの構成]
図1は、本発明の一実施形態における通信システムの構成を説明する図である。通信システムは、インターネットなどのネットワークNWに接続された通信管理サーバ1を含む。通信管理サーバ1は、ネットワークNWに接続された複数の通信拠点間の通信を、各通信拠点の状況に応じて制御する。後述する通信管理サーバ1の機能は、複数のサーバによって協働して実現されてもよい。この例では、通信拠点間の通信は、2つの通信方式が用いられる。2つの通信方式は、P2P型通信およびクライアントサーバ型通信である。図1では、3つの通信拠点T1、T2、T3が例示されているが、この数に限られない。通信拠点T1、T2、T3を区別せず説明する場合には、単に通信拠点という。SFUサーバ80は、クライアントサーバ型通信により用いられ、各通信拠点を仲介するサーバである。
図1は、本発明の一実施形態における通信システムの構成を説明する図である。通信システムは、インターネットなどのネットワークNWに接続された通信管理サーバ1を含む。通信管理サーバ1は、ネットワークNWに接続された複数の通信拠点間の通信を、各通信拠点の状況に応じて制御する。後述する通信管理サーバ1の機能は、複数のサーバによって協働して実現されてもよい。この例では、通信拠点間の通信は、2つの通信方式が用いられる。2つの通信方式は、P2P型通信およびクライアントサーバ型通信である。図1では、3つの通信拠点T1、T2、T3が例示されているが、この数に限られない。通信拠点T1、T2、T3を区別せず説明する場合には、単に通信拠点という。SFUサーバ80は、クライアントサーバ型通信により用いられ、各通信拠点を仲介するサーバである。
各通信拠点には、通信端末20が配置されている。通信端末20には、電子楽器30、収音装置40、撮像装置50、放音装置60および表示装置70が接続されている。各通信拠点において通信端末20は必ず存在するが、電子楽器30、収音装置40、撮像装置50、放音装置60および表示装置70の少なくとも一つが通信端末20に接続されていなくてもよい。電子楽器30、収音装置40、撮像装置50、放音装置60および表示装置70の少なくとも1つと通信端末20とが一体の装置として構成されてもよい。
電子楽器30は、演奏操作子、演奏操作子への操作に応じて音データDaを出力する音源、およびこの操作に対応する発音制御データDcを出力するデータ出力部を含む。電子楽器30は、この例では、演奏操作子として鍵を有する電子ピアノである。音データDaおよび発音制御データDcは通信端末20に出力される。音データDaは、音波形信号を示すデータであり、放音装置60に出力されてもよい。発音制御データDcは、例えばMIDI規格等の所定の規格にしたがって音源を制御するためのデータである。この場合、発音制御データDcは、発音開始タイミングに関する情報(ノートオン)および発音終了タイミングに関する情報(ノートオフ)などの発音内容を規定する情報を含む。
音源は発音制御データDcの制御によっても音データDaを出力することができる。電子楽器30は、外部から入力された発音制御データDcに応じて演奏操作子を駆動するソレノイド等の駆動部を含んでもよい。他の通信拠点から発音制御データDcを受信したときには、このような音源または駆動部に発音制御データDcが供給されればよい。演奏操作子が駆動されることによって電子楽器30において演奏が行われたことと同じ状況となるため、発音制御データDcに応じた音データDaが生成される。
収音装置40は、例えばマイクロフォンまたは音波形信号の入力端子を有し、マイクロフォンに入力された音または入力端子に入力された音波形信号を音データDaとして通信端末20に出力する。
撮像装置50は、例えばカメラを有し、カメラによって撮像された画像に応じた動画データDvを通信端末20に出力する。以下の説明において、画像とは静止画像および動画像の双方を含む。
放音装置60は、例えばスピーカを有し、通信端末20から供給された音データDaが示す音をスピーカから出力する。放音装置60に供給される音データDaは、他の通信拠点から送信された音データDaであるが、自身の通信拠点で生成された音データDaが含まれてもよい。
表示装置70は、例えば液晶ディスプレイを有し、通信端末20から供給された動画データDvが示す画像を液晶ディスプレイに表示する。表示装置70に供給される動画データDvは、他の通信拠点から送信された動画データDvであるが、自身の通信拠点で生成された動画データDvが含まれてもよい。
[2.通信端末の構成]
通信端末20は、制御部21、記憶部23、通信部25および操作部27を含む。制御部21は、CPU、RAMおよびROM等を含む。制御部21は、記憶部23に記憶されたプログラムをCPUにより実行することによって、プログラムに規定された命令にしたがった処理を行う。この例では、通信を切り替える方法(通信切替方法)を実現する処理を行うためのプログラムが記憶部23に記憶されている。通信切替方法は、通信管理サーバ1からの指示に基づいて、データの送信を行うための通信方式を切り替えるための処理を含む。
通信端末20は、制御部21、記憶部23、通信部25および操作部27を含む。制御部21は、CPU、RAMおよびROM等を含む。制御部21は、記憶部23に記憶されたプログラムをCPUにより実行することによって、プログラムに規定された命令にしたがった処理を行う。この例では、通信を切り替える方法(通信切替方法)を実現する処理を行うためのプログラムが記憶部23に記憶されている。通信切替方法は、通信管理サーバ1からの指示に基づいて、データの送信を行うための通信方式を切り替えるための処理を含む。
通信部25は、通信モジュールを含み、ネットワークNWに接続して、通信管理サーバ1、他の通信拠点の通信端末20およびSFUサーバ80などの外部装置と各種データの送受信を行う。通信部25(通信端末20)と通信管理サーバ1以外の外部装置との間で送信されるデータは、発音制御データDc、音データDaおよび動画データDvを含み、ストリーミングデータとして送信される。これらデータの送信を行うときの通信方式は、制御部21の制御によって設定される。上述したように、通信方式は、この例では、P2P型通信およびクライアントサーバ型通信を含む。
操作部27は、マウス、キーボード等の操作装置を含み、操作装置に対するユーザの操作を受け付け、その操作に応じた信号を制御部21に出力する。
記憶部23は、不揮発性メモリなどの記憶装置を含み、制御部21によって実行されるプログラムを記憶する。その他にも通信端末20において用いる様々なデータが記憶される。記憶部23に記憶されるデータは、通信制御テーブルを含む。このプログラムは、コンピュータにより実行可能であればよく、磁気記録媒体、光記録媒体、光磁気記録媒体、半導体メモリなどのコンピュータ読み取り可能な記録媒体に記憶された状態で通信端末20に提供されてもよい。この場合には、通信端末20は、記録媒体を読み取る装置を備えていればよい。また、このプログラムは、通信部25を介してダウンロードすることによって提供されてもよい。
図2は、本発明の一実施形態における通信制御テーブルを説明する図である。通信制御テーブルは、複数の通信モードのそれぞれにおいて、発音制御データDc、音データDaおよび動画データDvの送信に用いられる通信方式を規定する。複数の通信モードは、モードA、B、C、Dを含む。通信方式は、クライアントサーバ型通信(SFU)およびP2P型通信(P2P)を含む。
モードAでは、全てのデータがクライアントサーバ型通信(SFU)で送信される。モードDでは、全てのデータがP2P型通信(P2P)で送信される。一方、モードBでは、発音制御データDcがP2P型通信(P2P)で送信され、音データDaおよび動画データDvがクライアントサーバ型通信(SFU)で送信される。モードCでは、発音制御データDcおよび音データDaがP2P型通信(P2P)で送信され、動画データDvがクライアントサーバ型通信(SFU)で送信される。
通信端末20は、通信管理サーバ1から通信モードの設定が指示されると、制御部21は、その通信モードに対応する各データの送信における通信方式を決定するために、この通信制御テーブルを参照する。このようにして、制御部21は、指示された通信モードに対応する通信方式を通信部25に設定する。通信管理サーバ1による通信モードの設定については、後述する。
[3.通信切替方法]
続いて、通信端末20における通信切替方法について説明する。上述したように通信切替方法における各処理は、制御部21によって実行される。以下に説明する通信切替方法の処理は、例えば、操作部27に入力されたユーザの指示によって開始される。
続いて、通信端末20における通信切替方法について説明する。上述したように通信切替方法における各処理は、制御部21によって実行される。以下に説明する通信切替方法の処理は、例えば、操作部27に入力されたユーザの指示によって開始される。
図3は、本発明の一実施形態における通信端末の通信切替方法を説明するフローチャートである。通信端末20は、通信管理サーバ1に接続する(ステップS110)。このとき、通信端末20は、接続対象の通信拠点が参加するためのセッションルームを指定する。新たなセッションルームを通信管理サーバ1において開設することもできる。このセッションルームに参加する複数の通信拠点における通信端末20が、互いにデータの送信を行う対象の端末である。
通信端末20は、特徴量情報、通信負荷情報および処理負荷情報を通信管理サーバ1に送信することを開始する(ステップS120)。通信端末20は、通信管理サーバ1に接続している期間において、特徴量情報、通信負荷情報および処理負荷情報を、所定時間毎(例えば100ミリ秒毎)に通信管理サーバ1に送信する。
特徴量情報は、ストリーミングデータとして送信される発音制御データDcおよび音データDaの特徴量を含む。特徴量は、この例では、送信される時刻において発音がされているか否かを示す情報である。そのため、音データDaに関する特徴量情報は、その音データDaから得られる音量レベルが所定値を超えている期間に発音がされ、それ以外の期間は発音がされていないことを示すことにより、音データDaの発音期間を示す。発音制御データDcに関する特徴量情報は、その発音制御データDcが示すノートオンからノートオフまでの期間に発音がされ、それ以外の期間は発音されていないことを示すことにより、発音制御データDcの発音期間を示す。発音制御データDcに関する特徴量情報は、発音制御データDcを音源により音データDaに変換してから、その音データDaから得られる音量レベルが所定値を超えている場合に発音がされていることを示すようにしてもよい。
通信負荷情報は、通信端末20がデータを送信するときに用いる通信回線の負荷を示す情報である。通信負荷は、例えば、通信端末20と他の通信端末20とのP2P型通信における往復遅延時間(Round Trip Time)の測定によって得られる。一般的に、クライアントサーバ型通信よりもP2P型通信の方が、送受信されるデータ量が増えるため、通信負荷が大きくなる。したがって、通信回線に余裕がない場合、P2P型通信でも低遅延を実現できなくなる。
処理負荷情報は、通信端末20における処理負荷を示す情報である。処理負荷は、例えばCPUの負荷に相当する。一般的に、クライアントサーバ型通信よりもP2P型通信の方が、送受信されるデータ量が増えるため、エンコードおよびデコード等により処理負荷が大きくなる。したがって、通信端末20のデータ処理能力に余裕がない場合、P2P型通信でも低遅延を実現できなくなる。この処理負荷は、通信端末20において並行して実行される他のプログラムに起因するものも含んでもよい。
通信端末20は、通信管理サーバ1に接続すると、通信管理サーバ1から通信モードの設定指示を受信して、通信モードを設定する(ステップS130)。通信管理サーバ1によって指定される通信モードは、通信端末20によって指定されたセッションルームに設定された通信モードである。新たにセッションルームが開設された場合など、このセッションルームに通信モードが設定されていない場合には、通信管理サーバ1によって通信モードAの設定が指示される。既に開設されているセッションルームであれば、後述する通信制御方法によって別の通信モード(モードB、モードCまたはモードD)が設定されている場合がある。
通信端末20は、通信制御テーブルを参照して、設定された通信モードに応じて、各データの送信を行う。続いて、通信端末20は、通信管理サーバ1から切替信号S(X)を受信するまで待機する(ステップS140;No)。ここで、Xは、A、B、C、Dのいずれかを示す。A、B、C、Dは、それぞれモードA、モードB、モードC、モードDに対応している。切替信号S(X)を受信すると(ステップS140;Yes)、通信端末20は、この切替信号S(X)に応じた通信モードXを設定することによって、通信モードを切り替える(ステップS150)。そして、通信端末20は、切替信号S(X)を受信するまで待機する(ステップS140;No)。
通信端末20は、発音制御データDc、音データDaおよび動画データDvのそれぞれの送信に用いる通信方式を変更するように、通信管理サーバ1から制御される。
[4.通信管理サーバの構成]
通信管理サーバ1は、制御部11、記憶部13および通信部15を含む。制御部11は、CPU、RAMおよびROM等を含む。制御部11は、記憶部13に記憶されたプログラムをCPUにより実行することによって、プログラムに規定された命令にしたがった処理を行う。このプログラムには、通信端末20の通信を制御する方法(通信制御方法)を実現する処理を行うためのプログラムが含まれる。通信制御方法は、データの送信を行うための通信方式を切り替えることを通信端末20に指示するための処理を含む。この処理の詳細については後述する。通信部15は、通信モジュールを含み、ネットワークNWに接続して、各通信拠点の通信端末20と各種データの送信を行う。
通信管理サーバ1は、制御部11、記憶部13および通信部15を含む。制御部11は、CPU、RAMおよびROM等を含む。制御部11は、記憶部13に記憶されたプログラムをCPUにより実行することによって、プログラムに規定された命令にしたがった処理を行う。このプログラムには、通信端末20の通信を制御する方法(通信制御方法)を実現する処理を行うためのプログラムが含まれる。通信制御方法は、データの送信を行うための通信方式を切り替えることを通信端末20に指示するための処理を含む。この処理の詳細については後述する。通信部15は、通信モジュールを含み、ネットワークNWに接続して、各通信拠点の通信端末20と各種データの送信を行う。
記憶部13は、ハードディスクなどの記憶装置を含み、制御部11によって実行されるプログラムを記憶する。その他にも通信管理サーバ1において用いる様々なデータが記憶される。このプログラムは、コンピュータにより実行可能であればよく、磁気記録媒体、光記録媒体、光磁気記録媒体、半導体メモリなどのコンピュータ読み取り可能な記録媒体に記憶された状態で通信管理サーバ1に提供されてもよい。この場合には、通信管理サーバ1は、記録媒体を読み取る装置を備えていればよい。また、このプログラムは、通信部15を介してダウンロードすることによって提供されてもよい。
[5.通信制御方法]
続いて、通信管理サーバ1における通信制御方法について説明する。上述したように通信制御方法における各処理は、制御部11によって実行される。以下に説明する通信制御方法の処理は、例えば、セッションルームに複数の通信拠点が参加すると開始される。このとき、演奏モードは、モードAとして設定される。そのため、各通信拠点間における発音制御データDc、音データDaおよび動画データDvの送信が、全てクライアントサーバ型通信として設定される。
続いて、通信管理サーバ1における通信制御方法について説明する。上述したように通信制御方法における各処理は、制御部11によって実行される。以下に説明する通信制御方法の処理は、例えば、セッションルームに複数の通信拠点が参加すると開始される。このとき、演奏モードは、モードAとして設定される。そのため、各通信拠点間における発音制御データDc、音データDaおよび動画データDvの送信が、全てクライアントサーバ型通信として設定される。
図4は、本発明の一実施形態における管理サーバの通信制御方法を説明するフローチャートである。通信管理サーバ1は、複数の通信拠点における通信端末20から受信する特徴量情報を比較して、合奏状態が検出されるまで待機する(ステップS210;No)。
合奏状態とは、複数の通信拠点において演奏が行われている状態をいう。各通信拠点における演奏は、例えば、電子楽器30を用いた演奏であったり、アコースティック楽器を用いた演奏であったりする。電子楽器30を用いた演奏の場合、発音制御データDcおよび音データDaの少なくとも一方が通信端末20に供給される。アコースティック楽器を用いた演奏の場合、アコースティック楽器の発音が収音装置40に入力されて音データDaが通信端末20に供給される。
各通信拠点の通信端末20から送信される特徴量情報は、上述したように、ストリーミングデータとして送信される発音制御データDcおよび音データDaが各時刻において発音がされているか否かを示す情報を含む。したがって、この特徴量情報を時間軸に沿って比較することによって、複数の通信拠点において同時に発音がされているかどうかを検出することができる。ただし、特徴量情報により発音があったことが検出できたとしても、必ずしも演奏によらない発音の可能性もある。この例における合奏状態の検出方法は、演奏によらない発音をできるだけ除外する方法である。
図5および図6は、本発明の一実施形態における合奏状態の検出方法を説明する図である。これらの図は、通信拠点T1、T2、T3のそれぞれの通信端末20から送信される特徴量情報に基づいて、各通信拠点における発音期間(図においてメッシュ部分)を時刻tに沿って示している。特徴量は、通信拠点T1では発音制御データDcの発音を示し、通信拠点T2、T3では音データDaの発音を示している。図6は、図5の状況から少し時間が経過した後の状況に対応する。
合奏の検出方法の具体例について説明する。合奏検出の判定時点DP(現在時刻)の5秒前から判定時点DPまでの期間を1秒間ずつ区切ることによって、5つの区間W1~W5が定義される。通信管理サーバ1は、各区間(判定期間)において複数の通信拠点での発音期間があったかどうかを判定する。
実際の合奏では発音期間が重複しない、すなわち、同時の発音がないこともある。したがって、複数の通信拠点での発音期間が重複していなくても1つの区間において発音期間が存在すれば、その区間は合奏音があった区間として判定される。ここでいう複数の通信拠点とは、セッションルームに参加する全ての通信拠点とは異なってもよく、すなわち、セッションルームに参加する通信拠点のうち、少なくとも2つの通信拠点のことを示す。通信管理サーバ1は、区間W1~W5において合奏音があったと判定した場合に、これらの通信拠点が参加するセッションルームが合奏状態になったことを検出する。
判定時点DPから遡る時間(区間W1~W5の合計の時間)、区切られた区間の数、各区間の時間は一例であって、様々な値として設定されてもよい。区間W1~W5のそれぞれの長さが異なってもよい。この場合には、判定時点DPから離れた区間ほど短くてもよいし、判定時点DPに近い区間ほど短くてもよい。区間W1~W5は連続して並んでいなくてもよい。すなわち、隣接する区間の間が時間的に離れてもよい。
図5では、区間W1において通信拠点T1のみ発音があるため、区間W1には合奏音がないと判定される。一方、区間W2~W5には合奏音があると判定される。上述したように、通信拠点T1の発音期間と通信拠点T2の発音期間とが重複していない区間W2においても、合奏音があると判定される。この時点では、区間W1において合奏音がないと判定されているため、通信拠点T1~T3が参加するセッションルームが合奏状態になったことを検出していない。
図6では、区間W1~W5において合奏音があると判定される。したがって、通信管理サーバ1は、通信拠点T1~T3が参加するセッションルームが合奏状態になったことを検出する。合奏状態が検出されると、上記の条件を満たさなくなったとしても、後述する非合奏状態が検出されるまでは、セッションルームが合奏状態として維持される。
図4に戻って説明を続ける。合奏状態が検出されると(ステップS210;Yes)、通信管理サーバ1は、各通信拠点の通信端末20に切替信号S(D)を送信する(ステップS230)。上述したように通信端末20によって切替信号S(D)が受信されると、通信モードがモードAからモードDに切り替えられる。すなわち、各通信拠点間における発音制御データDc、音データDaおよび動画データDvの送信が、全てクライアントサーバ型通信からP2P型通信に切り替えられる。
通信管理サーバ1は、複数の通信拠点における通信端末20から受信する特徴量情報を比較して、非合奏状態が検出されるまで、通信モード切替処理を行う(ステップS310;No、ステップS400)。非合奏状態とは、全ての通信拠点において演奏が行われていない状態、または1つの通信拠点のみで演奏が行われている状態をいう。
非合奏状態の検出方法の具体例は、合奏状態の検出方法と反対である。すなわち、判定時点DPに対応する区間W1~W5において、いずれも合奏音がないと判定された場合に、非合奏状態が検出される。
非合奏状態が検出されると(ステップS310;Yes)、通信管理サーバ1は、各通信拠点の通信端末20に切替信号S(A)を送信する(ステップS900)。上述したように通信端末20によって切替信号S(A)が受信されると、通信モードがモードAとして設定される。すなわち、各通信拠点間における発音制御データDc、音データDaおよび動画データDvの送信が、全てクライアントサーバ型通信として設定される。そして、通信管理サーバ1は、再び合奏状態が検出されるまで待機する(ステップS210;No)。
通信モード切替処理(ステップS400)は、負荷値Ldに応じて通信モードを切り替える処理である。負荷値Ldは、各通信端末20から送信される通信負荷情報および処理負荷情報に基づいて、通信管理サーバ1によって算出される負荷の大きさの指標である。この例では、複数の通信端末20に対応する通信負荷および処理負荷をそれぞれ0%から100%までの範囲とし、最も大きい値を負荷値Ldとする。
図7は、本発明の一実施形態における通信モードの制御方法を説明する図である。図7は、通信モード切替処理において、通信モードが負荷値Ldに応じて切り替わるときの条件を示している。
例えば、通信モードがモードDであるときに、負荷値Ldが閾値TC1より大きくなると、通信管理サーバ1は、通信モードをモードCに切り替えるように各通信端末20に切替信号S(C)を送信する。通信モードがモードCであるときに、負荷値Ldが閾値TB1より大きくなると、通信管理サーバ1は、通信モードをモードBに切り替えるように各通信端末20に切替信号S(B)を送信する。一方、通信モードがモードCであるときに、負荷値Ldが閾値TC21より小さくなると、通信管理サーバ1は、通信モードをモードDに切り替えるように各通信端末20に切替信号S(D)を送信する。
ここで、TC1>TC2である。このようにすることで、LdがTC1より大きくなって通信モードがモードCに切り替わった直後にLdがTC1より小さくなったとしてもすぐにモードDには切り替わらないようになっている。他の閾値の関係も同様に、TB1>TB2であり、TA1>TA2である。モードAの負荷はモードBの負荷より少なく、モードBの負荷はモードCの負荷より少なく、モードCの負荷はモードDの負荷より少ない。したがって、TA1、TB1およびTC1は、同じ閾値として設定されていてもよい。TA2=TB2=TC2は、同じ閾値として設定されていてもよい。
このように、通信モード切替処理(ステップS400)では、通信管理サーバ1は、負荷値Ldが大きくなると、通信モードを現在のモードより負荷が軽くなるモードに変更し、負荷値Ldが小さくなると通信モードを現在のモードよりも通信遅延が少なくなるモードに変更する。上述した非合奏状態が検出されるまでは、この通信モード切替処理が継続される。
[6.データの送受信例]
続いて、上述のような通信制御方法および通信切替方法により、各通信拠点間における発音制御データDc、音データDaおよび動画データDvの送信に適用される通信方法について一例を説明する。
続いて、上述のような通信制御方法および通信切替方法により、各通信拠点間における発音制御データDc、音データDaおよび動画データDvの送信に適用される通信方法について一例を説明する。
図8は、通信拠点間のデータの流れを説明する図である。各拠点において演奏が行われていない場合には、通信モードがモードAとして設定された状態が維持される。この場合、発音制御データDc、音データDaおよび動画データDvの全てが、SFUサーバ80を介して通信拠点間で送受信される(図8において破線で示す経路)。すなわち全てのデータに対して、クライアントサーバ型通信が適用される。この状況では、通信遅延は大きくても合奏を行っていないので特に問題は生じないため、通信負荷および処理負荷を少なくすることが優先される。
通信拠点T1において演奏が行われた場合を想定する。この状態では、通信モードはモードAのままである。ここで、さらに通信モードT2において演奏が行われた場合、合奏状態が検出される。これにより、通信モードはモードDに切り替えられる。したがって、発音制御データDc、音データDaおよび動画データDvの全てが、P2P型通信となり、通信拠点間で直接送受信される(図8において実線で示す経路)。
その後、負荷値Ldが増加した場合には、通信モードがモードCに切り替わる。これによって、発音制御データDcおよび音データDaはP2P型通信による送信が維持されるもの、動画データDvのみSFUサーバ80を介した送信に切り替えられる。負荷値Ldが変化すると、その変化に従って通信モードが切り替わり、それぞれのデータの通信方式が切り替わる。
通信遅延を小さくするデータとして、動画データDvの優先順位が最も低く、発音制御データDcの優先順位が最も高い。動画データDvが遅延しても音の遅延が小さければ合奏を行うことには大きな支障がない。そのため、通信モードがモードDからモードCに切り替えられた段階で、動画データDvの送信は、クライアントサーバ型通信に切り替えられる。発音制御データDcは、データ量が少ないためP2P型通信を維持しても、負荷を増加する要因にはなりにくい。そのため、モードA以外の通信モードでは、発音制御データDcの送信は、P2P型通信を用いる。
通信拠点T1、T2の少なくとも一方で演奏が中断されると、非合奏状態が検出される。これにより、通信モードはモードAに切り替えられて、発音制御データDc、音データDaおよび動画データDvの全てが、P2P型通信となり、通信拠点間で直接送信される。
[7.各データ間の同期]
続いて、発音制御データDc、音データDaおよび動画データDvを受信した通信拠点において、放音装置60から出力される音と表示装置70で表示される映像とを同期する方法について説明する。ここでいう同期は、データ送信側におけるデータの各部の時間的な関係を、データ受信側においても維持することを示す。以下の説明は、データ送信側が通信拠点T1であり、データ受信側が通信拠点T2であることを想定する。
続いて、発音制御データDc、音データDaおよび動画データDvを受信した通信拠点において、放音装置60から出力される音と表示装置70で表示される映像とを同期する方法について説明する。ここでいう同期は、データ送信側におけるデータの各部の時間的な関係を、データ受信側においても維持することを示す。以下の説明は、データ送信側が通信拠点T1であり、データ受信側が通信拠点T2であることを想定する。
図9は、各データの同期方法を説明する図である。図9において、時刻tpは通信拠点T1から各データの特定の部分が送信されたタイミングを示し、時刻teは通信拠点T2において受信したデータを同期して出力するタイミングを示す。
時間dcは発音制御データDcの通信遅延に相当する時間である。そのため、通信拠点T2は、時刻tpから時間dcの経過後に発音制御データDcを受信する。時間daは音データDaの通信遅延に相当する時間である。そのため、通信拠点T2は、時刻tpから時間daの経過後に音データDaを受信する。時間dvは動画データDvの通信遅延に相当する時間である。そのため、通信拠点T2は、時刻tpから時間dvの経過後に動画データDvを受信する。
この例では、最も通信遅延が大きい動画データDvに同期させるため、時刻teは、動画データDvの受信時刻に対応する。そのため、通信拠点T2では、通信端末20は、発音制御データDcを受信してから時間htc(=時間dv-時間dc)の経過後に、その発音制御データDcを電子楽器30に供給する。発音制御データDcは、時間htcの経過までは、通信端末20においてバッファされる。電子楽器30は、音源によって発音制御データDcを音データDaに変換して、放音装置60に供給する。これによって、発音制御データDcに応じた音が放音装置60から出力される。
通信拠点T2では、通信端末20は、音データDaを受信してから時間hta(=時間dv-時間da)の経過後に、その音データDaを放音装置60に供給する。音データDaは、時間htaの経過までは、通信端末20においてバッファされる。これによって、音データDaに応じた音が放音装置60から出力される。通信拠点T2では、通信端末20は、動画データDvを受信すると、その動画データDvを表示装置70に供給する。これによって、動画データDvに応じた画像が表示装置70において表示される。このようにして、発音制御データDcに応じた音、音データDaに応じた音および動画データDvに応じた画像が、同期される。
時間htcおよび時間htaは、各通信拠点の関係(図9の例では通信拠点T1から通信拠点T2との関係)において、公知の技術によって予め取得されたものを用いてもよいし、それぞれのデータに送信時刻に対応するタイムスタンプが付与されることによって順次取得されるタイムスタンプの時間のずれから取得されてもよい。
これらとは別の方法で時間htcおよび時間htaが取得されてもよい。例えば、通信拠点T1において、演奏者による特定の動作が撮像されるとともに、その特定の動作と同時に特定の音が録音される。これによって得られた音データDaおよび動画データDvが通信拠点T2において受信され、その特定の動作と特定の音とのずれに基づいて時間htaが取得されてもよい。通信拠点T1において、電子楽器30の演奏によって発音制御データDcと音データDaとが得られる。この発音制御データDcと音データDaとが通信拠点T2において受信され、発音制御データDcに含まれるノートオンと音データDaの発音開始タイミングとのずれ(図10に示す時間htxに相当)と、時間htaとに基づいて時間htcが取得されてもよい。
動画データDvが大きく遅延する場合、特に通信モードがモードCである場合などにおいては、動画データDvを同期の対象外としてもよい。
図10は、動画データDvを同期しないときの各データの同期方法を説明する図である。図9に示す例とは異なり、通信拠点T2は、時刻tpに送信された動画データDvを時刻teよりも後に受信する。この例では、同期対象のデータのうち最も通信遅延が大きい音データDaに同期させるため、時刻teは、音データDaの受信時刻に対応する。そのため、通信拠点T2では、通信端末20は、発音制御データDcを受信してから時間htx(=時間da-時間dc)の経過後に、その発音制御データDcを電子楽器30に供給する。電子楽器30は、音源によって発音制御データDcを音データDaに変換して、放音装置60に供給する。これによって、発音制御データDcに応じた音が放音装置60から出力される。
通信拠点T2では、通信端末20は、音データDaを受信すると、その音データDaを放音装置60に供給する。これによって、音データDaに応じた音が放音装置60から出力される。このようにして、発音制御データDcに応じた音および音データDaに応じた音が、同期される。一方、動画データDvは、これらのデータに同期されない。
続いて、通信拠点T2における電子楽器30が、発音制御データDcに基づいて演奏操作子を駆動する駆動部を有することを想定する。この場合、電子楽器30に発音制御データDcが供給されてから、演奏操作子を駆動するまでの駆動時間を要する。その駆動時間を考慮して各データが同期されてもよい。このような同期においては、特定モードとして設定される。
図11は、特定モードのときの各データの同期方法を説明する図である。図11に示す時間dmは、発音制御データDcが供給されてから演奏操作子を駆動するまでに必要な駆動時間に対応する。時間dmは、電子楽器30の駆動部の特性として予め設定されてもよいし、事前に測定されてもよい。
この例では、発音制御データDcにより電子楽器30で音データDaが出力されるまでの時間が最も大きい。したがって、時刻teは、発音制御データDcに応じて演奏操作子が駆動される電子楽器30から音データDaが出力されるタイミングに対応する。そのため、通信拠点T2では、通信端末20は、音データDaを受信してから時間hty(=時間dc+時間dm-時間da)の経過後に、その音データDaを放音装置60に供給する。これによって、音データDaに応じた音が放音装置60から出力される。
通信拠点T2では、通信端末20は、動画データDvを受信してから時間htv(=時間dc+時間dm-時間dv)の経過後に、その動画データDvを表示装置70に供給する。これによって、動画データDvに応じた画像が表示装置70において表示される。このようにして、発音制御データDcに応じた音、音データDaに応じた音および動画データDvに応じた画像が、同期される。
発音制御データDcにより電子楽器30で音データDaが出力されるまでの時間が最も大きい場合、すなわち時間dmが大きい場合には、時間daおよび時間dvによっては、音データDaおよび動画データDvの送信をP2P型通信で行わなくてもよい。例えば、音データDaおよび動画データDvがクライアントサーバ型通信で通信拠点T1から送信されても、時刻teよりも前に通信拠点T2において受信される場合には、音データDaおよび動画データDvの送信をP2P型通信で行う必要がない。したがって、この場合には、通信モードがモードC、DであってもモードBとして設定されてもよい。
以上のとおり、一実施形態における通信システムでは、複数の通信拠点間の状況に応じて、通信方式を切り替えることができる。したがって、複数の通信拠点における演奏が合奏状態であるときに通信遅延を小さくする通信方式を適用し、非合奏状態であるときに通信負荷および処理負荷を小さくする通信方式を適用する、というように通信を制御することもできる。通信負荷または処理負荷が大きくなった場合には、データの種類毎に通信方式を制御することもできる。
<変形例>
以上、本発明の一実施形態について説明したが、本発明の一実施形態は、以下のように様々な形態に変形することもできる。また、上述した実施形態および以下に説明する変形例は、それぞれ互いに組み合わせて適用することもできる。
以上、本発明の一実施形態について説明したが、本発明の一実施形態は、以下のように様々な形態に変形することもできる。また、上述した実施形態および以下に説明する変形例は、それぞれ互いに組み合わせて適用することもできる。
(1)通信管理サーバ1が、SFUサーバ80の機能を有していてもよい。この場合には、通信管理サーバ1は、特徴量情報の代わりにクライアントサーバ型通信により送信されるデータを用いて、合奏状態を検出してもよい。
(2)通信管理サーバ1から通信端末20に送信される切替信号は、演奏モードを切り替えるための信号であるが、切り替え後の演奏モードを指定する代わりに、各データの通信方式を指定する信号であってもよい。この場合、通信方式を変更する必要のあるデータを指定する形式であってもよい。このようにすると、通信端末20は通信制御テーブルを有していなくてもよい。
(3)各通信拠点間を接続するP2P型通信が確立されるタイミングは、通信モードに応じてP2P型通信が必要になったタイミングであってもよいし、合奏状態の検出を開始する前のタイミングであってもよい。P2P型通信で送信するデータがないときには、P2P型通信の確立が解除されてもよい。
(4)通信方式を切り替えた場合に、通信端末20は、切替後の通信方式でデータを受信するまでは、切替前の通信方式で受信してから通信端末20でバッファしているデータを電子楽器30、放音装置60および表示装置70に出力してもよい。
(5)実施形態では通信拠点T1と通信拠点T2とが合奏していることにより、セッションルームが合奏状態であると検出され、検出時の比較対象とはならなかった通信拠点T3については、設定される通信モードとは異なる処理が実行されてもよい。例えば、通信拠点T3から送信されるデータは、通信遅延を小さくする必要がないから、クライアントサーバ型通信が用いられるようにしてもよい。
(6)通信モードは、モードA、Dのみとしてもよい。この場合には、通信負荷および処理負荷に応じて通信モードを切り替える処理は不要である。
(7)動画データDvは全ての通信モードにおいてクライアントサーバ型通信により送信されるようにして、通信方式の制御対象のストリーミングデータから除外されてもよい。
(8)通信端末20は、通信負荷および処理負荷が所定の値を超えた場合には、これらの負荷が低減するような処理を実行してもよい。通信端末20は、例えば、動画サイズを小さくする処理、動画解像度を低くする処理、動画フレーム周波数を低くする処理、音のサンプリング周波数を低くする処理、圧縮率を増加する処理およびオーディオチャンネルを削減する処理(ステレオをモノラルにする処理)によって、負荷を低減すればよい。これらの処理は、調整範囲が予め定められている。このように負荷を低減する処理を行う場合には、調整範囲内での調整ができなくなるまで、上述した負荷値Ldが増加しなくなる。
(9)合奏状態は、動画データDvを比較することにより検出されてもよい。この場合には、特徴量情報は、動画データDvに関する特徴量を含む。この特徴量は、例えば、動画データDvが示す画像を解析した結果として、楽器が画像に含まれているか否かを示す情報であってもよいし、動いている人が画像に含まれているか否かを示す情報であってもよい。合奏状態は、実施形態における発音期間に代えて、楽器が画像に含まれている期間または動いている人が画像に含まれている期間を用いることによって検出されればよい。このように、各通信拠点の状況に応じて通信拠点間の通信方式を制御するのであれば、各通信拠点の状況の検出には様々な方法が適用可能である。
この場合であっても、上記の変形例(7)のように動画データDvが通信方式の制御対象のストリーミングデータから除外されてもよい。このように、合奏状態の検出のように各通信拠点の状況を検出するためのストリーミングデータと、通信方法の制御対象となるストリーミングデータとは一致していなくてもよい。
合奏状態は、本変形例による画像に関する特徴量を比較することと、実施形態による音に関する特徴量を比較することとを併用することによって検出されるようにしてもよい。併用する場合には、いずれか一方の条件を満たした場合に合奏状態が検出されてもよいし、双方の条件を満たした場合に合奏状態が検出されてもよい。
(10)電子楽器30による演奏が行われた場合には、電子楽器30から出力される発音制御データDcおよび音データDaのうち、いずれか一方が通信端末20から送信されるようにしてもよい。例えば、通信拠点T1において電子楽器30による演奏が行われた場合、通信拠点T2、T3において、発音制御データDcを音データDaに変換できる機能を有する場合(例えば電子楽器30を備える場合)には、通信拠点T1の通信端末20は、電子楽器30で生成された音データDaを送信しない。一方、通信拠点T2、T3において、発音制御データDcを音データDaに変換できる機能を有しない場合には、通信拠点T1の通信端末20は、電子楽器30で生成された発音制御データDcを送信しない。発音制御データDcを音データDaに変換できる機能を有しているか否かの情報は、各通信拠点から通信管理サーバ1に予め送信されていればよい。このようにすることで、不要なストリーミングデータが各通信拠点から送信されなくなる。
(11)合奏状態は、複数の通信拠点における発音期間の関係に基づいて検出されていたが、発音期間ではなく音の相関に基づいて検出されてもよい。この場合には、複数の通信拠点における音が、区間W1~W5のそれぞれにおいて所定の相関関係を有するか否かを判定すればよい。特徴量は、相関関係を取得するために必要な情報であればよく、音に関連する情報であればよい。例えば、音に関連する情報としての特徴量が音の強弱に基づいて算出されたBPM(Beats Per Minute)であってもよい。この場合には、各通信拠点におけるBPMが区間W1~W5において10%以下の誤差となった場合に、合奏状態が検出されればよい。
同じ内容の演奏が複数の通信拠点で行われるような状況を想定した場合、複数の通信拠点から送信された音データDaにおける音波形信号を比較して、音波形信号の一致度を相関関係として取得してもよい。したがって、音に関連する情報としての特徴量は音波形信号である。通信遅延を考慮して、双方の信号の時間的な相対位置を所定範囲で変更しながら音波形信号の一致の程度を算出し、最も一致の程度が大きいときの値が一致度として採用される。この一致度が所定値より大きい場合に、合奏状態が検出されればよい。
通信遅延を考慮する方法の別の例として、通信管理サーバ1は、各通信拠点から音データDaを受信するときの通信遅延時間を取得して、これらの通信遅延時間に基づいて通信拠点からの音データDaの時間的な位置を、通信拠点から送信されたタイミングに調整するようにしてもよい。このようにして、各通信拠点に対応する音データDaの時間的な位置を調整することによって、通信管理サーバ1で受信した時刻を基準とした音データDaから、通信拠点から送信された時刻を基準とした音データDaに変換することができる。
このように変換された音データDaを用いて、音波形信号を比較することで、音波形信号の一致度を算出してもよい。これにより、通信遅延時間の影響を小さくすることができる。取得される通信遅延時間の精度によっては、上記の方法を併用し、変換された音データDaに基づく双方の信号に対して、時間的な位置を所定範囲で変更しながら音波形信号の一致の程度を算出するようにしてもよい。
その他にも、音に関連する情報としての特徴量として、例えば、音高、音量、音色、奏法、コードなどの音楽的分析要素が用いられてもよい。合奏状態は、同一種類の要素を比較して検出される場合に限らず、異なる種類の要素を比較して検出される場合もある。例えば、コードと音高とを比較して、コードの構成音と調和性の高い音高であることを合奏状態の検出の条件としてもよい。
例えば、和音など複数の音を同時に発音できる楽器(例えば、ピアノなどの鍵盤楽器、ギターなどの弦楽器)ではコードを特徴量として用いる。一方、単音での発音となる楽器(例えば、バイオリンなどの弦楽器、サックスおよびトランペットなどの管楽器)では特徴量として音高を用いる。コードと音高とを比較することによって、双方の楽器の合奏状態が検出されてもよい。楽器ではなく人声において、合奏状態の検出における比較対象として用いられてもよい。一人の声であれば、単音での発音となる楽器に相当し、複数人の声であれば、複数の音を同時に発音できる楽器に相当する。
音高を用いる場合には、例えば、時間経過に伴う音高の変化、すなわちフレーズを用いて、合奏状態が検出されてもよい。このとき、比較される2つのフレーズにおいて、同一となる音高の割合が所定割合以上であることを条件として、合奏状態が検出されてもよい。
(12)各データが送信される通信方式は、P2P型通信とクライアントサーバ型通信とのいずれかから選択される場合に限られず、通信遅延が異なる通信方式の組み合わせであれば、様々な組み合わせから選択されてもよい。
(13)合奏状態の検出は、通信管理サーバ1で行われる場合に限らず、いずれかの通信拠点の通信端末20で行われてもよい。この場合には、通信端末20は、他の通信拠点から送信されるデータの比較に基づいて合奏状態を検出する。通信端末20は、比較の結果として、合奏状態を検出した場合に、通信管理サーバ1に対して合奏状態を検出したという結果を通信管理サーバ1に送信すればよい。
以上が変形例に関する説明である。
本発明の一実施形態によれば、第1通信方式により第1端末から送信される第1ストリーミングデータにおける第1特徴量と、前記第1通信方式により第2端末から送信される第2ストリーミングデータにおける第2特徴量との比較結果を取得し、前記比較結果に基づいて前記第1特徴量と前記第2特徴量とが第1関係を有する場合に、前記第1端末と前記第2端末との間において前記第1通信方式により送信される通信制御対象のストリーミングデータを、前記第1通信方式による送信から当該第1通信方式とは異なる第2通信方式による送信に切り替えるための第1切替信号を、前記第1端末および前記第2端末に送信する、通信制御方法が提供される。さらに以下のように構成することもできる。
前記通信制御方法において、前記第1特徴量と前記第2特徴量とは、発音期間を規定する情報を含み、前記第1関係は、前記第1特徴量に規定される第1発音期間と前記第2特徴量に規定される第2発音期間とが、所定数の判定期間のそれぞれにおいて存在することを含み、前記通信制御対象のストリーミングデータは、前記第1ストリーミングデータおよび前記第2ストリーミングデータを含む。
前記通信制御方法において、前記第1特徴量と前記第2特徴量とは、音に関連する情報を含み、前記第1関係は、前記第1特徴量と前記第2特徴量とが所定の相関関係を有することを含み、前記通信制御対象のストリーミングデータは、前記第1ストリーミングデータおよび前記第2ストリーミングデータを含む。
前記通信制御方法において、前記音に関連する情報は音波形信号であり、前記第1関係は、前記第1特徴量に対応する音波形信号と前記第2特徴量に対応する音波形信号との時間的な相対位置を所定範囲で変更しながら得られる音の一致の程度が所定値より大きいことを含む。
前記通信制御方法において、前記音に関連する情報は音波形信号であり、前記第1関係は、前記第1端末に対する通信遅延時間に基づいて時間的な位置が調整された前記第1特徴量に対応する音波形信号と、前記第2端末に対する通信遅延時間に基づいて時間的な位置が調整された前記第2特徴量に対応する音波形信号とから得られる一致の程度が所定値より大きいことを含む。
前記通信制御方法において、前記第2通信方式の通信遅延は、前記第1通信方式の通信遅延よりも小さい。
前記通信制御方法において、前記第1通信方式では、前記第1端末と前記第2端末とは、サーバを介して互いに通信し、前記第2通信方式では、前記第1端末と前記第2端末とは、P2Pにより互いに通信する。
前記通信制御方法において、前記第1端末から前記第2端末に、前記第1通信方式により音波形信号データを含む第3ストリーミングデータがさらに送信され、前記第1ストリーミングデータは、発音制御データを含み、前記通信制御対象のストリーミングデータは、前記第1ストリーミングデータを含み、前記第1特徴量と前記第2特徴量とが第1関係を有する場合においても、前記第3ストリーミングデータは、前記第1通信方式により送信される。
前記通信制御方法において、前記第1端末から前記第2端末に、前記第1通信方式により音波形信号データを含む第3ストリーミングデータがさらに送信され、前記第1ストリーミングデータは、発音制御データを含み、前記通信制御対象のストリーミングデータは、前記第1ストリーミングデータおよび前記第3ストリーミングデータを含み、前記第1端末または前記第1端末の通信負荷が所定の条件を満たすと、前記第3ストリーミングデータを前記第2通信方式による送信から前記第1通信方式による送信に切り替えるための第2切替信号を前記第1端末に送信する。
前記通信制御方法において、前記第1端末から前記第2端末に、前記第1通信方式により音波形信号データを含む第3ストリーミングデータがさらに送信され、前記第1ストリーミングデータは、発音制御データを含み、前記通信制御対象のストリーミングデータは、前記第1ストリーミングデータおよび前記第3ストリーミングデータを含み、前記第1端末または前記第2端末の処理負荷が所定の条件を満たすと、前記第3ストリーミングデータを前記第2通信方式による送信から前記第1通信方式による送信に切り替えるための第2切替信号を前記第1端末に送信する。
前記通信制御方法において、前記比較結果に基づいて前記第1特徴量と前記第2特徴量とが第1関係を有した後において前記第1特徴量と前記第2特徴量とが第2関係を有する場合に、前記第2通信方式による通信確立を解除し、前記通信制御対象のストリーミングデータを前記第2通信方式による送信から前記第1通信方式による送信に切り替えるための第2切替信号を、前記第1端末および前記第2端末に送信する。
前記通信制御方法において、前記第1特徴量と前記第2特徴量とが第1関係を有する場合に、前記通信制御対象のストリーミングデータが前記第2通信方式により第3端末にさらに送信される。
1…通信管理サーバ、11…制御部、13…記憶部、15…通信部、20…通信端末、21…制御部、23…記憶部、25…通信部、27…操作部、30…電子楽器、40…収音装置、50…撮像装置、60…放音装置、70…表示装置、80…SFUサーバ
Claims (12)
- 第1通信方式により第1端末から送信される第1ストリーミングデータにおける第1特徴量と、前記第1通信方式により第2端末から送信される第2ストリーミングデータにおける第2特徴量との比較結果を取得し、
前記比較結果に基づいて前記第1特徴量と前記第2特徴量とが第1関係を有する場合に、前記第1端末と前記第2端末との間において前記第1通信方式により送信される通信制御対象のストリーミングデータを、前記第1通信方式による送信から当該第1通信方式とは異なる第2通信方式による送信に切り替えるための第1切替信号を、前記第1端末および前記第2端末に送信する、
通信制御方法。 - 前記第1特徴量と前記第2特徴量とは、発音期間を規定する情報を含み、
前記第1関係は、前記第1特徴量に規定される第1発音期間と前記第2特徴量に規定される第2発音期間とが、所定数の判定期間のそれぞれにおいて存在することを含み、
前記通信制御対象のストリーミングデータは、前記第1ストリーミングデータおよび前記第2ストリーミングデータを含む、請求項1に記載の通信制御方法。 - 前記第1特徴量と前記第2特徴量とは、音に関連する情報を含み、
前記第1関係は、前記第1特徴量と前記第2特徴量とが所定の相関関係を有することを含み、
前記通信制御対象のストリーミングデータは、前記第1ストリーミングデータおよび前記第2ストリーミングデータを含む、請求項1に記載の通信制御方法。 - 前記音に関連する情報は音波形信号であり、
前記第1関係は、前記第1特徴量に対応する音波形信号と前記第2特徴量に対応する音波形信号との時間的な相対位置を所定範囲で変更しながら得られる音の一致の程度が、所定値より大きいことを含む、請求項3に記載の通信制御方法。 - 前記音に関連する情報は音波形信号であり、
前記第1関係は、前記第1端末からの通信遅延時間に基づいて時間的な位置が調整された前記第1特徴量に対応する音波形信号と、前記第2端末からの通信遅延時間に基づいて時間的な位置が調整された前記第2特徴量に対応する音波形信号と、から得られる一致の程度が、所定値より大きいことを含む、請求項3または請求項4に記載の通信制御方法。 - 前記第2通信方式の通信遅延は、前記第1通信方式の通信遅延よりも小さい、請求項1から請求項5のいずれかに記載の通信制御方法。
- 前記第1通信方式では、前記第1端末と前記第2端末とは、サーバを介して互いに通信し、
前記第2通信方式では、前記第1端末と前記第2端末とは、P2Pにより互いに通信する、請求項1から請求項5のいずれかに記載の通信制御方法。 - 前記第1端末から前記第2端末に、前記第1通信方式により音波形信号データを含む第3ストリーミングデータがさらに送信され、
前記第1ストリーミングデータは、発音制御データを含み、
前記通信制御対象のストリーミングデータは、前記第1ストリーミングデータを含み、
前記第1特徴量と前記第2特徴量とが第1関係を有する場合においても、前記第3ストリーミングデータは、前記第1通信方式により送信される、
請求項1から請求項7のいずれかに記載の通信制御方法。 - 前記第1端末から前記第2端末に、前記第1通信方式により音波形信号データを含む第3ストリーミングデータがさらに送信され、
前記第1ストリーミングデータは、発音制御データを含み、
前記通信制御対象のストリーミングデータは、前記第1ストリーミングデータおよび前記第3ストリーミングデータを含み、
前記第1端末または前記第1端末の通信負荷が所定の条件を満たすと、前記第3ストリーミングデータを前記第2通信方式による送信から前記第1通信方式による送信に切り替えるための第2切替信号を前記第1端末に送信する、
請求項1から請求項7のいずれかに記載の通信制御方法。 - 前記第1端末から前記第2端末に、前記第1通信方式により音波形信号データを含む第3ストリーミングデータがさらに送信され、
前記第1ストリーミングデータは、発音制御データを含み、
前記通信制御対象のストリーミングデータは、前記第1ストリーミングデータおよび前記第3ストリーミングデータを含み、
前記第1端末または前記第2端末の処理負荷が所定の条件を満たすと、前記第3ストリーミングデータを前記第2通信方式による送信から前記第1通信方式による送信に切り替えるための第2切替信号を前記第1端末に送信する、
請求項1から請求項7のいずれかに記載の通信制御方法。 - 前記比較結果に基づいて前記第1特徴量と前記第2特徴量とが第1関係を有した後において前記第1特徴量と前記第2特徴量とが第2関係を有する場合に、前記第2通信方式による通信確立を解除し、前記通信制御対象のストリーミングデータを前記第2通信方式による送信から前記第1通信方式による送信に切り替えるための第2切替信号を、前記第1端末および前記第2端末に送信する、請求項1から請求項10のいずれかに記載の通信制御方法。
- 前記第1特徴量と前記第2特徴量とが第1関係を有する場合に、前記通信制御対象のストリーミングデータが前記第2通信方式により第3端末にさらに送信される、請求項1から請求項11のいずれかに記載の通信制御方法。
Priority Applications (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2020146821A JP2022041553A (ja) | 2020-09-01 | 2020-09-01 | 通信制御方法 |
US17/396,880 US11588888B2 (en) | 2020-09-01 | 2021-08-09 | Method of controlling communication and communication control device in which a method for transmitting data is switched |
CN202110956376.XA CN114205400B (zh) | 2020-09-01 | 2021-08-19 | 通信控制方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2020146821A JP2022041553A (ja) | 2020-09-01 | 2020-09-01 | 通信制御方法 |
Publications (1)
Publication Number | Publication Date |
---|---|
JP2022041553A true JP2022041553A (ja) | 2022-03-11 |
Family
ID=80355912
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2020146821A Pending JP2022041553A (ja) | 2020-09-01 | 2020-09-01 | 通信制御方法 |
Country Status (3)
Country | Link |
---|---|
US (1) | US11588888B2 (ja) |
JP (1) | JP2022041553A (ja) |
CN (1) | CN114205400B (ja) |
Families Citing this family (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2022041553A (ja) * | 2020-09-01 | 2022-03-11 | ヤマハ株式会社 | 通信制御方法 |
Family Cites Families (52)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6646195B1 (en) * | 2000-04-12 | 2003-11-11 | Microsoft Corporation | Kernel-mode audio processing modules |
US6653545B2 (en) * | 2002-03-01 | 2003-11-25 | Ejamming, Inc. | Method and apparatus for remote real time collaborative music performance |
JP4001091B2 (ja) * | 2003-09-11 | 2007-10-31 | ヤマハ株式会社 | 演奏システム及び楽音映像再生装置 |
JP4259329B2 (ja) | 2004-01-08 | 2009-04-30 | ヤマハ株式会社 | 演奏装置および合奏システム |
US7297858B2 (en) * | 2004-11-30 | 2007-11-20 | Andreas Paepcke | MIDIWan: a system to enable geographically remote musicians to collaborate |
JP2006284796A (ja) * | 2005-03-31 | 2006-10-19 | Yamaha Corp | 楽音信号送信端末および楽音信号受信端末 |
US7511215B2 (en) * | 2005-06-15 | 2009-03-31 | At&T Intellectual Property L.L.P. | VoIP music conferencing system |
US7518051B2 (en) * | 2005-08-19 | 2009-04-14 | William Gibbens Redmann | Method and apparatus for remote real time collaborative music performance and recording thereof |
US7853342B2 (en) * | 2005-10-11 | 2010-12-14 | Ejamming, Inc. | Method and apparatus for remote real time collaborative acoustic performance and recording thereof |
CN100507533C (zh) * | 2006-02-07 | 2009-07-01 | 合肥工大双发信息***技术有限公司 | 金属液综合性能在线智能检测*** |
US7593354B2 (en) * | 2006-03-22 | 2009-09-22 | Musigy Usa, Inc. | Method and system for low latency high quality music conferencing |
JP4924107B2 (ja) * | 2006-04-27 | 2012-04-25 | ソニー株式会社 | 無線通信システム、並びに無線通信装置及び無線通信方法 |
EP2039158B1 (en) * | 2006-06-27 | 2019-10-30 | Thomson Licensing | Performance aware peer-to-peer video-on-demand |
EP2036347B1 (en) * | 2006-06-27 | 2018-08-15 | Thomson Licensing | Admission control for performance aware peer-to-peer video-on-demand |
KR101207050B1 (ko) * | 2006-06-27 | 2012-11-30 | 톰슨 라이센싱 | 성능 인식 피어-투-피어 주문형 콘텐츠 서비스를 위한 대화식 재생 장치에 대한 지원 |
US7996550B2 (en) * | 2006-11-30 | 2011-08-09 | Red Hat, Inc. | Peer-to-peer download with quality of service fallback |
WO2008121650A1 (en) * | 2007-03-30 | 2008-10-09 | William Henderson | Audio signal processing system for live music performance |
US8301790B2 (en) * | 2007-05-30 | 2012-10-30 | Randy Morrison | Synchronization of audio and video signals from remote sources over the internet |
JP4977534B2 (ja) * | 2007-06-07 | 2012-07-18 | 株式会社日立製作所 | センサネットシステム、及びセンサノード |
US8078729B2 (en) * | 2007-08-21 | 2011-12-13 | Ntt Docomo, Inc. | Media streaming with online caching and peer-to-peer forwarding |
US8918541B2 (en) * | 2008-02-22 | 2014-12-23 | Randy Morrison | Synchronization of audio and video signals from remote sources over the internet |
US20090234967A1 (en) * | 2008-03-17 | 2009-09-17 | Nokia Corporation | Method, system, and apparatus for transferring P2P file distribution tasks between devices |
US8447875B2 (en) * | 2010-03-10 | 2013-05-21 | Thomson Licensing | Unified cache and peer-to-peer method and apparatus for streaming media in wireless mesh networks |
CA2796241C (en) * | 2010-04-12 | 2021-05-18 | Smule, Inc. | Continuous score-coded pitch correction and harmony generation techniques for geographically distributed glee club |
JP2011253462A (ja) * | 2010-06-03 | 2011-12-15 | Sony Corp | コンテンツ推薦システム、コンテンツ推薦装置、およびコンテンツ推薦方法 |
US20120050456A1 (en) * | 2010-08-27 | 2012-03-01 | Cisco Technology, Inc. | System and method for producing a performance via video conferencing in a network environment |
US9866731B2 (en) * | 2011-04-12 | 2018-01-09 | Smule, Inc. | Coordinating and mixing audiovisual content captured from geographically distributed performers |
US9236039B2 (en) * | 2013-03-04 | 2016-01-12 | Empire Technology Development Llc | Virtual instrument playing scheme |
US20150256613A1 (en) * | 2014-03-10 | 2015-09-10 | JamKazam, Inc. | Distributed Metronome For Interactive Music Systems |
CN105100954B (zh) * | 2014-05-07 | 2018-05-29 | 朱达欣 | 一种基于互联网通信及流媒体直播的交互应答***及方法 |
US20160140950A1 (en) * | 2014-11-14 | 2016-05-19 | The Board Of Trustees Of The Leland Stanford Junior University | Method and System for Real-Time Synthesis of an Acoustic Environment |
US20160197669A1 (en) * | 2014-12-11 | 2016-07-07 | Tesla Wireless Company LLC | Communication method and system that uses low latency/low data bandwidth and high latency/high data bandwidth pathways |
JP2016178419A (ja) * | 2015-03-19 | 2016-10-06 | 株式会社リコー | 通信制御装置、通信システム、通信制御方法およびプログラム |
AU2016270352B2 (en) * | 2015-06-03 | 2020-10-29 | Smule, Inc. | Automated generation of coordinated audiovisual work based on content captured from geographically distributed performers |
US9949027B2 (en) * | 2016-03-31 | 2018-04-17 | Qualcomm Incorporated | Systems and methods for handling silence in audio streams |
US10437552B2 (en) * | 2016-03-31 | 2019-10-08 | Qualcomm Incorporated | Systems and methods for handling silence in audio streams |
US10627782B2 (en) * | 2017-01-06 | 2020-04-21 | The Trustees Of Princeton University | Global time server for high accuracy musical tempo and event synchronization |
US10567788B2 (en) * | 2017-04-21 | 2020-02-18 | Zenimax Media Inc. | Systems and methods for game-generated motion vectors |
US11625213B2 (en) * | 2017-05-15 | 2023-04-11 | MIXHalo Corp. | Systems and methods for providing real-time audio and data |
US10951890B1 (en) * | 2017-05-16 | 2021-03-16 | Parsec Cloud, Inc. | Low-latency, peer-to-peer streaming video |
GB2566008B (en) * | 2017-08-23 | 2020-04-22 | Falmouth Univ | Collaborative session over a network |
US10944669B1 (en) * | 2018-02-09 | 2021-03-09 | GoTenna, Inc. | System and method for efficient network-wide broadcast in a multi-hop wireless network using packet echos |
KR102513297B1 (ko) * | 2018-02-09 | 2023-03-24 | 삼성전자주식회사 | 전자 장치 및 전자 장치의 기능 실행 방법 |
US10929092B1 (en) * | 2019-01-28 | 2021-02-23 | Collabra LLC | Music network for collaborative sequential musical production |
US11321931B2 (en) * | 2020-03-31 | 2022-05-03 | Home Box Office, Inc. | Creating cloud-hosted, streamed augmented reality experiences with low perceived latency |
US11196808B2 (en) * | 2020-05-06 | 2021-12-07 | Seth Weinberger | Technique for generating group performances by multiple, remotely located performers |
US11323496B2 (en) * | 2020-05-06 | 2022-05-03 | Seth Weinberger | Technique for generating group performances by multiple, remotely located performers |
US11616589B2 (en) * | 2020-06-25 | 2023-03-28 | Sony Interactive Entertainment LLC | Methods and systems for performing and recording live music near live with no latency |
US11546393B2 (en) * | 2020-07-10 | 2023-01-03 | Mark Goldstein | Synchronized performances for remotely located performers |
JP2022041553A (ja) * | 2020-09-01 | 2022-03-11 | ヤマハ株式会社 | 通信制御方法 |
US11329363B1 (en) * | 2020-11-09 | 2022-05-10 | Parsec Technologies, Inc. | Emergency portable hot spot with antennas built into cover |
US11579834B2 (en) * | 2020-12-12 | 2023-02-14 | Elite Audio Records | Digital audio workstation interface for streaming audiovisual data |
-
2020
- 2020-09-01 JP JP2020146821A patent/JP2022041553A/ja active Pending
-
2021
- 2021-08-09 US US17/396,880 patent/US11588888B2/en active Active
- 2021-08-19 CN CN202110956376.XA patent/CN114205400B/zh active Active
Also Published As
Publication number | Publication date |
---|---|
CN114205400A (zh) | 2022-03-18 |
US20220070254A1 (en) | 2022-03-03 |
US11588888B2 (en) | 2023-02-21 |
CN114205400B (zh) | 2023-09-01 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
Rottondi et al. | An overview on networked music performance technologies | |
KR100569774B1 (ko) | 좋은 앙상블로 음악을 재생하기 위한 동기 재생 시스템,및 앙상블을 위한 레코더 및 플레이어 | |
JP4934180B2 (ja) | 撥弦楽器演奏評価装置 | |
US20210335332A1 (en) | Video processing device and video processing method | |
US8723011B2 (en) | Musical sound generation instrument and computer readable medium | |
US20170287457A1 (en) | Apparatus, method, and computer-readable storage medium for compensating for latency in musical collaboration | |
JPH11331248A (ja) | 送信装置および送信方法、受信装置および受信方法、並びに提供媒体 | |
CN114120942A (zh) | 无时延地近乎现场演奏和录制现场互联网音乐的方法和*** | |
CN114205400B (zh) | 通信控制方法 | |
Hsu | Strategies for managing timbre and interaction in automatic improvisation systems | |
JP2023525397A (ja) | オーディオ波形サンプルを用いてライブ音楽を演奏及び録音するための方法及びシステム | |
JP6501344B2 (ja) | 聴取者評価を考慮したカラオケ採点システム | |
JP4333588B2 (ja) | セッション端末 | |
US20220301529A1 (en) | System and method for distributed musician synchronized performances | |
JP2014153516A (ja) | 判定装置 | |
JP2006284796A (ja) | 楽音信号送信端末および楽音信号受信端末 | |
JP2001228866A (ja) | カラオケ装置用の電子打楽器装置 | |
JP4214917B2 (ja) | 演奏システム | |
JP2008097096A (ja) | サーバ装置及び通信セッション確立方法 | |
JP2001060089A (ja) | カラオケ装置 | |
JP2008244888A (ja) | 通信装置、通信方法およびプログラム | |
WO2022168375A1 (ja) | 通信方法、通信システムおよび通信装置 | |
JP2015069053A (ja) | ストレッチチューニングを考慮して歌唱採点を行うカラオケ装置 | |
JP4159961B2 (ja) | カラオケ装置 | |
JP4192798B2 (ja) | 通信端末 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20230721 |
|
A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20240315 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20240409 |
|
A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20240607 |