なかるうのブログ一覧

Roon ARCのレビュー２回目、実践編となります。Android版がちょっと気に入らず、今回はiOS版で続行します。

自宅のライブラリが何TBあろうと、何百km離れていようと、回線さえあれば全ての曲を音質劣化なく楽しめてしまうという、プライベートストリーミングの終着点と呼びたくなるアプリがRoon ARCです。

クルマで使う姿を想像してみれば、「持ち出すアルバムを選ぶ」作業が必要なくなるのが大きい。
自宅でライブラリに追加した瞬間から外で聴けるのも魅力的で、これは試したくなります。





しかししかし。
前回Android版のRoon ARCを使った実験では、スマホ単体（イヤホン端子やBluetooth）では問題なく再生できたものの、USBオーディオ機器を使って音を出してもビットパーフェクト再生にはなりませんでした。

AndroidでUSBオーディオ再生する場合、機種やアプリにもよりますが多くはOSの制限によりサンプリングレート48kHzとなり、ハイレゾ音源はダウンコンバート、CD音源は44.1kHzから48kHzへ変換されます。またOSのミキサーを経由することによる音質劣化も発生します。

ハイレゾが欲しいわけじゃなく（自分のカーオーディオではどうせダウンコンバートする）、24bit/48kHzが悪いわけでもありませんが、CD音源をデータ改変なく再生できないのは、高音質を謳うRoonとしてはだめだろ・・・とテンションダウン。
バージョンアップで改善されるのはいつか。実はこの問題はARCが出る前、Roonリモートでも指摘されており、もうしばらく時間がかかるとみてiOS版にスイッチしました。

余談ですが、UAPP（USB Audio Player PRO）やHF Player、Hiby Musicなどのアプリでは、OSを経由しない独自のUSBドライバーにより上記の制限を回避しています。
（参考：Android端末でUSBオーディオする方法まとめ）

（2022/12/1追記）
ARCは速いペースでバージョンアップを続けており、リリースノートによると最新の1.0.5ではついにAndroid版でもUSBへのビットパーフェクト再生がサポートされました。
予想より早かったですね。Roon Labs.エライ！




まずはiOS版ARCのポテンシャルの確認から。
一般的なRoon ARCの使い方としては、スマホにイヤホンをつないだり、BluetoothやCarPlay（2023/2 Android Autoにも対応）で楽しむといったところでしょうが、当ブログとしてはもう少し高音質を狙います。

ARCはこれまでのRoonリモートを公衆ネットワーク経由で使えるようにしたものと考えればよく、Roonサーバー（コア）のようにネットワーク内の他のRoonデバイスに音を送る機能は現在ありません。
したがって、スマホにUSBオーディオ機器を接続するのが最も高音質な再生方法でしょう。

iPhoneでUSBオーディオする場合は、これを使用します。
（ポタアンなどでスマホと直結できる機種の場合は不要です。）

Lightning - USB 3カメラアダプタ （Apple）
名前に「カメラ」とありますが実体はセルフパワーの１ポートUSBハブです。USB（A端子）側にUSB機器、Lightning側に電源を接続します。iPhoneへの充電とUSBへのバスパワー供給をしながら使え車載にも便利です。

なおAndroidの場合は「Type-C」で「PD対応」なハブを使います。
（こちらもType-Cで直結可能なポタアンなら不要です。）

U2HC-T431PBK USBハブ Type-C USB-A 2.0×3ポート USB PD 60W対応 Type-C×1ポート ケーブル30cm マグネット付 ブラック （ELECOM）
ただし実際に充電しながら使えるかはスマホ次第で、仕様として公開されていない場合も多く自己責任で試すしかありません。Xperia 10 IIIでは大丈夫でした。

USB-DAC代わりのDAPを接続して確かめました。左はUSB充電器。


ここでトラブル発生。正しくUSB接続すると画像のようにDAPがDACモードになるはずが、最初は認識されませんでした。数十秒おきに一瞬だけ表示されるエラーメッセージを頑張ってスクショしたのがこれ。

電源の容量や接続順序にシビアなようです。認識したので次へ。

前回ご紹介したように、Wi-Fi接続時とセルラー（回線）接続時それぞれ音質モードを選べます。


ARCの現在のバージョンでは音質を４段階に設定できます。これはAndroidもiOSも同じ。


各モードについては、公式のFAQに説明があります。
「Original Format」：オリジナルフォーマット
　受信側が対応する限り、音源のフォーマットそのままで配信。未対応のフォーマットはダウンコンバート。
「CD Quality」：CD品質
　最高16bit/48kHzまたは16bit/44.1kHz FLAC。AACなどの場合はそのまま配信。
「Balanced」：バランス
　256kbps Opus
「Bandwidth Optimized」：帯域優先
　96kbps Opus
OpusはYouTubeなどで使われているロッシー（非可逆）圧縮です。

Android版にはなかったDSDの出力設定があり、対応DACならネイティブ再生が可能です。DoPはデータ中に特定の識別コード（マーカー）を入れる必要があるので、これができることは意図するデータを出力できる、つまりPCM音源もビットパーフェクト再生できることの目安になります。
dCSなんて超ハイエンドメーカー用の設定が出てくるあたりRoonらしいというか。


「Original Format」設定で24bit/96kHzのハイレゾ音源を再生。Roonでお馴染みのシグナルパス表示です。

ロスレス伝送できています。UAPPなどと同様、OSのオーディオエンジンの制約を回避できているようです。よしよし。

自分の使っているプロセッサーアンプはハイレゾ対応ではないので、「CD Quality」設定で再生してみます。この設定だとサンプリング周波数は最高48kHzとなり、デジコアにはちょうど良い具合です。



シグナルパス表示によると、レート変換とFLACエンコードまでをサーバー側で行い、スマホはFLACのデコードから先を担当しているようです。変換は64ビット浮動小数点で高精度に演算し、スマホと回線の負荷は抑えるよう工夫されています。また192kHzは48kHz、DSDは44.1kHzといった具合に整数分の一に変換されました。

PCの強力な演算能力を使ってオーディオ処理を行い、ネットワークで配信する。モバイルオーディオの枠を超えた取り組みで興味深いですね。
なおRoonではDSPと称してパラメトリックEQなどもコアが実行しますが、今のところARCは未対応です。
（2023/6/14追記）
最新バージョンではARCでもDSP機能（新たにMUSEと名乗るようです）が使えるようになりました。
ARCではスマホ側で処理が行われるようですが、紹介ページにあるこの動画の通り、パラメトリックEQを始めサンプリングレート変換などARC以前のRoonでコアが担っていたのと同様の強力かつ詳細なコントロールが可能になっています。動画を見て「いやバランスとか…」と思うなかれ、変換アルゴリズム選択など実は紹介されていない部分の方が面白く体験おススメ。


