JP2016001221A - 音声データ送信装置およびその動作方法 - Google Patents

Abstract

【課題】クライアント−サーバモデルの音声認識システムにおいて、利用者が音声を入力してからテキストデータが得られるまでの時間を短く感じさせ、かつ、ネットワークの混雑助長を防止可能にするための技術を提供する。【解決手段】ネットワーク監視装置２から、ネットワークＮにおける混雑状況を示す情報を取得し、取得した混雑状況を示す情報が予め定めた混雑状況より高いことを示すものか否かを判定する（Ｓ１）。ステップＳ１でＮＯ、さらにステップＳ３でもＮＯと判定されたなら、利用履歴データベース１２に記憶された音声の時間長が予め定めた時間長より長いか否かを判定する（Ｓ５）。ステップＳ１でＹＥＳ、または、ステップＳ５でＹＥＳと判定されたなら、非圧縮音声データを圧縮し、音声認識装置３に送信する（Ｓ１１）。ステップＳ５でＮＯと判定されたなら、非圧縮音声データをそのまま、音声認識装置３に送信する（Ｓ１３）。【選択図】図５

Description

本発明は、音声データ送信装置およびその動作方法に関するものである。

各種の機器やサービスにとって、音声での入力手段を備えることは、利用者に対しての利便性を高めるという点で重要である。音声入力のためには、音声認識システムが必要となる。クライアント−サーバモデルの音声認識システムでは、音声データのサイズがテキストデータより大きいこともあり、特にネットワーク帯域が細い場合には、音声データの圧縮が必要となる。音声データの圧縮を考慮したクライアント−サーバモデルでの音声認識システムとしては、音声認識の精度も考慮した方法が提案されている（特許文献１参照）。

特開２００６−３５００９０号公報

クライアント−サーバモデルの音声認識システムでは、クライアント（端末）に音声が入力され、音声データがサーバ（音声認識装置）に送信され、テキストデータに変換され、端末にテキストデータが送信される。端末は予め音声データを圧縮することもある。

圧縮すれば、音声データの送信時間は短くなるが、圧縮と伸張の時間が必要となる。圧縮しなければ、音声データの送信時間は長くなるが、圧縮と伸張の時間が不要となる。両者はトレードオフの関係にある。

例えば、音声の時間長が長く、音声データの送信時間が比較的長くなるような場合は、圧縮と伸張の時間が占める割合は小さい。よって、利用者は、音声の時間長が長いのだから、テキストデータが得られるまでの時間が長いのは仕方がないと感じ、これを許容すると考えられる。

しかし、音声の時間長が短く、音声データの送信時間が比較的短くなるような場合は、圧縮と伸張の時間が大きな割合を占める。よって、利用者は、音声の時間長が短い割には、テキストデータが得られるまでの時間が長いと感じ、これを不満に思う可能性がある。例えば、計算能力の低い端末では、圧縮に長時間を要するので、利用者は、一層そう思う可能性がある。

また、音声データが送信されるネットワークは、状況や時間帯などによっては混雑する。混雑時に非圧縮の音声データを送信するのは、混雑を助長することになるので、避けるのが好ましい。

本発明は、上記の課題に鑑みてなされたものであり、その目的とするところは、クライアント−サーバモデルの音声認識システムにおいて、利用者が音声を入力してからテキストデータが得られるまでの時間を短く感じさせ、かつ、ネットワークの混雑助長を防止可能にするための技術を提供することにある。

上記の課題を解決するために、第１の本発明は、音声を入力する音声入力部と、過去に入力された音声の時間長が記憶される利用履歴データベースと、前記音声入力部に入力された音声の非圧縮音声データまたは該非圧縮音声データを圧縮した圧縮音声データをネットワークに送出する音声データ送信部とを備え、前記音声データ送信部は、前記ネットワークを監視するネットワーク監視装置から当該ネットワークにおける混雑状況を示す情報を取得し、当該混雑状況を示す情報および前記利用履歴データベースに記憶された音声の時間長に基づいて、前記音声入力部に入力された音声の非圧縮音声データを圧縮するか否かを判断することを特徴とする。

