JPS6288027A - 音声バッファ・システム - Google Patents

Abstract

(57)【要約】本公報は電子出願前の出願データであるた
め要約のデータは記録されません。

Description

【発明の詳細な説明】 Ａ、産業上の利用分野 本発明は、音声バッファの管理を行うシステムに関する
ものであり、さらに詳しくは、リアル・タイムで音声メ
ツセージをバッファリングするシステムであって、バッ
ファリングされた音声メツセージのプロデューサおよび
コンシューマが異なるレコード・サイズの音声メツセー
ジを操作するものに関する。

Ｂ、従来技術 今日の情報処理環境においては、音声入力および音声出
力を行うことは、ますます普及しつつある。情報処理シ
ステムに音声を入力する能力があれば、そのような処理
システムの用途に広がる。

例えば、ユーザーが遠くから電話に向かってしゃべるだ
けでデータを入力することが可能になる。

電話のキーバッドを使う精巧なコーディング設計はいら
なくなる。さらに、システムに入力されるデータ量が、
キーバッドを用いてコード・インできるデータ量による
制限を受けなくなるので、大幅に増える。さらに音声入
力によってもたらされる利益は、キーボードを楽に扱え
ないユーザでも。

極めて簡単に、データのキーバンチの仕方を習うのに法
外な時間をかけることなく、データを入力できることで
ある。

情報処理システムに音声能力を提供する一つの方策は、
ホスト・プロセッサとともに信号プロセッサを用いて、
データの入出力とシステム内のデータの処理の両方を制
御することである。アナログ・オーディオ情報の入力、
デジタルへの変換。

利得制御および圧縮は、すべて信号プロセッサの制御下
で行われる。そこで問題となるのは、システムに入力中
のデジタル化された音声メツセージのバッファリングを
どうするかということである。

そのような問題は、信号プロセッサのバッファ・メモリ
の量が比較的少なく、小さなデータのブロックを極めて
頻繁にホスト・システムに転送する必要がある一方、ホ
スト・システムには相当量の使用可能なメモリがあり、
媒体の実行特性と整合させるため、大きなデータのブロ
ックを少ない頻度で記憶媒体に転送する必要のあるシス
テムにおいて、起こる。そこで、音声を入力からディス
ク・ファイルヘバツファリングする手段が求められる。

このようなバッファリングは、リアル・タイムで行われ
なければならない、ユーザーが話すと同時に、システム
上で実行されるアプリケーション・プログラムがバッフ
ァリングされた音声をディスクに記憶でき、その結果、
システムに入力できる音声データの量を制限せずに、連
続的な音声を許容できるようにするためである。一時に
音声メツセージの全体を受信するように制限されている
バッファによれば、システムに音声データを入力する方
策は不自然なものになる。有用であるためには、音声バ
ッファリングのための方策は、音声データを設定長に制
限することなく、入力されるままに音声データを受信可
能とするものでなければならない。

ディスク記憶媒体に対するこのようなリアル・タイム・
バッファリング能力をもたらすためには、バッファリン
グ機構は、アプリケーションによってディスクに転送さ
れるブロックのサイズを構成できるほど、フレキシブル
なものでなければならない。さらに、バッファリング機
構は、以前の転送が、リアル・タイムで行われる音声デ
ータの生成に遅れていないかについて、絶えずアプリケ
ーションにフィードバックできるものでなければならな
い。

米国特許第４１９３１２３号明細書には、音声セグメン
トを表わすデジタル・ワードと用いられるファースト・
イン・ファースト・アウト式のバッファが開示されてい
る。デジタル・ワードは、バッファに第一の速度で入力
され、バッファからは第一の速度より遅い第二の速度で
読み取られ、そしてＤ／Ａ変換器に印加される。第一の
ビットがバッファに書き込まれた後は、一定時間がたつ
まで、音声を表わすビットはバッファから読み取られな
い、誤り信号は、バッファが空になったときと、バッフ
ァが一杯になったときに１発生する。