残念というか当然というか「CD Quality」ではビット深度は16bitとなります。
CD音源は16bit/44.1kHzの無変換で出力してくれたので良いとして、本来自分の環境でもロスレス再生できるはずの24bit/48kHz（ハイレゾには割とある）はビット数が削られます。「Original Format」にすれば今度は96kHz以上の音源が聴けず、うーん。
（2022/11/3追記）
最新バージョンの「CD Quality」設定では、24bit/44.1kHzおよび24bit/48kHzの音源については24bitのままロスレス再生するようになりました。これは嬉しい。通信データは1.5倍になりますが、Roonでそんなことを気にするのも、ね。
88.2kHz以上およびDSDの場合は変わらず16bitに変換されています。

ハイレゾ対応のプロセッサーとDDCを組み合わせて「Original Format」を使う場合、DDCとプロセッサーの対応周波数が合っていないと再生できない音源が出来てしまいます。例えば96kHz対応のプロセッサーに192kHz対応のDDCだと192kHz以上の音源が聴けません。DDCを使わずUSBで直結できる機種ならよし、でなければAT-HRD500のようなSRC（サンプリングレートコンバーター）をかますか、DACでアナログ入力するか。このあたりがカーオーディオでの使いこなしのポイントになりそうです。
５つめの音質モード「カスタム」として最高周波数やビット深度を設定できるようにならないかな。
（2023/6/15追記）
上で追記したDSP機能「MUSE」で、デバイス毎に使用可能周波数を設定できるようになりました。


192kHzまで入力できるこれなら面倒がなさそうで、いいなぁ・・・
（2023/1追記）現在はHELIXにも（内部処理は96kHzとかでも）192kHzで入力可能な機種があります。


さて、
ここまでは良かったんだ…

テンション復活。こんな構成でクルマに持ち込んでみました。

Android派なもので、ついUSBと書いてしまいました・・・もちろんスマホ側はLightningです。

が、DDCのAudiophilleoを認識してくれず、スマホのスピーカーから音が出てきました。
今日はここで時間切れ。進展があったら、また更新したいと思います。




（2022/10/22追記）解決しました。
USBオーディオ用のバスパワーを別供給としたところ、動作するようになりました。カメラアダプターの給電能力は、バスパワーの機器を駆動するには少し弱いのかもしれません。
USBやLAN用のオーディオアイテムを多数販売するJS PC Audioさんの外部給電USBケーブルを使いました。セルフパワーのUSBハブとかiDefenderでも良いと思います。

仮設置状態です。スマホやDAPでUSBオーディオするとこうなりがちなケーブルの取り回しは何とかしたいところ。

横にあるBluetoothリモコンも使えました。スマホの画面を見ることなく、視線を前方に向けたまま手探りで曲送りでき安全です。

5Gなんてつながらない田舎道を一日走り回ってみたところ、途切れたり停止することなく快調に再生を続けてくれました。アルバムアートの表示がワンテンポ遅れるくらいで音の方は曲間の待ち時間も気にならず、本当に自宅のコンテンツを再生しているのか？と疑うくらいスムーズで驚きました。「CD Quality」設定でCD音源はロスレス再生ですが、少なくともそのレベルの音は軽く出ています。




問題はこれ。

お試しで購入したeSIMのデータ量をたった一日で使い切り、気が付けばデータシェアした主契約の容量を侵食していました。このプランは最大20GBまでありますが、Roon ARCをCD品質で楽しむには不足かもしれません。

データ量については、これはもう計算通りにしかなりません。「CD Quality」で2時間も再生すれば1GBほど。「Original Format」ならファイルサイズそのままですから、どうなるか予測可能です。
ロッシー圧縮でデータ量を抑える設定も可能とはいえ、それならApple Music (iTunes Match) でもいいわけで。自宅の音源そのままの音質で取り出せるとあって使わずにはいられない。
こんなサービスが現実となった今、データ量無制限の時代が待ち遠しい・・・そういえばもうありましたね。

果たしてドコモさんはこんなデータ量でも速度制限なく使わせてくれるのか。また2.4GHzのWi-Fiを経由しても実用になるか。持っている方はぜひレポートお待ちしています。
（2022/11/13追記）
画像の車載ルーターDCT-WR100Dを導入、普通に再生できました。ハードウェアなのか回線なのか速度はそれほど速くありませんが、幸い「CD Quality」設定では問題なさそうです。整備手帳上げました。
データ量を気にせずに済む環境になったので、しばらくARCをメインのオーディオソースとして使ってみようと思います。

さらにそういえば。つい最近5.2GHz帯の車載Wi-Fiが日本でも制度化されました。
2.4GHz帯よりも高速な5GHz帯のWi-Fiはこれまで屋外利用（自動車も屋外扱いです）に制限があり、W52のチャンネルは実質的に使用不可、W53は使用禁止、W56はレーダーとの干渉防止機能（DFS）のため接続が切れることがあり・・・と、どうにも使いにくかったのが解消されそうです。
おそらくその後、6GHz帯のWi-Fi 6Eも控えています。

パズルのピースが埋まってゆくようで、楽しみになってきました。


（2022/10/19追記）
Astell&KernのDAP、SP3000がRoon ARCに対応しました。DAPではAndroid搭載機でもOSをバイパスして高音質なオーディオ出力を可能にしており、こんな選択肢もできました。ただし後からインストールしたアプリの音声出力までその仕組みが有効なのか、またUSB出力が使えるかなど「対応」のレベルは不明です。

（2022/12/8追記）ShanlingのM7も対応。
（2022/12/12追記）ShanlingのM3 Ultra、M6 Ultraも対応。
（2023/1/2追記）HibyのRS8も対応（してました）。


（2022/10/23追記）
やる気になって主力音源級の扱いに昇格させました。

始動直後はUSBチャージャーの5Vで動作開始し、１分後にリニア電源が立ち上がったら切り離すよう構成しました。USBアイソレーターも投入。


（2022/10/29追記）
FLACによる高音質なストリーミングサービス、Qobuzの日本進出が発表されました。e-onkyoと組んだので邦楽も期待できそうです。
RoonはTIDALやQobuzに対応しており、これらのアカウントを持っていれば自分のライブラリと統合的に使うことができます。どちらも日本ではサービスインしておらず利用は難しかったのですが、ついに来るか！という感じです。どうか海外と同じRoon対応となりますように。


