SkyBeje開発記

SkyWayを使ったブラウザ間通信アプリを開発しています

ChromeのIndexedDB(2.0)に、限界までデータを登録してみました


 開発しているサービスでIndexedDBを使用しているのですが、現状のChromeの場合、どのくらいまでの容量を登録できるのか、また限界までデータ登録した場合、どのような動きになるのか不明だった為、検証してみました。

IndexedDB 2.0とは

 ブラウザに実装されているデータベースです。
 Indexed Database API 2.0 (日本語訳)

IndexedDBに限界までデータを登録してみました

 IndexedDBに、大容量データを登録できるサイトを作成して検証しました。
 https://skybeje.net/indexeddb_limit_test/  

 一応ソースはGitHubに置きました。
 https://github.com/iwatendo/Indexeddb_limit_test

 こんな感じです。
f:id:iwatendo:20180214235320p:plain

 

エラーハンドリングについてのメモ

 上記を作っていて、気がついた点のメモです。
 ・データ登録できなかった場合、DBRequest側のエラーは発生しない。
 ・データ登録できなかった場合、DBTransactionの「onAbort」が呼ばれる。
 ・その際に DBTransaction.errorに「QuoteExceededError」がセットされます。

検証してわかった事

 ・一定容量を超えると、IndexedDBにデータ登録できなくなる。
 ・IndexedDBに登録できるデータ量は、環境によって変化する。
 ・1つのサイトで限界までIndexedDBに登録しても、他サイトに影響は無い様子。

検証内容の詳細

 ストレージの容量が関係するらしいので、
 4台のPC(うち一台はタブレット)で、ストレージを確認しつつ検証しました。

f:id:iwatendo:20180214235643p:plain

1台目 Windwos10 Home(64bit) Version 1709  /  Chrome Version 64.0.3282.167

 ストレージ  Cドライブ 185G (残 64G) / Dドライブ 250GB(残 246GB)
 約12GBで QuoteExceededError が発生

 別ドメインにもテストサービスを配置して確認したところ、こちらも約12GBでQuoteExceededError が発生。最初に登録したサイトの12GBのデータは残ったままで、合計24GBのデータ登録できことになります。
 また、念の為Dドライブを外して試しましたが結果は同じでした。

2台目 MacOS High Sierra 10.13.3  / Chrome Version 64.0.3282.167

 ストレージ 121GB / 残 73GB
 約7GBで QuoteExceededError 発生
 こちらも別ドメインで、さらに7GB登録できる事を確認

3台目 Ubunth 16.04(スティックPC)/ Chrome Version 64.0.3282.167

 ストレージ 26GB / 残 16GB
 約1.1GBで QuoteExceededError 発生 

4台目 Android 7.1.1 ( タブレット / Nexus9 )/ Chrome Version 64.0.3282.137

 ストレージ14.56GB / 残 7.43GB
 約 688 MBで QuoteExceededError 発生  

Chrome  Developer Tools のクラッシュについてのメモ

  IndexedDBに大容量データを登録しても問題なく使用できる事は確認しましたが、大容量データを登録したテーブルを、Developer Toolsで確認しようとすると、以下のようなメッセージが表示され、ブラウザがクラッシュする場合があるようです。

f:id:iwatendo:20180215100638p:plain

 ※メモリ8GBのPCに、128MB×50件=6.4GBのデータを登録して確認した時に発生。

 

IndexedDBの保存先についてのメモ

 Windowsの場合、以下の場所に保存されるようです。
 C:\Users\(ユーザー名)\AppData\Local\Google\Chrome\User Data\Default\IndexedDB

 参考サイト:ChromeのIndexedDBの場所 (Mac・Windows) | EasyRamble


 私は普段 Visual Studio Code + Debugger for Chromeで開発していますが
 その場合の保存先は、以下の場所になるようです。

 C:\Users\(ユーザー名)\AppData\Local\Temp\vscode-chrome-debug-userdatadir_9222\Default\IndexedDB

 ※数値部分は環境によって変わるかもしれません。