第２の本発明は、音声データ送信装置の動作方法であって、前記音声データ送信装置は、音声を入力する音声入力部と、過去に入力された音声の時間長が記憶される利用履歴データベースと、前記音声入力部に入力された音声の非圧縮音声データまたは該非圧縮音声データを圧縮した圧縮音声データをネットワークに送出する音声データ送信部とを備え、前記動作方法は、前記音声入力部が音声を入力するステップと、前記音声データ送信部が、前記ネットワークを監視するネットワーク監視装置から当該ネットワークにおける混雑状況を取得するステップと、前記音声データ送信部が、当該混雑状況および前記利用履歴データベースに記憶された音声の時間長に基づいて、前記音声入力部に入力された音声の非圧縮音声データを圧縮するか否かを判定するステップとを含む特徴とする。

本発明によれば、クライアント−サーバモデルの音声認識システムにおいて、利用者が音声を入力してからテキストデータが得られるまでの時間を短く感じさせ、かつ、ネットワークの混雑助長を防止できる。

本実施の形態に係る音声データ送信装置を含む音声認識システムの概略図である。 ストリーミング送信方式とファイル送信方式の比較を示す図である。 圧縮しながらのストリーミング送信を示す図である。 ネットワーク帯域と遅延の推定値を示す図である。 音声データ送信部１３の処理の流れを示すフローチャートである。 利用履歴データベース１２の形式の一例を示す図である。 ネットワーク監視装置２が圧縮の要否を音声データ送信部１３に通知する場合に行う処理の一例を示すフローチャートである。

以下、本発明の実施の形態について図面を参照して説明する。

図１は、本実施の形態に係る音声データ送信装置を含む音声認識システムの概略図である。

音声認識システムは、クライアント−サーバモデルの音声認識システムであり、クライアントである音声データ送信装置１は、ネットワークＮに接続され、ネットワークＮには、ネットワーク監視装置２およびサーバである音声認識装置３が接続される。音声データ送信装置１は、例えば、携帯端末、スマートフォンである。

音声データ送信装置１は、音声を入力する音声入力部１１、過去に入力された音声の時間長が記憶される利用履歴データベース１２、音声入力部１１に入力された音声の非圧縮音声データまたは非圧縮音声データを圧縮した圧縮音声データをネットワークＮを介して音声認識装置３に送信する音声データ送信部１３、音声認識装置３からネットワークＮを介して音声認識の結果であるテキストデータを受信するテキストデータ受信部１４を備える。

音声入力部１１は、音声データ送信装置１内に組込まれているマイクを制御し、音声データ送信装置１の利用者の音声を入力し、音声を機械処理可能なデジタルデータである非圧縮音声データに変換し、音声データ送信部１３に渡す。

ここで、近年広く普及しているスマートフォンにおいては、OSレベルでマイク等のハードウェア制御を行うためのソフトウェア開発者向けSDK（Software Development Kit）が用意されていることが多く、指定されたプログラミング言語で特定のインターフェイスを通してマイクから音声データを取得することができる。取得された音声データは、最も一般的な非圧縮デジタルオーディオデータフォーマットであるリニアパルス符号変調（リニアPCM）フォーマットで扱われることが多い。

また、近年では、スマートフォン上のアプリケーションの一つであるブラウザからも端末のマイク制御が可能になってきており、例えば、WebRTCに含まれるMediaStream APIとWeb Audio APIを組み合わせて利用することで、リニアPCMフォーマットの音声データを取得することが可能である。なお、WebRTC、Web Audio APIについては、共にW3Cで標準化に向けた議論が行われている（ただし、２０１４年４月時点）。