しかしながら、リアル・タイムで音声データのバッファ
リングを行う概念は開示されていない。

米国特許第３７２７２０４号明細書には、非同期式のバ
ッファリング装置が開示されている。該装置のバッファ
は、情報シフト・レジスタと、ブックキーピング・レジ
スタとを含む。このバッファリングの方策は、シフト・
レジスタの情報シフト速度とブック・キーピング・レジ
スタの情報シフト速度を相互に適合させるものである。

すなわち、該方策によれば、二つのレジスタはタイミン
グのとれた関係に置かれる。しかしながら、該装置では
、二つのレジスタの情報がそれぞれの速度で走り、かつ
バッファへのデータの流れに適応することはできない。

米国特許第３１６６７１５号明細書には、記録媒体に応
じた様々な速度で、そして様々な記録密度で鉤作する非
同期式のシフト・レジスタが記載されている。しかしな
がら、バッファリングされたデータのコンシューマとプ
ロデューサが、異なる速度で動作するという概念は開示
されていない。

Ｃ０発明が解決しようとする問題点 このように、バッファを操作する資源が異なる速度で走
り、異なるレコード・サイズを要求するような状況を、
音声バッファ管理システムが扱えるようになる必要があ
る。このような必要性が生じるのは、信号処理環境にお
いて、音声メツセージは予期せぬ時に生成、消費され、
しかも様々な記憶媒体に記憶されるのが通例だからであ
る。結果として、バッファのスペースをめぐる競合と待
合せの管理は困難なものになる。

そこで１本発明は、バッファリング技術の改良を目的と
している。

本発明の他の目的は、音声メツセージをリアル・タイム
でバッファリングするシステムを提供することにある。

本発明のさらに他の目的は、バッファリングされたデー
タのプロデューサとコンシューマが、異なる速度で、そ
して異なるレコード・サイズで動作する信号処理システ
ムにおける、バッファの管理システムを提供することに
ある。

Ｄ９問題点を解決するための手段 このような目的を達成するために、ディジタル化された
音声信号が入っている固定長レコードが高速度で繰り返
しバッファに入力されるとともに、入力レコードの倍数
分からなるブロックが十分低速度で取り出される音声バ
ッファ管理システムが提供される。ディジタル化された
音声データのプロデューサは、入力アナログ・オーディ
オ信号を圧縮されたディジタル信号に変換する信号処理
システムである。バッファリングされたデジタル音声デ
ータのコンシューマは、アブヶーション・プログラムで
あり、これによって、データ・レコードの倍数分からな
るブロックがバッファから取り出され、他の媒体へ転送
される。

Ｅ、実施例 概要 以下に述べる好ましい実施例において、バッファとは、
全部でＮレコードからなり１Ｍレコードで１ブロツクを
形成するリング型のバッファをいう。したがって、バッ
ファはＮ／Ｍブロックを有する。バッファの動作の制御
に用いられるポインタは二つある。すなわち、プロデュ
ーサ・ポインタは、ブロックの中の次に書き込みが行わ
れるレコードを指示する一方、コンシューマ・ポインタ
は、バッファの中の次に読み取りが行われるブロックを
指示する。

信号処理システムは、音声データの記録と記憶を制御す
るいくつかの機能を提供する。音声記録が開始されると
、信号処理システムは、バッファを先頭から音声データ
・レコードで充てんし始める。バッファが終わりになる
まで、バッファは充てんされ続ける。バッファが終わり
になったときは、バッファの先頭のブロックが使用可能
になれば、また先頭から充てんが始まる。このような音
声バッファの充てんの循環過程の際に、ソフトウェア・
アプリケーションは、提供されている機能の一つを用い
て、未処理で、かつ最も古い完全な音声レコードのブロ
ックのアドレスを得る。次に、ソフトウェア・アプリケ
ーションは、このアドレスを用いて、音声データのブロ
ックをどこでも記録の記憶を望む所に書き込む。この機
能は、ほかに二つの目的を果たす。第一には、該機能に
より、信号処理システムに対して、前ブロックが今は解
放されており、より多くの音声データ・レコードを保持
できることを示す。第二には、一杯になっているブロッ
クの数を戻す。この数は、アプリケーションによって、
リアル・タイムのデータ速度に遅れていないかどうかの
指示として用いられる。

