自作でVideo Chat環境を作って導入した話 〜改善・課題編〜

「SEROKU フリーランス(以下、SEROKU)」の中の人をやっている ryosuke です。

今回は導入した Google Hangouts の機能をベースに、もう少しWESEEK社での用途向きに使いやすく調整した話と、失敗談、今後の展望の話題をします。

もう一歩のところをちょっと便利に

Video chatの選定、構築、設置まで済みましたが、これを毎日使うにはちょっと手間でした。何が手間かというと映像が出てくるまでに、

1. PCの電源を入れる
2. ブラウザを起動する
3. ブラウザでgoogle hangoutsのmeeting roomを選ぶ
4. 参加ボタンを押してmeeting roomに参加する

という作業を毎回する必要があるからです。

「その程度、やればよいのでは？」という意見もありそうですが、毎日毎日同じ作業をしなければならないのはなかなか面倒になってくるものです。そこで、上記の作業を一発でできるようにいくつかのギミックを導入しました。

[adinserter block="1"]

SlackからPC起動

WESEEK で使用している Slack には ruby で code を書くことで機能を自由に追加できる bot である lita を導入しています。このbotに機能を追加し、「九州と接続開始」と発言するとVideo Chat用のPCを起動するようにしました。botからPCを起動するのには Wake On LAN を使用しています。

ブラウザの自動起動

これは単純な手段を用いました。Video Chat用PCが起動したらブラウザが自動起動するようにしておきます。Windowsでいうところのスタートアップに登録する方法です。

サーバ用途のubuntuマシンでdaemon processを起動する際はsystemdなどに起動したいprocessの設定をしますが、今回はGUIが必要なアプリケーションを起動しますので、 Gnome が持つ autostart の機能で、ブラウザを起動するようにしました。

meeting roomに自動入室

Google Hangoutsではmeeting roomに名前を付けることができます。そしてこのmeeting roomへの直接リンクを生成することができるので、ブラウザのホームページにmeeting roomへのリンクを設定してしまえばおしまい。・・・ではありませんでした。直接リンクにアクセスしても実際にmeetingに参加するには画面に表示される「参加」ボタンをクリックする必要がありました。

PC起動からmeeting room入室直前まで到達してて、最後の一手でマウス操作が必要というのも癪です。そこで、ブラウザの操作も自動でできるようにしました。今回は、Selenium という Web Browser Automation Tool を使って「参加」ボタンが表示されたら自動でクリックするようにしました。

これでSlackに「九州と接続開始」と発言するだけで、別府オフィス - 本社 間の接続が簡単にできるようになりました。

Video Chat退室、PC切断もslackから

ここまでやるとPCの電源を切るのもslackから操作したくなります。これも lita に「九州と接続終了」と発言するとPCの電源を切るようにしました。 bot からPCの電源を切るために、PCにSSHでログインしてshutdownを実施するようにしています。

これらの対応により、社員ならば誰でも簡単にVideo Chatを接続することができるようになりました。

[adinserter block="1"]

Video Chatシステム、運用中に気付いた罠

ここまで紹介してきた、Video Chatシステムの導入ですが、実は全てが順調に進んだわけではありません。導入後に割とハマった落とし穴を紹介します。

googleアカウントが定期的にlogoutしてしまう問題

Video Chat に Google Hangouts を利用していますので、専用PCのブラウザでは Hangouts 用の googleアカウントで事前にログイン状態にしてあります。こうすることで、PC自動起動の際に毎回googleアカウントのパスワードなどを入力する工程を省略しています。しかし、たまにgoogleアカウントでログインしていない状態になることがありました。そのときは仕方なく人手でパスワードを入力し、ログインし直すようにしていました。

発生頻度を調べてみると、1回/月のペースで発生していることがわかりました。どうやらgoogleアカウントの仕様らしく、定期的な再ログインは回避できなさそうでした。

現在のところ1回/月の頻度でしか発生しない問題でしたので、特に対策はせずに必要になったら都度パスワードを手動入力する運用にしています。

マイクにAGCが効いていると相手の声が聞こえなくなる問題

遠隔で議論をしているとき、相手が長い間発言中に10秒ほど経過したあたりから唐突に相手の声が聞こえなくなる事象が頻発しました。しかしこちら側が「聞こえない」などと少しでも発言するとすぐに相手の声が聞こえるようになります。不可解な挙動にみえたのですが、詳細に調査してみると以下の挙動が相互作用していたのが原因でした。

• Google Hangouts が使用しているエコーキャンセラーは、相手側が発言しているときはこちら側のマイク入力をカットする
  • Hangouts は WebRTC という規格を使用してリアルタイムコミュニケーションを実現しています。そして WebRTC は Chrome に搭載されているため、Chrome で Hangouts が使えるようになっています。 Chrome の WebRTC 実装には AEC (Active Echo Cancellation) が搭載されています。これはスピーカーが発した音をマイクが拾うことで発生するエコーやハウリングを回避するための機能です。 Chrome の AEC では相手が発言中にこちら側のマイクの入力をカットすることで、エコーを回避しているようです。
