JP4379471B2 - 再生装置および再生制御方法 - Google Patents

Description

本発明は、ストリームデータを再生する再生装置、およびこの装置における再生制御方法に関し、特に、ネットワークを通じて接続されたサーバ装置から送信されるストリームデータを受信して再生する再生装置および再生制御方法に関する。

近年、デジタルデータ化されたオーディオコンテンツやビデオコンテンツが広く流通し、これらを手軽に記録・再生する機器も一般的に普及している。また、ネットワーク技術の発達に伴い、家庭内においてもＬＡＮ（Local Area Network）や無線ＬＡＮなどのネットワークシステムを構築することが容易になっている。

そして、このような家庭内のネットワークシステムにおいて、機器間でデジタルコンテンツを容易にやり取りできるようにすることが望まれており、そのために機器間の接続やコンテンツ制御などの手順の規格化が進められている。その規格の代表例として、米マイクロソフト社が発表したＵＰｎＰ（Universal Plug & Play）規格が広く知られている。また、このＵＰｎＰ規格をベースとしたＤＬＮＡ（Digital Living Network Alliance）ガイドラインが策定され、ＤＬＮＡガイドラインに準拠した機器の開発が現在進められている。

ＵＰｎＰ規格では、ＵＰｎＰ機器を、コンテンツを提供するメディアサーバ（Media Server）と、制御端末装置として機能するコントロールポイント（Control Point）と、再生装置として機能するメディアレンダラ（Media Renderer）との３つに分類している。なお、コントロールポイントの機能は、メディアサーバとして動作する機器と、メディアレンダラとして動作する機器のどちらに実装されてもよい。

そして、これらの機能との間での通信手順を規定することで、ネットワーク上におけるＵＰｎＰ機器の探索や、再生動作などの制御を容易に行うことが可能となっている。例えば、この制御手順を利用することで、１つのメディアレンダラから、メディアサーバからのコンテンツデータの送受信制御だけでなく、他のメディアレンダラに対するコンテンツデータの送信制御を行うことも可能となる（例えば、特許文献１参照）。

ところで、オーディオやビデオなどのストリームデータを再生するためには、デコーダの入力バッファに対して再生に必要な量のストリームデータが常に格納されているように、その残量を適切に管理する必要があることが知られている。このため、複数のコンテンツのストリームデータを連続的に再生する場合には、前のコンテンツの再生が終了する前に、次のコンテンツのストリームデータを取得してデコーダの入力バッファへの蓄積を開始する必要があった。

なお、デコーダの入力バッファの管理手法としては、入力データのフォーマットの種別ごとに再生出力時間を算出し、これらの和によって得られる蓄積データの残り再生可能時間を基準に入力バッファへのデータ読み込みを管理することで、複数の異なるフォーマットのデータを再生可能にしたものがあった（例えば、特許文献２参照）。
特開２００５−２５０８６７号公報（段落番号〔００９０〕〜〔００９７〕、図７） 特開２００５−１８２９７０号公報（段落番号〔００９６〕〜〔０１１６〕、図７）

ここで、ＨＤＤ（Hard Disk Drive）などの固定記録媒体や光ディスクなどの可搬型記録媒体が自機内に格納された再生装置では、各コンテンツのストリームデータの記憶位置をあらかじめ把握しておくことが可能であり、所望のストリームデータをデコーダの入力バッファに読み込む際に十分な伝送帯域を確実に確保できる。このため、異なるコンテンツのストリームデータを連続再生する場合、次のコンテンツのストリームデータを、デコーダの入力バッファに対して決められた短い時間で確実に読み込むことが可能である。

しかし、ＵＰｎＰのように、サーバ装置からネットワークを通じて受信したストリームデータを再生するシステムでは、コンテンツを再生する際に、再生装置側でそのコンテンツのメタデータをあらかじめ取得し、そこに記述された情報を基にサーバ装置に対してストリームデータの送信を要求するという手順が必要となる。また、ネットワークのトラフィック状態によっては、要求したメタデータやストリームデータを所定の時間内に確実に取得できないこともある。このため、再生装置において異なるコンテンツのストリームデータを再生する際に、コンテンツ間で再生音声が途切れたり、再生画像の動きが停止してしまうことを防止できないという問題があった。

本発明はこのような点に鑑みてなされたものであり、複数のストリームデータをネットワークを通じて受信して連続的に再生可能な再生装置、およびこの装置における再生制御方法を提供することを目的とする。

本発明では上記課題を解決するために、ネットワークを通じて接続されたサーバ装置から送信されるストリームデータを受信して再生する再生装置において、前記ストリームデータの属性情報の送信を前記サーバ装置に対して要求し、前記属性情報を対応する前記ストリームデータの再生順に受信する属性情報要求手段と、前記サーバ装置から受信された前記属性情報を順次受け取って一時的に記憶するキャッシュメモリと、前記キャッシュメモリに記憶された前記属性情報に基づき、当該属性情報に対応する前記ストリームデータが前記再生装置において再生可能であるか否かを判別するデータ判別手段と、前記キャッシュメモリから取得した前記属性情報を、前記キャッシュメモリより少ない数だけ一時的に記憶する属性情報バッファであって、少なくとも、現在再生しているものの次に再生する前記ストリームデータに対応する前記属性情報を保持する属性情報バッファと、前記属性情報バッファに記憶された前記属性情報に基づいて、対応する前記ストリームデータの送信を前記サーバ装置に対して要求するストリームデータ要求手段と、前記サーバ装置から受信された前記ストリームデータを順次記憶し、再生処理手段に対して出力するＦＩＦＯ方式のストリームデータバッファと、を有し、前記ストリームデータ要求手段は、前記ストリームデータバッファに対して再生中の前記ストリームデータが最後まで蓄積されると、次に再生する前記ストリームデータに対応する前記属性情報を前記属性情報バッファから読み込み、当該属性情報に基づいて次に再生する前記ストリームデータの送信を前記サーバ装置に要求し、前記属性情報要求手段は、前記キャッシュメモリに保持されたすべての前記属性情報が前記属性情報バッファに出力されると、前記キャッシュメモリにすでに記憶された前記属性情報に対応する前記ストリームデータの次に再生する前記ストリームデータに対応する前記属性情報を、前記キャッシュメモリに保持可能な数だけ再生順に送信するように前記サーバ装置に対して要求し、前記データ判別手段は、前記キャッシュメモリに保持された前記属性情報を前記属性情報バッファに出力させる際に、当該属性情報に対応する前記ストリームデータが前記再生装置において再生可能であるか否かを判別し、再生可能である場合は、当該属性情報を前記属性情報バッファにそのまま出力させ、再生不可能である場合は、当該属性情報の出力を行わずに、次の前記属性情報を前記キャッシュメモリから出力させるように制御する、ことを特徴とする再生装置が提供される。

このような再生装置では、属性情報要求手段によるストリームデータの属性情報の送信要求に応じて、サーバ装置から属性情報が、対応するストリームデータの再生順に受信される。受信された属性情報は、キャッシュメモリに一旦記憶された後、さらに属性情報バッファに順次記憶されて、一時的に保持される。この属性情報バッファは、少なくとも、現在再生しているものの次に再生するストリームデータに対応する属性情報を保持している。また、属性情報バッファは、キャッシュメモリより少ない数の属性情報を記憶する。

ストリームデータ要求手段は、このような属性情報バッファに記憶された属性情報に基づいて、対応するストリームデータの送信をサーバ装置に対して要求する。この要求に応じて受信されたストリームデータは、ＦＩＦＯ方式のストリームデータバッファに順次記憶された後、再生処理手段に出力される。これにより、ストリームデータは再生順に順次ストリームデータバッファに格納され、順次再生処理手段に出力されて連続的に再生される。また、ストリームデータ要求手段は、ストリームデータバッファに対して再生中のストリームデータが最後まで蓄積されると、次に再生するストリームデータに対応する属性情報を属性情報バッファから読み込み、読み込んだ属性情報に基づいて次に再生するストリームデータの送信をサーバ装置に要求する。これにより、１つのストリームデータの再生終了を待たずして、次に再生するストリームデータが受信されて、ストリームデータバッファに格納される。

また、キャッシュメモリに保持された属性情報が属性情報バッファに出力される際には、この属性情報に対応するストリームデータが再生装置において再生可能であるか否かが、データ判別手段によって判別される。ここで、再生可能である場合は、この属性情報が属性情報バッファにそのまま出力される。一方、再生不可能である場合は、この属性情報の出力が行われずに、次の属性情報がキャッシュメモリから出力される。そして、属性情報要求手段は、キャッシュメモリに保持されたすべての属性情報が属性情報バッファに出力されると、キャッシュメモリにすでに記憶された属性情報に対応するストリームデータの次に再生するストリームデータに対応する属性情報を、キャッシュメモリに保持可能な数だけ再生順に送信するようにサーバ装置に対して要求する。

本発明によれば、現在再生しているものの次に再生するストリームデータに対応する属性情報が、現在再生中のストリームデータの再生終了以前にあらかじめ受信されて属性情報バッファに保持され、再生中のストリームデータがストリームデータバッファに最後まで蓄積された段階で、次に再生するストリームデータがサーバ装置から受信されて、ストリームデータバッファに格納される。従って、ネットワーク上の通信の混雑状態やサーバ装置の処理負荷状態などに関係なく、複数のストリームデータの連続再生を、ストリームデータ間で再生動作を停止させずに確実に実行できる。また、サーバ装置から受信された属性情報は、より容量の大きいキャッシュメモリを介して属性情報バッファに格納され、キャッシュメモリから属性情報バッファに対しては、対応するストリームデータが再生可能なものである場合のみ、属性情報が出力される。従って、属性情報に基づくストリームデータの再生処理を連続的に実行できる。