（2022/12/17追記）
しばらく使ったので不具合の記録など。
・稀に曲送りに失敗し、30秒ぐるぐるの後「Poor connection」とエラーを出すことがあります。こうなるとそのまま操作を繰り返してもたいていダメで「Playback Internal Error」とか「Something went wrong」なんて情けないエラーに進行したりします。アプリを再起動すると何事もなかったかのように復旧するので回線とは別の問題のような気もします。
・冒頭で追記した通り、Android版でもUSBへのビットパーフェクト出力ができるようになりましたが、自分の機器では今のところ「Audio Device Error」となって再生できません。USB出力においてiOS版とAndroid版は完全に同じというわけではないようです。


（2023/3/31）iOS版ARCはAirPlayが使えるので、AirPlay対応機器を接続する方法でも高音質が得られそうです。ただし現在のAirPlayは（CarPlayも）ハイレゾに対応しておらず、この点ではUSBオーディオにメリットがあります。
この後のブログで試しています。
ラズパイとUSBオーディオで作る高音質（？）AirPlayレシーバー
（2023/6/5）作成したAirPlayレシーバーの性能を検証しました。
AirPlayの実力を確かめてみる（私がApple嫌いなわけ）


（2013/8/12）モバイル回線でロスレスストリーミングは実用に足るのか？長期間使ってみた感想をまとめました。
Roon ARCに思う


（2024/10/30追記）
Qobuzが待望のサービス開始。海外版と同様にRoonとの連携も実現しており、RoonやRoon ARCの画面のままサブスク音源も聴けるのは大変便利です。ようやくRoonの魅力が全開になった感じですね。
Qobuz、来！
CarPlayでUSBオーディオ

Roonがバージョン2.0となり、新たに登場したスマホアプリのRoon ARCとの組み合わせにより、自宅のサーバー（Roonコア）に保存した音楽ライブラリを外出先で再生できる！ようになりました。やるなRoon。










Roonの紹介動画です。


ちょっと古いですが以前レビューしていますのでご覧ください。
Roonとラズパイで遊ぶ

このブログが2016年で、当時はRoonでコアと称するサーバーアプリをWindowsにインストールしましたが、その後PCの更新にともないコアを再構築。仮想化基盤上にTrueNASのファイルサーバーを立て、それをLinux版のRoonコアから参照する構成としました。

仮想化オーディオサーバーの製作(1) (ESXi)
仮想化オーディオサーバーの製作(2) (TrueNAS/OpenMediaVault)
仮想化オーディオサーバーの製作(3) (MinimServer/Roon)
（別に、こんな凝ったことしなくてもRoonは使えますよｗ）

（2024/7追記）無償版ESXiが提供終了となったので作り直しました。
仮想化オーディオサーバーをProxmox VEで再構築した

そしてこちらが今回の新機能Roon ARCの動画です。

何の説明もないイメージ映像ですが、これはもう・・・みんカラで取り上げないワケにはいくまいて。

ARCを使用するのに追加料金は発生しません。とはいうものの、Roon自体のライセンスフィー（月間$12.99／年間$119.88／永年$699.99の３択）は円安で厳しくなりました。永年契約が$500以下だった（しかも円高の）時に購入した人は得しましたね。
（2022/12/6追記）価格改定のアナウンスがあり、2023/1からは月間$14.99／年間$149.88／永年$829.99となるそうです。




自宅にRoon環境のセットアップが完了している前提で始めます。
（2024/6追記）これは重要かもしれません。自分はRoon ARCの実装前からRoonを使っていたので気が付きませんでしたが、いきなりサーバーのセットアップからARCまで全部やろうとすると、動かなかった時に何が悪いのか途方に暮れる可能性大です。まずは自宅内で確実にRoonとして使えることを確認してから、が良いと思います。

まずはサーバー側から。
Roonコアを最新版にバージョンアップし、「Settings」→「Roon ARC」画面を開くと、配信可能かどうかチェックしてくれました。

おや？エラーです。仕方ない調べますか。

公式のガイド
Getting Started With ARC
ARC Port Forwarding
によると、ARCクライアントへの配信を行うための条件は、
・ルーターがUPnPまたはNAT-PMPによるポート開放に対応していること
とあり、未対応の場合は手動でポート開放を行う必要があります。（ポート番号は上の画面で表示・変更可能）

UPnPやNAT-PMPは、対応ルーターならたいていメニューにその設定があるので有効であることを確認します。条件を満たす環境であれば、おそらく何もしなくても配信可能となっているでしょう。
手動でのポート開放は、オンラインゲームや自宅サーバーをやっている人なら馴染みがあると思いますが、ある程度ネットワークやルーターの知識が必要になります。

さてエラーの原因は・・・
自分のインターネット環境は、高速化のためIPoE契約（IPv6 IPoE。商品名でv6オプションとかv6プラスなどと呼ばれているもの）に移行しており、IPv4用にDS-Lite（transix）接続を使っているため、原理的にポート開放ができない状態でした。
そこでルーターの設定を変更、v4の接続方式を従来のPPPoEに戻したところ

配信可能となりました。サーバー側で設定などは特になく、これだけで準備完了です。

以上の結果から、どうやら現時点ではIPv4でのポート開放が必要で、従って
・インターネットのプロバイダーがIPv4のグローバルアドレスを発行していること
も条件となりそうです。CATVインターネットなど、グローバルアドレスがオプションサービスだったり対応不可のケースもあるので注意です。

ひとまず回避したけど、せっかくIPoEにしているのにPPPoE接続では速度アップは限定的で、恩恵にあずかれないのはもったいないなぁ・・・ARCが使えそうだったら対策を考えることにします。

同じIPoEでもMAP-E接続の場合は手動でポート開放の設定ができるようです。いずれにせよひと手間かかりますのでIPoE契約の人は注意してください。

（2022/10/1追記）
IPv6でのUPnPによる配信については、まだ対応するルーターが限られており、ネットワークの状況を考えてもRoon Labsの選択は間違いではないと思います。しかしv4のIPアドレスが枯渇した現在、多くの人が配信側に回る可能性のあるサービスこそv6対応を推進して欲しいな、とも。

（2023/5/21追記）
Roonの最新バージョン2.0.16でIPv6に対応したとのこと。やるなRoon。

（2025/1/4追記）
Roonのバージョン2.0.36（2024/5リリース）で、VPNサービス・Tailscale経由での接続に対応しました。ポート開放ができない環境の対策として使えそうです。




続いてクライアント側をセットアップします。
スマホにRoon ARCをインストールし、起動します。
とりあえず自宅ネットワーク内で、AndroidスマホをWi-Fi接続して試してみました。

