JP6209357B2 - デジタル音楽放送受信時のエラー防止システム - Google Patents

Description

本発明はデジタル音楽放送受信時のエラー防止システムに関する。

カラオケ店における背景音楽（ＢＧＭ）などに用いる音楽データがインターネットなどを通じて提供されるようになってきている。このような音楽データは通常ＵＤＰ（User Datagram Protocol）のような低信頼のプロトコルを用いたマルチキャストストリーミング通信により伝送される。パケットの欠損や破壊などのエラーが発生すると、音飛びやノイズなど音声に乱れが生じるため、エラーを防止する施策が講じられている。たとえば特許文献１では、伝送エラー部分を再送することにより伝送エラーを修正している。

特開２００２−８４２３９号公報

カラオケの伴奏データや歌詞データなどのカラオケデータもインターネットなどの通信ネットワークを通じてホスト側からカラオケ装置側に配信されるようになってきている。カラオケデータの配信とＢＧＭのストリーミングとは同じ物理回線を用いることから、通信が混み合いエラーが発生し易くなっている。しかしながら、特許文献１に記載のシステムでは、エラーが発生した部位について再送を行うため、再送によってむしろ通信ネットワークがさらに混み合うことになってしまい、パケットの欠損や破壊などのエラーが解消されないという状況が生じうる。

本発明は、このような背景を鑑みてなされたものであり、ＢＧＭの配信に係るエラーを低減することを目的とする。

上記課題を解決するための本発明の主たる発明は、デジタル音楽放送受信時のエラー防止システムであって、ＢＧＭ用の音楽データであるＢＧＭデータを受信して再生する音楽再生手段と、カラオケ用のデータであるカラオケデータを受信するカラオケデータ受信手段と、前記ＢＧＭデータが再生されていないときよりも前記ＢＧＭデータが再生されているときの方が前記カラオケデータ受信手段による単位時間あたりの通信量が少なくなるように制御処理を行う通信量制御手段と、を備えることとする。

本発明のデジタル音楽放送受信時のエラー防止システムによれば、ＢＧＭデータが再生されているときにはカラオケデータの配信に係る通信量を少なくすることができる。したがって、カラオケデータの配信に係る通信量を低減し、ＢＧＭデータの通信に使用可能な帯域を確保することができる。よって、ＢＧＭデータの配信に係る通信エラーを抑止することができる。

また、本発明のデジタル音楽放送受信時のエラー防止システムでは、前記カラオケデータ受信手段はパケット通信により前記カラオケデータを受信し、前記通信量制御手段は、前記ＢＧＭデータが再生されていないときよりも前記ＢＧＭデータが再生されているときの方が前記カラオケデータ受信手段の受信するパケットのサイズが小さくなるように前記制御処理を行うようにしてもよい。

この場合、ＢＧＭが再生されている場合には、カラオケデータの伝送についてのパケットのサイズを小さくすることができる。したがって、通信路におけるカラオケデータのバースト転送が抑制され、カラオケデータを伝送するパケット間にＢＧＭデータのためのパケットを挿入する隙間が生じるようにすることができる。よって、ＢＧＭデータの配信に係るパケットの欠損などのエラーを抑制することができる。

また、本発明のデジタル音楽放送受信時のエラー防止システムは、カラオケ装置と、前記カラオケ装置と通信可能に接続されるサーバ装置とを含んで構成され、前記サーバ装置は、前記通信量制御手段と、前記カラオケデータを分割した分割データのそれぞれを前記カラオケ装置に送信するカラオケデータ送信部と、を備え、前記制御処理は、前記ＢＧＭデータが再生されていないときよりも、前記音楽再生手段により前記ＢＧＭデータが再生されているときの方が、前記カラオケデータの分割数が大きくなるように分割することを含むようにしてもよい。

この場合、ＢＧＭの配信に係るエラーを抑制しつつ、カラオケデータの送信側（サーバ装置側）において通信量を調整することができるので、既存のカラオケ装置を改変する必要がなく、大量のカラオケ装置を改変する手間を省くとともに、改変に起因する不測の不具合の発生確率を抑制することができる。

その他本願が開示する課題やその解決方法については、発明の実施形態の欄および図面により明らかにされる。

本発明によれば、ＢＧＭの配信に係るエラーを低減することができる。

本実施形態に係るデジタル音楽放送受信時のエラー防止システムの概略構成例を示す図である。 カラオケ装置２、ラジオ再生装置５および転送装置４１，４２の配置例を示す図である。 ラジオホスト装置３のハードウェア構成例を示す図である。 ラジオホスト装置３のソフトウェア構成例を示す図である。 ラジオ再生装置５のハードウェア構成例を示す図である。 ラジオ再生装置５のソフトウェア構成例を示す図である。 カラオケホスト装置１のハードウェア構成例を示す図である。 カラオケホスト装置１のソフトウェア構成例を示す図である。 カラオケ装置２のハードウェア構成例を示す図である。 カラオケ装置２のソフトウェア構成例を示す図である。 本実施形態のカラオケ装置２における処理を説明する図である。 カラオケホスト装置１におけるカラオケデータの調整処理の流れを示す図である。

＝＝システム構成例＝＝
以下、本発明の実施形態について説明する。図１は本実施形態に係るデジタル音楽放送受信時のエラー防止システムの概略構成例を示す図である。

本実施形態のデジタル音楽放送受信時のエラー防止システムはカラオケホスト装置１、カラオケ装置２およびラジオホスト装置３を含んで構成され、これらは通信回線４に接続される。通信回線４は、たとえば、光ファイバー、イーサネット（登録商標）、公衆電話回線、無線通信網などにより構築される。通信回線４ではパケット通信によるデータ通信が行われる。本実施形態では通信回線４はインターネットであり、ＴＣＰ／ＩＰのプロトコルに従ったパケット通信が行われることを想定する。

カラオケホスト装置１は、サーバ装置として機能し、伴奏データや歌詞データなどを含むカラオケに用いられるデータ（以下、カラオケデータという。）を蓄積して管理する。

カラオケ装置２は、たとえばカラオケ店ＫＢの各カラオケルームＲＭに設置され、カラオケに関する各種の制御処理を行う。カラオケ装置２は、カラオケデータを記憶し、選曲されたカラオケ楽曲に係るカラオケデータに基づいて伴奏の演奏制御、歌詞および背景映像の表示制御、ならびにマイクから入力された歌唱音声信号の処理などを行う。

カラオケデータはカラオケホスト装置１からカラオケ装置２に提供される。新曲が登録された場合などには、カラオケホスト装置１からカラオケ装置２に向けてカラオケデータが送信される。カラオケホスト装置１からカラオケ装置２へのカラオケデータの送信は、ネットワーク層においてはＩＰｖ４（Internet Protocol Version 4）、トランスポート層においてはＴＣＰ（Transmission Control Protocol）に従って行われる。カラオケルームＲＭにおいて、カラオケ装置２と通信回線４との間には転送装置４１（ルーティング装置、ルータあるいはゲートウェイと呼ばれる。）が設置され、転送装置４１によりＩＰｖ４のパケットの経路制御が行われる。ＴＣＰによるデータ通信ではカラオケホスト装置１とカラオケ装置２との間でのハンドシェイクにより確実にデータが伝送される。

ラジオホスト装置３はカラオケルームＲＭにおいて背景音楽（ＢＧＭ）として再生するための音楽データ（以下、ＢＧＭデータという。）を管理する。ＢＧＭデータは、たとえばＭＰ（Moving Picture experts group audio layer）３、ＭＰ４などの形式のデータである。カラオケ店ＫＢの営業時間中、ラジオホスト装置３からカラオケルームＲＭに向けてＢＧＭデータが送信される。