また、次に、信号処理システムから来るレコードを記憶
するスペースがバッファにないときは、いつでもアプリ
ケーションに割り込みかがけられる。

このレコード、そして続くレコードはすべて、アプリケ
ーションがバッファから古いデータを移動してしまうま
で、放棄される。これらの放棄されたレコードは、再生
時の音声の不連続の原因となり得る。

本実施例で開示されるバッファリングの方策は。

反対方向（オーディオ再生）にも用いられる。この反対
モードでは、アプリケーションによる制御の下、バッフ
ァは記憶済の音声データのレコードによって充てんされ
ている。再生が開始されると、デジタル化された音声デ
ータを信号プロセッサに渡すために、信号処理システム
はバッファの先頭からレコードを用い始める。信号処理
システムは、バッファが終わりになるまでバッファから
レコードを使い続ける。バッファが終わりになったとき
は、バッファの先頭のブロック１を新しいオーディオレ
コードが入っている限り、また先頭から始める。音声バ
ッファの再生過程の際に、アプリケーションは、提供さ
れているもう一つの機能を用いて、既に再生浴の、最も
古い音声レコードのブロックのアドレスを得る。次に、
アプリケーションは、このアドレスを用いて、次のレコ
ードのセットを記録済ファイルからバッファに読み取る
。

記録時と同様にして、この機能を用いることによって、
酸ブロックが今は新しいデータで一杯であることが信号
処理システムに示される８また、空のブロックの数が戻
される。この数は、アプリケーションによって、データ
を送る速度がリアル・タイムの要求に遅れない程度に速
いかどうかの指示として用いられる。万一バッファが空
になると、アプリケーションに割り込みがかけられ、ア
プリケーションがバッファにもつと音声レコードを与え
るまで、信号処理システムは沈黙する。

最良の実施態様 第１図に示されるように、デジタル化された音声サンプ
ルは、回線３４を通して信号処理システム５０の記録バ
ッファ１５に入力される。記録バッファ１５は、ピンポ
ン型のバッファであり１個別のバッファ１７．１８から
成り立っている。回線３４を通して入力されるデジタル
化された音声サンプルは、バッファ１７または１８のど
ちらが空いている方へ向けられる。第１図に示されるよ
うに、バッファ１８が充てん済のとき、バッファ１７は
空である。デジタル化された音声サンプルは、実質的に
エンドレスのストリームであり１本質的に連続的な明瞭
な音声メツセージを表現する。

ストリームは、音声がシステム５０に入力中である限り
続く。システム５ｏに久方可能な音声データの量は予め
制限されてはいない。

次に、矢印１９で記されるように、デジタル化された音
声サンプルは、記録バッファ１５がらハードウェア°イ
ンタフェース４４を越え、ホスト・システム１２に常駐
するバッファ２０に伝送される。バッファ２０は８個の
レコードがら成る。バッファ２０の最初の二つのレコー
ドは、レコード２２．２５である。レコード２２．２５
は一緒になってブロック２６を構成する。一般に、信号
処理システム５０によれば、アプリケーション１０がバ
ッファ２０の中のレコードの数および１ブロツクの中の
レコードの数を指定することができる。