初回の起動画面。


Roonのユーザー認証。

Roon ARCから自宅サーバー（コア）へのアクセスは自分しかできないようになっていますが、ポート開放自体ある程度のセキュリティリスクを伴う行為ですので、そこは理解の上で。

認証が終わると、あっさりコアを見つけてくれました。


初回接続時は何やら同期が走りますが、すぐに終わります。


ユーザープロファイルを選択できるようです。


Roonっぽい画面になりました。この時点で普通に再生可能で、次回以降はこの画面から開始となります。

Wi-FiがつながっていればWi-Fiで、無ければモバイル回線を使って再生します。Wi-Fiは自宅内でも、またモバイルルーターなど自宅外でも使用可能で、コアと同一ネットワーク内でしか使用できないRoon Remoteとの最大の違いです。
ただしRoon Remoteのようにネットワーク内のRoon機器を操作することはできず、出力先はスマホのイヤホン端子、またはスマホに（USBやBluetoothなどで）接続した機器に限定されます。今のところARCはRemoteの後継ではなく補完関係の別アプリとして設計されているようです。

ダウンロードのアイコンは、Wi-Fi接続時に楽曲をローカルストレージに保存しておき、外出時の通信量を抑えるためのもの。回線速度が追いつかないような高レートのハイレゾ音源をロスレス再生する場合にも使えそうです。

設定画面を下の方にスクロールすると・・・


皆さんの興味はここですよね？再生設定の「Automatically pick best quality」をOFFにすると・・・


Wi-Fi接続時とセルラー（回線）接続時で個別に音質を設定できます。


４段階の設定があります。「Original Format」や「CD Quality」を試してみたいところ。
現在のバージョンでは、microSDへのダウンロードはできないようです。


USB出力は使えるのか？UAPPのようにビットパーフェクトで再生できるのか？
車に持ち込んで試してみたいと思います。




（2022/10/3追記）
現在、Android版のRoon ARCではUSBオーディオ機器を接続してもサンプリングレートは48kHz固定となり、OSのミキサーを回避したビットパーフェクト再生はできません。（何シテル？では16bitとつぶやきましたが、実際に試したところ24bit/48kHzでした。）

一方、iOS版は96kHz以上のハイレゾやDSDもそのままUSB出力可能となっています。イヤホン端子やBluetoothでRoon ARCを楽しむ分にはAndroidでも問題ありませんが、「ガチに」オーディオするなら、iPhoneにUSBオーディオをつなぐしかない状況と言えそうです。
実はAndroidにおけるRoonのオーディオ出力はARCが出る前から同じ仕様だったので予想できたことですが・・・ちょっと期待が過ぎたようです。

この件については公式のコミュニティにスレッドがあり、「いっそオーディオ出力はARCからUAPPを呼び出したら？」なんて提案まで上がっています。UAPPはバックグラウンドでDLNAレンダラーとして動作できるので意外と実現性あるんじゃないかと思いますがどうでしょうね。
自分としては、高音質を謳うRoonならUSBへのビットパーフェクト再生は最低限クリアして欲しいので、今のところ不採用。続編は進展があってからアップすることにします。




（2022/10/16）
結局Android版のバージョンアップを待てず、iOS版で車載実験してみました。次のブログをご覧ください。



（2022/12/1追記）
ARCは速いペースでバージョンアップを続けており、リリースノートによると最新の1.0.5ではついにAndroid版でもUSBへのビットパーフェクト再生がサポートされました。
コミュニティでは「クリスマスまでには対応してくれるよね！」なんて声もありましたが、それより早かったですね。

新型コロナによって一変した生活が続いていますが、皆様お元気でしょうか。自分は職業柄（プラス身体上の理由もあり）オフ会やイベントの類は一切遠慮して意気消沈・・・とまでは言わないまでも何か物足りない日々を送っております。
そんな時に職場のエライ人から「飲み会やるから全員出席な！」なんて言われてブチ切れですよ。何のために我慢してると思ってんだコノヤロウ！

あ、「みんなのカーライフ」でしたね。毒吐くのはここまでにします。








70,000kmに到達しました。年間ほぼ10,000kmペースで順調に伸びています。
過去のクルマは月500kmほど。走るのが好きなんでしょうね。

キリ番なんて今までとらえたこと無かったのに今回なぜかゲットできたので、久しぶりにブログをしたためてみました。
総括といっても、別にハコ替え構想中じゃないです。今後も静かに乗り続けるつもりです。


今年の春先。こういうのは気付きました。


B7パサートさん、購入直後からウォーターポンプが３回交換になった時はさすがに
「外れか？」
と思いましたが幸い保証期間内。その後トラブルらしいトラブルといえはヒーターコアが詰まったこと位で（ポンプ交換に伴うLLC変更と因果関係は無かったのか？多少の疑念は残っています・・・）まぁ許容範囲かって感じです。
（修理記録は愛車紹介に書き留めています。）

昔乗っていたBX16TZiでは、夏場にエアコンを使うと30分ほどでルーバーから霜を噴き始め、「パキパキッ」とアニメで氷を表現するような音とともにファンが凍り付いて止まるのが持病でした。でもガラスの血管？ハイドロニューマチックは最後までノートラブルで「空飛ぶ絨毯」の乗り心地を堪能できました。今どきの輸入車、主要な部分はそうそう壊れるもんじゃないっす。


DSGは楽しい。

DCT（デュアルクラッチ・トランスミッション）のドイツ語読みとなるDSG。
VAG（VW/Audiグループ）だけかと思ったらホンダもリコール出していたり、採用メーカーの一つだったメルセデスベンツがATに移行したりと分が悪い状況にはありますが、個人的には過去最も気に入っているトランスミッションです。

アクセルペダルを踏むとタイヤが地面を蹴る、そのダイレクト感はトルコンATやCVTとは明らかに違うメリットであり、MTに近いもの。感性に訴える楽しさがあります。
平地から緩斜面に入り、アクセルを踏み足す。エンジンが唸る。次の瞬間にはヴォン！とシフトダウンして加速態勢に入る、一連のその動きが自然で
「あぁ、マニュアルだったらこんな感じで登ってゆくんだろうな」
と思わせるものがあります。

乗っていると、自然と意識がクルマに向くんですよ。
フライバイワイヤ感覚の電動車もまた違った面白さがありますけど、終わりつつあるICE車を楽しむためのトランスミッションとして素晴らしいものだと思います。


DSGは面倒くさい。