以下、本発明の実施の形態を図面を参照して詳細に説明する。以下の説明では、家庭内に形成されるＬＡＮシステム（ホームネットワークシステム）に本発明を適用した場合を想定する。また、このＬＡＮシステムを通じて送受信されるコンテンツデータの例として、オーディオデータを適用する。

［ホームネットワークの構成］
図１は、実施の形態に係るホームネットワークシステムの構成例を示す図である。
図１に示すホームネットワークシステムは、サーバ装置１および２と、オーディオ再生装置３〜５とが、ＬＡＮ６を通じて接続された構成となっている。

サーバ装置１および２は、例えばパーソナルコンピュータなどの情報処理装置や、オーディオコンテンツのレコーダなどであり、ＬＡＮ６への接続機能を備えるとともに、ＨＤＤなどの大容量記憶媒体を備えている。そして、ＨＤＤに蓄積されているオーディオデータを、ＬＡＮ６を通じてオーディオ再生装置３〜５に対して提供することが可能となっている。オーディオ再生装置３〜５は、それぞれＬＡＮ６への接続機能を備えており、サーバ装置１および２からＬＡＮ６を通じて送信されるオーディオデータを受信して再生する。

なお、このホームネットワークシステムにおいては、実際には例えば、サーバ装置１および２とオーディオ再生装置３〜５とが図示しないブロードバンドルータにそれぞれ接続することにより、ＬＡＮシステムが形成される。この場合、ブロードバンドルータは、ＬＡＮ６上の機器に対するＤＨＣＰ（Dynamic Host Configuration Protocol）サーバ機能およびＮＡＴ（Network Address Translation）機能を備え、これにより、ＬＡＮ６上の各機器が外部ネットワーク（ＷＡＮ：Wide Area Network）側の回線を共有できるようにもなっている。

以上のようなホームネットワークシステムでは、サーバ装置１および２は、オーディオデータを提供する情報提供装置としての機能を備え、オーディオ再生装置３〜５は、サーバ装置１および２からのオーディオデータの提供を受けて再生するクライアント装置（情報再生装置）としての機能を備えたものとなっている。そして、ユーザは、オーディオ再生装置３〜５のそれぞれを通じて、サーバ装置１または２が提供する異なったオーディオコンテンツを楽しむことが可能である。すなわち、オーディオ再生装置３〜５は、再生しようとするオーディオデータ（オーディオコンテンツ）に応じて、サーバ装置１および２のいずれか一方を、オーディオデータの配信元として選択することが可能となっている。

さらに、本実施の形態のオーディオ再生装置３〜５は、電子機器間の接続やコンテンツデータのやり取りを簡単に行うようにするため、例として、ＤＬＮＡが推奨するガイドラインに準拠した機器であるものとする。ＤＬＮＡガイドラインでは、電子機器の検出や制御、コンテンツデータの管理の手順として、米マイクロソフト社が発表したＵＰｎＰに標準で対応するよう求めている。

ＵＰｎＰは、１０／１００ＢＡＳＥ−Ｔのイーサネット（Ethernet，登録商標）を用いたネットワーク通信において代表的なＩＥＥＥ（Institute of Electrical and Electronic Engineers）８０２ネットワーク上で用いることが可能な、ＩＰ（Internet Protocol）およびＩＰ上のＴＣＰ（Transmission Control Protocol）、ＵＤＰ（User Datagram Protocol）などで構成されるプロトコル群とデータフォーマットの仕様であり、インターネット標準通信（ＴＣＰ／ＩＰ通信）における機能を拡充するものである。

そして、ＵＰｎＰをオーディオ再生装置などのいわゆるＣＥ（Consumer Electronics）機器に採用することにより、オーディオ再生装置などのＣＥ機器が、他のＣＥ機器やパーソナルコンピュータとの間で簡単に相互認証し、ネットワークを通じたサービスの提供や提供されたサービスの実行を、ユーザに面倒な作業をさせることなく、簡単かつ適正に行うことを可能にするものである。

［ＵＰｎＰの概要］
図２は、ＵＰｎＰのプロトコルスタック（プロトコル群の構造）について説明するための図である。

図２に示すように、ＵＰｎＰでは、実際のデータの送受信はインターネット標準通信プロトコルによって行われる。また、以下に説明するようなＵＰｎＰの独自の機能を実現するために、ＳＳＤＰ（Simple Service Discovery Protocol）、ＧＥＮＡ（General Event Notification Architecture）、ＳＯＡＰ（Simple Object Access Protocol）、ＨＴＴＰ（HyperText Transfer Protocol）などのプロトコル群が用いられる。

さらに、ＵＰｎＰでは、図２に示すように、ベンダ定義（UPnP Vendor Defined）、ＵＰｎＰフォーラム作業委員会定義（UPnP Forum Working Committee Defined）、デバイス仕様（構造）定義（UPnP Device Architecture Defined）がなされることになっている。

そして、ＵＰｎＰは、アドレッシング（Addressing）、ディスカバリ（Discovery）、ディスクリプション（Description）、コントロール（Control）、イベンティング（Eventing）、プレゼンテーション（Presentation）の６つの機能を提供している。以下、ＵＰｎＰが提供する６つの機能について説明する。

オーディオ再生装置などのＵＰｎＰ機器（ＵＰｎＰが搭載された電子機器）では、ＵＰｎＰの機能を用いてオーディオデータを利用するために、ＵＰｎＰ・ＡＶ・アーキテクチャという規定に従うことなる。ＵＰｎＰ・ＡＶ・アーキテクチャにおけるＵＰｎＰ機器は、以下のように３種類に分類されている。

すなわち、ＵＰｎＰ・ＡＶ・アーキテクチャでは、ＵＰｎＰ機器を、コンテンツを提供するメディアサーバと、制御端末装置として機能するコントロールポイントと、再生装置として機能するメディアレンダラとの３つに分類している。ここで、メディアサーバは、ネットワークシステムにおいて一般にサーバ装置と呼ばれているものに相当し、メディアレンダラは、ネットワークシステムにおいて一般にクライアント装置と呼ばれているものに相当する。

また、コントロールポイント（制御端末装置）は、ネットワークに接続された各ＵＰｎＰ機器を制御することができるものである。コントロールポイントとしての機能は、メディアサーバにもメディアレンダラにも搭載することが可能であり、ネットワークを構成するすべての電子機器にコントロールポイントを搭載することも、また、ネットワークを構成する任意の電子機器にコントロールポイントを搭載することも可能となっている。本実施の形態では、オーディオ再生装置３〜５のそれぞれにコントロールポイントとしての機能が搭載されているものとする。

また、ＵＰｎＰにおけるアドレッシングは、各ＵＰｎＰ機器が、ＩＥＥＥ８０２ネットワーク上で自機を特定するためのアドレスを取得する機能であり、ＤＨＣＰまたはＡｕｔｏ−ＩＰが用いられる。

ディスカバリは、アドレッシングの後に行われ、これによりコントロールポイントは、コントロールしたいターゲット機器（メディアサーバまたはメディアレンダラ）を発見することができる。ここで用いられるプロトコルは、上述のＳＳＤＰである。ネットワークシステムを構成する各電子機器は、ＩＥＥＥ８０２ネットワークに接続されたときに、自分自身が備えるデバイスやサービスを通知するメッセージを、ＩＥＥＥ８０２ネットワーク上にブロードキャストする。コントロールポイントは、このブロードキャストされたメッセージを受信することで、ＩＥＥＥ８０２ネットワークにどのような機器が接続されたかを知ることができる。

ディスカバリによって、コントロールポイントが発見したコントロール対象の電子機器が出力したＳＳＤＰパケットには、デバイスディスクリプション（Device Description）のＵＲＬ（Uniform Resource Locator）が記述されている。コントロールポイントは、そのＵＲＬにアクセスすることにより、その電子機器のさらに詳しいデバイス情報をデバイスディスクリプションから取得することができる。

このデバイス情報には、アイコン情報、モデル名、生産者名、商品名や、そのデバイスが有するサービスの詳しい情報が記載されているサービスディスクリプション（Service Description）などが記述されている。コントロールポイントは、これらのデバイスディスクリプションやサービスディスクリプションから、ターゲット機器に対するアクセスの方法を知ることができる。デバイスディスクリプションやサービスディスクリプションは、ＸＭＬ（eXtensible Markup Language）で表現されている。

コントロールの機能は、アクション（Action：実行）とクエリ（Query：問い合わせ）の２つの機能に大きく分類される。アクションは、サービスディスクリプションのアクション情報に規定された方法で行われ、アクションを実施（Invoke）することによって、コントロールポイントはターゲット機器を操作することができる。クエリは、サービスディスクリプションの機器情報（State Variable）の値を取り出すために用いられる。コントロールでは、上述のＳＯＡＰというトランスポートプロトコルが利用され、その表現としてはＸＭＬが用いられる。

イベンティングは、機器情報の値が変更されたとき、そのことをターゲット機器からコントロールポイントに通知させるために用いられる。このイベンティングでは、上述のＧＥＮＡというトランスポートプロトコルが利用され、その表現としてはＸＭＬが用いられる。プレゼンテーションは、ユーザにユーザインタフェースを用いたコントロール手段を提供するために用いられる。

各ＵＰｎＰ機器は、以上のようなＵＰｎＰ機能を用いることにより、ユーザに複雑な操作を求めることなく、ネットワークに参加し、通信が行える状態になるだけでなく、他のＵＰｎＰ機器の検出や接続までも自動的に行うことができるようにされる。