本実施例では、バッファ２０の中の二つのレコードによ
って一つのブロックが形成されている。ポインタ２３は
、デジタル化された音声が、矢印１９に従って、記録バ
ッファ１５からバッファ２０の次に使用可能なレコード
へ転送されるのを管理する。この例では、ポインタ２３
によって、ブロック２６のレコード２２が、次にデータ
が入力される使用可能なレコードであることが示されて
いる。バッファ２０はリング型のバッファであり、左か
ら右へ、ページを越えて充てんされる。記録バッファ１
５は、一時に一つのレコードをバッファ２０へ転送する
。したがって、ブロック２６のようなバッファ２０の１
ブロツクを充てんするには、レコードの転送を二度行う
ことになる。

第１図に示されるように、ブロック２７は音声データに
よって充てん済である。矢印２９は、情報がブロック２
７からアプリケーション・プログラミング・インタフェ
ース１１を越えて転送されることを記している。アプリ
ケーション・プログラミング・インタフェース１１を越
える転送は。

すべて１ブロツクずつ行われる。ポインタ２８は、次に
インタフェース１１を越えて転送されるブロックの始ま
りを示すのに用いられる。プログラミング・インタフェ
ース１１を越える情報の転送は、プログラミング・イン
タフェース１１を用いるホスト１２の上で走るソフトウ
ェア・アプリケーション１０（第５図参照）の制御の下
で行われる。

アプリケーション１０、アプリケーション・プログラミ
ング・インタフェース１１、ホスト１２および信号処理
システム５０の間の対話については、後で第５〜７図を
参照しつつ、より詳細に説明する。

第２図は逆の処理、すなわち、オーディオ再生について
示す。この場合、１ブロツクのデータは。

矢印３１に従って、インタフェース１１を越えて転送さ
れる。ここでも、インタフェース１１を越える転送は、
すべて１ブロツクずつ行われる・ボインタ２３は、バッ
ファ２０の中の情報がインタフェース１１を越えて入力
される次のブロックを示す。この場合、情報はブロック
２７に入力される。ポインタ２８は、今度は、ホスト１
２のバッファ２０からハードウェア・インタフェース４
４を越えて記録バッファ１５へ転送される次のレコード
を指示する。そのような転送は、矢印３２によって示さ
れている。この場合、バッファ１７は既に充てん済なの
で、レコード３３は記録バッファ１５のバッファ１８へ
転送される。そして、音声情報は２回＠３４を通して出
力される。

第３図のフロチャートには、記録バッファ１５からバッ
ファ２ｏへの情報の転送が記述されている。第３図用に
、バッファ２０をＡＰＩ（アプリケーション・プログラ
ム・インタフェース）バッファと計うことにする。すな
わち、これら二つの用語は交換可能である。ＡＰＩバッ
ファ、つまりバッファ２０がホスト１２に常駐すること
は強調されなければならない。判断ブロック８１では、
ＡＰＩバッファが一杯か否かについて判断される６バツ
フア２０が一杯の場合、記録バッファ１５からハードウ
ェア・インタフェース４４を越えてデータが転送される
ことはない。しかしながら、ＡＰＩバッファが一杯でな
い場合、すなわち、少なくとも一つのレコードが空の場
合、バッファ１７またはバッファ１８の一方の内容はＡ
ＰＩバッファへ転送される。バッファ１７または１８の
一方の情報の転送については、ステップ８２．８３゜８
４に記されている。矢印１９に従って転送が行われた後
、ステップ８５に従い、ポインタ２３は１ブロツク用増
加される。この場合、ポインタ２３が増加して、レコー
ド２２はもう一杯であり、次に充てんされるレコードは
レコード２５であることが示される。最後に、ステップ
８６に示されるように、ＡＰＩバッファ２０の中の充て
ん済のレコード数のカウントが、１だけ増加する。レコ
ードのカウントを増す、または、そもそも保存する理由
は、第４図に関連してより明確に説明される。

第４図のフローチャートには、ＡＰＩバッファ２０から
インタフェース１１を越えて行われる情報の転送が記さ
れている。ステップ８７では、バッファ２０の中に、イ
ンタフェース１１を越えて転送するための、使用可能な
充てん済のブロックがあるか否かについて判断される。