図２に示すように、カラオケルームＲＭにはカラオケ装置２およびラジオ再生装置５が設置され、ラジオ再生装置５がラジオホスト装置３から受信したＢＧＭデータを再生し、これによりカラオケルームＲＭにおいてＢＧＭが再生されることになる。

ＢＧＭデータはストリーミング方式によりリアルタイムにラジオホスト装置３からラジオ再生装置５に送信される。本実施形態では、マルチキャストアドレスに対してパケットを送信するマルチキャストストリーミングによりＢＧＭデータが提供されることを想定する。ラジオホスト装置３からラジオ再生装置５へのＢＧＭデータの送信は、ネットワーク層においてＩＰｖ６（Internet Protocol Version 6）、トランスポート層においてはＵＤＰ（User Datagram Protocol）に従って行われる。カラオケルームＲＭにおいて、ラジオ再生装置５と通信回線４との間には転送装置４２が設置され、転送装置４２によりＩＰｖ６のパケットの経路制御が行われる。ＵＤＰではハンドシェイクが行われないため、通信回線４における通信量が多い場合などにはパケットが欠損すること（パケットロス）が発生することがあり、この場合ＢＧＭに音飛びやノイズなどの乱れが生じることになる。

カラオケ装置２とラジオ再生装置５とは通信路７により通信可能に接続される。通信路７は、たとえばＵＳＢケーブルや無線通信路とすることができる。また、通信路７はＺｉｇｂｅｅ（登録商標）などによるセンサネットワークとしてもよいし、イーサネット（登録商標）などを用いた通信ネットワークとしてもよい。カラオケ装置２は通信路７を介してラジオ再生装置５におけるＢＧＭの再生状況を取得する。

本実施形態のデジタル音楽放送受信時のエラー防止システムでは、ラジオ再生装置５においてＢＧＭが再生されているときにカラオケデータの通信量を減らすことにより、ＢＧＭデータの配信に係るエラーを低減し、これによりＢＧＭに音飛びやノイズが生じないようにしている。

＝＝ラジオホスト装置３＝＝
＜ハードウェア構成＞
図３はラジオホスト装置３のハードウェア構成例を示す図である。ラジオホスト装置３は、制御部３１、通信部３２、記憶部３３および入力部３４を備える。

制御部３１は、ラジオホスト装置３における制御の中心となる部分であり、ＣＰＵ３１ａやメモリ３１ｂを備える。ＣＰＵ３１ａは、メモリ３１ｂに記憶された動作プログラムに従って各種の制御を実行する。メモリ３１ｂは、ＣＰＵ３１ａに実行されるプログラムを記憶したり、プログラムの実行時に各種情報を一時的に記憶したりする記憶素子である。通信部３２は、ラジオホスト装置３を通信回線４に接続するためのインタフェースを提供する。記憶部３３は、たとえばハードディスクドライブなどの大容量の情報を記憶する記憶装置である。入力部３４はデータの入力を受け付ける。入力部３４は、たとえばキーボードやマウス、タッチパネルなどの入力装置（不図示）からデータの入力を受け付けることができる。また、入力部３４は、ＤＶＤやＣＤ−ＲＯＭ、ＩＣカード、可搬型のハードディスクドライブなどの外部記憶装置と接続するインタフェース（不図示）を備え、入力装置による操作に応じて外部記憶装置からデータを読み出すこともできる。

＜ソフトウェア構成＞
図４はラジオホスト装置３のソフトウェア構成例を示す図である。ラジオホスト装置３は、ＢＧＭデータ登録部３１１、ストリーミング処理部３１２およびラジオデータ記憶部３３１を備える。

なお、ＢＧＭデータ登録部３１１およびストリーミング処理部３１２は、たとえばＣＰＵ３１ａがメモリ３１ｂに記憶されているプログラムを実行することにより実現されるようにしてもよいし、ハードウェア回路として実現するようにしてもよい。ラジオデータ記憶部３３１は、記憶部３３が提供する記憶領域の一部として実現することができる。

ラジオデータ記憶部３３１はＢＧＭデータを記憶する。ＢＧＭデータ登録部３１１は、ＢＧＭデータをラジオデータ記憶部３３１に登録する。ＢＧＭデータ登録部３１１は、オペレータからＢＧＭデータの入力を受け付けるようにしてもよいし、他のサーバ装置にアクセスしてＢＧＭデータを取得するようにしてもよい。ストリーミング処理部３１２は、マルチキャストストリーミングによりＢＧＭデータを送出する。なお、ストリーミング処理部３１２は、ＢＧＭデータ登録部３１１に入力されたＢＧＭデータをそのままリアルタイムにマルチキャストアドレスに対して転送するようにしてもよい。なお、ラジオホスト装置３によるＢＧＭデータのマルチキャストストリーミングには、たとえばインターネットラジオなどに用いられている一般的な手法を採用することができる。

＝＝ラジオ再生装置５＝＝
＜ハードウェア構成＞
図５はラジオ再生装置５のハードウェア構成例を示す図である。ラジオ再生装置５は、制御部５１、通信部５２、記憶部５３、音響処理部５４および通信部５６を備える。制御部５１は、ラジオ再生装置５における制御の中心となる部分であり、ＣＰＵ５１ａおよびメモリ５１ｂを備える。ＣＰＵ５１ａは、メモリ５１ｂに記憶された動作プログラムに従って各種の制御を実行する。メモリ５１ｂは、ＣＰＵ５１ａに実行されるプログラムを記憶したり、プログラムの実行時に各種情報を一時的に記憶したりする記憶素子である。記憶部３３は、たとえばハードディスクドライブなどの大容量の情報を記憶する記憶装置である。

通信部５２は、ラジオ再生装置５を通信回線４に接続するためのインタフェースを提供する。通信部５２は、制御部５１によって動作が制御される。本実施形態では、通信部５２は、イーサネット（登録商標）に接続するためのネットワークインタフェースであるものとする。通信部５２には、ＩＰｖ６のＩＰアドレス、イーサネット（登録商標）において伝送可能な最大のパケットサイズ（ＭＴＵ；Maximum Transmission Unit）など、パケット通信に関する各種のパラメータが設定される。

通信部５６は、ラジオ再生装置５を通信路７に接続するためのインタフェースを提供する。通信部５６は、制御部５１によって動作が制御される。通信部５６は、たとえばシリアル通信を行うためのＵＳＢなどのシリアルインタフェースであってもよいし、無線通信を行うための無線通信機であってもよい。また、通信路７がイーサネット（登録商標）である場合にはネットワークインタフェースとすることもできる。

音響処理部５４は、音響に関する各種の処理を行う。音響処理部５４にはスピーカ５１１が接続され、音響処理部５４は、ＢＧＭデータに基づく放音信号をスピーカ５１１に出力する。スピーカ５１１は、音響処理部５４からの放音信号に基づいて放音する。これにより、ＢＧＭが再生されることになる。

＜ソフトウェア構成＞
図６はラジオ再生装置５のソフトウェア構成例を示す図である。ラジオ再生装置５は、ストリーミング処理部５２１、ＢＧＭ再生部５２２、ラジオステータス送信部５２３およびラジオステータス記憶部５３１を備える。