• マイクを接続するとOS(ドライバ)側でAGCがdefaultでONになっている
  • マイクの入力音量を一定に保つために AGC (Auto Gain Control) という機能が搭載されています。マイクに近づいて発言した時と少し離れて発言した時はかなりの音量差が発生してしまうのですが、AGC はその差を緩和するような働きをします。
• 購入したスピーカーマイクはマイク入力に割と大きめのノイズがのる
  • 採用したスピーカーマイクの MM-MC28 は安価でありながら、マイク・スピーカーを搭載し、更にエコーキャンセラーも内蔵しているお値打ち品です。ですが搭載しているエコーキャンセラーによる影響か、比較的大きめのノイズが常時入力されていました。といっても、マイクの近くに座って発言している分には支障のないS/N比は確保できています。

この3つの要素がどのように悪さをしていたかというと、

1. 相手(以降Bと表記)が長期間発言をする
2. こちら(以降Aと表記)は発言せずに、Bの発言に耳を傾ける
3. スピーカーマイク搭載のエコーキャンセラーの働きにより、Aのマイクにはスピーカーから発せられたBの音声は入力されない
4. A側では目立った音声の入力がないため、OSのAGC機能によってマイクの入力音量が次第に大きくされる。
5. A側のスピーカーマイク固有の入力ノイズが大きくなる
6. A側のノイズが十分大きな入力となり、 Bの Chrome の AEC はAが発言していると判定しBのマイクの入力をカットする
7. Bの声が聞こえなくなる
8. Aの人間が異変に気付き「聞こえない」と発言する
9. A側でノイズに比べて大きな音声入力が発生したのでOSのAGC機能によってマイクの入力音量が下げられる。
10. 「聞こえない」の発言が終わった直後、十分大きな入力はなくなるためBの Chrome の AEC はAは発言をしていない状態と判定しBのマイクの入力を再開する
11. Bの音声が聞こえるようになる

という流れの繰り返しによって問題が起きていることがわかりました。

以下の2つの対応をすることで、この問題を解消は解消することができました。

• OS の AGC を OFF にする
• Chrome の AEC を OFF にする

スピーカーマイクの耐久性

通常の会議であれば、1回の使用時間は短めだと思います。しかしWESEEKでの使い方では1日8時間近く毎日連続使用しています。そのせいもあってか執務室で使用しているスピーカーマイクは半年ほどでスピーカーに大きなノイズがのったり、音声が出力されないといった不具合が発生してしまいました。保証期間中の故障ということで新品と交換を行ったのですが、数ヶ月使用していたところ、同じような不具合の予兆が発生しています。一方で使用時間の短い、会議室に設置している同型のスピーカーマイクは特に不具合なく動作しています。もしかしたらメーカーとしてはWESEEKでの長時間使用するような使い方は想定外なのかもしれません。

[adinserter block="1"]

今後の展望

上記で紹介したようにトラブルや課題も発生しつつ、すでに半年以上の運用を続けており、Video Chatシステムを使用した拠点間のコミュニケーションについては一定の成果を果たしています。しかし、まだ完全な理想状態ではありません。よりよいコミュニケーションを支援し、業務が円滑に進むためにも、今後も少しずつ改善を行おうと考えています。最後に今後の改善予定についてご紹介します。

大画面化

現在は27inchのディスプレイを使用しています。別府オフィスはまだ人数が少ないですのでまだ小さめのディスプレイでも問題がありませんが、今後人数が増えた時に画面が手狭になり、メンバーの顔が見えなくなってしまいます。

最近はTV用の大型ディスプレイが安価に入手できるようになりましたので、50inch超のディスプレイを導入しようと考えています。

高画質化

解像度が1920x1080のカメラを使用していますが、 Google Hangoutsでは映像は1280x720に縮小して転送されます。カメラ1つにつき1人の顔を映せばよいのであれば現状の画質で問題ありませんが、本来は各々の執務室全体を映すような仕様の仕方を想定していますので、より高精細である方が用途に適しているといえます。

現状のHangoutsでは1280x720が上限ですので、Hangoutsのスペックアップを待つか、1920x1080で転送できる他のサービスに乗り換えるかが必要になる見込みです。

複数カメラの切り替え

普段は執務室全体を映す状態で構わないのですが、例えば遠隔での議論中にホワイトボードに書きながら話を進めたいことがあります。このような場合、現状ではカメラを移動することで対応しています。が、それも次第に面倒になるものなので、ホワイトボードが見える位置にカメラを追加し、簡単に表示切り替えができないか検討しています。

高音質化

スピーカーマイクを導入していますが執務室に1つずつしか設置していません。そのためマイクから遠くの人の発言を拾うには不十分なのが現状です。スピーカーマイクをカスケード接続して複数個所に設置できるような製品もありますので、導入を検討しています。

[adinserter block="1"]

まとめ

いかがでしたか？拠点間のコミュニケーションロスによる業務進行への悪影響を最小化すべく導入した Video Chat システムについて、全3回にわたってお送りしてきました。皆さんのコミュニケーションの在り方や改善策の検討に参考にしてみてください。

 

＞自作でVideo Chat環境を作って導入した話 〜経緯編〜
＞自作でVideo Chat環境を作って導入した話 〜選定編〜

 

 

 

ryosuke
profile:正確無比な開発マシーン。