IndexedDBの手動削除について

 前述のフォルダの下に、更にサイト毎にフォルダが生成されます。
 http(s)_(URL)_(port番号).indexeddb.leveldb

 一定サイズを超えるバイナリ(ArrayBuffer等)の場合は、blobに保存されます。
 http(s)_(URL)_(port番号).indexeddb.blob

 普段は特に意識する必要は無いと思いますが、今回いろいろ試してる際に Chrome側からテーブルを削除しても blobデータが消えない現象が発生しました。
 
 仕方ないのでChromeを落とした状態で、手動でフォルダ(.leveldbと.blobの両方)を削除してみたところ、特に問題なく削除できました。あまり推奨はできませんが、同じような現象が発生した場合に、手動で削除してみても良いかもしれません。

さいごに

  IndexedDBに大容量のデータを登録しても大丈夫かな?という漠然とした不安があったのですが、今回の検証で、まぁ大丈夫そうという印象になりました。他のブラウザでは検証してないですが、少なくてもChromeの場合は安定動作する感じです。
 
 というわけで、今後もIndexedDBをガンガン使っていきたいと思います。

2018/03/07 追記

 Google Chromeの場合、Developer Toolsで確認できるようになったみたいです。

f:id:iwatendo:20180307080711p:plain

SkyWayでChromeのバックグラウンドタブからのデータ送信が遅くなる現象について

はじめに

 表題の件について、現象は以前から認識していたのですが、ブラウザ側の問題と認識していて保留にしてました。

 TK (@TK11235)さんが開発している、ユドナリウムでもデータ送信速度が遅くなる現象が発生する様子で、ちょっと気になったので原因を調査してみました。

検証環境

Windows 10
Chrome 64
・SkyWay.js 1.1.5

データ送信(DataConnectionのsend)が遅くなる原因について

 ブラウザ側の仕様で、バックグラウンドタブの「setInterval」のウエイトが、最低1000msになるのが原因のようです。

 参考サイト:モダンブラウザのタイマー処理の制限をWebSocketを使って突破する(WebWorkersについて追記あり) (Kanasansoft Web Lab.)


 skyway.js内でデータ送信する際に「setInterval」を使用している箇所があります。
 ウェイトは1msを指定しているようなので、通常は数ミリ秒で送信されますが、バックグラウンドタブからの場合に、1秒間に1回しかデータがsendされないようです。

 そのため連続sendした場合にデータが溜まり、重くなるようです。

現象が発生する具体的なケース

 ユドナリウムの場合、プレイヤー間でPeer接続する場合に各種データを送信しあうと思うのですが、Peer接続される側のバックグラウンドタブ(または最小化状態)の場合、データ取得が少し遅れるようです。
 
 実際にユドナリウムを2つ開いて接続する事で、現象を確認できます。
(接続される側に、画像やチャットメッセージを少し登録して試すと体感できます)

 2つともフォアグラウンドタブの場合
 すぐに相手側のチャットメッセージが表示されると思います。

f:id:iwatendo:20180207230149p:plain

 

 接続される側(右側)がバックグラウンドタブ(または最小化状態)の場合
 チャットや画像が接続元(左側)に表示されるまで、約2~3秒掛かります。

f:id:iwatendo:20180207230931p:plain

 

 秒数的に、左側から右側のタブへ3回程sendしていると思われます。

 ちなみに私が作っているサービスでは、もっと遅延を発生させる事ができるのですがPC1台で再現させる手順が若干複雑なので省略します。

解決策案について

 SkyWay側の問題というより、ブラウザの仕様の問題とは思うのですが、skyway.js側で、なんらかの対策を入れて貰うと嬉しいので、対策を開発者コミュニティの方にお願いしてみたいと思います。

 

追記:
 SkyWayの開発者コミュニティでお願いした所、回答を頂けました。SkyWay側でサポートするのは難しいとの事ですが、対策方法等を教えて頂けました。また、私が実施した対策も書いてあるので、この問題で困った場合は、以下も参考にしてみてください。

support.skyway.io 

SkyWayの利用可能ドメイン指定とlocalhostでのデバックについて

はじめに

 SkyWayを使ったWebサービスを開発する際に、SkyWayのコンソールで「利用可能ドメイン」を指定すると思いますが、私は暫くドメインを跨いでの接続はできないと勘違いしていました。

 ドメインを跨いで接続できる事により、様々な方法でデバックできる事に気が付いたので、今回はその事について書きます。

 