なお、ストリーミング処理部５２１、ＢＧＭ再生部５２２およびラジオステータス送信部５２３は、たとえばＣＰＵ５１ａがメモリ５１ｂに記憶されているプログラムを実行することによりソフトウェアとして実現されるようにしてもよいし、ハードウェア回路として実現するようにしてもよい。ラジオステータス記憶部５３１は、記憶部５３が提供する記憶領域の一部として実現することができる。

ラジオステータス記憶部５３１は、ラジオ再生装置５におけるＢＧＭの再生状況（以下、ラジオステータスという。）を記憶する。ラジオステータスには、少なくともＢＧＭデータが再生されているか否か（再生フラグ）が含まれる。本実施形態では、ラジオステータスにはさらに、欠損したパケットの個数（パケットロス数）、受信予定のパケット数に対するパケットロス数の割合（パケットロス率）、パケットにエラーが検出された回数（エラー数）、エラーが発生したパケットの割合（エラー率）が含まれるものとする。また、本実施形態では、ラジオステータス記憶部５３１は最新のラジオステータスのみを記録するものとする。

ストリーミング処理部５２１は、マルチキャストストリーミングにより伝送されるＢＧＭデータを受信する。

ＢＧＭデータのパケットには、たとえばエラー検出用のデータ（チェックサム）が含まれており、ストリーミング処理部５２１は、これを用いてＢＧＭデータのエラーを検出する。ストリーミング処理部５２１は、エラーを検出した場合、ラジオステータス記憶部５３１に記憶されているラジオステータスのエラー数をインクリメントし、エラー率を算出してラジオステータスのエラー率を更新する。

また、ＢＧＭデータのパケットには、連続したシーケンス値が含まれ、ストリーミング処理部５２１は、シーケンス値を参照することによりパケットの欠損（パケットロス）を検出する。ストリーミング処理部５２１は、パケットロスを検出した場合には、ラジオステータスのパケットロス数をインクリメントし、パケットロス率を算出してラジオステータスのパケットロス率を更新する。

ＢＧＭ再生部５２２（本発明の音楽再生手段に該当する。）は、ＢＧＭデータを再生する。ＢＧＭ再生部５２２は、ＢＧＭデータを音声信号に復号する。ＢＧＭ再生部５２２による音声信号の復号処理については周知の手法を用いることができる。ＢＧＭ再生部５２２は、復号した音声信号を音響処理部５４に与えてスピーカ５１１からＢＧＭが放音されるようにする。ＢＧＭ再生部５２２はＢＧＭデータの再生処理を開始したときには、ラジオステータス記憶部５３１に記憶されるラジオステータスの再生フラグを「真」に設定し、ＢＧＭデータの再生処理を終了したときには、再生フラグを「偽」に設定する。ＢＧＭ再生部５２２は、たとえばラジオ再生装置５に設けられたスイッチ（不図示）が押下されたことに応じて再生処理を開始または終了することができる。また、ＢＧＭ再生部５２２が再生処理を開始または終了するタイミングでストリーミング処理部５２１を起動するようにしてもよい。

ラジオステータス送信部５２３は、ラジオステータスを外部に提供する。本実施形態では、ラジオステータス送信部５２３は、通信路７からラジオステータスを取得するためのリクエスト信号（以下、ラジオステータス取得信号という。）を受信し、ラジオステータス取得信号に応じてラジオステータス記憶部５３１に記憶されているラジオステータスを読み出し、読み出したラジオステータスを応答するものとする。

＝＝カラオケホスト装置１＝＝
＜ハードウェア構成＞
図７はカラオケホスト装置１のハードウェア構成例を示す図である。カラオケホスト装置１は、制御部１１、通信部１２、記憶部１３および入力部１４を備える。

制御部１１は、カラオケホスト装置１における制御の中心となる部分であり、ＣＰＵ１１ａやメモリ１１ｂを備える。ＣＰＵ１１ａは、メモリ１１ｂに記憶された動作プログラムに従って各種の制御を実行する。メモリ１１ｂは、ＣＰＵ１１ａに実行されるプログラムを記憶したり、プログラムの実行時に各種情報を一時的に記憶したりする記憶素子である。通信部１２は、カラオケホスト装置１を通信回線４に接続するためのインタフェースを提供する。記憶部１３は、たとえばハードディスクドライブなどの大容量の情報を記憶する記憶装置である。入力部１４は、たとえばキーボードやマウス、タッチパネルなどの入力装置（不図示）からデータの入力を受け付けることができる。また、入力部１４は、ＤＶＤやＣＤ−ＲＯＭ、ＩＣカード、可搬型のハードディスクドライブなどの外部記憶装置と接続するインタフェース（不図示）を備え、入力装置による操作に応じて外部記憶装置からデータを読み出すこともできる。また、カラオケ装置１をリモートから操作する場合には、入力部１４は通信部２２を介してデータの入力を受け付けてもよい。

＜ソフトウェア構成＞
図８はカラオケホスト装置１のソフトウェア構成例を示す図である。カラオケホスト装置１は、カラオケデータ登録部１１１、カラオケデータ分割部１１２、カラオケデータ送信部１１３、ラジオステータス受信部１１４、カラオケデータ記憶部１３１、配信パラメータ記憶部１３２およびラジオステータス記憶部１３３を備える。

なお、カラオケデータ登録部１１１、カラオケデータ分割部１１２、カラオケデータ送信部１１３およびラジオステータス受信部１１４は、ＣＰＵ１１ａがメモリ１１ｂに記憶されている動作プログラムを実行することにより実現されるようにしてもよいし、ハードウェア回路として実現するようにしてもよい。カラオケデータ記憶部１３１、配信パラメータ記憶部１３２およびラジオステータス記憶部１３３は、記憶部１３が提供する記憶領域の一部として実現することができる。

カラオケデータ記憶部１３１はカラオケデータを記憶する。カラオケデータには、楽曲データ、背景映像データなどが含まれる。楽曲データは、カラオケ楽曲に関するデータであり、カラオケの伴奏を演奏するための伴奏データ、歌詞を表示するための歌詞データ、音程をガイドするためのガイド音を再生するためのガイドメロディ（ＧＭ）データなどが含まれる。背景映像データは、カラオケ演奏時における背景映像を表示するための動画データであり、たとえばＭＰＥＧ形式のデータである。

カラオケデータ登録部１１１は、カラオケデータをカラオケデータ記憶部１３１に登録する。カラオケデータ登録部１１１は、オペレータからカラオケデータの入力を受け付けてカラオケデータ記憶部１３１に登録することができる。

カラオケデータ分割部１１２は、カラオケ装置２に送信するためにカラオケデータを分割する。カラオケデータ分割部１１２は、所定のサイズのチャンク（以下、シーケンスという。）に、送信対象となるカラオケデータを分割する。送信対象となるカラオケデータは、たとえば入力部１４を介してオペレータから指定を受け付けるようにして行われている。

配信パラメータ記憶部１３２はカラオケデータの配信に関するパラメータ（以下、配信パラメータという。）を記憶する。本実施形態では、配信パラメータにはシーケンスのサイズ（たとえば５ＭＢなどの任意の数値である。以下、シーケンスサイズという。）が含まれるものとし、配信パラメータはカラオケ装置２ごとに記憶されるものとする。カラオケデータ分割部１１２は、送信先のカラオケ装置２に対応するシーケンスサイズを配信パラメータ記憶部１３２から読み出し、読み出したシーケンスサイズごとのシーケンスにカラオケデータを分割する。

カラオケデータ送信部１１３は、カラオケデータをカラオケ装置２に送信する。カラオケデータ送信部１１３は、分割されたシーケンスを順次ＴＣＰのソケットを通じてカラオケ装置２に送信していく。カラオケデータ送信部１１３は、たとえば、定期的にカラオケデータを送信するようにしてもよいし、カラオケデータ登録部１１１がカラオケデータを登録したことを契機として送信するようにしてもよい。