DSGといえば気になるのが不具合。
新車から70,000kmまでジャダーが出なかった記念に、自分のDSGとの付き合い方を記しておきます。
正しいかどうかはわかりませんし、世代によっても違うとは思いますが、あながち間違いでもなかったのかなと。


0. アイドリングストップはOFFにします。発進が一瞬遅れるのと、それを気にすると（特に交差点の右折時など）アクセルワークが荒くなりギクシャクした挙動になりがちなので、自分は常時OFFにしています。

1. ブレーキペダルから足を離しアクセルペダルへ。この時アクセルはまだ踏みません。

2. ほんの一瞬、クリープ（DSGの疑似クリープ機能）で進み始めるのを待ちます。

3. 動いたのを感じたらアクセルペダルを「少しだけ」踏みます。自分の車の場合は200～300rpm程度、アイドリングが1000rpmだったら1200rpm強まで上げます。

4. １速のクラッチがつながり、回転が落ちかけたらその分だけ（落ちないように・落ちる前に）踏み足してあげる感じで、エンジンの回転を感じながらアクセルペダルを開けてゆきます。
この時アクセルを開けるタイミングと量に注意で、タイミングが速いとギクシャクした発進になり、踏み遅れたり踏みすぎるとノッキング気味になります。

「DSGの１速のアクセルペダルは、クラッチペダル。」
踏む方向は逆ですが、こんな風にイメージするとスムーズに発進できると思います。
なお２速以降は特別な気遣いは不要で、自由に扱って大丈夫です。

以上。文章では小難しく見えても、時間にして1.5秒ほど。
１か月も試行錯誤しているうちに、似たような操作になったオーナーさんも結構いるのでは？

ベストな操作は一定ではなく、路面の傾斜、エンジンの状態、ミッションの温度などによっても変わるようで、
「よし！今のはカンペキ！」という発進を維持するのは意外に難しいです。

トルコンATやCVTと同じ感覚のオープンループ制御ではない、機械と人の「クローズドループ」であることに気付けるか、また許容できるか、さらに楽しめるか、そこがDSGと相性が合うかどうかの分岐点になると思います。
（人間が右足と左足で完全に制御できるMTより、かえって難しいかもしれません。）


DSGはオートマか？

いわゆるオートマと同じように使えるけど、ちょっとだけ違うモノという意識を持って接した方がうまく行く、というのがDSG/DCTに対する自分の実感です。

おかしいと思うのは、VWのディーラーではDSGの操作方法を一切レクチャーしてくれないこと。

売る方からすれば、特別なことを要求して「DSGは面倒くさい」というイメージは持たれたくないはずで、ATやCVTと同じ感覚で扱ってもらって大丈夫！と言いたいのかもしれませんが、現実は使い方によっては不具合も出ているわけで、そこまでの信頼性、汎用性を謳うにはほんの少しだけ足りないものがあると感じています。

そういう意味で、VAGのような大メーカーが全車種に採用したのは間違い、あるいは少しだけ早すぎたのかもしれません。

無理に「普通」と言い張って機械に負担をかけさせ、不具合が出たら乗り換え推奨、運悪くそんな中古車を購入して外れを引く人がいても知らんぷり、というのは不誠実だと思うのです。

別にいいじゃないですか、「ドイツの精密機械ですから」って言っちゃえば。
ちょっとした気遣いでトラブルを避けられ、かつトルコンATやCVTにはないメリットを享受できるなら、「そういうもんです、コツがあるんですよ」と積極的に指導した方が、ユーザーは信頼すると思うのですが。
特にVWの場合は、ちょっとした不都合でも隠せば大炎上することは学んでいるはずなのに。

だいたい輸入車を選ぶ時点で、ユーザーは多少なりともクルマ好きではあるわけですし。
そんなに普通のクルマを売りたいか！
まぁ売りたいですよねスミマセン・・・

初見の方には冗談のような話ですが、ネットワークオーディオのネットワークが混雑していると、音質に影響があることがわかってきました。

そこで、昨年手に入れたOpenWrtという武器を使って、この路線でもう少し攻めてみることにします。
ただただローカルファイルを高音質に再生することだけに特化した取り組みで、サブスクともYouTubeとも親和性は考えていないのでご容赦。


以下は、ネットワークオーディオ用のネットワークをホームネットワークから分離した図です。これは、ネットでもそこそこ見かける手法です。


通常のルーター1に加えて、オーディオ専用にルーター2を設置します。
オーディオ用ネットワークLAN2と汎用ネットワークLAN1のアドレスを変えて別セグメントとすることにより、LAN1の機器が発するブロードキャストパケットがLAN2に流れ込まないようにできます。

ルーター2は普通の家庭用ルーターでもいいですし、もっと手軽には

WMR-433W2（バッファロー）
上位のLANとの接続は無線になりますが、こんなトラベルルーターを使う手もあります。
整備手帳上げました。

いわゆる「二重ルーター」の弊害で、LAN1のPCからLAN2のオーディオサーバーにアクセスすることはできません（ポートを開ければ可能ですがネットワーク分離の意味が薄れる）。この不便に目をつぶれば音質的にはメリットがあり、LAN1の機器が多いほど効果を感じることができます。

なぜこんなことで音質に影響するのか？少なくともレンダラーに届くデータに変化はないはずなので、もっとアナログ的な機序、例えばこんなメカニズムでしょうか。

オーディオネットワーク上の非オーディオパケットが減る
→レンダラーが不要なパケットの受信処理を行わなくて済む
→LANコントローラやCPUの動作が減る
→レンダラー全体のGNDや電源の電圧変動が抑えられる
→レンダラーのorレンダラーに接続されるDACやDDCのノイズが減る

デジアナ混載回路を設計したことのある人なら否定はしないんじゃないかと思いますが、オカルトですかね？




一歩進めて、ラズパイを使ってルーターとサーバーを一体化し、HUBを排除したのがこれ。みん友さんからアイデアを頂いたこのシステムの製作過程はこちら。
直結ネットワークオーディオ（実用化編） - MinimServer2 on OpenWrt/RaspberryPi3 -

HUBレスについては、まだネットワーク分離ほど一般的ではないように思います。「オーディオ用HUB」なんてのもある位なので、無くして音が良くなるか懐疑的な人もいるかもしれません。

HUBをなくしてもネットワークのトラフィックが減るわけではありません。しかしEthernet上の各機器においてクロックは非同期。HUBのクロックがなくなる分「静か」になるのでは？と期待しました。
またHUBによるストア＆フォワード動作が無くなるので、サーバーとレンダラーの遅延（レイテンシー）はゼロになります。