この判断は、まず、保存中のレコード・カウントが、ブ
ロック・カウント以上であるかについて判断することに
よって行われる。ここで、ブロック・カウントは、１ブ
ロック当りのレコードの数に等しい。本実施例では、１
ブロック当りのレコードの数は２である。したがって、
バッファ２０からインタフェース１１を越えて行われる
ブロックの転送は、レコード・カウントが少なくとも２
に等しいときに起こる。第４図に示されるように、レコ
ード・カウントがブロック・カウントよりも小さいとき
は。

インタフェース１１を越えて転送が起こることはない。

しかしながら、一旦レコード・カウントがブロック・カ
ウント以上になると、転送が行われるとともに、ステッ
プ８８に示されるように、ポインタ２８は２（ブロック
・カウント、つまり１ブロック当り２レコードというこ
と）だけ増加される。その結果、ポインタ２８は、バッ
ファ２０からインタフェースを越えて転送される次のブ
ロックを示す。この場合、ポインタ２８は、ブロック２
７の直ぐ右のブロックを指示する。さらに、ステップ８
９に示されるように、レコード・カウントは、ブロック
・カウント、つまり２だけ減らされる。そのようにする
理由は、バッファ２０からインタフェース１１を越えて
ブロックが転送される度に、二つのレコードが転送され
るからである。例えば、転送前に、バッファ２０の中で
、４レコード、したがって、２ブロツクが充てん済であ
ったとすれば、記ｔ−★バッファ１５から新たな転送が
行われる前に、バッファ２０の中で充てん済のままにな
るのは２レコードだけになるのである。

第５図は、単純化された機能ブロックの形で、アプリケ
ーション１０および信号処理システム５０の、入出力コ
マンドおよび割込みを示す。アプリケーション１０は、
プログラミング、インタフェース１１を越えて、それぞ
れホスト・システム１２に位１ａされるドライバ４１、
インプレメンテ−ジョン・コード４２およびハードウェ
ア割込みルータ４３と対話する。ハードウェア・インタ
フェース４４は、ホスト処理システム１２と信号処理シ
ステム５０との境界を形成する。アプリケーション・コ
マンドは一命令メモリ２１の区画２４で終わる一方、割
込みは区画２４で始まる。区画２４は、信号ヅロセツサ
制御プログラムを含む。

この制御プログラムは、区画９２．９３．９４の命令メ
モリ２１を管理して、区画９２．９３．９４の信号処理
コードが同時に走ることを可能にし。

その結果、信号処理システム５０の資源の共用を図る。

プログラミング・インタフェース１１を規定するコマン
ドおよび割込みは、第６図および第７図を参照して、よ
り詳細に説明する。

第６図は、アプリケーション１０からインタフェース１
１を越え、ホスト１２を通って信号処理システム５０に
至るコマンドの流れを詳しく説明している。アプリケー
ション１０からインタフェース１１に入力されるコマン
ドには、二つのタイプの識別が含まれている。第一のタ
イプの識別は、使用されるべき機能セットについてであ
り、この識別により、適当な制御ブロック５１が選択さ
れる。制御ブロック５１は、インプレメンテ−ジョン・
コード４２をアクセスする。第二のタイプの識別は、与
えられた機能セットの中の特定コマンドについてである
。ドライバ４１は、これらのコマンドを取り出し、次い
で、これらをインプレメンテ−ジョン・コード４２の適
当な位置へ回す。

インタフェース１１およびドライバ４１に入力されるコ
マンドの一部である制御ブロック選択情報は、特定の制
御ブロック５１を識別する。この制御ブロック５１は、
コマンド・ベクトル・ブロック５２の始まりを指示する
ポインタ・ブロック７１を含む。コマンドに含まれるコ
マンド・コード情報は１回線７２を通して出力される。