ラジオステータス受信部１１４は、カラオケ装置２から送信されるラジオステータスを受信する。なお、ラジオステータスにはラジオ再生装置５を特定する情報（以下、機器ＩＤという。）が付帯されるものとする。ラジオステータス受信部１１４は、受信したラジオステータスを機器ＩＤに対応付けてラジオステータス記憶部１３３に登録する。ラジオステータス記憶部１３３にはラジオ再生装置５ごとに最新のラジオステータスのみが記憶されるものとする。

＝＝カラオケ装置２＝＝
＜ハードウェア構成＞
図９はカラオケ装置２のハードウェア構成例を示す図である。カラオケ装置２は、制御部２１、通信部２２、記憶部２３と、音響処理部２４、表示処理部２５、通信部２６、操作部２７を備える。

制御部２１は、カラオケ装置２における制御の中心となる部分であり、ＣＰＵ２１ａおよびメモリ２１ｂを備える。ＣＰＵ２１ａは、メモリ２１ｂに記憶された動作プログラムに従って各種の制御を実行する。たとえば操作部２７からの操作を受け付ける操作入力処理やシーケンサとして動作するシーケンサ処理を行う。メモリ２１ｂは、ＣＰＵ２１ａに実行されるプログラムを記憶したり、プログラムの実行時に各種情報を一時的に記憶したりする記憶素子である。このため、メモリ２１ｂには、各種のプログラムを記憶する記憶領域が設けられている。

記憶部２３は、たとえばハードディスクドライブなどの、各種のデータを記憶する記憶装置である。

通信部２２は、カラオケ装置２を通信回線４に接続するためのインタフェースを提供する。通信部２２は、制御部２１によって動作が制御される。本実施形態では、通信部２２は、イーサネット（登録商標）に接続するためのネットワークインタフェースであるものとする。通信部２２には、ＩＰｖ４のＩＰアドレス、イーサネット（登録商標）において伝送可能な最大のパケットサイズ（ＭＴＵ；Maximum Transmission Unit）など、パケット通信に関する各種のパラメータが設定される。

通信部２６は、カラオケ装置２を通信路７に接続するためのインタフェースを提供する。通信部２６は、制御部２１によって動作が制御される。通信部２６は、たとえばシリアル通信を行うためのＵＳＢなどのシリアルインタフェースであってもよいし、無線通信を行うための無線通信機であってもよい。また、通信路７がイーサネット（登録商標）である場合にはネットワークインタフェースとすることもできる。

音響処理部２４は、音響に関する各種の処理を行う。音響処理部２４には、マイク２１２が接続される。マイク２１２は、歌唱者の音声をアナログの歌唱音声信号に変換して音響処理部２４に入力させる。音響処理部２４は、マイク２１２を通じて入力された歌唱音声信号をデジタルの歌唱音声データに変換する。また、音響処理部２４にはスピーカ２１１が接続され、音響処理部２４は、楽曲データに応じて生成された楽音信号と歌唱音声データとを所定のバランスでミキシングし、放音信号としてスピーカ２１１に出力する。スピーカ２１１は、音響処理部２４からの放音信号に基づいて放音する。音響処理部２４はまた、カラオケ楽曲に対する演奏の制御を行う。

表示処理部２５は、カラオケ演奏時における背景映像の表示に関する制御を行う。表示処理部２５にはモニタ２１３が接続される。カラオケ演奏時、表示処理部２５には背景映像データが入力され、表示処理部２５は、背景映像データをデコードし、デコードで生成された背景映像の映像信号に歌詞テロップを合成し、合成後の映像信号をモニタ２１３に出力する。モニタ２１３は、表示処理部２５からの映像信号に基づいて映像を画面に表示する。すなわち、モニタ２１３には、背景映像に歌詞テロップが重ねられた映像が表示されることになる。

操作部２７は、カラオケ利用者からの操作を受け付ける。操作部２７は、たとえばパネルスイッチやリモコン受信回路などから構成される。操作部２７は、利用者によるパネルスイッチやリモコン装置２１４の操作に応じた操作信号を制御部２１に対して出力する。制御部２１は、操作入力処理を行うことで操作信号を検出し、対応する処理を実行する。

リモコン装置２１４は、カラオケ装置２との間で情報を送受信するための双方向通信可能な短距離無線通信部（不図示）を備え、カラオケ楽曲の予約時などに操作される。カラオケ楽曲の予約時において、リモコン装置２１４からは、演奏対象の楽曲を識別するための楽曲ＩＤを含んだ操作信号が送信される。

＜ソフトウェア構成＞
図１０はカラオケ装置２のソフトウェア構成例を示す図である。カラオケ装置２は、カラオケデータ登録部２２１、ラジオステータス取得部２２２、ラジオステータス送信部２２３、パケットサイズ変更部２２４、カラオケデータ記憶部２３１およびラジオステータス記憶部２３２を備える。

なお、カラオケデータ登録部２２１、ラジオステータス取得部２２２、ラジオステータス送信部２２３およびパケットサイズ変更部２２４は、たとえばＣＰＵ２１ａがメモリ２１ｂに記憶されているプログラムを実行することにより実現されるようにしてもよいし、ハードウェア回路として実現するようにしてもよい。また、カラオケデータ記憶部２３１およびラジオステータス記憶部２３２は、記憶部２３が提供する記憶領域の一部として実現することができる。

カラオケデータ記憶部２３１はカラオケデータを記憶する。上述したように、カラオケデータには、楽曲データ、背景映像データなどが含まれる。カラオケデータ登録部２２１（本発明のカラオケデータ受信手段に該当する。）は、カラオケホスト装置１から送信されるシーケンスを順次受信し、受信したシーケンスを連結してカラオケデータを生成し、生成したカラオケデータをカラオケデータ記憶部２３１に登録する。

ラジオステータス取得部２２２は、ラジオステータスを取得する。ラジオステータス取得部２２２は、ラジオステータス取得信号を、通信路７を介してラジオ再生装置５に送信し、これに対してラジオ再生装置５から応答されるラジオステータスを受信する。ラジオステータス取得部２２２は、受信したラジオステータスをラジオステータス記憶部２３２に登録する。ラジオステータス記憶部２３２には、最新のラジオステータスのみが記憶されるものとする。

ラジオステータス送信部２２３は、ラジオステータスをカラオケホスト装置１に送信する。ラジオステータス送信部２２３は、ラジオステータス取得部２２２からラジオステータスを受け取り、これをカラオケホスト装置１に送信するようにしてもよいし、定期的に、または、ラジオステータス記憶部２３２が更新されたことを契機として、ラジオステータス記憶部２３２からラジオステータスを読み出してカラオケホスト装置１に送信するようにしてもよい。

パケットサイズ変更部２２４（本発明の通信量制御手段に該当する。）は、ラジオステータスに応じて通信部２２によるパケット通信に係るパケットのサイズを変更する制御処理を行う。パケットサイズ変更部２２４は、ＢＧＭが再生されているときは再生されていないときよりも小さくなるようにパケットのサイズを設定する。本実施形態では、パケットサイズ変更部２２４は、ラジオステータスに含まれる再生フラグが「真」である場合には、通信部２２のＭＴＵを所定の最小値に設定し、再生フラグが「偽」である場合には、通信部２２のＭＴＵを所定の最大値に設定することにより制御処理を行う。

