音楽用低遅延リモートコミュニケーションサービス・プロダクト構想

いろんな状況から、音楽関係のひとびと(アーティストとは限らない)もリモート・遠隔でレッスンをしたり、セッションをしたりアンサンブルをしたい気持ちが高まっている。現状存在するZOOMやSkypeが主に使われているけれど、どちらも、そしてほかのほとんどのプロダクト・サービスも音楽用には作られておらず、音質が不十分で遅延が大きいために使いづらい。このサービスorプロダクトはそれを解決し、離れていても隣にいるような、音楽的に心地よい環境を提供することを目的とする。

(画像はこちらの映像を拝借しました - Le Boléro de Ravel par l'Orchestre national de France en #confinement #ensemble àlamaison)

#earthMetronome ← 共通タグです。

用途

音楽レッスン、アンサンブル、他拠点同時パフォーマンス、等

必要条件

・低遅延 - ZOOM/Skypeが170 - 200ミリ秒(片道)なのでそれ以下

・高音質 - 48KHz/16bit ステレオで音楽再生可能 (低遅延モードと選択的？)
・マルチプラットフォーム - PC, Mac, iOS, Android
・低コスト - クライアント・サーバーとも
・(Optional) オープンプラットフォーム/機能付加可能 (音声＋タイムスタンプまたはクロック付きリアルタイムデータストリームをベースとする)

動画は低ビットレート、もしくは紙芝居的に限定。

要素技術

・音声コーデックOpusまたはその派生コーデック

Opus Codec

・WebRTCまたはそれに代わるリアルタイムコミュニケーションプラットフォーム

WebRTC

検討機能

・音声最優先モード(動画はコマ落とし等でとにかく音声低遅延・高品質優先)
・テンポ情報/ クロック(MTC)伝送(ジャムシンク含む)
・URL情報とクロック伝送 (使用例: YouTubeなどの共有データ同時・同期再生)
・高音質レコーディング / 再生(両端で高音質レコーディングし、クロックに従って同時再生するなど)
・音程→MIDIデータ化→低遅延データ伝送(UDP、 <10mSec + ネットワーク遅延)→リモート再生→アーカイブ
・マルチチャンネル伝送(2ch以上、片方向のみ？)
・スコアの共有・スコア上でのアノテーション

技術検討課題

・既存のサービス・クライアントで使えそうなものはないのか？
目的は開発ではなく、既存のリモート音楽環境を改善することである
・SDK/フレームワーク調査
・ライセンス調査
・VPN/閉域リモートネットワーク下の制限
・専用ハードウェア - さらなる(業務向け)低遅延高品質伝送 - 入出力AES、S/PDIF、I2S + MIDI(MTC)とか

現時点の調査進捗

時雨堂さんが提供しているWinRTCを使用したMac / Unix / Windows のコンソールベースのOSSネイティブクライアント (github上にリポジトリあり)をとっかかりにしてWebRTCおよびそこでの標準音声圧縮コーデックOpusを調査中。

株式会社時雨堂

WebRTC Native Client Momo

これを使用して(audioのみで)遅延測定すると

210ミリ秒(最初のZOOMなどの遅延測定方法と同じ)。Skype(クライアント)とほぼ同じ。ZOOMより遅い。

ただ、以下のように、audio processingなどを全部キャンセルした状態では、

c:\>momo --no-video-device 
  --disable-echo-cancellation 
  --disable-auto-gain-control 
  --disable-noise-suppression 
  --disable-typing-detection 
  --disable-residual-echo-detector 
  ayame wss://ayame-lite.shiguredo.jp/signaling xxxxx-unique-code

130ミリ秒達成。この辺がネットワーク＋コーデックによる圧縮・伸張にかかる素の状態だと思われる。

WebRTCとOpusの調査(コードレベル)

WebRTC API / getUserMedia

https://www.w3.org/TR/mediacapture-streams/

指定できる constraints の中身およびブラウザ毎のサポートレベルはこれが詳しい。

WebRTCで開発者が利用できるオーディオ関連の設定 - Qiita

↑の原典？はこちら。

Supported Audio Constraints in getUserMedia()

sampleRate: specifies a desired sample rate, not sure if it should be used as an encoding setting or as a hardware requirement, higher is better (Audio CDs for example have 44000 samples/s or 44kHz)
sampleSize: each sample’s size in bits, higher is better (Audio CDs have a sample size of 16 bits/sample )
volume: it takes values between 0.0 (silence) and 1.0 (max volume), it’s used as a multiplier for each sample’s value
echoCancellation: whether or not to use echo cancellation to try and remove the audio that went to the speakers from the input that comes through the mic
autoGainControl: whether or not to modify the volume of the input from the mic
noiseSuppression: whether or not to try and remove the background noise from the audio signal
latency: specified in seconds, controls the time between the start of the sound processing and the data being made available to the next step, not so sure why you’d want higher latency but audio codecs do differ in latency
channelCount: specifies the number of channels to use with 1 being mono, 2 being stereo. It works with some webcams and laptops with dual mics.

考察：音楽専用にすると考えると、エコーキャンセラー、ゲインコントロール、ノイズサプレッションはデフォルトオフで、音量は送る側が「聴きながら」制御できるとマル。もしくはウィザード的に設定する。イヤフォンを前提にすればエコーキャンセラーは不要(か？)。

Opus エンコードの仕様

Opus: Opus Encoder

2.5mSecフレームモードが存在する (WebRTCでは10mSecフレーム使用)

また、音声品質・遅延量を考慮した voip / audio / restricted-lowdelay の3モードが存在する。

Next Action Items

・WebRTCのオプションによる遅延・音質の変化を検証 : 100mSec以下にできそうかどうか→プロトタイプA
・Opusコーデックの各モードでレイテンシーを測定してみる。また音質劣化の度合いを聴いてみる)
・Opus + UDPでどのくらい遅延を少なくできるか(Windowsクライアントでトライアル)→プロトタイプB
・プロトタイプA/Bの検証協力者募集
・プロダクトマネージャ募集(まだ無給)