図３は、メディアサーバに格納されたコンテンツを管理するツリー構造の例を示す図である。
ＵＰｎＰ機器であるメディアサーバには、ＣＤＳ（Contents Directory Service）という機能（Service）が組み込まれており、メディアサーバはこの機能により、コントロールポイントに対して、メディアサーバにどのようにコンテンツが格納されているかを通知する。ＣＤＳには、コンテナ（Container）とアイテム（Item）という二つの抽象化されたオブジェクト（Object）があり、これらはいわば、米マイクロソフト社が提供するＯＳ（Operating System）であるＷＩＮＤＯＷＳ（登録商標）におけるフォルダ（Folder）とファイル（File）に相当する。コンテナとアイテムは、図３に示すように常にツリー構造を作ることになっている。なお、本実施の形態では、メディアサーバから送信されるオーディオデータが、図３におけるアイテムに対応している。

コントロールポイントは、図３に示したツリー構造をメディアサーバから取得することにより、各コンテンツのＵＲＬ（情報が書いてあるリンク（Link））を得ることができる。そして、所望のオーディオコンテンツ（アイテム）の情報が取得できた場合、メディアサーバのＡＶトランスポート（ＡＶ Transport）という機能を用いてオーディオコンテンツの再生や停止など、オーディオトラック（オーディオデータ）についての操作を行うことができるようにされる。

本実施の形態のサーバ装置１および２とオーディオ再生装置３〜５のそれぞれは、上述のように、ＵＰｎＰのアドレッシング機能を用いて、ＴＣＰ／ＩＰの通信が可能な状態になり、ＵＰｎＰのディスカバリ機能を用いてお互いの機器認証を行う。これによって、各機器は、ネットワークの構成を把握し、目的とする電子機器との間で通信を行うことができるようにされる。

［サーバ装置の構成例］
次に、本実施の形態のホームネットワークシステムを構成する各電子機器の構成例について説明する。

図４は、サーバ装置のハードウェア構成を示すブロック図である。なお、ここでは例としてサーバ装置１の構成について説明するが、サーバ装置２も同様のハードウェア構成により実現できる。

図４に示すように、サーバ装置１は、ＣＰＵ（Central Processing Unit）１１、ＲＯＭ（Read Only Memory）１２、ＲＡＭ（Random Access Memory）１３、ＨＤＤ１４、入力インタフェース（Ｉ／Ｆ）１５、グラフィック処理部１６、および通信インタフェース（Ｉ／Ｆ）１７を備え、これらは内部バス１８を介して相互に接続されている。

ＣＰＵ１１は、このサーバ装置１全体に対する制御をつかさどる。ＲＯＭ１２には、ＣＰＵ１１において実行するプログラムや処理に必要なデータなどが記録されている。ＲＡＭ１３は、主に各種の処理において作業領域として用いられるものである。

ＨＤＤ１４は、多数のデジタルコンテンツ（提供情報）などを蓄積することが可能な容量を持っている。また、ＨＤＤ１４は、ＣＰＵ１１により実行される各種のプログラムや処理用のデータなどを保持するとともに、コンテンツのトランスコードやコンテンツをＬＡＮ６を通じて他の機器に送信する際などに作業領域としても用いられる。

本実施の形態では、ＨＤＤ１４には、オーディオ再生装置３〜５に対してオーディオストリームを送信する、ＤＬＮＡガイドラインに準拠したサーバとして機能するためのサーバプログラムが格納されて、ＣＰＵ１１により実行される。また、このサーバプログラムの機能としては、ＨＤＤ１４に格納されたオーディオストリームの符号化方式やサンプリングレート、量子化レートなどを変換するトランスコード機能を含んでもよい。

入力Ｉ／Ｆ１５には、例えばキーボードやマウスなどの入力装置１５ａが接続されている。この入力Ｉ／Ｆ１５は、入力装置１５ａからの信号を、内部バス１８を介してＣＰＵ１１に送信する。

グラフィック処理部１６には、例えばＬＣＤ（Liquid Crystal Display）などの表示装置１６ａが接続されている。このグラフィック処理部１６は、ＣＰＵ１１からの命令に従って、表示装置１６ａの画面上に画像を表示させる。

通信Ｉ／Ｆ１７は、図示しないＬＡＮケーブルを介してＬＡＮ６に接続し、他の機器との間でデータの送受信を行う。
［オーディオ再生装置の構成例］
図５は、オーディオ再生装置のハードウェア構成を示すブロック図である。なお、ここでは例としてオーディオ再生装置３の構成について説明するが、オーディオ再生装置４および５も同様のハードウェア構成により実現できる。

図５に示すように、オーディオ再生装置３は、ＣＰＵ３１、ＲＯＭ３２、ＲＡＭ３３、フラッシュメモリ３４、入力インタフェース（Ｉ／Ｆ）３５、入力部３５ａ、グラフィック処理部３６、表示部３６ａ、通信インタフェース（Ｉ／Ｆ）３７、オーディオデコーダ３８、Ｄ／Ａ変換部３９、オーディオアンプ４０、およびスピーカ４１を備えている。これらのうち、スピーカ４１を除く各ブロックは、内部バス４２を介して接続されている。

ＣＰＵ３１は、このオーディオ再生装置３全体に対する制御をつかさどる。ＲＯＭ３２には、ＣＰＵ３１において実行するプログラムや処理に必要なデータなどが記録されている。ＲＡＭ３３は、主に各種の処理において作業領域として用いられるものである。なお、これらのＣＰＵ３１、ＲＯＭ３２、およびＲＡＭ３３は、マイクロコンピュータとして実現されてもよい。フラッシュメモリ３４は、書き換え可能な不揮発性メモリであり、例えば、オーディオ再生装置３の電源が落とされても保持しておくべき種々のデータが記録されるものである。

入力Ｉ／Ｆ３５は、入力部３５ａからの信号を、内部バス４２を介してＣＰＵ３１に送信する。入力部３５ａには、操作キーなどの各種入力スイッチが設けられている。グラフィック処理部３６は、ＣＰＵ３１からの命令に従って、表示部３６ａの画面上に画像を表示させる。表示部３６ａは、例えばＬＣＤなどから構成される。

通信Ｉ／Ｆ３７は、図示しないＬＡＮケーブルを介してＬＡＮ６に接続し、他の機器との間でデータの送受信を行う。また、通信Ｉ／Ｆ３７は、ＬＡＮ６を通じて受信したパケットからオーディオストリームのデータを抽出し、オーディオデコーダ３８に直接受け渡すことが可能になっている。

オーディオデコーダ３８は、通信Ｉ／Ｆ３７から受信したオーディオストリームをデコードする機能を備える。このオーディオデコーダ３８は、例えば、ＭＰ３（Moving Picture Experts Group−Audio Layer 3）などの各種符号化方式のオーディオデータをデコード可能となっている。また、ＬＰＣＭ（Linear Pulse Code Modulation）方式のオーディオデータが入力された場合には、そのまま後段のＤ／Ａ変換部３９に出力することが可能となっている。なお、このオーディオデコーダ３８の機能は、ＣＰＵ３１においてソフトウェアが実行されることで実現されてもよい。

Ｄ／Ａ変換部３９は、オーディオデコーダ３８から供給されたデジタルオーディオデータを、アナログオーディオ信号に変換する。オーディオアンプ４０は、Ｄ／Ａ変換部３９から供給されたアナログオーディオ信号を所定のレベルに増幅し、これをスピーカ４１に供給する。これにより、スピーカ４１からは、これに供給されたアナログオーディオ信号に応じた音声が再生出力される。

次に、オーディオ再生装置３〜５において複数のオーディオストリームを連続的に再生する場合の動作について説明する。なお、以下の各実施の形態では、サーバ装置１から送信されるオーディオストリームを、オーディオ再生装置３において受信して再生する場合を例に説明するが、当然ながら、オーディオ再生装置４および５でもオーディオ再生装置３と同様の機能を実現可能であり、また、オーディオストリームの送信元としてサーバ装置２を選択して同様の連続再生動作を実行することも可能である。

［ストリームの連続再生動作：第１の実施の形態］
図６は、第１の実施の形態に係るオーディオ再生装置でのバッファ制御について説明するための図である。

第１の実施の形態では、再生するオーディオストリームのデータを一時的に格納するオーディオバッファ１０１と、それらのオーディオストリームのメタデータを一時的に格納するメタバッファ１０２とを用いた、オーディオ再生装置３におけるオーディオストリームの連続再生の基本的な動作について説明する。なお、ここで説明するバッファの読み出し・書き込み制御やオーディオデータ・メタデータの受信制御などは、ＣＰＵ３１においてプログラムが実行されることで実現される。また、ここでのオーディオストリームとは、図３に示したアイテムに対応するオーディオデータファイルである。

オーディオバッファ１０１およびメタバッファ１０２は、ともにＲＡＭ３３を用いて実現されるＦＩＦＯ（First In First Out）方式のバッファであり、例えばリングバッファなどとして実現される。オーディオバッファ１０１には、オーディオストリームの再生時に、サーバ装置１から受信されたオーディオストリームのデータが順次格納される。これらのオーディオデータはオーディオデコーダ３８によって順次読み出されて、必要に応じてデコードされ、Ｄ／Ａ変換部３９によりアナログ変換される。これにより、音声信号が再生出力される。

メタバッファ１０２は、オーディオ再生装置３で再生可能なオーディオストリームのメタデータを格納するためのバッファであり、ここでは例として、４つ分のオーディオストリームに対応するメタデータを格納する容量を備えている。これらのメタデータは、オーディオ再生装置３からの要求に応じてサーバ装置１から送信されたものであり、メタデータには、対応するオーディオストリームのデータを取得するためのロケーション情報（ＵＲＬ、ポート番号など）が少なくとも格納されている。また、オーディオストリームに付与されたタイトル、制作者名（アーティスト名）、アルバム名、トータル再生時間、データサイズなど、再生時の表示動作や再生動作の制御に必要な情報が格納されていてもよい。なお、このメタバッファ１０２に格納されるメタデータは、例えばブラウズ（Browse）アクションに応じてサーバ装置１からＸＭＬデータとして送信されたメタデータから、必要な情報を抽出したものである。