SkyWayを利用した通常のWebサービスの動作イメージ

 はじめに、SkyWayを使ったWebサービスの動作イメージの簡単な説明をします。
 (Chromeのマーク=ブラウザです)

f:id:iwatendo:20180205164649p:plain

 Step1 各端末がWebサーバにアクセス。HTMLやJavaScriptを取得。
 Step2 各端末がSkyWayのサーバーにアクセス。各端末のブラウザを繋げます。
 Step3 ブラウザ間で通信します。

 ※実際にはもっと複雑ですが、大雑把にはこんな感じだと思います。
 

ローカルホストでの開発について

 開発時はローカルにWebサーバーを立てて、利用可能ドメインに「localhost」を指定して、開発するのが一般的だと思います。


その場合の動作メージは
f:id:iwatendo:20180205171518p:plain

 Step1 同一端末内でブラウザを2つ立ち上げ、ローカルWebサーバーにアクセス。
 Step2 各ブラウザがSkyWayのサーバーにアクセス。ブラウザ間を繋げます。
 Step3 ブラウザ間で通信します。


複数端末で、各自のローカルWebサーバーを使用してのデバック

 ここからが、私が最初気付かなかったデバック方法です。

 各端末が同一のAPIキーを指定していれば、それぞれのローカルWebサーバーのlocalhostに接続した状態でも、ブラウザ間で通信ができます。

f:id:iwatendo:20180205172623p:plain

 Step1 それぞれの端末で、各自のローカルWebサーバーにアクセス
 Step2 SkyWayのサーバーにアクセスし、ブラウザ間を繋げる
 Step3 ブラウザ間で通信
 
 この方法だと、Webサーバーを準備しなくても、複数端末を使ってのデバックが可能です。通常はこういったデバックが必要になるケースはあまり無いかもしれませんが、複雑な実装のデバックをする場合に、役に立つ事があるかもしれません。


ドメインを跨いでの接続

 SkyWayのコンソールの「利用可能ドメイン名」に、複数のドメインを指定すると別々のドメインにアクセスしたブラウザ間でも、通信が可能です。

f:id:iwatendo:20180205174036p:plain


 例えば、オンライン家庭教師のようなサービスを作る際に、生徒側がアクセスするドメインと、先生側がアクセスするドメインを別にするといった実装が可能です。

 また、生徒側のUIと、先生側のUIを、それぞれ別の形でも実装できます。


ドメインを跨いだ接続ができる事を利用したデバック方法

 前述のドメインを跨いで接続できる事を応用して
 ローカルホストと、Webサーバー間での接続もできます。

f:id:iwatendo:20180205174522p:plain


 接続イメージ

f:id:iwatendo:20180205174607p:plain

 Step1 2つのブラウザのうち、片方は外部のWebサーバーにアクセス
     もう一方はローカルホストに接続
 Step2 SkyWayのサーバーにアクセスし、ブラウザ間を繋げる
 Step3 ブラウザ間で通信


 ※但し基本的には localhost からのアクセスは許可しない方が安全だと思います。
 ※私は上記の形でデバックする場合、テスト用のWebサーバーを使用しています。


最後に

 こういった内容の記事を見かけた事がなかったので書いてみました。

 SkyWayを使ったサービスを開発している方や、今後SkyWay使ったサービスを開発してみたいと考えてる人のお役に立てれば幸いです。

 また何か気がついた点がありましたら、コメントかTwitterの方に連絡頂ければと思います。

SkyWayでSDPを覗いて対応Codecを確認してみました。

先日書いた記事の追記になります。

 


端末毎のCodecの確認方法について
SDPで判断できます。という情報をTwitterで頂きました。

SDP自体は何となく聞いた事があったので、なるほどと思い、早速確認してみようと思ったのですが、skyway.js の APIリファレンスを確認してもSDPが確認できそうな関数が見当りません。

JavaScript SDK APIリファレンス - SkyWay - Enterprise Cloud WebRTC Platform


