前回までのお話
自社の主力製品を調査し、FPGA 事業部の方向をすり合わせることにした Y 君。ただ、自社製品で取り扱っているからという理由だけで通信を対象とした製品を扱うのは不十分と考え、幾らかの市場調査を加え、特にリアルタイム性を有する Social Media という分野に焦点をあててプレゼンを行った。打ち合わせにおいて大きな反対はなかったものの、宿題として具体的な製品イメージおよび製品仕様の提出が課された。慌てた Y 君は、作成したプレゼン資料を持参し、改めて先生のもとへ向かった。
教授は不在でした
Y 君： 急なところすいません。大変ご無沙汰しております。先日はご挨拶にいけず申し訳ありませんでした。
先生 B：いえ、大丈夫です。前回は教授が大丈夫で私が駄目だったのですが本日は逆なので私が対応します。
Y 君：はい、よろしくお願いいたします。
先生 B：でも、Y 君も大分社会人らしくなりましたね。
Y 君： もう卒業して大分たちますので。でも先生は全然お変わりなく。
先生 B：大学は時間の流れが速いようで緩やかですからね。さて、世間話はさておき、プレゼン資料をみましょうか。
Y 君：教授のお陰で先日のプレゼンは無事乗り切ることができました。
先生 B：それは良かったです。後程，教授にも伝えておきます。
個人向け通信用 FPGA システムの要求仕様
先生 B： さて、今日の質問は何でしょうか。
Y 君： (説明資料を手渡し) 我が社の通信技術を利用することが望ましいと考え、通信技術を必要とする個人向けシステムについて考えたいと思います。そこで、先生に今回お伺いしたいのは、何を、どこまで、どれくらいの価格でできるかなのですが・・・。
先生 B： ずいぶんとざっくりとした質問ですね。そういうのはニーズ調査とかしてから来てもらう方が良いと思いますが・・・．
Y 君： 申し訳ないです。ただ、たたき台となるような資料はいくらか用意させて頂きました。こちらの資料を見て頂けないでしょうか。
先生 B： FPGA のチップ単価のグラフですね。まず、何を基準にしてこの調査をしたか教えてもらえますか。
Y 君： はい。当社の販売価格設定の関係から、チップ単価が15万円を超える FPGA をまず調査から除外しました。次に、通信用インタフェースの実装に必要な論理素子数を調査し、約70,000個と仮定しました。これに演算部を加えて、総論理素子数が100,000個以上の FPGA のみを調査対象としています。この条件に合致し得られた FPGA 単価をプロットしたものが図1になります。また、同様にオンチップメモリ量についても 10M ビット以上の FPGA のみを調査対象としました。これは図2に示しています。
Y 君： 図1と図2のプロットで同色同形状は同じ FPGA を意味しています。また、プロットが重なっていますが、単価データとしては約150件得ているので目安としては十分だと考えています。
先生 B： なるほど。それで、どの程度の演算をさせたいのでしょうか。
Y 君： すいません。実は、そこについては何も考えてなくて。そこで、先生と一緒に議論させて頂ければと思っているのですがどうでしょうか。
先生 B： うーん、先ほどもいいましたが先に市場調査とかきちんとしないと。そういうところは相変わらずですね。仕方ないですね。時間もないと思うので、一緒に考えていきましょうか。
Y 君： よろしくお願いします。
先生 B： まず初めに、通信用モジュールについては Y 君の会社にノウハウがある、だからこの部分は議論から除く、ということで大丈夫ですか？
Y 君： 問題ありません。
先生 B： 次に、通信用モジュールで使用予定の論理素子数が70,000個、メモリが 10M ビットとしました。図1から90,000個以上、図2から 1.4M ビットくらいは利用できるということですよね。逆に言えば、廉価なシステムを狙うならその範囲でアプリを考えたい、ということですね。
Y 君： はい、そうなります。
先生 B： スペクトラムアナライザとかだと面白くありませんし・・・、Y 君個人のアイデアで構わないので、具体的にどのような用途に利用するまたは利用したいかを教えてもらえないでしょうか。
Y 君： 会社では偉そうなことを言っていたのですが実はバンドの練習で使えるとうれしいかな、と。
先生 B： バンド？周波数ではなく？
Y 君： はい。音楽のバンドです。社会人になってから知り合った友人たちとバンドを組んでいて、ベース、ドラム、ボーカル、そしてギターは２人いて僕はどちらかというとサイドギターなんですが、この練習が最近うまくいかなくて困ってるんです。
先生 B： 最近、ということ何かあったのですか？
Y 君： コロナ禍です。コロナ禍のせいでレンタルスタジオが使えなくなって練習が難しく。オンラインツールを使って簡単に集まれる、と喜んでいたのですがそんな簡単な話じゃないこともわかってきたんです。
先生 B： まぁ、ネットワークを介してだとそうなるでしょうね。
Y 君： そう言われますが、一緒に練習ができないのはバンドにとって死活問題なんです。
先生 B： 死活問題って大げさな・・・。
Y 君： 先生！これは一大事なんです。
先生 B： まぁ、落ち着いて、落ち着いて。とりあえず、会社の業務を利用して自分のやりたいことをやってしまおうと。
Y 君： そう言われると何だか微妙ですが・・・。オンラインツールも色々とあるんです。例えば、JamKazam、Ninjam、Jammr、また最近では YAMAHA が無料で Syncroom を提供していて、このツールはもう神なのですが、ただ使っているとどんどんと欲がでてきて・・・。
先生 B： バンドのことはよくわかりませんけど、とにかく困っている、と。そして、別の場所にいるメンバがあたかも一緒にいるような音楽共有用の疑似空間をインターネット上に作りたい、ということですね。
Y 君： そうです。もちろん、インターネット通信を使っているので幾らか遅れとか音の違いがあるのは仕方がないとは思っています。ただ、できるだけそれを小さくしたいんです。
先生 B： テーマとしてもいいと思いますよ。趣味ならモチベーションも上がりますし、会社にとっても良いものができるなら Win=Win ですね。ただ、利用できるハードウェア資源の範囲で、どの程度のことができるのかをもう少し考えてみましょう。
Y 君： うーん。
先生 B： ・・・。
Y 君： うーん。
先生 B： 何か思い浮かびましたか？
Y 君： そうですね、せっかくなので今よりも細かい音の違いや臨場感を際立たせるようなシステムにしたいですね。
先生 B： そうすると、音質と遅延時間になるかな。
Y 君： 音質は良い方がいいですし、時間遅れは小さい方がいいですね。
先生 B： どちらから話をしましょうか。遅延時間の方からかな。
Y 君： どちらからでも構いません。よろしくお願いいたします。
先生 B： では、まず現在のイメージを図にしましょうか。バンドのメンバが 5 名だと 5 か所の相互接続が必要となります。ただ、まずは単純化して、2 か所の通信から考えることにしましょう。
Y 君： あ、図ですが用意したものがあります。こんな図ですがいかがでしょうか。
先生 B： わかりやすいですね。まず、一番遠いところに住んでるメンバを A さんとしますと、住所はどのあたりになるのでしょうか。
Y 君： 一番遠いところに住むメンバですか。４月に社内で部署が異動するメンバがいて、配属は確か福岡だったと思います。
先生 B： それは結構遠いですね。Y 君が東京で A さんが福岡とするとその距離は・・・、887 km ですね。つまり、バンド練習するには、人でもデータでもこの距離を移動しないと駄目ということです。東京＝福岡間の光ファイバの遅延時間を計算すると直線距離の場合で片道約 4.4 ミリ秒 ( 1000 分の 4.4 秒 ) ですね。ただ、光ファイバを直線状に敷設工事するのは実際には無理なので 2 ～ 3 倍の距離として考えるのが良いでしょう。そうすると 10～15 ミリ秒くらいとなります。
Y 君： 10 ミリ秒というと 100 分の 1 秒ですよね。非常に短くて驚きました。
先生 B： 通信会社に勤めている人間が何を言っているんですか (笑)。これは、図 3 で考えると橙色の線で書かれた部分ですね。ただ、それ以外にも沢山の時間遅れの要因があります。ただ、緑の線で書かれたオーディオインタフェースの繋がり部分はあまり気にしなくても良いでしょう。一方、水色の線で書かれた部分、オーディオインタフェースからのデータを読み取り、Windows OS や MacOS がリモートスタジオのアプリを管理し、アプリがデータを処理してインターネットへと送る、という一連の処理には注意が必要ですね。
Y 君： 注意というのは何でしょうか。
先生 B： この水色の線で書かれた部分ですが、例えば Windows OS を使用しているなら、Windows OS の動作に必要なサービスプログラム ( カーネルプログラム ) やそれ以外にも Y 君が意識していないところで動くアプリケーションプログラム ( ウィルス対策ソフトなど ) があるわけです。バンドのセッション中にパソコンを扱うことはないと思いますが、パソコンの中では様々なプログラムを順番に自動で処理していきます。この「自動」で処理の部分が過ぎると「勝手」と思いたくなるのですが、この「勝手」が過ぎると水色の線で書かれた処理に 0.5 秒かそれ以上かかることが出てきます。
Y 君： パソコンを使っている最中にマウスカーソルが止まったり、日本語入力ができなかったりするのと同じですね。ただ先生のお話だと、インターネット通信で東京から福岡まで旅する橙色の線より、パソコン内を移動するだけの水色部分の方が時間がかかることがある、ということですがそれで合っていますか？
先生 B： はい、そうです．もちろん常にそうなる訳ではなくいろいろな要因が絡み合ってそうなる訳ですが、それで困ることには違いありません。Y 君のシステムで通信時間の遅れを短くする ( 遅れの最大を保証する ) には不確定な要素を省き、シンプルにする必要があります。FPGA を使うならアプリと OS をなくして直接つないでしまえばこの問題をある程度は解決できます。音を加工しないで再生する、録音する、通信する、というだけなら回路規模的にも問題はないでしょう。よって、まずはこんな感じでしょうか。
Y 君： 確かに、大分すっきりしました気がします。それではここから音質の議論ですね。
先生 B： そうです、と言いたいのですが、遅延時間についてどれくらいまで許容できるか、という話もしておいた方が良いでしょう。
Y 君： 確かに、言われるとそうかもしれません。バンド仲間の間でもボーカルの口パク ( リップシンク、lip sync) は気になると話をしています。興味で調べたものなのですが、国際電気通信機構 (ITU) の ITU-R BT.1359-1 で音声遅延の主観評価の図があったのでお見せします。
Y 君： 映像に関する資料なので画像と音声のズレの話で通信における音の遅延時間とは異なりますが参考にはなると思います。興味深かったのは、音声が画像に対して先行する方が違和感が大きく、音声が画像に対して遅れた方が許容できるという部分です。
先生 B： それに関連する話は脳科学の観点から調査した研究報告があります。少し古いですが 2003 年のネイチャーに掲載されたもので、脳が光に対する音の時間遅れを自動的に計算して認識時にズレを制御・調整している、というものです ( Nature volume 421, 911(2003)) 。折角だから、リモートライブを提供する際、このような人間の特性を考慮して FPGA 上で画像と音声を統合配信してより臨場感が高めたらどうでしょうか。バンド側は時間の遅れを極最小にする方向で調整し必要に応じて音質は落とす。聴衆側はバンドの映像と合わせて、遅れの許容範囲でバンド全部の音を高品質にミックスして送る、とかね。ただ、その際には、音脈分凝なども気にすると良いかもしれません。
Y 君： 音脈分凝？それは何ですか？
先生 B： 人間の音認識機能のことです。音脈というのは書き言葉（文章）でいう文脈の音版です。単音のつながりと考えてください。分かりにくければ音符の繋がりと考えてもらって結構です。ドレミドレミドミソドレミレ、などですね。
Y 君： なるほど。楽譜と考えれば良いのでしょうか。では、分凝とは何でしょうか。
先生 B： 分凝は、文字通りの説明でしかなく、分けて集めなおすことです。化学や生物学などでも使われる単語です。つまり、音脈分凝とは、耳（鼓膜）に到着したときに一つの振動（信号の塊）として届いた音を、脳内で選り分けて、異なる音脈として認識しなおすという処理のことです。複数の人が同時にしゃべってもきちんと別の人が話したと認識するでしょう。交通量の多い道路の脇で話をしても、車の走行音と人の声を間違えないですよね。そのことを意味しています。
Y 君： 今まで考えたことはなかったですが、確かにそういう機能が自動的に働いているんですね。でも、その音脈分凝と今回の音配信の話が何と関係するのでしょうか。
先生 B： もう少し見てみましょう。音脈分凝だけでなく音の話は、NTT の Web ページがわかりやすいかもしれません。私が気にしたいのは音脈分凝において、時間間隔を狭めていくと音の高さの違いが音脈の認識に影響を与える、という部分です。過去、これをあまり考えずに、意図せず蝉の鳴き声発生器を FPGA で作ってしまったことがありました。
Y 君： 蝉の鳴き声とか鈴虫の鳴き声が作れる、というのであればそれはそれで需要がありそうですが・・・。ただ、今回の話で言うと、バンドのデータも詰め込めすぎるとあまり良くない、ということでしょうか。
先生 B： そうですね。時間があればデータの送信方式（プロトコルやデータフォーマット）も含めて、ライブストリーミングにより臨場感を持たせるような音配信方法を検討するのが良いと思います。図 4 のように出力デバイスが一つ (スピーカーないしヘッドホン) かつ繋がっている相手が 1 名だとあまり関係ないですが、繋がるメンバーを増やしたり、より大規模にオーケストラなどを対象にするようなら考える価値があると思います。
Y 君： オーケストラとはずいぶんとスケールの大きい話ですね。
先生 B： 企業で進めるなら大きな話も考えないと。そこにビジネスチャンスがあるかもしれません。また、これは通信部の話になりますが、聴衆向けに圧縮送信することは良いと思いますが、バンドメンバ間の通信は、遅延時間の方をより気にすると思うので、データを圧縮せずにそのまま送った方が良いかもしれません。CD 音源 (パルス符号変調：PCM) で 1.41 Mビット毎秒 (=1.35 Miビット毎秒 ) 程度、モノラルにしてラジオレベルに音質を下げれば、この通信速度を 1/8 まで下げることできます。
Y 君： ありがとうございます。ここまでの話をまとめると、サウンドインターフェースからの入力を FPGA で処理して、一方はバンド共有用にしたものをすぐ送信、もう一方は聴衆用に高品質なものを送信ですね。
先生 B： そうなりますね。他にもシステムの構成は考えられますが、それが一番シンプルだと思います。あと付け加えるなら、バンドメンバ間の音共有だけなら P2P 通信で良いですけど、沢山の聴衆がいるような場合は回線がオーバーフローするため、インターネット上にサーバを立ててそこから配信することになるでしょうね。
Y 君： 個人レベルで保有するパソコンに 10 名が同時に接続すると処理が間に合わなさそうですね。有名な無観客配信ライブが2020年6月にありましたが、あの規模でできるようなシステムが作れるといいなぁ、と思います。
先生 B：ぜひ、成功させ実現してください。おーっと、もうこんな時間だ。時間が押しているので、システムの話を続けると、音が遅れるのは仕方がないと思って、遅れた場合は届いていない音を予測して流してしまう、という考え方もあります。
Y 君： 届いてない音を流してしまうんですか？
先生 B：音の予測です。 映像関連だと、例えば GAN (敵対的生成ネットワーク) を用いて数秒先の映像を予測するという試みがマサチューセッツ工科大学などで既に報告されています。映像の方が研究としてインパクトがありますけど、実用としては、今回のような音声通信などから利用が進むかもしれません。また、メンバーがある程度固定されているので学習の範囲が狭くできること、またそれにより演算回路を小さくできる期待があること、を考えると会社に持ち帰って考えるのも一つではないでしょうか。探せば沢山の資料が出てくると思うのでここでの紹介は省きます。
Y 君： いろいろとアイデアが出てきますね。最初はそうしようかと思ったのですが、本日お話させて頂いて、限られた FPGA でも、何とかなりそうな気がしてきました。
先生 B： FPGA で利用できる回路規模が限られている、というところから考えたわけですが、話をしたようにいくらかは面白いことはできると思います。さて、最後に今までの議論をまとめて FPGA の規模に戻すと、図 1 ないし図 2 の紫の丸で示された FPGA でも十分かもしれませんね。これは、えーと・・・。
Y 君： Xilinx 社の 7-Seris Artix XC7A200T ですね。
先生 B： つまり、そのクラスの FPGA を中心に考え、P2P 通信をベースに UDP でデータグラム通信をするパートと、聴衆配信用として音源圧縮を加えたインターネット上のサーバと TCP/IP 通信するシステムが並行して動作。その精度や接続先数のサポートは回路規模に合わせて変える。また、ユーザ側が価格と性能を選択できる余地を残す。オプションとして、音飛び補償機能を提案し、それは GAN などに基づいた先読み補償回路によって実現され、製品のリアルタイム動作を保証する、かな。
Y 君： はい、十分です。あとは、社に持ち帰ってなんとかしたいと思います。
おわりに
会社への帰途、電車の中で准教授と話した内容のメモを見ながら改めて考えに耽る Y 君。バンドは自分の大好きなことだから、やりたいこと、やれないこと、技術的な問題点、それを解決するための提案、が次々と浮かんでくる。エンジンのかかった Y 君が世に出す製品はどうなるのか。仕事が楽しいのは良いことだけど、徹夜して不眠が続いたりすると健康に悪影響を及ぼすのでそんなことはないように。元気な姿で音を楽しむ姿を期待して・・・。
( 了 )
筑波大学 山口佳樹