このオーディオ再生装置３でオーディオストリームを再生する際の基本的な手順は、以下のようになる。まず、サーバ装置１から、送信可能なオーディオストリームのリスト情報を取得し、このリスト情報に基づき、再生可能なオーディオストリームを表示部３６ａに一覧表示して、ユーザから選択入力を受ける。次に、リスト情報に基づき、選択されたオーディオストリームに関するさらに詳細な情報が記述されたメタデータの送信を、サーバ装置１に対して要求する。このメタデータには再生に必要な情報が記述されており、受信したメタデータに記述された情報を基にサーバ装置１にアクセスして、対応するオーディオストリームの送信を、サーバ装置１に対して要求する。そして、この要求に応答してサーバ装置１から送信されたオーディオストリームが、オーディオバッファ１０１に順次蓄積され、オーディオデコーダ３８に読み出される。

次に、このようなオーディオ再生装置３において、複数のオーディオストリームを連続的に再生する際の処理について説明する。まず、メタバッファ１０２には、あるオーディオストリームの再生が開始されると、少なくとも次に再生されるオーディオストリームのメタデータを格納しておく。図６の例では、トラック１のオーディオストリームが再生中であり、メタバッファ１０２には、その次に再生されるトラック２のオーディオストリームに対応するメタデータが格納されている。

一方、オーディオバッファ１０１では、再生対象のオーディオストリームのデータが順次格納され、所定容量だけ蓄積された時点で、オーディオデコーダ３８からの読み出しが開始される。また、オーディオバッファ１０１では、常にオーディオストリームのデータで満たされ、空きが生じないようにデータの読み込みが制御される。

その後、再生中のオーディオストリームのすべてのデータが受信され、オーディオバッファ１０１に空きが生じるようになると、オーディオ再生装置３では、現在再生中のオーディオストリームの再生終了を待たずに、メタバッファ１０２に格納されていた、次のオーディオストリームに対応するメタデータが読み出される。そして、そのメタデータに記述されたロケーション情報に基づき、次のオーディオストリームの送信がサーバ装置１に要求されて、そのオーディオストリームが受信され、オーディオバッファ１０１の空き領域に順次格納されていく。オーディオバッファ１０１では、常に空き領域が生じないように、次のオーディオバッファ１０１が読み込まれていく。

これにより、現在再生中のオーディオストリームのデータがすべてオーディオバッファ１０１からオーディオデコーダ３８に読み出されると、引き続き次のオーディオストリームのデータがオーディオデコーダ３８に読み出され、そのデータ再生が連続的に実行される。また、メタバッファ１０２には、再生が終了されたオーディオストリームのメタデータが消去されて、現在格納されているものの次に再生されるオーディオストリームのメタデータが、サーバ装置１から受信されて格納される。

なお、メタバッファ１０２の更新のために新たなメタデータの送信をサーバ装置１に要求するタイミングは、次に再生するオーディオストリームをサーバ装置１から受信するためにメタデータが参照されてから、そのオーディオストリームの再生が終了するまでの期間とすればよい。

以上のバッファ制御により、ＬＡＮ６での通信の混雑状態やサーバ装置１の処理負荷状態などに関係なく、前のオーディオストリームの再生終了タイミングに、次のオーディオストリームの先頭領域のデータを確実に受信して、オーディオバッファ１０１に蓄積しておくことができるので、楽曲間の音切れ時間を常に最小限に抑えて連続再生を確実に実行できる。

また、このような効果を奏するために、オーディオバッファ１０１の容量は、ＬＡＮ６での通信の混雑状態やサーバ装置１の処理負荷状態などを考慮して決定されればよい。例えば、メタデータを参照して次のオーディオストリームの送信を要求し、それに応答してオーディオストリームをサーバ装置１から受信してオーディオバッファ１０１への格納を開始するまでの最大時間を予想しておき、その予想最大時間内に、オーディオストリームがオーディオバッファ１０１から読み出されるデータ量以上とするように、オーディオバッファ１０１の容量を決定する。

また、メタバッファ１０２には、少なくとも次に再生するオーディオストリームのメタデータが保持されていればよいが、図６のように複数のオーディオストリームのメタデータを保持しておくことで、ＬＡＮ６での通信の混雑やサーバ装置１の処理負荷増加などによってメタデータ自体の受信が遅れた場合でも、メタバッファ１０２に格納されているトラック数の範囲で、連続再生動作を実行させることが可能になる。

さらに、メタデータに基づき、前後のオーディオストリームの符号化フォーマットやサンプリング周波数、ビットレートなどの仕様が同じであることがわかっていれば、次のオーディオストリームのデコードを開始する際にオーディオデコーダ３８などの後段の回路を初期化しないように制御することで、オーディオストリームの切り換え時に無音状態がまったく生じない、いわゆるギャップレス再生を確実に行うことも可能になる。

なお、図６の例では、メタバッファ１０２には、現在再生中のオーディオストリームのメタデータをその再生終了時まで保持しておき、再生制御部などから参照できるようにしている。しかし、この他に、オーディオストリームをサーバ装置１から取得する際に、そのために必要なメタデータをメタバッファ１０２から読み出して、別のメモリ領域に格納しておき、この時点でメタバッファ１０２に対して、現在格納されているものの次に再生されるオーディオストリームのメタデータを読み込むようにしてもよい。

［ストリームの連続再生動作：第２の実施の形態］
図７は、第２の実施の形態に係るオーディオ再生装置が備える主な機能を示すブロック図である。

第２の実施の形態に係るオーディオ再生装置３では、上記の第１の実施の形態で説明したオーディオバッファ１０１およびメタバッファ１０２に加えて、メタデータをキャッシュしておくためのキャッシュメモリ１０３を設けている。これにより、複数のオーディオストリームの連続再生をより正確に実行できるようにするとともに、ランダム再生などにも容易に対応できるようにする。なお、キャッシュメモリ１０３も、ＲＡＭ３３などにより実現されるものである。

本実施の形態のオーディオ再生装置３は、複数のオーディオストリームを連続再生するための機能として、図７に示すように、再生制御部１１０、通信制御部１２０、およびユーザインタフェース（Ｕ／Ｉ）制御部１３０を備えている。なお、これらの各部の機能は、ＣＰＵ３１によってプログラムが実行されることで実現される。

再生制御部１１０は、オーディオストリームの再生に関する動作全般を制御する制御部であり、Ｕ／Ｉ制御部１３０を通じて受け付けたユーザの操作入力情報に応じた処理を実行する。この再生制御部１１０は、オーディオバッファ制御部１１１、メタバッファ制御部１１２、キャッシュ制御部１１３、フィルタ１１４、およびランダム番号生成部１１５を備えている。

オーディオバッファ制御部１１１は、オーディオバッファ１０１へのオーディオストリームのデータ読み込みや、そのデータをオーディオデコーダ３８からの要求に応じてオーディオデコーダ３８に対して読み出す動作を制御する。また、オーディオバッファ１０１の空き領域を管理し、空きが発生した場合には、メタバッファ１０２に記憶された、次に再生するオーディオストリームのメタデータを参照して、そのデータに記述されたロケーション情報を通信制御部１２０に引き渡し、対応するオーディオストリームの送信を要求させる。

メタバッファ制御部１１２は、メタバッファ１０２へのメタデータの読み込みや、そのメタデータの読み出しの動作を制御する。メタバッファ制御部１１２は、１つのオーディオストリームの再生（ここではデコード）が終了すると、そのことの通知をオーディオバッファ制御部１１１から受け、次のメタデータを読み出してメタバッファ１０２に供給するようにキャッシュ制御部１１３に要求する。

キャッシュ制御部１１３は、キャッシュメモリ１０３へのメタデータの読み込みや、そのメタデータのメタバッファ１０２への読み出しを制御する。キャッシュ制御部１１３は、メタバッファ制御部１１２からの要求に応じて、キャッシュメモリ１０３内のメタデータをフィルタ１１４を通じてメタバッファ１０２に読み出す。また、キャッシュメモリ１０３内のメタデータの読み出し状態を管理し、すべてのメタデータが読み出されると、通信制御部１２０に対して、次に再生するオーディオストリームのメタデータの送信を要求させる。

フィルタ１１４は、キャッシュメモリ１０３から読み出されたメタデータが、オーディオストリームに対するものであるか否かを判別し、正しい場合はそのメタデータをメタバッファ１０２に出力し、正しくない場合はそのことをキャッシュ制御部１１３に通知する。

ランダム番号生成部１１５は、楽曲順をランダムに並び替えて再生させるランダム再生（シャッフル再生）のための再生順を決定するブロックであり、再生するトラック番号をランダムに指定する乱数発生機能を備えている。

通信制御部１２０は、ＬＡＮ６を通じた通信処理を制御するブロックであり、ここでは、再生制御部１１０からの要求に応じて、ＵＰｎＰで規定された通信手順を実行することが可能となっている。また、その通信手順により受信されたメタデータをキャッシュメモリ１０３に格納し、オーディオストリームのデータをオーディオバッファ１０１に格納する。

Ｕ／Ｉ制御部１３０は、入力部３５ａに対するユーザの入力操作を入力Ｉ／Ｆ３５を通じて検知して、その入力操作に応じた操作入力情報を再生制御部１１０に出力する。また、再生制御部１１０からの制御情報に従って、例えば、サーバやコンテンツの選択時、コンテンツの再生時など、場面に応じた表示情報を生成してグラフィック処理部３６に出力し、表示情報に応じた画像を表示部３６ａに表示させる。

図８は、第２の実施の形態に係るオーディオ再生装置でのバッファ制御について説明するための図である。
図８では例として、オーディオストリームをトラック１〜トラック２０（ｔｒ１〜ｔｒ２０）の順に連続再生する場合のキャッシュメモリ１０３、メタバッファ１０２、およびオーディオバッファ１０１におけるデータ書き込み・読み出しの状態を模式的に示している。なお、ここでは例として、キャッシュメモリ１０３は１０トラック分のメタデータを保持し、メタバッファ１０２は４トラック分のメタデータを保持できるものとする。