音声データ送信部１３は、ネットワーク監視装置２からネットワークＮの混雑状況、音声認識装置３から負荷状況を取得し、混雑状況と負荷状況と利用履歴データベース１２に記憶された音声の時間長に基づき、音声を入力してからテキストデータが得られるまでの時間を利用者が短く感じるという状況を確保した上で、非圧縮音声データを必要ならば圧縮し、非圧縮音声データまたは圧縮した圧縮音声データをネットワークＮを介して音声認識装置３に送信する。

ここで、圧縮するか否かが遅延に及ぼす影響について説明する。

音声を非圧縮音声データに変換（量子化）する際の量子化ビット数を16、チャンネル数を1、サンプリング周波数を16kHzとする。この場合、非圧縮音声データ（リニアPCM）のビットレートは256kbps（=16×1×16）となる。

非圧縮音声データの圧縮の方式については、既に様々な方式が提案されており、大きく可逆圧縮と非可逆圧縮に分けられる。通常、音声認識システムにおいては、例えば、音声データの品質に関しての要求がそれほど高くないこともあり、圧縮率を重視し非可逆圧縮を用いることが多かった。例えば、speexやopusなどである。ここでは、圧縮率を仮に10%とし、圧縮後の圧縮音声データのビットレートについては25.6kbpsとする。また、圧縮および伸長（圧縮されたデータを非圧縮の状態に戻すこと）に要する時間については、処理を行う端末の処理性能に大きく依存するが、現在広く普及しているパーソナルコンピュータ（PC）においては、概ね入力される音声の実時間長に対して1/10 〜 1/50程度であることが多い。一方で、スマートフォンを含む携帯端末においては、現状では、PCよりも処理能力が低いこともあり、ここでは、仮に圧縮に擁する時間を実時間長の1/2と仮定する。

クライアント−サーバモデルの音声認識システムでは、ストリーミング形式の音声データ送信方法を用いることが一般的である。ストリーミング形式を用いることで、発話終了を待たずに音声データの送信を開始できる。

図２に示す通り、発話終了後にまとめてデータを送信するファイル送信形式よりも音声データ全体のサーバへの到着を早めることが可能になる。結果として、利用者の発話終了後、すみやかに音声認識等の処理を開始できる。ストリーミング送信において、音声データを都度送信する際の単位をフレームと呼び、1フレームの時間的な長さは数十ms程度とすることが多い。ここでは、仮に50msとする。

ストリーミング形式での送信に圧縮を組み合わせた場合、処理のイメージは図３のようになる。

ここで、音声認識装置３において、最終的な認識結果（テキストデータ）を得るためには、音声データ（非圧縮音声データまたは圧縮音声データ）全体が音声認識装置３に到達していなければならない。発話終了から音声データ全体の音声認識装置３への到達に要する時間については、図２、３からも分かる通り、音声データの最終フレームのみを考慮することで十分である。

以上の考察より、非圧縮の場合、発話終了から音声認識装置３が音声認識処理を開始できるまでの時間（処理開始までの遅延、以降、単に遅延と示す）は次の式（１）で求めることができる。

同様に、圧縮を行う場合については次の式（２）となる。

ここで、一例として、ネットワーク帯域を25.6Mbpsとした場合、既に示したビットレート、圧縮処理時間、および、フレーム長を用いた上で、式（２）における伸長時間については、音声認識装置３が主としてサーバ側で構成されることを鑑み、処理能力が携帯端末と比較し大幅に高いことから、ここでは伸長時間を無視すると、遅延は圧縮を行った場合25.05ms圧縮を行わなかった場合0.5msとなり、非圧縮の方が音声認識処理開始までの遅延が小さくなることが分かる。

同様にして、ネットワーク帯域について複数のケースでの遅延をまとめたものが図４であり、ネットワーク帯域が細い場合は圧縮を行った方が遅延が小さく、ネットワーク帯域が太い場合は非圧縮の場合の方が遅延が小さい。