ただ skyway.js を確認してみると「offer」や「sdp」のワードで大量にヒットします。
10,000行を超えるスクリプトなので、ちょっと見てすぐに理解できる代物では無さそうなのですが、とりあえず offerMessage や answerMessage を覗くと SDPを確認できる事がわかりました。

 

スクリプトのどの箇所のSDP確認するのが最適なのか判断できなかったのですが
以下の2箇所にコンソール出力処理を追加して確認してみました。

skyway.js(ver 1.0.1)の、Connectionクラス内(1,788行付近)

console.info("Connection HandleAnswer");
console.info(answerMessage.answer.sdp); 

 

skyway.js(ver 1.0.1)のMeshRoomクラス内(16,840行付近)


console
.info("MeshRoom offerMessage");
console.info(offerMessage.offer.sdp);


※作ったサービスはMeshRoomを使っている為、上記の箇所で確認しましたが
 SFURoomやPeerで直接の場合だと、別の箇所で確認する必要があると思います。

ビデオ通話が可能なケースのSDPを確認

PC側 Chrome / Mobile側 Nexus9
※DevToolsでMobile側のConsoleログを確認しています。

Mobile(Nexus9)側で確認したログ (MeshRoom OfferMessageのSDP)
VP8 / VP9 / H264 の表記あり。Chromeの対応Codecが表示されていると思われます。

f:id:iwatendo:20171122163617p:plain


PC側(Chrome)で確認したログ(Connection HandleAnserのSDP)
VP8 / VP9 の表記あり。Nexus9の対応Codecが表示されていると思われます。

f:id:iwatendo:20171122163626p:plain

 

ビデオ通話ができないケースのSDPを確認

PC側 Sfari / Mobile側 Nexus9

Mobile側で確認したログ (MeshRoom OfferMessageのSDP)
H264の表記のみ。Safariの対応Codecが表示されていると思われます。

f:id:iwatendo:20171122165128p:plain

同時に skyway からエラーメッセージの出力されていました。

PC側(Safari)側では、Video/AudioのSDPメッセージ出力はされていませんでした。

結論

 SDPの読み方は理解していないのですが、予想どおりSafariはH264のみ対応だけれども、Nexus9はH264に対応していないため動作しないという事で合ってそうです。

 上記のような感じでSkyWayでもSDPは確認できるようですが、プログラムから対応Codecを判定する為には skyway.js の改造が必要になりそうです。
 skyway.jsはオープンソースなので、きっちり改造してプルリクを出してみたりしても良いのかもしれません。(私はそこまでやれるスキルと自信が無いですが)

 とりあえず、未対応Codecの場合はエラーが発生するようなので、skywayのエラーを拾えるようであれば拾って、未対応端末と表示する方針にしようかなと思っています。

最後に

 SafariのWebRTCがH264にしか対応しないと聞いたときは、よく分かってなかったのですが、色々とやっかいですね。

 現状だと、iOS端末とAndroid端末で、モバイル端末のブラウザ間でビデオ通話する場合は、Android端末がH264に対応している必要がありますが、AndroidはブラウザではH264に対応できない端末が多いらしいです。

 私はスマホアプリの開発経験がなかったりするのですが、スマホ対応は色々考えることが多く、更には機種差分もあったりして難しいですね。色々と全部ブラウザだけで実現できたら良いのですが、現状なかなかそうもいかないようです。


何か気になる点等がありましたら、コメントかTwitterの方に書いて頂ければ嬉しいです。

SkyWay(WebRTC)を使ってスマホとPCでビデオ通話するサービスを作った時にハマった箇所のメモ

 少し前に、iOS11のSafariがWebRTCに対応したので、iPhoneでのWebRTCの動作検証も兼ねて、前から作ってみようと思っていたSkyWay+GoogleMapのサービスを作ってみました。 
 

~ 現場から中継お願いします!~

f:id:iwatendo:20171120103607p:plain
f:id:iwatendo:20171120102118p:plain

 

 パソコンで上記のページを開いて、QRコードスマートフォンで読み込むと、パソコンとスマホでビデオ通話ができます。同時にスマートフォン側の位置が、GoogleMapで表示されます。現状は機能的にシンプルな感じですが、気まぐれに機能を拡張したいきたいと思っています。

 地図表示は調べれば大量にサンプルがあるので問題無く作れましたが、iPhoneでビデオ通話する部分の実装は結構苦労しました。作っていてハマった箇所と、それに対して実施した対策、未解決の問題について書いていきたいと思います。