まず、トラック１の再生開始がユーザの操作入力により指示されると、図８（Ａ）に示すように、キャッシュメモリ１０３は、トラック１を先頭とした１０トラック分のメタデータが格納された状態となる。これらのメタデータは、再生開始が要求された時点でサーバ装置１からあらためて受信してもよいし、それ以前に受信されたものであってもよい。

さらに、これらの１０トラック分のメタデータの中から、先頭の４トラック分のメタデータがメタバッファ１０２に読み込まれる。そして、まずトラック１のメタデータに記述されたロケーション情報を基に、対応するオーディオストリームが受信され、オーディオバッファ１０１に蓄積されていき、そのオーディオストリームの再生が開始される。

また、第１の実施の形態と同様に、トラック１のオーディオストリームの全データが受信され、オーディオバッファ１０１に空きが生じるようになると、次に再生されるトラック２のメタデータがメタバッファ１０２から参照され、そのメタデータに基づいてトラック２のオーディオストリームの受信が開始されて、オーディオバッファ１０１に蓄積される。

また、トラック１のオーディオストリームの再生が終了すると、メタバッファ１０２では、トラック１のメタデータが消去され、その空き領域に、キャッシュメモリ１０３から次のトラック５のメタデータが読み込まれる。なお、この他に、例えば、トラック１の再生のためにトラック１のメタデータがメタバッファ１０２から読み出された時点、あるいは、次のトラック２のオーディオストリームの受信が開始された時点で、トラック１のメタデータがメタバッファ１０２から消去され、トラック５のメタデータが書き込まれるようにしてもよい。

以後、上記の処理が繰り返され、最後に格納されたトラック１０のメタデータがメタバッファ１０２に読み込まれたとする。このとき、図８（Ｂ）に示すように、トラック７のオーディオストリームの再生が開始され、メタバッファ１０２には、トラック７〜１０のメタデータが格納されている。キャッシュ制御部１１３は、キャッシュメモリ１０３内のすべてのメタデータがメタバッファ１０２に読み込まれたことを検出すると、通信制御部１２０を制御して、次の１０トラック分のメタデータを送信するようにサーバ装置１に要求させる。この結果、トラック１１〜２０までのメタデータがキャッシュメモリ１０３に上書きされ、以後、上記と同様にキャッシュメモリ１０３内のメタデータが先頭から順にメタバッファ１０２に読み込まれる。

このように、メタバッファ１０２より多くのトラック数のメタデータを蓄積可能なキャッシュメモリ１０３を設け、このキャッシュメモリ１０３からメタバッファ１０２にメタデータを読み出す構成としたことで、再生対象のオーディオストリームのメタデータを即座に取得して、確実に連続再生できるようになる。例えば、再生時間の短いオーディオストリームが数曲再生されて、メタバッファ１０２の蓄積データが頻繁に更新されるような場合でも、メタデータをその都度サーバ装置１から受信することなく、キャッシュメモリ１０３に保持されたメタデータを読み込んで連続再生を継続できるようになる。

ところで、サーバ装置１側のコンテンツ管理のツリー構造によっては、オーディオストリームのメタデータに混ざって、それ以外のデータに関するメタデータがサーバ装置１側から受信される場合もある。例えば、同じコンテナの子階層に、オーディオストリームとビデオストリームのアイテムが混在したり、アイテムとともにさらにコンテナが存在する場合もある。

このような場合、同じコンテナの子階層のオブジェクトに関するメタデータが、そのオブジェクトの種類に関係なく、サーバ装置１で付与された順番で受信されて、キャッシュメモリ１０３に一旦格納される。そして、キャッシュメモリ１０３から各オブジェクトのメタデータが読み出されたとき、フィルタ１１４によって、そのメタデータがオーディオストリームに関するものであるか否かが判定される。オーディオストリームに関するものであった場合は、そのままメタバッファ１０２に転送されるが、そうでなかった場合にはフィルタ１１４からキャッシュ制御部１１３に対してエラーが通知され、通知を受けたキャッシュ制御部１１３の制御によって、キャッシュメモリ１０３から次のオブジェクトに対応するメタデータが読み出される。

これにより、メタバッファ１０２には、オーディオストリームに関するメタデータのみが格納されるので、このメタバッファ１０２からオーディオバッファ制御部１１１がメタデータを順次読み出すことで、オーディオストリームを連続的に再生できる。すなわち、次に再生するオーディオストリームのデータを受信しようとするタイミングで、メタバッファ１０２内の次のメタデータがオーディオストリームに関するものであるか否かを判別する必要がなくなり、楽曲間で余計な無音期間が発生することなく、連続再生を確実に継続できるようになる。

次に、オーディオストリームの連続再生時における各部の処理について説明する。まず、図９は、連続再生動作が開始されるまでのオーディオ再生装置における処理手順を示すフローチャートである。

〔ステップＳ１１〕オーディオ再生装置３では、ＬＡＮ６に接続されると、サーバ装置を探索する処理が実行される。
まず、オーディオ再生装置３がＬＡＮ６に接続されると、通信制御部１２０により自身のネットワークアドレスが取得された後、再生制御部１１０は、サーバ装置を探索するように通信制御部１２０に要求する。通信制御部１２０は、ＵＰｎＰで規定されたサーチメッセージをＬＡＮ６上にマルチキャストする。ＬＡＮ６上のサーバ装置１および２は、サーチメッセージに応答して、自身を特定するＩＤや、デバイスディスクリプションを取得するためのＵＲＬなどを返信する。

通信制御部１２０は、以上の手順で探索されたサーバ装置１および２に関する情報を再生制御部１１０に渡し、再生制御部１１０は、サーバ装置１および２を選択するための画面を表示させるようにＵ／Ｉ制御部１３０に指示する。これにより、表示部３６ａには、探索されたサーバ装置１および２の名前などが一覧表示され、ユーザからの選択入力を待機する状態となる。

〔ステップＳ１２〕オーディオ再生装置３では、サーバ装置を選択するためのユーザによる入力操作に応じて、選択されたサーバ装置（ここではサーバ装置１とする）から、送信可能なコンテンツの情報を得るための処理が実行される。

ここでは、再生制御部１１０は、サーバ装置１が選択されたことをＵ／Ｉ制御部１３０を介して検出すると、そのサーバ装置１からデバイスディスクリプションを取得するように、通信制御部１２０に要求する。通信制御部１２０は、対応するＵＲＬにアクセスしてＧＥＴコマンドによりデバイスディスクリプションを受信した後、サーバ装置１でコンテンツを管理している階層構造のルートのロケーションを得て、そのルートの子階層についての情報を要求する。

この要求に対する応答から、子階層にコンテナのみ含まれる場合には、そのコンテナの情報を再生制御部１１０に渡す。再生制御部１１０は、それらのコンテナをユーザに選択させるための画面表示をＵ／Ｉ制御部１３０に要求する。これにより、コンテナに付与された名前が表示部３６ａに一覧表示され、ユーザはこれらから１つを選択する操作を行う。再生制御部１１０は、選択されたコンテナの子階層の属性情報を取得するように、通信制御部１２０に対して要求する。

このような手順が繰り返されることにより、子階層の情報が順次得られる。一般的には、ルートの子階層のコンテナはアーティストごとに設けられ、さらのその子階層のコンテナはアルバムごとに設けられ、そのコンテナの子階層に、楽曲に対応するアイテムが存在する。なお、オーディオ再生装置３から、アーティストなどの検索条件を指定して、その条件に応じた階層構造に従ってアイテムを探索することもできる。

以上の処理により、子階層にアイテムが存在した場合には、そのアイテムに関する概略的な情報を示すメタデータがＸＭＬデータとして取得される。上述したように、本実施の形態では、アイテムはコンテンツ（ここでは楽曲）のストリームデータに対応しており、基本的には、１つのアルバムに対応するコンテナの子階層に含まれるアイテムに関するリスト情報が取得されることになる。

〔ステップＳ１３〕サーバ装置１から取得されたアイテムのリスト情報は、通信制御部１２０から再生制御部１１０に渡される。再生制御部１１０は、そのリスト情報に基づき、再生可能な楽曲のタイトルやアーティスト名などの情報を一覧表示した選択画面を表示させるように、Ｕ／Ｉ制御部１３０に要求する。これにより、表示部３６ａには、再生可能な楽曲の情報が一覧表示され、オーディオ再生装置３は、最初に再生させる楽曲に対する選択操作の待機状態となる。

〔ステップＳ１４〕再生制御部１１０は、楽曲の選択情報をＵ／Ｉ制御部１３０を介して受け取ると、その楽曲に関する情報をさらに詳細に記載したメタデータを受信するように、通信制御部１２０に要求する。このとき、選択された楽曲を先頭として１０曲（１０トラック）分のメタデータを一度に受信するように要求する。図８の例では、例えばトラック１が選択された場合、トラック１〜１０のメタデータの受信を要求する。通信制御部１２０は、トラック番号を指定してメタデータの送信をサーバ装置１に要求するためのアクションを実行する。

サーバ装置１から受信されたメタデータは、通信制御部１２０を介してキャッシュメモリ１０３に格納される。キャッシュ制御部１１３は、キャッシュメモリ１０３内の先頭４トラック分のメタデータを、フィルタ１１４を介してメタバッファ１０２に供給する。

〔ステップＳ１５〕オーディオバッファ制御部１１１は、メタバッファ１０２から１トラック分のメタデータを読み込み、このメタデータに記述されたロケーション情報を通信制御部１２０に渡して、対応するオーディオストリームを取得するように要求する。通信制御部１２０は、ロケーション情報を基にサーバ装置１にアクセスして、オーディオストリームの送信を要求する。

