ブログ

2017/04/16

ROONを分析して、気がついた内容を書きます。

ROONはネットワークプレイで発生するいくつかの問題に対して、多くの悩みを改善しました。

DLNAで発生する問題では、メディアサーバの応答に対する保証が無いため、あらかじめバッファリングをしなければならない状況が発生します。
このようなバッファリングはレンダラーの立場では負荷が発生します。

また、レンダラーによるバッファが無制限な場合、最初に音源の全てをダウンロードする可能性も発生します。
各種音源のデコードによってPCMデータに変える作業がレンダラーで行われるということです。
これによってレンダラーに負荷が発生し、これ以降でノイズにつながり、結局、音質に影響を与えます。

ROONの場合を見ると、一旦すべてのデータはPCM、DSDなどデコードが必要でない純粋なデータをコアが予め作って送るので、付加的なデコードは必要としないことになります。
オープンになっているRoonBridgeの場合には少し違うように動作するものと思われ、Monoプラットフォームによるソフトウェアの動作に追加的な負荷が発生します。ROONパートナーの場合、ソースコードをシステムにポーティングして負荷がほとんど発生しないことになります。実際WDACに採用したROON関連ソフトウェアのサイズは非常にコンパクトで、CPU負荷は1~2%程度の消耗です。

最も重要な部分はネットワーク伝送の部分です。この部分で最も重要な部分がトラフィックの均一化と正確なタイミングです。

ROONはコアの高い性能を利用し、非常に正確なタイミングで必要な最小サイズのデータを均一なタイミングでROONクライアント（レンダラー）へ配信します。これはイーサネットハードウェアや関連ソフトウェアに負荷を均一に分散します。更に、瞬間的に負荷が高まったり低くなる事は全く発生しなくなります。もちろん、これを処理するコアは相当な負担で動作することになるが、レンダラーにこれらの機能が全て揃っているDLNAに比べれば圧倒的な音質の差になります。

Plug and Playの場合、DLNAはUPnPをベースとするが、ROONの場合は固有のプロトコルを利用するために認識する速度が速く、トラブルが発生する余地も無くなります。

標準は、その標準を理解する方法によっては互換性を100%にしにくい場合がありますが、この場合は閉鎖的な方式が優れた場合が多いです。