この構成では、鮮度感のある、クリアかつダイナミックな音が得られました。反面「デジタル臭さ」を感じる部分もあり、LANケーブルによる違いも明確に感じたことから、ラズパイのEthernetの信号品質がよりダイレクトに影響するようになったのかもしれません。




ここまでが昨年までの進捗。その後別のことで遊んでいる間にネタを思いつきました。コンセプトは、
「オーディオ用ネットワークのトラフィックと機器を最小に！」
です。

オーディオ領域が極めてシンプルで、理屈はともかく良い音が出そうな図でしょ。

必要なことは次の２つ。

1. DLNAルーティングの実装
DLNAのコントロールポイントとして使うスマホやPCは、それ自身が結構なブロードキャストパケットを吐きます。これがLAN2を汚していると考えたので、コントロールポイントをオーディオネットワークの外、LAN1に出してしまいたい。
DLNAのルーター越えってどうやるんだ？

2. ファイルサーバーの分離
ラズパイの電源は脆弱で、消費電力の大きなSSDなどをUSBにつなぐと5Vラインが盛大に変動します。たとえデータとして正常に通信出来ていてもEthernetの信号品質への影響は否定できません。
そうだ、DLNAサーバーのうちストレージ部分だけNASとしてLAN1に出せばいいじゃん。今日び、512GBとか1TB位のファイルサーバーならスマホで用が足りる時代なんだし。




今年はこんな構想でやってみたいと思います。さてどうなりますか。
書いた以外にも課題が多いシステムなので、年内に動くかなぁ？

手のひらサイズのミニPCで作るオーディオサーバーの最終回です。
やっとオーディオネタに戻ってきました。今年はこんなことばっかやってますね・・・












（2024/1追記）
Broadcomによるvmware社の買収が完了し、ここで紹介したvSphere Hypervisor（ESXi）にも影響が取りざたされています。はっきりしたところで記載したいと思います。

（2024/2追記）
無償版vSphere Hypervisor（ESXi）の提供終了が公式に発表されました。残念です。

（2024/7追記）
ESXiの代わりにProxmox VEで作り直しました。
仮想化オーディオサーバーをProxmox VEで再構築した

（2025/4追記）
無償版ESXi8の提供が再開されました。




前回までで仮想化基盤とファイルサーバーを準備しました。いよいよオーディオサーバーに仕上げます。
DLNA（UPnP/OpenHome）もRoonも使える、多機能ファンレスサーバーを目指します。SMBプロトコル（NFSも追加可能）のファイルサーバーと併せ、ネットワークオーディオと名の付くプレーヤーにはたいてい対応できると思います。

前回からまた少し変わって、最終的にはこんな構成になりそうです。

メインのファイルサーバー、TrueNASの仮想マシンVM1は旧サーバーからデータを引っ越し、既に稼働状態に入っています。
WindowsServerからのデータ移動にはFreeFileSyncを使いました。

VM1にある楽曲ファイルを使ってオーディオ配信を行うのがVM2とVM3です。メインのサーバーを動作させたままで安全に機能追加できるのは仮想化のメリットですね。
CPUの性能の範囲で、とはなりますが、軽量OSを選べば今回のような省電力PCでも2つ3つは動かせます。

作成した仮想マシンは、こんな風に仮想ネットワークでつながります。

物理的なLANポートは１つしか接続していないのに、それぞれのマシンが独立したアドレスを持ち、ネットワーク上に台数分のPCが出現したように見えます。マネジメントネットワークとはESXi自身の管理画面のことです。


MinimServer2のインストール

当ブログではお馴染み、DLNA/UPnPサーバーのMinimServer2をインストールします。
どのマシンで動作させるか。MinimServer2はWindows・Macの他Linuxでも動作しますが、TrueNASのベースOSであるFreeBSDには未対応です。

調べてみたところ、MinimServer公式の掲示板にFreeBSDで動作させたという投稿がありました。ただし一部のライブラリはLinuxとFreeBSDで互換性がなく再コンパイルが必要になるそうです。MinimServerがバージョンアップするたびライブラリを入れ替えるのはちょっと面倒、もう一つのRoonは未知数ですがリソース喰いではありそう、というわけで今回はバックアップサーバーのOpenMediaVaultに載せることにしました。

OMVのベースOSはDebianでRaspberry Pi OSと同じ、rootのシングルユーザー運用である点はルーター用OSのOpenWrtと同じです。今年とった杵柄、キネヅカでサクッと行くよ。

ffmpegのインストール

MinimStreamerによるトランスコード（変換）配信を行う場合に必要なコーデック群です。SSHからコマンド一発で入ります。
root@openmediavault5:~# apt update 
root@openmediavault5:~# apt install ffmpeg 
以上。


Java実行環境のインストール

Javaはリリースされたばかりの最新LTS（長期サポート）版、Oracle JDK17（Java Platform, Standard Edition (Java SE) Development Kit）を使いました。
WindowsPCでOracleの公式サイトにアクセスし、Linux用の「x64 Compressed Archive」をダウンロードします。
（2021/10/4追記）
長時間（24hとか）稼働するとNASにアクセスできなくなることがあり、旧バージョンに変更しました。とりあえずJDK8では問題なさそうです。

せっかくのNASなので、Windowsからは共有フォルダ経由でOpenMediaVaultに転送します。shareという名前でフォルダを作成しています。
共有フォルダはOpenMediaVault側では/srv下のdevで始まる名前のディレクトリにあり、任意の場所（ここでは/usr/share）に展開します。
root@openmediavault5:~# cp /srv/dev-disk-by-uuid-xxxx-xxxx/share/jdk-17_linux-x64_bin.tar.gz /usr/share 
root@openmediavault5:~# cd /usr/share 
root@openmediavault5:/usr/share# tar xzvf jdk-17_linux-x64_bin.tar.gz 

chownコマンドでファイルのオーナー設定を修正。パスの通ったディレクトリにリンクを張って起動確認します。
root@openmediavault5:/usr/share# chown -hR root:root jdk-17 
root@openmediavault5:/usr/share# ln -s /usr/share/jdk-17/bin/java /usr/sbin 
root@openmediavault5:/usr/share# java -version 
java version "17" 2021-09-14 LTS 
Java(TM) SE Runtime Environment (build 17+35-LTS-2724) 
Java HotSpot(TM) 64-Bit Server VM (build 17+35-LTS-2724, mixed mode, sharing) 



リモートマウントプラグインのインストール