＝＝処理＝＝
図１１は本実施形態のカラオケ装置２における処理を説明する図である。

ラジオステータス取得部２２２は、ラジオステータス取得信号をラジオ再生装置５に送信し、これに対してラジオ再生装置５から応答されるラジオステータスを受信し（Ｓ６０１）、受信したラジオステータスをラジオステータス記憶部２３２に登録する（Ｓ６０２）。ラジオステータス送信部２２３は、ラジオステータスをカラオケホスト装置１に送信する（Ｓ６０３）。

パケットサイズ変更部２２４は、通信部２２に設定されているＭＴＵを取得し（Ｓ６０４）、ラジオステータスに含まれる再生フラグが「真」である場合（Ｓ６０５：ＹＥＳ）、ＭＴＵが所定の最小値より大きければ（Ｓ６０６：ＹＥＳ）、通信部２２のＭＴＵに所定の最小値を設定する（Ｓ６０７）。一方、再生フラグが「偽」である場合に（Ｓ６０５：ＮＯ）、ＭＴＵが所定の最大値よりも小さければ（Ｓ６０８：ＹＥＳ）、パケットサイズ変更部２２４は、通信部２２のＭＴＵに所定の最大値を設定する（Ｓ６０９）。

＝＝効果＝＝
以上のようにして、ラジオ再生装置５においてＢＧＭが再生されている場合には、通信部２２のＭＴＵを最小値に設定することができる。したがって、ラジオ再生装置５においてＢＧＭが再生されている場合には、カラオケ装置２に対してカラオケデータが伝送されるパケットが、再生されていない場合に比べて小さくなるようにすることができる。

カラオケ装置２がラジオ再生装置５と同じサイトに設置され、同じ通信回線４を使用する場合には、カラオケデータの伝送に大きなパケットが用いられると、通信回線４においてバースト転送が行われることになり、パケット間に他のデータのパケットを時分割により多重化をさせることができず、パケットロスが発生する可能性が高まる。特に、ハンドシェイクの行われるＴＣＰによるカラオケデータの転送により帯域が圧迫された場合には、ＵＤＰによるコネクションレス通信が行われるマルチキャストストリーミングにおいてはパケットロスが発生し易い。

これに対し本実施形態のデジタル音楽放送受信時のエラー防止システムによれば、ＢＧＭが再生されている場合にカラオケデータの伝送についてのパケットのサイズを小さくすることができる。したがって、カラオケデータの伝送につき、通信回線４におけるバースト転送が抑制される。これにより、カラオケデータを伝送するパケット間にＢＧＭデータのためのパケットを挿入する隙間が生じるようにすることができる。よって、ＢＧＭデータの配信に係るエラーを抑制し、ＢＧＭに音飛びやノイズなどの乱れが発生することを防止することができる。

一方で、本実施形態のデジタル音楽放送受信時のエラー防止システムによれば、ＢＧＭが再生されていない場合には通信部２２のＭＴＵに最大値を設定することができる。ＭＴＵに最大値を設定した場合にはイーサネット（登録商標）における伝送効率が向上するので、ＢＧＭが再生されていない場合には、カラオケデータの配信効率を向上させることができる。

また、本実施形態のデジタル音楽放送受信時のエラー防止システムでは、パケットのサイズの変更はカラオケ装置２の通信部２２のＭＴＵを変更するものとしているので、パケットのサイズの変更に係る制御処理を実装することは容易である。したがって、容易な実装によりＢＧＭデータの配信に係るエラーを効果的に防止することが可能となる。

＝＝変形例１＝＝
以上の説明では、カラオケ装置２のＭＴＵを変更することにより、ＢＧＭが再生されているときにパケットを小さくしてＢＧＭデータのパケットロスを抑制するものとしたが、これに加えてまたはこれに代えて、カラオケホスト装置１において送出するカラオケデータの量を調整するようにしてもよい。この場合、カラオケ装置１において、ラジオステータス受信部１１４は、受信したラジオステータスに応じて、ラジオステータスの受信元のカラオケ装置２に対応する配信パラメータを更新する。

図１２は、カラオケホスト装置１におけるカラオケデータの調整処理の流れを示す図である。

ラジオステータス受信部１１４は、カラオケ装置２からラジオステータスを受信すると（Ｓ６２１）、受信したラジオステータスをラジオステータス記憶部１３３に登録し（Ｓ６２２）、ラジオステータスに含まれる再生フラグが「真」であるか否かによりＢＧＭが再生中か否かを判定する（Ｓ６２３）。ラジオステータス受信部１１４は、ＢＧＭが再生中である場合（Ｓ６２３：ＹＥＳ）、カラオケ装置２に対応する配信パラメータ記憶部１３２のシーケンスサイズが所定の最小値よりも大きければ（Ｓ６２４：ＹＥＳ）、当該シーケンスサイズを当該最小値に更新する（Ｓ６２５）。

一方、ＢＧＭが再生中でない場合（Ｓ６２３：ＮＯ）、ラジオステータス受信部１１４は、カラオケ装置２に対応するシーケンスサイズが所定の最大値よりも小さければ（Ｓ６２６：ＹＥＳ）、シーケンスサイズを所定の最大値に更新する（Ｓ６２７）。

以上のようにして、ＢＧＭが再生されている場合には、カラオケ装置２に送信するシーケンスが小さくなるようにすることができる。したがって、ＢＧＭの再生中には、カラオケデータは数多くのシーケンスに分割することができるので、パケットの間に隙間が生じ、ＢＧＭデータのパケットについての時分割多重化を行い易くなる。よって、ＢＧＭデータのパケットの欠損を低減し、ＢＧＭの再生に係るエラーを低減することができる。

また、シーケンスを増やすことにより、シーケンスの送出処理に係るオーバヘッドが発生し、カラオケデータの伝送に係る単位時間あたりの通信量を低減することになる。したがって、単位時間あたりの物理的な通信量が低減されるため、ＢＧＭデータの通信に使える帯域を増やすことができる。これにより、ＢＧＭデータの配信に係るエラーを低減し、ＢＧＭに音飛びやノイズが生じないようにすることができる。

また、カラオケ装置２ではＭＴＵの変更を行わないようにして、カラオケホスト装置１においてのみシーケンスのサイズ（分割数）を調整する場合には、既存のカラオケ装置２に改変を加えることなく、ＢＧＭデータのエラーを低減することが可能となる。したがって、大量のカラオケ装置２を改変する手間を省くことができる。また、改変に起因する不測の不具合の発生確率を抑制することができる。

なお、シーケンスサイズを小さくする（分割数を増やす）代わりに、カラオケホスト装置１の通信部１２のＭＴＵを小さくするようにしてもよい。この場合、カラオケ装置２ごとに独立した論理的な通信部１２を設け、カラオケ装置２に対応する通信部１２のＭＴＵのみを変更することができる。

また、シーケンスサイズを小さくする代わりに、カラオケデータ送信部１１３が、ＢＧＭが再生されているときの方が送信間隔が長くなるように、複数のシーケンスの送信間隔を延ばすようにしても良い。

＝＝変形例２＝＝
また、本実施形態では、カラオケ装置２において通信部２２のパケットサイズ（ＭＴＵ）を変更するものとしたが、転送装置４１が転送するパケットのパケットサイズを変更するようにしてもよい。