最初に

・GoogleMapについては詳しく書く必要は無いと思われるので省略します。
・私はWebRTCの深い部分の知識は無く、SkyWay頼みで作っている感じです。

検証端末

パソコン側
 ・Windows10 / Chrome 62
 ・MacOS 10 / Chrome 62 / Safari 11

スマホ / タブレット
 ・iPhone7(iOS 11.1.1 / Safari)
 ・Nexus9 (Android 7.1.1 / Chrome)

ハマった箇所1: 同一デバイスでの複数のMediaStream

 Android(Chrome)の場合、一つのデバイスを複数のMediaStreamに利用できました。
 iPhone(Safari)の場合:一つのデバイスを複数のMediaStreamに利用できない様子。

 Android(Chrome)のみに対応していた時の実装

  プレビュー用: MediaStreamConstraints = { video: true }
  送信用: MediaStreamConstraints = { video: true, audio: true }
  の2つのMediaStreamを作ってました。(そもそもこの方法が非効率?)


 以下のように修正したところ、動作するようになりました。

  MediaStreamConstraints = { video: true, audio: true } で1つだけ作成し
  プレビューと送信用の両方に使用するようにしました。
 (プレビュー用のVideoタグには、mutedを付けました。)

ハマった箇所2: MediaStreamConstraintsの指定

 SkyWayJSの話になりますが、MeshRoomにJoinRoomする際に、Audioのみを指定していると音がでませんでした。
(今回の作ったサービスは1対1の接続なのでMeshRoom使わなくても良いのですが、楽したい為にMeshRoom使ってます。Peerで直接繋ぐと大丈夫かもしれません。)

 対策として、使わなくてもVideoを指定する事にしました。
 修正前:
  パソコン側:MediaStreamConstraints = { audio: true }
  スマホ側: MediaStreamConstraints = { video: true, audio: true }
 修正後:
  どちらも、 MediaStreamConstraints = { video: true, audio: true }

 この件については、SkyWayの開発者コミュニティに同様の問題の報告が上がっています。MeshRoomやSFURoomに接続する時に VideoとAudioを使ってる人と、Audioだけの人が混在すると上手く動作しないケースがあるようです。

 最初はスマートフォン側にはパソコン側の映像を表示しない方針で作っていたのですが、ダミーでvideoを送るくらいなら、映してしまおうと思い方針を変えました。

 ハマった箇所3: iPhoneでの音量調整

iPhoneの場合、Video / Audioタグを使った場合、Volumeを変更しても音量が変わりませんでした。そのためiPhoneの場合は、WebAudioを使うようにしてみました。

但しWebAudioも、Android(Chrome)とiPhone(Safari)で挙動が違うようです。
Androidの場合はVideo/AudioタグのVolumeで音量調整ができていたので、Safariの場合のみWebAudioを使う実装にしました。

気になる点として、iPhoneの場合はハードウェアキーでの音量調整ができません。
画面上のスライドバーでのみ音量調整が可能な状態です。

追記)iOS11.2で、Video/Audioタグを使った場合でも
   ハードウェアキーで音量調整ができようになったようです。

ハマった箇所4: TrackStartErrorの発生

 Nexus9にて、getUserMedia 時にエラーが発生し、プレビュー画面が表示されないケースが頻発しました。確認してみると、MediaStreamError(name="TrackStartError")が発生していました。

 エラーが発生している原因は不明なのですが、何度かリトライすると成功する感じなので、1秒毎にリトライ(5回まで)する事で対応しました。
 デバックして確認すると1~2回のリトライで成功する感じでした。

ハマった箇所5: アプリ内ブラウザ(WebView)での挙動

 LINE等のアプリから起動すると、標準ブラウザではなくアプリ内ブラウザ(WebView)で起動されます。その場合にgetUserMediaが動作しないケースがあるようです。

 ・iPhoneのLINEの場合、そもそも getUserMediaが無いというエラーが発生。
 ・AndroidのLINEの場合、権限が無いというエラーが発生。
 ※Androidの場合は起動できるアプリもあるようです。