MinimServerの楽曲ファイルは、メインサーバーTrueNASの共有フォルダを使用します。（ローカルのバックアップHDDには手を付けたくないので）
OpenMediaVaultのプラグインを使って他のNASにアクセスできるようにします。管理画面の「プラグイン」からインストールします・・・が、デフォルトでは純正プラグインしか表示されないので、最初に以下のコマンドでサードパーティー製のプラグインを使用可能にします。詳しくはこちら。
root@openmediavault5:~# wget -O - https://github.com/OpenMediaVault-Plugin-Developers/packages/raw/master/install | bash 

表示された「openmediavault-remotemount」をインストールします。

TrueNAS側でユーザーを作成し、OpenMediaVault側からそのユーザー名でアクセスします。設定方法はこちら。

「ファイルシステム」画面にTrueNASの共有フォルダが表示されています。


MinimServer2のインストール

MinimServer2は64bitのLinux Intel版を使います。
やり方はJavaと同様で、インストールパッケージをWindowsPCでダウンロードしてOpenMediaVaultに転送、任意の場所（ここでは/usr/share）に展開します。
root@openmediavault5:~# cp /srv/dev-disk-by-uuid-xxxx-xxxx/share/MinimServer-2.0.18-linux-intel.tar.gz /usr/share 
root@openmediavault5:~# cd /usr/share 
root@openmediavault5:/usr/share# tar xvf MinimServer-2.0.18-linux-intel.tar.gz 


MinimServerのセットアッププログラムを実行。rootのシングルユーザーとして設定します。
root@openmediavault5:/usr/share# minimserver/bin/setup root 
MinimServer desktop integration is disabled 
MinimServer automatic startup is disabled 
Do you want to change these settings (y/n)? 
y 
Enable desktop integration for MinimServer (y/n)? 
n 
Enable automatic startup for MinimServer (y/n)? 
y 
MinimServer automatic startup has been enabled 

MinimServerの初期設定を行うため、コマンドライン版のstartcで起動します。
root@openmediavault5:/usr/share# minimserver/bin/startc 
初回だけライブラリの場所を聞かれるので、上でマウントしたTrueNASの楽曲フォルダ名を入力します。

ライブラリのスキャンが始まり、しばらく経って「MinimServer is running」と表示されれば起動完了。

MinimWatch（とJava）をインストールしたPCに同じ内容が通知され、アイコンが緑色になります。ならない場合はPCのファイアウォールがJavaをブロックしていないかチェック。パブリックネットワークあるある。


startcによる起動ではコンソールを閉じるとMinimServerも止まってしまうので、いったん終了します。
>exit 
リブートしてPCのタスクトレイにあるMinimWatchのアイコンが再度緑色になれば成功です。
root@openmediavault5:/usr/share# reboot 


MinimStreamerのインストール

必要によりMinimStreamer（有償）をインストールします。設定方法は以前のブログをご覧ください。
ネットワークオーディオ自作(8) ラズパイサーバーを改良する

以上でMinimServer2はセットアップ完了です。lightMPDなど、DLNA/UPnP対応のレンダラーで再生します。


Roon Coreのインストール

Roonについて

最新バージョンの1.8。相変わらずの美しい画面です。

Roonについて語りだすとブログ１本になってしまうので、ちょっと古いですが以前の投稿をご覧ください。
Roonとラズパイで遊ぶ

逆木さん（PC関係が不得手な評論家センセーの多い中、この方のコンピューターオーディオ論は納得感があります）呼称するところの「総合音楽鑑賞ソフト」Roon。提供される圧倒的な情報量と、それにより演出される「曲との出会い」が楽しく、音楽好きの方には特に体験をおススメします。統合運用できるTIDALに（2021/10/4追記：Qobuzにも！）国内導入の噂もあり、実現すればさらに強力な音楽コンシェルジュになってくれることでしょう。

とはいえ、有料（年間サブスクリプションまたは永年ライセンス制）かつ楽曲情報が英語のみ（操作系やタグの日本語表示は可能）という２点から、日本ではまだヒットしそうにないのが残念なところです。

Roonのサーバー機能は「コア」と呼ばれています。今まで使ってきたのはWindows版、今回はLinux版のコアをセットアップしました。最初はNUC用に最適化されたROCK（Roon Optimized Core Kit）を使うつもりでしたが、仮想マシンに入れるにはトリッキーな作業が必要なようで通常のLinux版にしました。


仮想マシンVM3の設定とUbuntu Serverのインストール

Roonのハードウェア要件はこちら。
Roonでは、再生デバイスに合わせたサンプルレート変換などをコアで行うため、サーバー側のハードウェア要求スペックが高くなっています。Linux版はOSが軽量な分、他のプラットフォームに比べハードルが少し下がります。
推奨ディストリビューションはUbuntuかArch。今回はUbuntuをデスクトップレスのサーバー構成で導入します。サーバーと聞くと重そうですが、GUIが無いので最小構成ではデスクトップ版よりかえって軽量にできます。

仮想マシンのリソースはこのくらい。CPUの性能からDSPなどRoonのフル機能は無理でも、通常の再生には支障ない程度を狙います。

プロビジョニングポリシーをThic（Eager Zeroed）にして128GBを確保しようとしたら、60%前後初期化したところでESXiが他の仮想マシンもろともコケました。
安全ちゃうやんか！
この設定はディスクの初期化時に高負荷がかかり、再現性があることからNVMeあたりのハードウェアに問題がありそうです。安全な環境は堅牢なハードウェアあってこそ、ということですか。
デフォルト設定のThic（Lazy Zeroed）なら大丈夫でしたので続行します。
（2021/10/1追記）
M.2 SSDをキングストンの低消費電力タイプに変更。高負荷でも安定したかな？

Ubuntu Server（20.04 LTS）のインストールISOイメージを公式サイトからダウンロード、ESXiのデータストアにアップロードし、仮想マシンのCD/DVDドライブにセットしてインストールします。
画面表示に従って設定を進めてゆきます。といってもユーザー名等を設定するこの画面以外特に変更するところはありませんでした。


インストールが完了したら再起動。CDROMを取り出してと言われたらESXiの管理画面でISOイメージの接続を外します。


起動したらログインし、タイムゾーンの設定とシステム更新を行っておきます。
$ sudo timedatectl set-timezone Asia/Tokyo 
$ sudo apt update 
$ sudo apt upgrade 



Roon Coreのインストール

インストールガイドはこちら。引き続き、以下のコマンドでインストールします。
$ sudo apt install ffmpeg 
$ sudo apt install cifs-utils 
$ curl -O http://download.roonlabs.com/builds/roonserver-installer-linuxx64.sh 
$ chmod +x roonserver-installer-linuxx64.sh 
$ sudo ./roonserver-installer-linuxx64.sh 