〔ステップＳ１６〕サーバ装置１からオーディオストリームが送信され、これを受信したオーディオ再生装置３では、オーディオストリームが通信制御部１２０を介してオーディオバッファ１０１に順次供給される。そして、このオーディオバッファ１０１からデータがオーディオデコーダ３８に順次読み出されることで、再生動作が実行される。

図１０は、連続再生時におけるオーディオバッファ制御部によるオーディオバッファの空き管理処理手順を示すフローチャートである。
上述したように、オーディオバッファ制御部１１１は、オーディオバッファ１０１にオーディオストリームのデータが蓄積されると、オーディオデコーダ３８からの要求に応じて、オーディオバッファ１０１内のデータを順次オーディオデコーダ３８に読み出すように制御する。このとき、オーディオバッファ制御部１１１は、以下の手順によりオーディオバッファ１０１に対するデータの読み込みを管理する。

〔ステップＳ２１〕オーディオバッファ制御部１１１は、メタバッファ１０２から、１トラック分のメタデータを読み込む。
〔ステップＳ２２〕オーディオバッファ制御部１１１は、読み込んだメタデータに記述されたロケーション情報を通信制御部１２０に転送して、対応するオーディオストリームの送信を要求する。通信制御部１２０は、その要求に応じて、対応するオーディオストリームを送信するためのアクションを実行し、サーバ装置１からこれに応じてオーディオストリームの送信が開始される。送信されたオーディオストリームのデータは、オーディオバッファ１０１に順次蓄積される。

〔ステップＳ２３〕オーディオバッファ制御部１１１は、オーディオバッファ１０１の空き状態を監視し、空きが発生していない場合にはステップＳ２４の処理を実行する。また、１つのオーディオストリームの受信が完了して、オーディオバッファ１０１に空きが生じ始めた場合には、ステップＳ２１に戻って、次のトラックのメタデータをメタバッファ１０２から読み込む。この結果、次に再生されるオーディオストリームがサーバ装置１から送信されるようになる。

〔ステップＳ２４〕オーディオバッファ制御部１１１は、ユーザの操作などにより連続再生動作の終了が要求されたか否かを判別する。要求されていない場合は、ステップＳ２３に戻ってオーディオバッファ１０１の空き状態を判別し、要求された場合は処理を終了する。

以上の処理により、オーディオバッファ１０１には、オーディオストリームのデータがバッファ容量分だけ常に保持される。そして、１つのオーディオストリームの受信が完了すると、そのオーディオストリームの再生終了を待たずに、次のオーディオストリームの受信が自動的に開始される。

図１１は、メタバッファ制御部におけるメタバッファの管理処理手順を示すフローチャートである。
〔ステップＳ３１〕連続再生動作が開始されると、メタバッファ制御部１１２は、キャッシュ制御部１１３に対して、４トラック分のメタデータを読み出すように要求する。この結果、キャッシュメモリ１０３からは、４トラック分のメタデータが、フィルタ１１４を介してメタバッファ１０２に読み込まれる。

〔ステップＳ３２〕メタバッファ制御部１１２は、オーディオバッファ制御部１１１からの要求に応じて、メタバッファ１０２に格納された、最も再生順の早いトラックのメタデータを、オーディオバッファ制御部１１１に出力させる。

〔ステップＳ３３〕メタバッファ制御部１１２は、１つのオーディオストリームの再生が終了し、次のオーディオストリームの再生が開始されたか否かを判定する。開始されていない場合はステップＳ３４の処理を実行し、開始された場合はステップＳ３５の処理を実行する。

なお、次のオーディオストリームの再生開始は、例えば、オーディオデコーダ３８において新たなオーディオストリームのデコードが開始されたこと、あるいは、オーディオバッファ１０１から新たなオーディオストリームのデータ読み出しが開始されたことなどの通知を、オーディオバッファ制御部１１１から受けることで判断できる。

〔ステップＳ３４〕メタバッファ制御部１１２は、ユーザの操作などにより連続再生動作の終了が要求されたか否かを判定する。要求されていない場合は、ステップＳ３３に戻って次のオーディオストリームの再生開始を判定し、要求された場合は処理を終了する。

〔ステップＳ３５〕メタバッファ制御部１１２は、キャッシュ制御部１１３に対して、次の１トラック分のメタデータを読み出すように要求する。この結果、キャッシュメモリ１０３からは、次の１トラック分のメタデータがフィルタ１１４を介してメタバッファ１０２に転送される。メタバッファ制御部１１２は、転送されたメタデータを、ステップＳ３２で出力したメタデータの記憶領域に上書きする。

なお、上記の処理では、次のオーディオストリームの再生が開始されたときに、次の１トラック分のメタデータをメタバッファ１０２に読み込むようにしている。これにより、現在再生中のオーディオストリームのメタデータがメタバッファ１０２に常に保持され、このメタデータを装置内の各部が参照できる。しかし、そのような処理の代わりに、ステップＳ３２でメタバッファ１０２から１トラック分のメタデータを出力させると、すぐに次の１トラック分のメタデータが読み込まれるように制御してもよい。

図１２は、キャッシュ制御部におけるキャッシュメモリの管理処理手順を示すフローチャートである。
図９のステップＳ１４の制御処理により、サーバ装置１から所定トラック数分（ここでは１０トラック分）のメタデータが送信され、それらのメタデータがキャッシュメモリ１０３に蓄積されると、キャッシュ制御部１１３は、以下のような手順でキャッシュメモリ１０３の読み書きを制御する。

〔ステップＳ４１〕キャッシュ制御部１１３は、メタバッファ制御部１１２から、１トラック分のメタデータの出力要求を受けたか否かを判定する。要求を受けていない場合はステップＳ４２の処理を実行し、要求を受けた場合はステップＳ４３の処理を実行する。

〔ステップＳ４２〕キャッシュ制御部１１３は、ユーザの操作などにより連続再生動作の終了が要求されたか否かを判別する。要求されていない場合は、ステップＳ４１に戻ってメタバッファ１０２に対する出力要求の有無を判定し、要求された場合は処理を終了する。

〔ステップＳ４３〕キャッシュ制御部１１３は、キャッシュメモリ１０３から、読み出し済みのものの次のオブジェクトのメタデータを、フィルタ１１４に対して読み出す。
〔ステップＳ４４〕フィルタ１１４は、読み出されたメタデータがオーディオストリームに関するものであるか否かを判定する。オーディオストリームに関するメタデータであれば、そのままメタバッファ１０２に転送するが、そうでなかった場合には、そのことをキャッシュ制御部１１３に通知する。

キャッシュ制御部１１３は、フィルタから通知があった場合にはステップＳ４３に戻って、次のオブジェクトのメタデータをキャッシュメモリ１０３から読み出し、通知がなかった場合には、ステップＳ４５の処理を実行する。

なお、この図１２では省略しているが、連続再生動作の開始直後では、図１１のステップＳ３１の処理によりメタバッファ制御部１１２からは４トラック分のメタデータの出力が要求される。従って、連続再生開始直後のみ、ステップＳ４３およびＳ４４では、先頭から４トラック分のオーディオストリームのメタデータを読み出すような処理が行われる。

また、フィルタ１１４は、読み出されたメタデータがオーディオストリームに関するものであった場合に、さらに、そのメタデータから対応するオーディオストリームの符号化方式やサンプリング周波数、ビットレートなどを解析し、このオーディオストリームがオーディオ再生装置３において再生可能なものであるか否かを判定してもよい。この場合、再生可能と判定した場合のみ、メタデータをメタバッファ１０２に転送し、再生不可能と判定した場合には、そのことをキャッシュ制御部１１３に通知して、次のメタデータをキャッシュメモリ１０３から取得する。

〔ステップＳ４５〕キャッシュ制御部１１３は、キャッシュメモリ１０３内のすべてのメタデータが読み出されたか否かを判定する。読み出されていないメタデータが存在する場合は、ステップＳ４１に戻って、そのまま次のメタデータの出力要求を待機し、すべてのメタデータが読み出し済みの場合は、ステップＳ４６の処理を実行する。

〔ステップＳ４６〕キャッシュ制御部１１３は、図９のステップＳ１２で取得されていたリスト情報と、すでにメタバッファ１０２に転送済みのトラック番号の情報とを基に、次の１０個分のオブジェクトを指定する情報を通信制御部１２０に転送して、それらのオブジェクトのメタデータの送信を要求する。通信制御部１２０は、その要求に応じて、対応するメタデータを送信するためのアクションを実行し、サーバ装置１からは、これに応じて、指定された１０個分のオブジェクトのメタデータが送信される。送信されたメタデータは、キャッシュメモリ１０３に上書きされ、その後、ステップＳ４１の処理が再度実行される。

以上のオーディオバッファ制御部１１１、メタバッファ制御部１１２、およびキャッシュ制御部１１３の処理により、オーディオバッファ１０１には常時オーディオストリームのデータが満たされ、１つのオーディオストリームの受信が終了すると、連続して次のオーディオストリームのデータがオーディオバッファ１０１に確実に格納される。従って、ＬＡＮ６での通信の混雑状態やサーバ装置１の処理負荷状態などに関係なく、楽曲間で余計な無音期間が発生しない連続再生動作を確実に実行できる。

次に、このオーディオ再生装置３におけるランダム再生時の制御について説明する。図１３は、ランダム再生時におけるキャッシュメモリの管理処理手順を示すフローチャートである。

オーディオ再生装置３では、図９のステップＳ１１，Ｓ１２の手順により、１つのコンテナの子階層に含まれるアイテムに関するリスト情報が取得された後、この子階層に含まれるオーディオストリームの送信順をランダムに指定することで、ランダム再生を実行できる。なお、ランダム番号生成部１１５は、取得されたリスト情報に基づき、コンテナ内に存在するアイテム数の範囲で、ランダムにトラック番号を指定する。