この場合、パケットサイズ変更部２２４は、転送装置４１にアクセスして、転送装置４１が転送するパケットのサイズが、ＢＧＭが再生されているときの方が再生されていないときよりも小さくなるように、転送装置４１の設定（たとえばＭＴＵの設定）を変更する。これにより、カラオケ装置２の設定を変更することなく、ＢＧＭの再生が途切れないように、カラオケデータの伝送に係るパケットのサイズを調整することができる。したがって、カラオケ装置２の設定を変更したことに起因する、カラオケ装置２における他の機能への不測の影響を回避しつつ、ＢＧＭデータの配信に係るエラーを低減し、これによりＢＧＭに音飛びやノイズが生じないようにすることができる。

また、カラオケ店ＫＢ内において、転送装置４１がカスケード接続されているような場合には、最もＷＡＮ（Wide Area Network）側の転送装置４１のＭＴＵを変更するようにしてもよい。この場合、パケットサイズの変更を行うための処理は最上位の転送装置４１に対してのみ行えばよいため、変更処理が簡単になるとともに、カラオケ装置２の設定を変更することに起因する不測の影響を予防することができる。

＝＝変形例３＝＝
また、本実施形態では、ラジオステータスのうち再生フラグに応じて、すなわち、ＢＧＭが再生されているかどうかに応じてパケットのサイズを変更するものとしたが、これに代えてまたはこれに加えて、その他のラジオステータスに応じてパケットのサイズを変更するようにしてもよい。

たとえば、パケットサイズ変更部２２４は、図１１のステップＳ６０５においてＢＧＭが生成中と判定した後（Ｓ６０５：ＹＥＳ）、パケットロス数またはパケットロス率が所定の閾値を超えたか否かを判定し、閾値を超えた場合にのみステップＳ６０６に進むようにすることができる。

この場合、パケットの欠損が発生している度合いに応じてパケットのサイズの変更を行うかどうかを決定することができる。したがって、カラオケデータのデータ量に比して通信回線４における帯域が広い場合など、パケットロスが生じていないような状況であれば、ＢＧＭが再生中であってもカラオケデータの伝送に係るパケットのサイズを変更しないようにすることで、カラオケデータの伝送効率を向上させることができる。

また同様に、パケットサイズ変更部２２４は、エラー数またはエラー率が所定の閾値を超えた場合ステップＳ６０６に進むようにしてもよい。

パケットの欠損は発生していないとしても、エラー訂正が数多く必要になるほどパケットにエラーが発生しているような状況は、通信回線４が混み合っていることに起因することも考えられる。したがって、エラー訂正の発生数が多ければカラオケデータのパケットのサイズを小さくして通信量を低減させることにより、通信回線４が混まないようにして、ＢＧＭデータについてのエラーの発生を抑制することが可能となる。よって、ＢＧＭデータの処理負荷が低減することができる。また、エラーに起因する音飛びなどの不具合を回避することができる。

また同様に、パケットサイズ変更部２２４は、たとえばラジオ再生装置５からＢＧＭデータの再生処理に関するステータスを取得することにより、ＢＧＭデータの再生にエラーが発生しているか否かを判定し、エラーが発生している場合にのみパケットのサイズを小さくする（ステップＳ６０６，Ｓ６０７）ようにしてもよい。

この場合、たとえばＢＧＭデータの再生に関するユーザプログラムからは通信に関するパケットロスやエラー訂正が検知できないような場合であっても、ＢＧＭデータの再生にエラーが出ている場合には、通信回線４でパケットロスが発生し、あるいはパケットにエラーが生じるような通信品質の低下が発生していることが考えられるので、これに対応して、カラオケデータの通信量を低減させることにより、ＢＧＭデータの再生のエラーを回避可能となることが期待される。

＝＝変形例４＝＝
本実施形態では、ラジオ再生装置５から取得したラジオステータスをカラオケ装置２がカラオケホスト装置１に送信するものとしたが、ラジオ再生装置５からカラオケホスト装置１に送信するようにしてもよい。

この場合、ラジオ再生装置５のラジオステータス送信部５２３は、通信回線４を介してカラオケホスト装置１に対してラジオステータスを送信する。また、カラオケホスト装置１は、ラジオステータスに応じてＢＧＭが再生されているか否かを検知する音楽再生検知手段と、ＢＧＭが再生されていることを検知した場合に、パケットサイズを小さくするパケットサイズ調整手段とを備えるようにする。カラオケホスト装置１が備えるパケットサイズ調整手段は、上述したようにカラオケホスト装置１の通信部１２のＭＴＵの値を変更するようにしてもよいし、パケットのサイズを変更するように指示するメッセージをカラオケ装置２に送信し、カラオケ装置２のパケットサイズ変更部２２４が当該メッセージの受信に応じて通信部２２のＭＴＵの値を変更するようにしてもよい。

これにより、既存のカラオケ装置２に対してラジオステータスの判定処理などの処理を追加することなく、リモートからＭＴＵの値の変更ができるようにすればよく、デジタル音楽放送受信時のエラー防止システムにおける変更箇所を最小限としつつ、ＢＧＭの配信に係るエラーを低減することができる。

＝＝変形例５＝＝
本実施形態では、カラオケ店ＫＢにおけるカラオケルームごとに、ラジオ再生装置５が再生されているか否かを判定するものとしたが、カラオケ店ＫＢ全体においていずれかのラジオ再生装置５が再生されているか否かにより、パケットのサイズを変更するようにしてもよい。この場合、いずれか１台のカラオケ装置２を親装置として、他のカラオケ装置２からラジオステータスを集約するようにしてもよいし、各カラオケ装置２と通信可能に接続させた管理用の店舗サーバ装置を設置し、店舗サーバ装置がカラオケ装置２からラジオステータスを受信するようにしてもよい。

親装置または店舗サーバは、いずれかのラジオステータスの再生フラグが「真」である場合、すなわち、いずれかのラジオ再生装置５でＢＧＭが再生されている場合には、ＭＴＵを最小値に変更するように指示するコマンドを各カラオケ装置２に送信する。カラオケ装置２は、このコマンドに応じてＭＴＵを最小値に設定する。

また、親装置または店舗サーバは全てのラジオステータスの再生フラグが「偽」となった場合、すなわち、全てのラジオ再生装置５においてＢＧＭの再生が行われていない場合には、ＭＴＵを最大値に設定するように指示するコマンドを各カラオケ装置２に送信する。カラオケ装置２は、このコマンドに応じてＭＴＵを最大値に設定する。

このようにすることで、カラオケ店ＫＢ全体において確実にＢＧＭに音飛びやノイズが生じないようにすることが可能となる。

＝＝変形例６＝＝
本実施形態では、ラジオ再生装置５がＢＧＭデータを受信している場合に、カラオケ装置２によるカラオケデータの受信に係る通信量を少なくするものとしたが、ＢＧＭデータの受信に代えて、またはこれに加えて、カラオケデータ以外のものが通信されている場合にカラオケデータの通信量を少なくするようにしてもよい。

たとえば、通信デュエットを行う場合にカラオケ装置２が他のカラオケ装置２から送信される音声データおよび動画データの少なくともいずれか（以下、デュエットデータという。）を受信している間、カラオケデータの受信に係るパケットサイズを小さくするようにすることができる。デュエットデータはＴＣＰまたはＵＤＰにより伝送することが可能であり、この場合、たとえばカラオケ装置２には物理的または論理的ネットワークインタフェースを複数設け、デュエットデータとカラオケデータとは異なるネットワークインタフェースを介して通信するようにし、パケットサイズ変更部２２４は、カラオケデータの通信に用いられているネットワークインタフェースについてのパケットサイズを変更することができる。これにより、通信デュエットを行っているときにカラオケデータの配信が行われたとしても、通信デュエットに係る音飛びやノイズ、映像の乱れなどの通信エラーを低減することができる。