これだけ。

（2021/10/23追記）
11月のアップデートの前にライブラリ「libicu」をインストールしておいてね！とのメールが届きました。
$ sudo apt update 
$ sudo apt install libicu66 
これはUbuntu20の場合。libicuはUnicodeのライブラリで、Linux版のフレームワークをMonoから.NETに移行してパフォーマンスを改善するため、だそうです。


以降サーバーに触る必要はなく、このコンソールもexitして閉じてしまってOKです。設定はネットワーク上のPCやスマホ・タブレットから行えます。


Roon Coreの設定

コマンドにCIFSの文字が出てきたことからわかるように、Roonのファイル共有はWindows互換です。TrueNASにユーザーを作成し、SMBプロトコルで楽曲フォルダにアクセス可能としておきます。

PCでWindows版Roonを起動するとコアを見つけてくれます。Roon Remoteアプリをインストールしたスマホなどでも可能です。

Roonのライセンスはコア単位なので、１ライセンスで運用できるコアは１台のみ。旧サーバーとはここでお別れ（削除はされず無効状態）となります。

ログイン後、楽曲フォルダを登録します。ホスト名が通らずIPアドレスで指定しました。


TrueNASの音楽フォルダが見えました。「Select this folder」すると楽曲のスキャンが始まります。仮想ネットワークでつながっているので高速です。

数分で普通に使えるようになり、引き続きバックグラウンドで曲の解析が行われ数日間はCPUパワーを消費します。サーバーなので放っておけばよいです。（状況は「Settings」－「Library」で確認できます）

Roonのコアはそれ自体はファイルサーバー機能を持たず、今回のように外部のPCやNASの音源を参照するか、OSのファイル共有を使う必要があります。仮想化でNASと組み合わせると１台でコアとライブラリを兼用でき使いやすくなります。NASやNAS用OSにコアをインストールするのも良いかも、と思いました。

あとは好みのオーディオデバイスを接続すれば再生可能。Roonのハードウェア対応は多彩です。
Roon Readyの機器であれば確実で音質も担保されますが、音を出すだけならPCにつながるものは大抵使えます。デバイスをPCに接続する場合は、Roon BridgeをインストールしておけばRoonを起動しなくてもスマホなどから再生コントロール可能です。

Bluetoothアダプターで気軽に聴いたりもできますし、自分は古のネットワークオーディオ：

Squeezebox Boomを再利用したりしています。
ピュアオーディオ用途でPCを経由するのは嫌だけどRoon Readyのプレーヤーなんて持ってない、そんな場合は市販のRoon対応ブリッジでUSBやS/PDIFに変換したり、ラズパイにRoon BridgeやRoon対応ディストリビューションを入れて自作することもできます。




以上で完成です。今回は「ホームネットワークに接続するファイルサーバー兼オーディオサーバー」というシナリオで構成してみました。
より音質を重視するなら、LANアダプターと以前作成したOpenWrtによるルーター（ネットワーク分離）を追加して、「オーディオ専用LANポート付きサーバー」なんてこともできると思います。
HUB基板を内蔵しただけの市販「オーディオ用」サーバーとは一味違うぞ！
とかね。




仮想化を使ってみて、OS/2やBeOS、はたまたNeXTSTEPなどOSを取っ換え引っ換えしていた時代の楽しさを思い出しました。あの頃は仮想化もなく、自分はOSを起動し直しては変わるUIで遊ぶ程度でしたが、現在はファイルサーバーやルーター、オーディオサーバーなど専用OSが多数あり、これらを並列動作させて実用的に使える環境になりました。

ただ、その一方でPCは電源を入れれば選択の余地なくWindowsが立ち上がるようになって久しく、簡単にはOSを変えられないモノになってしまっています。今こそクリーンコンピューターの思想が必要なのだ！




（2021/9/26追記）
リソースの割り当て状況はこんな感じです。このあたりのチューニングも仮想化で面白いところです。

使用するコアの総数が物理コア数を超える（オーバーコミット）と、ESXiによるスケジューリングが入りパフォーマンスが低下します。実際に発生する頻度が高くなり過ぎない程度が良いでしょう。
メモリーとストレージは、ESXiが使う分を含めて物理的な容量の範囲に収めています。メモリーのオーバーコミットは避けるべき、ストレージはThicプロビジョニングの場合オーバーコミットできません。

欲を言えば8コア・32GB位あると遊ぶ余裕ができますが、そうなるとメーカー製PCの多くは強制空冷になってしまい、オリオさんあたりのファンレスPCが欲しくなります。
まぁ、この位で留めておくのが乙ってもんですかね。


（2021/10/8追記）
MinimServer2もRoonも安定動作しています。OSの選択、リソース設定などまだ最適解には達していない気もしつつ、ひとまず正式運用に入りました。

Roonで有名なシグナルパス表示です。オーディオファイル向けにはビットパーフェクトで再生できているかどうかのインジケータとして使えますが、あえてフォーマット変換させて負荷をかけてみました。以前のサーバーでは無理だった、DSD256からPCM48kHzへの変換も途切れることなく再生できています。ただしギャップレス再生はできず曲間で一瞬止まります。
なんでそんな変換を？と思うかもしれませんが、Bluetoothヘッドホンで聴く時はDSD不可、とかじゃ困るわけですよ。こういう能力は大事。
処理性能はこの条件（DSP機能はOFF）でリアルタイムの3倍程度と表示されています。flacなどのPCM音源やDSDでもネイティブ再生なら負荷はこれよりずっと軽くなり、１ストリームであればDSPを入れても一通りの再生はこなせそうです。上出来でしょ。


（2024/5/19追記）
RoonのベースOSにしたUbuntuを最新版にアップグレードしたところ動作が不安定となり、数日放っておくとRoonの仮想マシンがCPU100%状態で固まるようになってしまいました。車でRoon ARCを使う時にこれでは脱力感半端ないので、ROCK（Roon Optimized Core Kit）に入れ替えました。
現在のROCKはUEFIに対応し、ESXi環境にも比較的容易にインストールできるようになっています。コミュニティに上がっているこの手順でいけました。
ROCK VM on ESXi
中で必要と説明されているキーボードのパススルーについてはこちらの動画が分かりやすいです。


ただ、肝心のESXiが冒頭朱書きの状況ですので、このブログ自体あまり有用ではなくなってしまいました。仮想化基盤でNASとRoonを動かすと
・仮想ネットワークで高速に接続できる
・Roonが重くなったり最悪フリーズしてもファイルサーバーに影響しない
などメリットがありますが、今から同じことをするならProxmox VEとかですかね？