〔ステップＳ５１〕ランダム再生の開始時には、ランダム番号生成部１１５によって少なくとも初回４曲分のトラック番号がランダムに生成され、これらのメタデータがサーバ装置１から受信されて、キャッシュメモリ１０３を介してメタバッファ１０２に格納される必要がある。このとき、キャッシュメモリ１０３は、初回４曲分を含む１０トラック分のメタデータによって満たされている。

このような状態とするための最も簡単な処理手順としては、ランダム番号生成部１１５により初回１０曲分のトラック番号が生成され、キャッシュ制御部１１３が、これらのトラック番号を通信制御部１２０に通知して、これらに対応するメタデータをサーバ装置１から送信させる。そして、受信したメタデータをキャッシュメモリ１０３に格納した後、そのキャッシュメモリ１０３から再生順にメタデータをメタバッファ１０２に読み出すように制御する。この場合には、キャッシュメモリ１０３内のメタデータがすべてメタバッファ１０２に対して読み出されるまでは、それらのメタデータを再生順にメタバッファ１０２に読み出すように制御した後、次のステップＳ５２以後の処理が実行されればよい。

〔ステップＳ５２〕キャッシュ制御部１１３は、メタバッファ制御部１１２から、１トラック分のメタデータの出力要求を受けたか否かを判定する。要求を受けていない場合はステップＳ５３の処理を実行し、要求を受けた場合はステップＳ５４の処理を実行する。

〔ステップＳ５３〕キャッシュ制御部１１３は、ユーザの操作などによりランダム再生動作の終了が要求されたか否かを判別する。要求されていない場合は、ステップＳ５２に戻ってメタバッファ１０２に対する出力要求の有無を判定し、要求された場合は処理を終了する。

〔ステップＳ５４〕キャッシュ制御部１１３は、ランダム番号生成部１１５から、新たなトラック番号を取得する。
〔ステップＳ５５〕キャッシュ制御部１１３は、取得したトラック番号に対応するメタデータがキャッシュメモリ１０３に格納されているか否かを判定する。対応するメタデータが格納されていた場合にはステップＳ５７の処理を実行し、格納されていなかった場合にはステップＳ５６の処理を実行する。

〔ステップＳ５６〕キャッシュ制御部１１３は、ステップＳ５４で取得したトラック番号を先頭とした１０オブジェクト分（ここでは１０トラック分）のメタデータを受信するように、通信制御部１２０に対して命令する。通信制御部１２０は、サーバ装置１に対してこれらのメタデータの送信を要求するアクションを実行し、それに応じた受信されたメタデータがキャッシュメモリ１０３に上書きされる。

〔ステップＳ５７〕キャッシュ制御部１１３は、ステップＳ５４で取得したトラック番号に対応するメタデータを、キャッシュメモリ１０３からメタバッファ１０２に転送させる。

このような処理によれば、１つのコンテナの子階層に、キャッシュメモリ１０３に格納できる数より多くのトラック数のオーディオストリームが存在する場合でも、それらの全オーディオストリームを対象としてランダムに再生順を決定することができる。

また、新たなトラック番号をランダムに生成したときに、そのトラック番号に対応するメタデータがキャッシュメモリ１０３に格納されていない場合にのみ、そのメタデータをサーバ装置１からあらためて受信するので、メタデータの送信要求を行う回数が減少される。さらに、新たなトラック番号の生成は、それに対応するオーディオストリームの再生開始直前に行うのでなく、それより遥かに前の、メタバッファ１０２に新たなメタデータを格納するタイミングで行われるので、メタバッファ１０２には直近の４トラック分のメタデータが常に格納された状態となる。従って、メタバッファ１０２のメタデータをオーディオバッファ制御部１１１が即座に参照できるので、ランダム再生時においても、余計な無音期間のない連続再生動作を実行できる。

なお、以上の図１３では、説明を簡単にするために、キャッシュメモリ１０３にはオーディオストリームに関するメタデータのみが格納されるものとした。しかし、図１２で説明したフィルタ１１４の機能を用いて、オーディオストリームに関するメタデータのみを抽出して、メタバッファ１０２に供給することも可能である。この場合、キャッシュメモリ１０３からメタバッファ１０２に対してメタデータを転送する際に、フィルタ１１４により、そのメタデータがオーディオストリームに関するものでないと判定されたり、再生不可能であると判定された場合には、ランダム番号生成部１１５に新たな番号を生成させ、ステップＳ５６の処理に進んで、その番号を先頭とした次の１０オブジェクト分のメタデータを受信すればよい。

［ストリームの連続再生動作：第３の実施の形態］
図１４は、第３の実施の形態に係るオーディオ再生装置のバッファ構成と、その制御について説明するための図である。

第３の実施の形態では、楽曲の再生途中に、次の楽曲の再生を開始させる動作（飛ばし再生）、あるいは同じ楽曲を先頭から再度再生させる動作（戻り再生）を要求した場合でも、即座にそれらの動作を実行できるようにしている。このために、オーディオストリームのデータを格納するオーディオバッファ１０１ａを、図１４に示すように、２つの先頭データ領域１０４および１０５と、ＦＩＦＯ領域１０６とに分割している。

先頭データ領域１０４および１０５は、ともに一定容量を持つメモリ領域であり、各領域には、再生中のオーディオストリームの先頭から所定量のデータ、または、次に再生されるオーディオストリームの先頭から所定量のデータのいずれかが交互に格納される。そして、これらの先頭データ領域１０４および１０５に蓄積されたデータは、各領域に対応するオーディオストリームの再生が終了するまで保持される。

一方、ＦＩＦＯ領域１０６は、オーディオストリームのデータのうち、先頭データ領域１０４および１０５に格納されたデータを除いた残りのデータが順次格納されるＦＩＦＯ方式メモリ領域であり、例えばリングバッファとして実現される。この領域には、最初に、再生中のオーディオストリームのデータのうち、先頭データ領域１０４および１０５の一方に格納されたデータの位置より後のデータが順次格納される。その後、オーディオストリームの受信が終了すると、次に再生されるオーディオストリームのデータのうち、先頭データ領域１０４および１０５の他方に格納されたデータの位置より後のデータが順次格納される。

ここで、例として、図１４に示すトラック１のオーディオストリームが再生される場合、まず、メタバッファ１０２内のトラック１のメタデータに基づいて、トラック１のオーディオストリームの送信がサーバ装置１に要求され、これに応じて送信されたオーディオストリームのデータが、オーディオ再生装置３で受信される。このとき、受信したオーディオストリームのデータは、先頭データ領域１０４に格納される。そして、先頭データ領域１０４の空きがなくなると、その後の受信データがＦＩＦＯ領域１０６に格納される。

オーディオデコーダ３８は、まず、先頭データ領域１０４からデータを読み出してデコード処理を行い、この領域のデータをすべて読み出すと、次にＦＩＦＯ領域１０６からデータを読み出すことで、トラック１のオーディオストリームの再生を継続する。そして、その再生中に、戻り再生を要求する操作入力が行われた場合には、先頭データ領域１０４の先頭から再度オーディオデコーダ３８にデータが転送される。これにより、オーディオストリームの先頭データを再度サーバ装置１から受信することなく、戻り再生を即座に実行できる。また、先頭データ領域１０４からデータを読み出している間に、トラック１のメタデータに基づいて、再度サーバ装置１に送信要求を行って残りのデータを受信し、データをフラッシュしたＦＩＦＯ領域１０６に蓄積していくことで、オーディオストリームの再生が継続される。

一方、トラック１のオーディオストリームの再生が開始されたとき、オーディオ再生装置３は、トラック１とは別の通信セッションをサーバ装置１との間で実行し、トラック２のメタデータに基づき、それに対応するオーディオストリームの送信をサーバ装置１に要求する。これにより、トラック２のオーディオストリームのデータをトラック１のデータと並行して受信する。このとき、例えば、受信中のトラック１のオーディオストリームの受信速度を検出し、所定の速度以上であれば、トラック２のオーディオストリームを並行して受信するための処理を起動してもよい。

受信されたトラック２のオーディオストリームのデータは、先頭データ領域１０５に格納される。ここでは、先頭データ領域１０５の容量分だけ受信された後、一旦受信を停止し、ＦＩＦＯ領域１０６に空きが生じたときに、残りのデータを受信してＦＩＦＯ領域１０６に格納していく。このような処理により、トラック１のオーディオストリームの再生中に飛ばし再生が要求された場合には、トラック２のオーディオストリームのデータを、先頭データ領域１０５から即座にオーディオデコーダ３８に転送でき、この時点でトラック２のオーディオストリームの先頭データをサーバ装置１から受信する必要がなくなる。

なお、トラック２のオーディオストリームの再生が開始されると、その残りのオーディオストリームをサーバ装置１から受信し、データをフラッシュしたＦＩＦＯ領域１０６に順次蓄積しておくことで、そのオーディオストリームの再生が継続される。

実施の形態に係るホームネットワークシステムの構成例を示す図である。 ＵＰｎＰのプロトコルスタック（プロトコル群の構造）について説明するための図である。 メディアサーバに格納されたコンテンツを管理するツリー構造の例を示す図である。 サーバ装置のハードウェア構成を示すブロック図である。 オーディオ再生装置のハードウェア構成を示すブロック図である。 第１の実施の形態に係るオーディオ再生装置でのバッファ制御について説明するための図である。 第２の実施の形態に係るオーディオ再生装置が備える主な機能を示すブロック図である。 第２の実施の形態に係るオーディオ再生装置でのバッファ制御について説明するための図である。 連続再生動作が開始されるまでのオーディオ再生装置における処理手順を示すフローチャートである。 連続再生時におけるオーディオバッファ制御部によるオーディオバッファの空き管理処理手順を示すフローチャートである。 メタバッファ制御部におけるメタバッファの管理処理手順を示すフローチャートである。 キャッシュ制御部におけるキャッシュメモリの管理処理手順を示すフローチャートである。 ランダム再生時におけるキャッシュメモリの管理処理手順を示すフローチャートである。 第３の実施の形態に係るオーディオ再生装置のバッファ構成と、その制御について説明するための図である。