また、たとえばリモコン装置２１４に再生させるための動画データ（以下、サムネイル動画データという。）がカラオケホスト装置１からカラオケ装置２に伝送される間にカラオケホスト装置１からカラオケデータも伝送される場合、サムネイル動画データを受信している間、カラオケデータの受信に係るパケットサイズを小さくすることができる。この場合にも、カラオケデータの通信量が減り、リモコン装置２１４へのサムネイル動画データの伝送効率が向上する。したがって、リモコン装置２１４においてサムネイル動画データの再生が停止するなどの不具合を抑制することが可能となり、リモコン装置２１４を操作しているユーザに対する応答時間を短縮し使い勝手を向上することができる。

＝＝変形例７＝＝
本実施形態では、ＢＧＭが再生されている場合にカラオケデータの伝送に係る通信量が少なくなるようにしたが、カラオケ装置２が受信するデータに応じてＢＧＭデータの通信量を少なくなるようにしてもよい。

たとえば、ラジオ再生装置５が、カラオケ装置２におけるデータの受信状況（以下、カラオケステータスという。）を取得するカラオケステータス取得部と、カラオケ装置２が優先度の高いデータを受信している場合にラジオ再生装置５のＭＴＵの値を所定の最低値に設定するパケットサイズ変更部とを備えるようにすることができる。カラオケステータスには、カラオケ装置２が現在どのようなデータを受信しているかを示す情報を含める。ラジオ再生装置５のパケットサイズ変更部は、カラオケステータスにＢＧＭよりも優先度の高い所定のデータ（たとえばデュエットデータ）を受信していることを示す情報が含まれている場合に、ＭＴＵの値を所定の最低値に設定し、優先度の高い所定のデータを受信していることを示す情報が含まれていない場合には、ＭＴＵの値を所定の最高値に設定することができる。なお、優先度を判定するために、ラジオ再生装置５は、カラオケ装置２が受信するデータの種別ごとに優先度を記憶する表を備えるようにしてもよい。

また、カラオケ装置２がラジオ再生装置５を制御してラジオ再生装置５における通信に係るパケットサイズを変更するようにしてもよい。たとえば、カラオケ装置２がＢＧＭよりも優先度の高い所定のデータを受信している場合に、ラジオ再生装置５に対してパケットサイズを小さくするように指示するコマンドを送信し、ラジオ再生装置５がこれに応じてパケットサイズを小さくするようにし、たとえばデュエットが終了した場合など、ＢＧＭよりも優先度の高いデータの受信が終了した場合には、カラオケ装置２がパケットサイズを大きくするように指示するコマンドをラジオ再生装置５に送信し、ラジオ再生装置５がこれに応じてパケットサイズを大きくするようにすることができる。

また、ラジオ再生装置５のパケットサイズを変更する代わりに、ＢＧＭの音質を下げるようにしてもよい。この場合、ラジオ再生装置５は、カラオケ装置２がＢＧＭよりも優先度の高いデータを受信していることを示すカラオケステータスを取得した場合、ラジオホスト装置３に対して、圧縮率の高いＢＧＭデータ（すなわちビットレートが低く通信量が少なくなるが音質の低いＢＧＭデータ）を送信するように指示するコマンドを送信し、ラジオホスト装置３はこれに応じて圧縮率の高いＢＧＭデータを送出するようにすることができる。また、ラジオ再生装置５は、カラオケ装置２における優先度の高いデータの受信が終了した場合には、圧縮率の低いＢＧＭデータ（すなわちビットレートが高く通信量が多くなるが音質の高いＢＧＭデータ）を送信するように指示するコマンドを送信し、ラジオホスト装置３はこれに応じて圧縮率の低いＢＧＭデータを送出するようにすることができる。このようにしてＢＧＭデータの通信量を調整することができる。

以上のようにＢＧＭよりも優先度の高いデータを受信している場合にＢＧＭデータの通信量を減らすことにより、たとえば通信デュエットを行うときに、デュエットデータの再生に係る遅延や映像の乱れなどの不具合を防止することができる。

＝＝その他の変形例＝＝
本実施形態では、ネットワークインタフェースのＭＴＵを変更するものとしたが、これに限らず、カラオケ装置２の通信部２２について単位時間あたりの通信量が、ＢＧＭが再生されているときの方がＢＧＭの再生されていないときよりも少なくなればよい。カラオケデータの配信に係る通信量を低減することにより、ＢＧＭデータのストリーミングに使用可能な帯域が確保できるので、ＢＧＭデータの配信に係るパケットロスやデータ誤りなどのエラーを抑止することができる。単位時間あたりの通信量を低減する手法としては、ＭＴＵを小さくすること以外にも、たとえば、ネットワークインタフェースの通信速度の設定を変更したり、１０００ｂａｓｅＴを利用可能なネットワークインタフェースに対して１００ｂａｓｅＴを使用するように通信規格を変更したり、転送装置４１が半二重通信に対応しているような場合には、全二重通信から半二重通信に変更したりすることができる。上述したシーケンスサイズの変更も、単位時間あたりの通信量の変更に含まれる。

ネットワークインタフェースの通信速度の設定の変更には、ＴＣＰのフロー制御に係るウィンドウサイズ（広告ウィンドウサイズ）およびＴＣＰの輻輳制御に係るウィンドウサイズ（輻輳ウィンドウサイズ）を変更することを含む。たとえば、ＭＴＵを変更することに代えて、ＴＣＰにおけるＡＣＫ応答に含まれる広告ウィンドウサイズを、ＢＧＭが再生されている場合にはＢＧＭがされていない場合よりも小さくなるように設定することができる。また、広告ウィンドウサイズの最大値を、ＢＧＭが再生されている場合にはされていない場合よりも小さくなるように設定しておき、この最大値と受信バッファの空き容量とに応じて広告ウィンドウサイズを決定するようにしてもよい。また、カラオケホスト装置１から送出されるデータ量を制御する場合、ＢＧＭが再生されているときには明示的な輻輳通知をカラオケホスト装置１に送信することにより、カラオケホスト装置１における輻輳ウィンドウが小さくなるようにしてもよい。また、変形例２の場合には、転送装置４１のＭＴＵを変更する代わりに広告ウィンドウサイズおよび輻輳ウィンドウサイズの少なくともいずれかを変更するようにしてもよい。

また、本実施形態では、カラオケホスト装置１およびラジオホスト装置３はいずれも１台のコンピュータであるものとしたが、これに限らず、複数台のカラオケ装置２およびラジオホスト装置３ごとに１台のカラオケホスト装置１およびラジオホスト装置３を設置するようにしてもよいし、複数台のコンピュータで仮想的に１台のカラオケホスト装置１またはラジオホスト装置３を構成するようにしてもよい。

また、本実施形態では、ＩＰｖ４による通信を行うカラオケ装置２に対して転送装置４１を設け、ＩＰｖ６による通信を行うラジオ再生装置５に対して転送装置４２を設けるようにしたが、ＩＰｖ４およびＩＰｖ６の両方に対応する１台の転送装置を設置し、通信回線４とカラオケ装置２およびラジオ再生装置５との間のパケットを転送するようにしてもよい。

また、本実施形態では、カラオケデータの配信についてはＩＰｖ４で、ＢＧＭデータのマルチキャストについてはＩＰｖ６で行われるものとしたが、これに限らず、両方をＩＰｖ４またはＩＰｖ６で行うようにしてもよい。この場合にも、転送装置４１および転送装置４２は１台の転送装置とすることができる。