ポインタ・ブロック７１からのポインタ情報と一緒にな
って、コマンド・コードは、このコマンド・コードに該
当するコマンド・ベクトル５２の特定位置を指示または
索引づけする。実行後、コマンド・ベクトル５２は、コ
マンド・プロセッサ５３の中の特定のインプレメンテ−
ジョン・コードを指示する。

必要とされるこの特定のコードを見つけた後、ドライバ
４１は、必要とされるコードを含むこのコマンド・プロ
セッサ５３に制御権を渡す。事実上コマンド・ベクトル
５２は、回線７２およびポインタ・ブロック７１を通し
て出されるコマンド・コードとともに、アドレス指定機
能を営む。したがって、コマンド・プロセッサ５３は、
アプリケーション１０から信号処理システム５０へ出力
される特定のコマンドを実現する。

第７図は、信号処理システム５０からホスト１２へ帰っ
てインタフェース１１へ、そしてアプリケーション１０
の中のアプリケーション割込みルーチン６１へ至る割込
みの流れを詳細に示す。割込みは信号処理システム５０
によって起こされ、ハードウェア・インタフェース４４
を越えて、回線７３を通してハードウェア割込みルータ
４３へ出力される。割込みは、区画情報と割込みのタイ
プについての情報とを両方含む。区画情報は、制御ブロ
ック６６を識別するのに用いられる。制御ブロック６６
は、割込みベクトル６７の開始点を指示するポインタ７
２を含む。割込みのタイプは、回線７５を通して入力さ
れる。ポインタ７２と一緒になって、割込みベクトル・
ブロック６７の正しい開始点がアクセスされる。実行後
、割込みベクトル６７は、割込みハンドラ６８の入力点
を指示する。次にハードウェア割込みルータ４３は、割
込みハンドラ６８に対する割込みの経路指定を行う。次
に１割込みハンドラ６８は、アプリケーション割込みベ
クトル６４を通じてアプリケーション割込みルーチン６
１に至るまでの割込みを実行して回す。回線６３を通し
てアプリケーション割込みルーチン６１に提供される情
報には、どの割込みが起きて、アプリケーション１０に
割込み処理の制御権を渡すかについての情報が含まれる
。

アプリケーション１０に制御権が渡された後、状況読取
りコマンドが、アプリケーション１ｏから出力される。

次に、状況読取り情報は、回線６２を通して１割込み状
況ブロック６５からアプリケ−ジョン割込みルーチン６
１に入力される。この信号は、送られたばかりの割込み
に関してより多くの情報を提供するものであり、かつ、
以前の状況読取りコマンド以後に起こったすべての割込
みを、アプリケーション割込みルーチン６１に知らせる
。割込み状況ブロック６５は、ハードウェア割込みルー
タ４３によって割込みハンドラ６８がアクセスされる度
に、割込みハンドラ６８によって更新される。

記録または再生機能セットのように機能セットは、二つ
のソフトウェア・ファイルを含む。一つはホス１〜処理
システム１２のためのものであり、もう一つは信号処理
システム５０のためのものである。機能セットが活動化
されると１両方のファイルはホスト１２のメモリ（図示
省Ｂ！ｓ）にロードされ、次いで、信号処理コードが命
令メモリ２１にダウンロードされる。このダウンローデ
ィングは、基本的には、ベース区画９４によって行われ
るメモリ対メモリの移動である。このダウンローディン
グは、他の区画、すなわち、９２．９３の一方が実行さ
れている間に行うことができる。