SafariのWebViewは、getUserMediaは未実装らしいですし、Androidの場合は、各アプリ毎に権限の設定がされていてユーザー側からは変更できないと思います。

どうしようも無いので、getUserMediaに失敗した場合は
「標準ブラウザを起動してください」と表示するようにしました。

ハマった箇所6: iPhoneのフリーズ

 iPhoneにてパソコン側から送られてきた映像をピンチアウト(2本の指での拡大)等をしてVideoタグがディスプレイの幅からはみでた場合に、iPhoneがフリーズする場合があります。(iOS側のバグと思われます)

この件については、SkyWayの公式サイトにも記述があります。
https://support.skyway.io/hc/ja/articles/236202427


 作っているサービスは、PC側から送られる映像は小さく表示していたので、暫くこの問題に気がつきませんでした。
 何度かフリーズさせてみた感じでは、PC側の映像の動かない状態で、左側にVideoタグがはみ出た場合に、フリーズする可能性が高いように感じました。仮想Webカメラ(MenyCam)を使ってテストする事が多いのですが、MenyCamの初期画面の場合にフリーズしやすい感じでした。


 スマホがフリーズしてしまうのは流石に致命的な問題なので、暫定対応として拡大/縮小ができないようにしました。

 この問題が完全に修正されるまで、怖くてサービスの公開はしづらい気がします。
 修正されたとしても、iOSのバージョンチェックして、古いバージョンは弾くような実装にしないとまずい気もします。

追記)iOS11.2でフリーズする不具合が修正されたようです。

未解決の問題1: 端末ごとの対応Codec

以下の4パターンのうち、最後のパターンはPC側に映像が表示されませんでした。

 1.PC側 chrome / Mobile側 iPhone ○
 2.PC側 chrome / Mobile側 Nexus9 ○
 3.PC側 safari / Mobile側 iPhone ○
 4.PC側 safari / Mobile側 Nexus9 ×

 これについてはコーデックの問題ではないか予想し、試しにMeshRoomの接続オプションで'H264'を指定してみたところ、パターン2とパターン4で表示されなくなりました。この事から、Nexus9がH264のエンコードに対応してないのでは?と思っています。(safariのWebRTCは、H264しかサポートしてないらしいです。)

 裏付けをとりたいのですが、対応端末がH264のエンコードに対応しているかわかる資料や、確認する為の方法を見つけることができませんでした。可能であれば、JavaScript上でチェックできるようにしたいです。


追記:時雨堂のVさんからコメント頂きました。SDPで確認できるとの事です。
   Vさんありがとうございました。

 追記2:上記について確認してみました。

iwatendo.hateblo.jp

未解決の問題2: Safariでのデバイス名称取得について

 マイクやカメラのデバイス名称の取得する為に、navigator.mediaDevicesを使用しているのですが、safariは未対応で名称取得できないようです。
 https://developer.mozilla.org/ja/docs/Web/API/Navigator/mediaDevices

 PC側で、仮想カメラ(MenyCam/CamTwist) や仮想マイク(NETDUETTO)を使いたいので、デバイス名称は表示したいんですよね。

未解決の問題3: アプリ切替時の映像表示

 現状、スマホで別のアプリに切替えて戻ってきた時に、パソコン側の映像が消える場合があります。ただ数十秒待ってると表示されるようになります。
 これについては、対策をこれから考えようと思います。

未解決の問題について

 未解決の問題1と2については、PC側はChromeを使えば問題無いです。

 Windowsユーザーの場合はSafariは利用できないですし、MacユーザーでもChromeは使えます。また、Safariは現状スクリーンシェアに対応していません。PCのスクリーンシェアをスマホに表示する事も考えているのでChromeの方が何かと都合が良いです。

 上記のような理由で、PC側のブラウザはChrome推奨としています。
 Safariでも使えなくは無いけれど機能制限あり。という方針で作ってます。