このような圧縮するか否かが遅延に及ぼす影響を考慮し、音声データ送信部１３は図５に示す様な流れで、非圧縮音声データに対し、圧縮を行うか否かを決定する。

より具体的には、まず、音声データ送信部１３は、ネットワーク監視装置２から、ネットワークＮにおける混雑状況を示す情報を取得し、取得した混雑状況を示す情報が予め定めた混雑状況より高いことを示すものか否かを判定する（Ｓ１）。

例えば、ネットワーク監視装置２は、混雑状況を示す情報として圧縮の要否を音声データ送信部１３に通知する。この場合のネットワーク監視装置２の処理内容については後述する。音声認識装置３から圧縮の要否が通知される場合、音声データ送信部１３は、圧縮必要の通知か、圧縮不要の通知かを判定する（Ｓ１）。

なお、これに限らず、例えば、混雑状況を示す情報は混雑状況の高さを示す数値であってもよい。その場合、音声データ送信部１３は、数値が予め定めた閾値より高いか否かを判定する（Ｓ１）。

なお、例えば、混雑状況を示す情報は、混雑状況の低さを示す数値（例えば、実効スループット）であってもよい。その場合、音声データ送信部１３は、実効スループットが予め定めた閾値より低いか否かを判定する（Ｓ１）。

ステップＳ１でＮＯと判定されたなら、音声データ送信部１３は、音声認識装置３から音声認識装置３における負荷状況を示す情報を取得し、取得した負荷状況を示す情報が予め定めた負荷状況より高いことを示すものか否かを判定する（Ｓ３）。

混雑状況と同様に、負荷状況を示す情報は、例えば、圧縮の要否である。例えば、音声認識装置３は、自身のネットワークインタフェースの利用率が予め定めた閾値より高いなら、圧縮が必要であると通知し、利用率が閾値以下なら、圧縮が不要であると通知する。

この場合、音声データ送信部１３は、圧縮必要の通知か、圧縮不要の通知かを判定する（Ｓ３）。

なお、これに限らず、例えば、負荷状況を示す情報は負荷状況の高さを示す数値（前述の利用率など）であってもよい。この場合、音声データ送信部１３は、数値が予め定めた閾値より高いか否かを判定する（Ｓ３）。

以上、２つの条件については、利用者が遅延を短く感じるようにするという目的に加え、ネットワークＮの帯域を有効に使い、なるべく多くの利用者に音声認識装置３を利用してもらうという目的もある。つまり、ネットワークＮの全体が空いている場合、音声認識装置３に十分な余裕がある場合には、利用者が遅延を短く感じるようにすべく、非圧縮音声データをやりとりする。

ステップＳ３でＮＯと判定されたなら、音声データ送信部１３は、利用履歴データベース１２に記憶された音声の時間長が予め定めた時間長より長いか否かを判定する（Ｓ５）。

記憶された音声の時間長が比較的長い場合、利用者は、その音声の音声認識に長時間を要することを経験的に把握している。よって、多少の遅延を利用者は許容するものと考えられる。

一方、記憶された音声の時間長が比較的短い場合、利用者にとって遅延が許容しがたいものとなると考えられる。

したがって、記憶された音声の時間長が短い場合、非圧縮音声データのままとし、遅延を小さくすることが有効と考えられる。

図６は、利用履歴データベース１２の形式の一例を示す図である。

利用履歴データベース１２には、過去に利用したサービス、利用日時、音声が入力されたかテキストデータが入力されたかのフラグ、入力データ（テキストデータが入力された場合はそのテキストデータが、一方、音声が入力された場合は音声認識された結果のテキストデータが保持される）、音声が入力された場合の音声の時間長を含む利用履歴が蓄積される。

ここで、ステップＳ５の判定に用いる音声の時間長の求め方を説明する。