また、本実施形態では、ＢＧＭデータはマルチキャストストリーミングにより伝送されるものとしたが、これに限らず、ユニキャストストリーミングであってもよい。また、ストリーミングのプロトコルは、音楽データのダウンロード中に再生を行う方式であればどのようなものであってもよい。

また、本実施形態では、ＵＤＰによりＢＧＭデータを伝送し、ＴＣＰによりカラオケデータを伝送するものとしたが、これに限らず、ＢＧＭデータをＴＣＰを用いたストリーミングにより伝送するようにしてもよい。

また、本実施形態では、カラオケ装置２が主体となって、ラジオステータス取得信号をラジオ再生装置５に送信し、これに対してラジオステータスデータが応答されるものとしたが、ラジオ再生装置５が主体となってラジオステータスデータをカラオケ装置２に送信するようにしてもよい。この場合、ラジオ再生装置５は、定期的にラジオステータス記憶部２３２に記憶されているラジオステータスを読み出してカラオケ装置２に送信するようにしてもよいし、ラジオステータス記憶部２３２のラジオステータスが更新されたことを契機としてラジオステータスを送信するようにしてもよい。

また、本実施形態では、カラオケホスト装置１からのカラオケデータの配信に関する配信パラメータには、シーケンスサイズのみが含まれているものとしたが、これ以外にもたとえば日時等のシーケンスの送信を開始するタイミングを決定するための情報、シーケンスを送信する間隔、通信プロトコル、エラー時の回復方法など、カラオケデータの配信に関する各種のパラメータを設定することができる。

また、本実施形態では、ラジオステータスとして、再生フラグ、パケットロス数、パケットロス率、エラー数およびエラー率の全てが含まれているものとしたが、これに限らず、これらのうちのいずれかのみが含まれるようにしてもよい。また、パケットロス数、パケットロス率、エラー数およびエラー率の少なくともいずれかに応じてパケットのサイズを変更する場合には、ラジオステータスには再生フラグが含まれなくてもよい。

また、再生フラグを取得せず、ラジオ再生装置５が起動しているか否かによりＢＧＭの再生がされているか否かを判定するようにしてもよい。この場合において、通信路７でＴＣＰ／ＩＰによる通信が行われるときには、ラジオステータス取得部２２２は、ＩＣＭＰ（Internet Control Message Protocol）によるエコーリクエスト（ｐｉｎｇコマンド）をラジオ再生装置５に送信し、これに対する応答をラジオステータスとして取得するようにし、ラジオ再生装置５が起動している場合にＢＧＭデータが再生されていると判定するようにすることができる。

また、本実施形態では、ラジオ再生装置５がラジオステータスを記録するものとしたが、カラオケ装置２がラジオステータスを検出するようにしてもよい。この場合、カラオケ装置２のラジオステータス取得部２２２は、たとえば転送装置４２とラジオ再生装置５との間のパケットをキャプチャして、マルチキャストストリーミングにおけるパケットロスを検出するようにすることができる。この場合、ラジオ再生装置５がラジオステータスを提供しない場合に対応することができる。

また、転送装置４２においてマルチキャスト通信の開始および終了、ならびにマルチキャスト通信におけるパケットロスを記録するようにし、カラオケ装置２のラジオステータス取得部２２２が転送装置４２からこれらを取得するようにしてもよい。この場合にも、ラジオ再生装置５がラジオステータスを提供しない場合に対応することができる。

また、本実施形態では、カラオケホスト装置１のラジオステータス記憶部１３３およびカラオケ装置２のラジオステータス記憶部２３２には最新のラジオステータスのみが記憶されるものとしたが、日時に対応付けてラジオステータスの履歴を格納するようにしてもよい。この場合、再生フラグが「偽」に変化してから所定の時間が経過するまでは再生がなされているものと判断することができる。

また、ラジオステータス記憶部１３３は、現在時刻が店舗の営業時間内であるか否かによりＢＧＭが再生されているか否かを判断するようにしてもよい。この場合、ラジオステータスをラジオ再生装置５に問い合わせる必要がない。

以上、本実施形態について説明したが、上記実施形態は本発明の理解を容易にするためのものであり、本発明を限定して解釈するためのものではない。本発明は、その趣旨を逸脱することなく、変更、改良され得るとともに、本発明にはその等価物も含まれる。

１…カラオケホスト装置，２…カラオケ装置，３…ラジオホスト装置，４…通信回線，５…ラジオ再生装置，７…通信路，１１…制御部，１１ａ…ＣＰＵ，１１ｂ…メモリ，１２…通信部，１３…記憶部，１４…入力部，１１１…カラオケデータ登録部，１１２…カラオケデータ分割部，１１３…カラオケデータ送信部，１１４…ラジオステータス受信部，１３１…カラオケデータ記憶部，１３２…配信パラメータ記憶部，１３３…ラジオステータス記憶部，２１…制御部，２１ａ…ＣＰＵ，２１ｂ…メモリ，２２…通信部，２３…記憶部，２４…音響処理部，２５…表示処理部，２６…通信部，２７…操作部，２１１…スピーカ，２１２…マイク，２１３…モニタ，２１４…リモコン装置，２２１…カラオケデータ登録部，２２２…ラジオステータス取得部，２２３…ラジオステータス送信部，２２４…パケットサイズ変更部，２３１…カラオケデータ記憶部，２３２…ラジオステータス記憶部，３１…制御部，３１ａ…ＣＰＵ，３１ｂ…メモリ，３２…通信部，３３…記憶部，３４…入力部，３１１…ＢＧＭデータ登録部，３１２…ストリーミング処理部，３３１…ラジオデータ記憶部，４１…転送装置，４２…転送装置，５１…制御部，５１ａ…ＣＰＵ，５１ｂ…メモリ，５２…通信部，５３…記憶部，５４…音響処理部，５６…通信部，５１１…スピーカ，５２１…ストリーミング処理部，５２２…ＢＧＭ再生部，５２３…ラジオステータス送信部，５３１…ラジオステータス記憶部，ＫＢ…カラオケ店，ＲＭ…カラオケルーム

Claims (2)

1. ＢＧＭ用の音楽データであるＢＧＭデータを受信して再生する音楽再生手段と、
   カラオケ用のデータであるカラオケデータをパケット通信により受信するカラオケデータ受信手段と、
   前記ＢＧＭデータが再生されており、且つ欠損した前記カラオケデータのパケットの個数または受信予定の前記カラオケデータのパケット数に対する欠損した前記カラオケデータのパケットの個数の割合が所定の閾値を越えた場合、前記カラオケデータ受信手段が単位時間あたりに受信する前記カラオケデータのパケットサイズが前記ＢＧＭデータが再生されていないときよりも小さくなるように制御処理を行う通信量制御手段と、
   を備えることを特徴とするデジタル音楽放送受信時のエラー防止システム。
2. ＢＧＭ用の音楽データであるＢＧＭデータを受信して再生する音楽再生手段と、
   カラオケ用のデータであるカラオケデータをパケット通信により受信するカラオケデータ受信手段と、
   前記ＢＧＭデータが再生されており、且つ前記カラオケデータのパケットにエラーが検出された回数またはエラーが発生した前記カラオケデータのパケットの割合が所定の閾値を越えた場合、前記カラオケデータ受信手段が単位時間あたりに受信する前記カラオケデータのパケットサイズが前記ＢＧＭデータが再生されていないときよりも小さくなるように制御処理を行う通信量制御手段と、
   を備えることを特徴とするデジタル音楽放送受信時のエラー防止システム。
   

Images