最後に

 SafariがWebRTCに対応したのがつい最近です。WebRTC(及びSkyWayの)Safari対応の資料や記事がまだまだ少ない状況なのでけっこう苦労しました。また、もっと良い実装方法もあるように思いますし、Safari側の修正や、SkyWayのSafari対応で変わっていく部分もあると思います。

 ただ、色々と試行錯誤した内容が残っているだけでも、これからWebRTC(SkyWay)を使ったスマホ向けサービスを作る人の参考になるかもしれないと思いましたので、書き残しておく事にしました。

何か気になる点がありましたら、コメントかTwitterの方に書いて頂ければと思います。

 

音声合成をボイスチャットで使う仕組みを作ってみました

グループ通話またはライブ配信する際に、チャット入力した文章を音声合成してマイクに流す仕組みを作ってみました。

基本的には、開発中のSkyBeje用に作ってみた仕組みですが、SkypeやDiscordの音声通話にも応用できると思います。


以下の3種類の音声合成を、ボイスチャットに使う仕組みを作ってみました。

・定番の音声合成ソフト「棒読みちゃん
株式会社エーアイAITalk
HOYA株式会社VoiceText

 

 (注意)AITalk / VoiceTextについては、無料で試せるWebAPIを使いましたが、この2つは、商用利用禁止・二次利用禁止のWebAPIです。基本的には開発や検証目的として公開されているAPIとのことですので注意してください。詳細については、それぞれのWebAPIの利用規約を参照してください。

 

棒読みちゃん」の音声をマイクに流す仕組み

棒読みちゃんの音声をマイク代わりに使う方法は、以下を参考にさせて頂きました。
棒読みちゃんをマイク代わりに使う : らいっちのPC奮闘記

 

棒読みちゃんのインストール方法や設定方法、仮想マイクデバイス(NETDUETTO)については、上記ページを参考にしてください。ちなみに上記ページはSkype用として説明されていますがDiscordにも適用できると思います。

SkyBejeとの連動については、棒読みちゃんの標準プラグインにある「クリップボード監視」機能を使ってみました。

f:id:iwatendo:20171105111042p:plain

 

SkyBeje側の設定

f:id:iwatendo:20171105111057p:plain


あとは、グループ通話のマイクデバイスに「NETDUETTO Driver」を選択します。

f:id:iwatendo:20171105162918p:plain

 

 ライブ配信する場合も同様で、マイクに「NETBUETTO Driver」を選択します。

f:id:iwatendo:20171105163039p:plain

 

これで自分のチャットの発言が、棒読みちゃんの音声でマイクに出力されるようになります。(ただし、他の人のメッセージの読上げはできません)


音声合成API(AITalk / VoiceText)を使ってボイスチャット

色々調べてたら、VoiceTextを再生できる棒読みちゃんプラグインを作られている人がいました。(Voiceroid Talk Plusというプラグインも作っている人です)

Voicetext Talk Ver1.5.0.0:Wangdora Eve. - ブロマガ


最初、このプラグインでいけるかなと思ったのですが、プラグイン側で音声を標準デバイスに出力しているとの事で、棒読みちゃん側で設定したデバイスには出力できない仕様のようでした。

 

バイス指定の他に、音声パラメータも指定したかったのでツールを自作しました。
github.com

 

詳細は上記のGitHubのページを見て貰いたいのですが、少しだけ補足です。

AITalk と VoiceTextには感情パラメータというのがあります。上記ツールではVoiceTextは感情パラメータを指定できるようにしたのですが、AITalkでの感情パラメータの指定方法が不明だった為、上記のアプリからは指定できません。(WebAPIからは指定できないのかもしれません)

他、SkyBejeは複数のアクターやアイコンを登録できて、切り替えながら発言することができます。アイコンごとに音声パラメータを設定できるようにしたので、喜んでいるアイコンに対しては喜んでいる音声パラメータを、怒ってるアイコンに対しては怒っている音声パラメータを設定するようなことができます。

 

現状の設定画面はこんな感じです。
f:id:iwatendo:20171105232630p:plain

 

チャット画面はこんな感じでアイコンを切替えながら発言できますが、同時に音声パラメータも切り替わって音声合成されます。 (右側はアイコン毎の音声パラメータです)

f:id:iwatendo:20171106090705p:plain

 

問題点や懸案事項