動作中に、デジタル化された音声をバッファ２０に転送
する必要が生じると、アプリケーション１０はＢＵＦＦ
ＩＮＩＴ　（バッファ初期設定）コマンドを出し、音声
データが転送されるホスト１２の中のバッファを指定す
る。ＢＵＦＦＩＮＩＴコマンドの目的は、バッファ２０
をＲＥＣＯＲＤ（記録）機能セットを結びつけ、バッフ
ァ２０での音声データのバッファリングを可能にするこ
とにある。このとき、新しい空のバッファが設定される
。次に、アプリケーション１０によって５ＴＡＲＴ　（
開始）コマンドが出され、バッファ２０への音声データ
の入力が開始される。もし、これがＢＵＦＦＩＮＩＴの
後の最初の５ＴＡＲＴコマンドならば、ＲＥＣＯＲＤ機
能セットは、バッファ２０が空であると解し、バッファ
の先頭、つまりレコード２２へ、音声データを記録し始
める。

バッファ２０への音声データの入力は、５ＴＯＰ（終了
）コマンドによって停止される。バッファ２０の充てん
過程の際、アプリケーション１０は、ＬＩＳＴＥＮ（リ
スン）コマンドを用いて、未処理、すなわちインタフェ
ース１１を越えて転送されていなくて、かつ最も古い完
全な音声レコードのブロックのアドレスを得る。該アド
レスは、完全なブロック（その点から使用可能なブロッ
ク）の数と一緒に戻される。次に、アプリケーション１
０は、この情報を用いて、どこでも音声データの記憶を
望む所へ、インタフェース１１を越えて音声データで転
送された後に、ブロックを書き込む。次にアプリケーシ
ョン１０によって出力されるＬＩＳＴＥＮコマンドは、
ＲＥＣＯＲＤ機能セットに対して、このブロックが今は
解放されてより多くの音声データを保持できることを示
す。

また、アプリケーション１ｏは、Ｌ　Ｉ　５ＴＥＮによ
って戻された完全なブロックの数を用いて、音声データ
の生成に遅れていないか、つまり、音ｊ！＃データはバ
ッファリング中であって失われていないかどうかの指示
とすることができる。バッファ２０が一杯になり、かつ
依然として音声データを記録バッファ１５から受信中の
場合は、５ＰＥＥＣＵ　　ＬＯ５Ｔ（音声損失）割込み
条件が生じ。

過剰の音声データのレコードは、次のＬ　Ｉ　５ＴＥＮ
がバッファ２０のスペースを解放するまで、放棄される
。そのようなことが起こると、記録は不連続なものにな
ってしまう。第二の割込み条件は、ＲＥＣ（）ＲＤ　（
記録）条件テ；Ｊ＞　’）　、　ＲＥ　ＣＯＲＤ（記８
）条件は、各処理済レコードの先頭で生じる。割込み条
件の最後は、５ＩＬＥＮＣＥ　（沈黙）条件であり、記
録動作中に、沈黙が一定期間を越えた場合に生しる。こ
のような事態になると、５ＴＯＰコマンドが出され、記
録は終わる。ＲＥＣＯＲＤ機能セットで用いられるコマ
ンドの最後は、に）Δ１’ＡＥＮＤ（データ・エンド）
コマン１（である。ＤＡＴＡＥＮＤコマンドは、５ＴＯ
ｒ’コマンドによってＲＥＣＯＲＤ機能が終了した後、
残っているデータをバッファ１５から出し尽くし、最後
のブロックのバッファ２０への記録を完了させる。

第２図に示されるように再生機能では、ＢＵＦＦＩＮＩ
Ｔコマンドは、バッファ２０をＰＬＡＹＢＡＣＫ　（再
生）機能セラ１〜と結びつけるのに用いられる。このコ
マンドは、インタフェース１１を越えてホスト１２の中
の選択されたバッファに転送される音声データが通るバ
ッファを与えるのに用いられる。ＢＵＦＦＩＮＩＴコマ
ンドが出されるときに、ホス１−１２の中でバッファが
現に設定されていて動作中であるときは、インタフェー
ス１１の下の他のどんなバッファリング済音声データと
も一緒に放棄される。Ｓ　Ｔ　Ａ　ＲＴコマンドは、イ
ンタフェース１１を越えてバッファ２０へ、そして信号
処理システム５０の中の記録バッファ１５へ、音声デー
タの転送を開始する。５ＴＯＰコマン１〜は、音声デー
タがバッファ２０がらハードウェア・インタフェース４
４を越えて記録バッファ１５へ転送されるのを終了する
のに用いられる。