符号の説明

１，２……サーバ装置、３〜５……オーディオ再生装置、６……ＬＡＮ、１１，３１……ＣＰＵ、１２，３２……ＲＯＭ、１３，３３……ＲＡＭ、１４……ＨＤＤ、１５，３５……入力インタフェース、１５ａ……入力装置、１６，３６……グラフィック処理部、１６ａ……表示装置、１７，３７……通信インタフェース、１８，４２……内部バス、３４……フラッシュメモリ、３５ａ……入力部、３６ａ……表示部、３８……オーディオデコーダ、３９……Ｄ／Ａ変換部、４０……オーディオアンプ、４１……スピーカ、１０１……オーディオバッファ、１０２……メタバッファ

Claims (8)

1. ネットワークを通じて接続されたサーバ装置から送信されるストリームデータを受信して再生する再生装置において、
   前記ストリームデータの属性情報の送信を前記サーバ装置に対して要求し、前記属性情報を対応する前記ストリームデータの再生順に受信する属性情報要求手段と、
   前記サーバ装置から受信された前記属性情報を順次受け取って一時的に記憶するキャッシュメモリと、
   前記キャッシュメモリに記憶された前記属性情報に基づき、当該属性情報に対応する前記ストリームデータが前記再生装置において再生可能であるか否かを判別するデータ判別手段と、
   前記キャッシュメモリから取得した前記属性情報を、前記キャッシュメモリより少ない数だけ一時的に記憶する属性情報バッファであって、少なくとも、現在再生しているものの次に再生する前記ストリームデータに対応する前記属性情報を保持する属性情報バッファと、
   前記属性情報バッファに記憶された前記属性情報に基づいて、対応する前記ストリームデータの送信を前記サーバ装置に対して要求するストリームデータ要求手段と、
   前記サーバ装置から受信された前記ストリームデータを順次記憶し、再生処理手段に対して出力するＦＩＦＯ方式のストリームデータバッファと、
   を有し、
   前記ストリームデータ要求手段は、前記ストリームデータバッファに対して再生中の前記ストリームデータが最後まで蓄積されると、次に再生する前記ストリームデータに対応する前記属性情報を前記属性情報バッファから読み込み、当該属性情報に基づいて次に再生する前記ストリームデータの送信を前記サーバ装置に要求し、
   前記属性情報要求手段は、前記キャッシュメモリに保持されたすべての前記属性情報が前記属性情報バッファに出力されると、前記キャッシュメモリにすでに記憶された前記属性情報に対応する前記ストリームデータの次に再生する前記ストリームデータに対応する前記属性情報を、前記キャッシュメモリに保持可能な数だけ再生順に送信するように前記サーバ装置に対して要求し、
   前記データ判別手段は、前記キャッシュメモリに保持された前記属性情報を前記属性情報バッファに出力させる際に、当該属性情報に対応する前記ストリームデータが前記再生装置において再生可能であるか否かを判別し、再生可能である場合は、当該属性情報を前記属性情報バッファにそのまま出力させ、再生不可能である場合は、当該属性情報の出力を行わずに、次の前記属性情報を前記キャッシュメモリから出力させるように制御する、
   ことを特徴とする再生装置。
2. 前記属性情報バッファは、少なくとも、現在再生している前記ストリームデータの次に順次再生する一定数の前記ストリームデータに対応する前記属性情報を保持し、
   前記ストリームデータ要求手段は、前記属性情報バッファに記憶された前記属性情報を再生順に読み込む、
   ことを特徴とする請求項１記載の再生装置。
3. 前記データ判別手段により、前記キャッシュメモリから読み込んだ前記属性情報に対応する前記ストリームデータが再生不可能と判別されたときに、前記キャッシュメモリ内の前記属性情報のすべてについて再生可能か否かの判定済みであった場合に、前記属性情報要求手段は、前記キャッシュメモリにすでに記憶された前記属性情報に対応する前記ストリームデータの次に再生する前記ストリームデータに対応する前記属性情報を、前記キャッシュメモリに保持可能な数だけ再生順に送信するように前記サーバ装置に対して要求することを特徴とする請求項１記載の再生装置。
4. 前記データ判別手段は、前記キャッシュメモリから読み込んだ前記属性情報に基づき、当該属性情報に対応する前記ストリームデータの種類と、当該ストリームデータの符号化形式、サンプリング周波数およびビットレートの中の少なくとも１つとから、当該ストリームデータが再生可能であるか否かを判別することを特徴とする請求項１記載の再生装置。
5. 前記キャッシュメモリから前記属性情報バッファに対して新たな前記属性情報を記憶させる際に、前記ストリームデータの再生順を示す再生番号をランダムに生成する再生順生成手段と、
   生成された前記再生番号に対応する前記属性情報が前記キャッシュメモリに記憶されているか否かを判定し、記憶されていた場合には、当該属性情報を前記キャッシュメモリから前記属性情報バッファに出力させ、記憶されていなかった場合には、当該属性情報を先頭として、前記キャッシュメモリに保持可能な数だけの前記属性情報を前記サーバ装置から送信させるように、前記属性情報要求手段に要求するランダム再生制御手段と、
   をさらに有することを特徴とする請求項１記載の再生装置。
6. 前記ストリームデータバッファには、再生中の前記ストリームデータの先頭から所定量のデータを保持する先頭データ保持領域と、前記先頭データ保持領域に保持されたデータの残りの前記ストリームデータが順次格納されるＦＩＦＯ領域とが設けられ、
   また、
   前記ストリームデータの再生中に、ユーザの操作入力により戻り再生動作が要求されると、前記先頭データ保持領域に保持されたデータをその先頭から前記再生処理手段に再度供給するとともに、前記先頭データ保持領域に保持されたデータの残りの前記ストリームデータを前記サーバ装置から再度送信させるように、前記ストリームデータ要求手段に要求する戻り再生制御手段をさらに有することを特徴とする請求項１記載の再生装置。
7. 前記ストリームデータバッファには、次に再生する前記ストリームデータの先頭から所定量のデータを保持する次ストリーム先頭データ保持領域と、それ以外のデータが格納されるＦＩＦＯ領域とが設けられ、
   前記ストリームデータ要求手段は、新たな前記ストリームデータの再生が開始されると、次に再生する前記ストリームデータに対応する前記属性情報を前記属性情報バッファから読み込んで、当該属性情報に対応する前記ストリームデータの送信を前記サーバ装置に要求し、その要求に応じて受信した前記ストリームデータを前記次ストリーム先頭データ保持領域に記憶させ、
   また、
   前記ストリームデータの再生中に、ユーザの操作入力により飛ばし再生動作が要求されると、前記次ストリーム先頭データ保持領域に保持されたデータをその先頭から前記再生処理手段に供給するとともに、前記次ストリーム先頭データ保持領域に保持されたデータの残りの前記ストリームデータを前記サーバ装置から送信させるように、前記ストリームデータ要求手段に要求し、その要求に応じて受信された前記ストリームデータを前記ＦＩＦＯ領域に順次格納するように制御する飛ばし再生制御手段をさらに有することを特徴とする請求項１記載の再生装置。
8. ネットワークを通じて接続されたサーバ装置から送信されるストリームデータを受信して再生するための再生制御方法において、
   属性情報要求手段が、前記ストリームデータの属性情報の送信を前記サーバ装置に対して要求して、前記属性情報を対応する前記ストリームデータの再生順に受信し、
   属性情報記録制御手段が、前記サーバ装置から受信された前記属性情報をキャッシュメモリに順次格納して一時的に記憶させ、
   前記属性情報記録制御手段が、前記キャッシュメモリに保持された前記属性情報を、前記キャッシュメモリより少ない数の前記属性情報を保持可能な属性情報バッファに対して、少なくとも、現在再生しているものの次に再生する前記ストリームデータに対応する前記属性情報が当該属性情報バッファに保持されるように記憶させ、
   ストリームデータ要求手段が、前記属性情報バッファに記憶された前記属性情報に基づいて、対応する前記ストリームデータの送信を前記サーバ装置に対して要求し、
   ストリームデータ記録制御手段が、前記サーバ装置から受信された前記ストリームデータをストリームデータバッファにＦＩＦＯ方式で順次格納して、再生処理手段に対して出力する、
   処理を含み、
   前記ストリームデータの送信を要求する処理では、前記ストリームデータバッファに対して再生中の前記ストリームデータが最後まで蓄積されると、前記ストリームデータ要求手段により、次に再生する前記ストリームデータに対応する前記属性情報が前記属性情報バッファから読み込まれて、当該属性情報に基づいて次に再生する前記ストリームデータの送信が前記サーバ装置に要求され、
   前記属性情報の送信を要求する処理では、前記キャッシュメモリに保持されたすべての前記属性情報が前記属性情報バッファに出力されると、前記キャッシュメモリにすでに記憶された前記属性情報に対応する前記ストリームデータの次に再生する前記ストリームデータに対応する前記属性情報を、前記キャッシュメモリに保持可能な数だけ再生順に送信するように、前記属性情報要求手段により前記サーバ装置に対して要求され、
   前記キャッシュメモリに保持された前記属性情報が前記属性情報バッファに出力される際には、データ判別手段により、当該属性情報に対応する前記ストリームデータが前記再生装置において再生可能であるか否かが判別され、再生可能である場合は、当該属性情報が前記属性情報バッファにそのまま出力され、再生不可能である場合は、当該属性情報の出力が行われずに、次の前記属性情報が前記キャッシュメモリから出力される、
   ことを特徴とする再生制御方法。

Images