上記のプログラムを作る前から、AITalk / VoiceTextのWebAPIが「商用利用禁止」というは把握してたのですが、オープンソースとしてGitHubに公開するし、広告とかも入れないので、遊び用途なら問題ないと考えていました。

しかし、GitHubのReadMeを書くタイミングで、しっかりと利用規約を確認してみたところAITalk / VoiceText両方の利用規約に「無料でもウェブサイトに一般公開した場合は商用とみなす」的な記述があり、これは多分遊び用途で気軽に使っちゃダメなやつだ、と気が付きました(笑)

ただ、利用規約で曖昧部分もあって、判断に迷う部分があったので、そこは問合せてみようと思ってます。

 

また、これも後で気がついたのですが、Windowsのネイティブアプリの場合だと、APIキーの扱いに困ります。GitHubにコミットするソースにはAPIキーは含めないとしても、ビルド時にAPIキーをバイナリの中に含めてしまえば、逆アセンブルすればAPIキーが拾われてしまう可能性がありそうですし。。

 

上記のような問題もあって、個別にAPIキーを設定するようにしてるのですがAITalk(DocomoDeveloper Support)の場合は、サービスやアプリの単位でAPIキーを発行する感じで、個別に発行するようものでも無いようなんですよね。(VoiceTextの場合は、個人に対してAPIキーを発行している感じなのですが)

 

さいごに

と、まぁ色々と問題はあるのですが、ASP.NET用とか、社内で使うツールとかに応用できなくはないかもしれないと思い、プログラムはGitHubに置いておく事にしました。

最後まで読んでいただき、ありがとうございました。
ご質問やご意見がありましたら、お気軽にコメントしていただければと思います。

SkyWay Developer Meetup #1に参加してきました。

9月29日に上野で開催された、表題のイベントに参加してきました。
復習も兼ねて、各種資料やまとめのリンクを集めてみました。

以下、SkyWay Developers Meetup #1 で、発表時に使われたスライド資料です。

SkyWayの目指す世界

 SkyWayを使いこなすために

 LT : iOSでのSkyWay開発の勘所とTips

 LT : Skywayのビデオチャットを録画しよう。そう、ブラウザでね

 

 LT : SkyWay JS SDKの歩き方

以下のリンクから、LTの資料が見れます。
SkyWay JS SDKの歩き方


上記のLT発表者の leader22 さんのブログです。
Q&A大会のメモも残ってて、素晴らしいです。

 

LT:SkyWay × cognitive service

 

Togetterまとめ

 

雑感

こういったイベントに参加するのは初めてだったのですが、非常に勉強になりましたし、良い刺激を受けました。SkyWayの開発者の方と直接を話をする事もできましたし、SkyWayを使ったサービスの開発者同士の繋がりも作れるイベントでしたし、もっと早くこういったイベントに参加すれば良かったな・・と、しみじみ思いました。

ちなみに私は岩手県に住んでますが、行く前は「岩手から参加するのは、きっと私ぐらいだろ~」とか思ってたのですが、他にも岩手から参加してる学生さんがいて、しかも立派にLTしてて驚きました。(内容も面白くて興味が湧くものでした)

次回も参加できそうであれば、是非また参加したいと思えるイベントでした。
ただ、時期にもよりますが、岩手から毎回行くのは色々と厳しい(笑)

前回のWebRTC Meetup Osakaでは、appear.inを使って、東京と大阪を繋いでたみたいですが、あんな感じで地方からも、もっと勉強会やイベントに参加できるようなったら嬉しいですね。

その為にも、もっとSkyWayを色んな人に知ってもらいたいですね。
同業者の知り合いに、私が作っているサービスを見せながら、SkyWay(WebRTC)を使うとこんな事ができるぞ~と布教はしているのですが、なかなか仕事には繋がりません。まぁ私が説明ヘタっていうのもあるのですが(笑)

 


その他、会場で頂いたSkyWayのシールをノートPCに貼ってみました。

f:id:iwatendo:20171001194403j:plain

中央のシールがちょっと斜めになってるのは、りんごマークを隠すように貼った為。
シールを貼る時に気がついたのですが、このロゴは空に道が続いてるのを表してるんですね。

 


さて、Meetupで刺激を受けてやる気が沸いてきたので、作ってるサービスの開発頑張ります!