インタフェース１１を越えてバッファ２０へ。

そしてインタフェース４４を越えて記録バッファ１５へ
、という音声データの転送の循環過程の際に、アプリケ
ーション１０は、５ＰＥＡＫ　（スピーク）コマンドを
用い、既に再生済の、最も古い完全な音声レコードのブ
ロックのアドレスを得る。

このブロックのアドレスは、その点からの使用可能な空
のブロックの数と一緒に戻される。そして、アプリケー
ション１０は、このアドレスを用いて、次のレコードの
セットをバッファ２ｏに読み取る。

次に５１）Ｅ　Ａ　Ｋを用いると、再生機能セラ１−に
は、このブロックが今は新しいレコトードで一杯であっ
て、再生可能であることが示される。アプリケーション
［Ｏは、５ＰＣＡＫによって戻された空のブロックの数
を用いて、再生速度に遅れていないかどうかの指示とす
ることができる。バッファ２０が空になり、かつ、再生
、つまり記録バッファ１５への音声データの転送が終了
した場合は、５ＰＥＥＣＩＩ　　Ｌｏｓｓ　（音声損失
）割込み条件が生じる。この結果、再生に不連続が生じ
る。ＲＥＣＯＲＤ　　ＰＲＯＣＥＳＳ　（記録処理）割
込み条件は、各処理済レコードの先頭で生じる。この割
込みによって、ポインタ２８の増加が図られる。

５ＴＡＲＴおよび５ＴＯＰコマンドは、再生機能セラ１
−において、前記ＲＥ　ＣＯＲＤ　機能セットの場合と
同様の使い方をされる。違う点は、音声データの流れが
逆向きだということである。

以−１；１本発明をその好ましい実施例について説明し
たが、本発明の要旨を逸脱しない範囲で、種々の変形が
１耳能であることは：１うまでもない。

Ｆ２発明の効果 本発明の音声バッファ管理システムによれば、（１）音
声メツセージをリアル・タイムでバッファリングするこ
とが可能である。

（２）バッファリングされた音声メツセージのプロデュ
ーサとコンシューマが、異なる速度で動作することが可
能である という優れた効果が得られろ。

【図面の簡単な説明】

第１図は本発明の一実施例における音声バッファ・シス
テムの機能ブロック図であり、記録モードを示す。 第２図は同実施例の音声バッファ・システムの機能ブロ
ック図であり、再生モードを示す。 第３図はフロチャートであり、信号処理システムからホ
スト・システムへの情報の転送を記す。 第４図はフロチャートであり、ソフトウェア・アプリケ
ーションによる制御の下での、ホスト・システムからフ
ァイルへの情報の転送を示す。 第５図は単純化した機能ブロック図であり、本実施例の
全体のシステムを示す。 第６図は単純化した機能ブロック図であり、アプリケー
ション・プログラムからプログラミング・インタフェー
スを越え、ホスト処理システムを通って信号処理システ
ムへ至るコマンドの流れを示す。 第７図は単純化した機能ブロック図であり、信号処理シ
ステムからホスト処理システムを通ってアプリケーショ
ン・プログラムに帰る割込みの流れを示す。

Claims (1)

1. 【特許請求の範囲】 本質的に連続的な、明瞭な音声メッセージを表現する、
   実質的にエンドレスの音声データのストリームを受信す
   る手段と、 受信した実質的にエンドレスの音声データのストリーム
   を記憶する手段と、 前記音声メッセージがもとのまま残つている前記記憶さ
   れた音声データのストリームを、リアル・タイムで出力
   する手段 とを含むことを特徴とする音声バッファ管理システム。