具体的には、利用者が今音声入力を行おうとしているサービスの過去の利用履歴をｎ件（例えば、ｎ＝５）、利用履歴データベース１２から取り出す。ここで、利用履歴データベース１２から取り出す過去の利用履歴を、現在利用しようとしているサービスと同一のものという限定を行う例を示したが、当該限定を行わなくてもよい。

取り出したｎ件の利用履歴の中に、テキストデータが入力されたことを示すフラグを含む利用履歴がある場合には、入力データ（テキストデータ）を音節で表したものに変換した上で、ステップＳ５の判定に用いる音声の時間長を、以下の式（３）によって、求める。

ここで、ｋは利用者ごとに異なる話すスピードに基づいた係数である。一例として、係数ｋは、利用履歴データベース１２において、音声が入力されたことを示すフラグを含む利用履歴における音声の時間長と入力データに基づき、式（３）の関係性を利用し、最小二乗法によって求められる。

得られたｎ件の利用履歴における音声の時間長の平均値を、ステップＳ５の判定に用いる音声の時間長とする。

ステップＳ５では、これが予め定めた閾値Ｔｐ（例えば、Ｔｐ＝５．０）より長いか否かを判定する。

なお、利用履歴データベース１２から、音声入力を行おうとしているサービスの利用履歴を取り出す際に、例えば、過去300秒以内に入力された利用履歴に限定するといった時間的な制約を設けてもよい。

図５に戻り、音声データ送信部１３は、ステップＳ１、Ｓ３でＹＥＳと判定されたなら、または、ステップＳ５で、利用履歴データベース１２に記憶された音声の時間長が予め定めた時間長より長いと判定されたなら（Ｓ５：ＹＥＳ）、非圧縮音声データを圧縮し、音声認識装置３に送信し（Ｓ１１）、処理を終える。

一方、音声データ送信部１３は、ステップＳ５でＮＯと判定されたなら、非圧縮音声データをそのまま、音声認識装置３に送信し（Ｓ１３）、処理を終える。

ステップＳ５でＮＯと判定されたなら、非圧縮音声データをそのまま、音声認識装置３に送信するので（Ｓ１３）、利用者は音声を入力してからテキストデータが得られるまでの時間を短く感じられ、また、ステップＳ１でＹＥＳと判定されたなら、非圧縮音声データを圧縮し、音声認識装置３に送信するので（Ｓ１１）、ネットワークＮの混雑助長を防止できる。

図７は、ネットワーク監視装置２が圧縮の要否を音声データ送信部１３に通知する場合に行う処理の一例を示すフローチャートである。音声データ送信装置１が携帯端末であり、携帯電話網に属する場合、ネットワーク監視装置２は、このフローチャートに従って圧縮の要否を音声データ送信部１３に通知する。

ネットワーク監視装置２は、基地局から、基地局の通信範囲内に存在する端末数を取得し、これが予め定めた数より多いか否かを判定する（Ｓ１０１）。

ネットワーク監視装置２は、ステップＳ１０１でＮＯと判定されたなら、基地局から、ネットワークＮの帯域使用率を取得し、これが予め定めた値より高いか否かを判定する（Ｓ１０３）。

ネットワーク監視装置２は、Ｓ１０１またはＳ１０３でＹＥＳと判定されたなら、音声データ送信部１３に対し、圧縮が必要であると通知し（Ｓ１０５）、処理を終える。

ネットワーク監視装置２は、Ｓ１０３でＮＯと判定されたなら、音声データ送信部１３に対し、圧縮が不要であると通知し（Ｓ１０７）、処理を終える。

音声認識装置３は、受信した非圧縮音声データに対し、または、圧縮音声データについては、伸長処理を行ったうえで、音声認識を行い、結果（テキストデータ）をネットワークＮを介して、テキストデータ受信部１４に送信する。

ここで、テキストデータに代え、このテキストデータを例えば、検索システムに入力して得た検索結果を送信することもできる。

以上のように、本実施の形態によれば、音声を入力してからテキストデータが得られるまでの時間を利用者が短く感じるという状況を確保することができ、かつ、ネットワークＮの混雑助長を防止できる。

本実施の形態に係る技術は、特にネットワークＮの帯域が太く（Ｓ１：ＹＥＳ）、かつ、音声認識装置３の負荷状況に余裕がある（Ｓ３：ＹＥＳ）場合に、ネットワークＮの利用効率よりも、音声を入力してからテキストデータが得られるまでの時間を利用者が短く感じることを優先するので（Ｓ３：ＮＯ）、利用者にとってのサービスの体感品質を向上させることができる。

なお、本実施の形態の音声データ送信装置１としてコンピュータを機能させるためのコンピュータプログラムは、半導体メモリ、磁気ディスク、光ディスク、光磁気ディスク、磁気テープなどのコンピュータ読み取り可能な記録媒体に記録でき、また、インターネットなどの通信網を介して伝送させて、広く流通させることができる。

１ 音声データ送信装置
２ ネットワーク監視装置
３ 音声認識装置
１１ 音声入力部
１２ 利用履歴データベース
１３ 音声データ送信部
１４ テキストデータ受信部

Claims (4)

1. 音声を入力する音声入力部と、
   過去に入力された音声の時間長が記憶される利用履歴データベースと、
   前記音声入力部に入力された音声の非圧縮音声データまたは該非圧縮音声データを圧縮した圧縮音声データをネットワークに送出する音声データ送信部とを備え、
   前記音声データ送信部は、
   前記ネットワークを監視するネットワーク監視装置から当該ネットワークにおける混雑状況を示す情報を取得し、当該混雑状況を示す情報および前記利用履歴データベースに記憶された音声の時間長に基づいて、前記音声入力部に入力された音声の非圧縮音声データを圧縮するか否かを判断する
   ことを特徴とする音声データ送信装置。
2. 前記利用履歴データベースは、音声を用いたサービスの利用ごとに、利用したサービスと当該サービスの利用にて用いた音声の時間長を対応づけて記憶するものであり、前記利用履歴データベースに記憶された音声の時間長は、前記利用履歴データベースにおいて、利用しようとするサービスと同じサービスについて記憶された音声の時間長の平均値であり、
   （１）取得した混雑状況を示す情報が予め定めた混雑状況以下を示すものである、または、（２）当該混雑状況を示す情報が当該予め定めた混雑状況より高いことを示すものであり、かつ前記平均値が予め定めた時間長より長いなら、前記音声入力部に入力された音声の非圧縮音声データを圧縮する一方、（３）当該混雑状況を示す情報が当該予め定めた混雑状況より高いことを示すものであり、かつ前記平均値が予め定めた時間長以下なら、前記音声入力部に入力された音声の非圧縮音声データを圧縮しない
   ことを特徴とする請求項１記載の音声データ送信装置。
3. 音声データ送信装置の動作方法であって、
   前記音声データ送信装置は、
   音声を入力する音声入力部と、
   過去に入力された音声の時間長が記憶される利用履歴データベースと、
   前記音声入力部に入力された音声の非圧縮音声データまたは該非圧縮音声データを圧縮した圧縮音声データをネットワークに送出する音声データ送信部とを備え、
   前記動作方法は、
   前記音声入力部が音声を入力するステップと、
   前記音声データ送信部が、前記ネットワークを監視するネットワーク監視装置から当該ネットワークにおける混雑状況を取得するステップと、
   前記音声データ送信部が、当該混雑状況および前記利用履歴データベースに記憶された音声の時間長に基づいて、前記音声入力部に入力された音声の非圧縮音声データを圧縮するか否かを判定するステップと
   を含む特徴とする音声データ送信装置の動作方法。
4. 請求項１または２記載の音声データ送信装置としてコンピュータを機能させるためのコンピュータプログラム。
   

Images