なかるうのブログ一覧

Twitterやインスタを見ていると皆さん短いやり取りなのに的確にコミュニケーションがとれていて、何というか人間の通信プロトコルも変化していると感じます。おじさんはConnection TimeoutとかAccess Deniedとかされないようにしたいものです。体のどこかにUSBポートが隠されていてapt upgradeなんて入力できないもんかね。
（訳：今回のブログは長いよ！）








カーオーディオで愛用してきたUSB-DDCを新調したものの、Roon ARCで動作せず対策しました、というネタです。
ついでにスマホから生えるUSBケーブルが野暮ったいので、音質を確保しながらスマートにしてみようと。

iOS版Roon ARCはAirPlayに対応しており、AirPlayレシーバーを用意すればワイヤレスかつ良い音で聴けます。市販製品としては


SOUNDFORM CONNECT （Belkin）


WiiM Mini （WiiM）

などで、これらは光デジタル出力を搭載しています。自分はUSB-DDCを使うため、USBトランスポートになるAirPlayレシーバーを探したらそれもちゃんとあって、


ZEN Stream （iFi audio）

や、ラズパイユーザーにはお馴染みのVolumioなどが対応しているようです。

しかし、これらをAirPlayで使ったときにロスレス伝送なのか、さらにビットパーフェクトなのかとなると判然としない。ネットを漁ってみると、
「AirPlay1は16bit/44.1kHzのALAC、AirPlay2は現時点ではAAC」
なんて情報もあり。
古い方が高音質ってこと？現時点って何？Appleさんが詳細な仕様を公開していないので本当のところがわかりません。

そこで、AirPlay1専用に設定することで音質を担保できそうなラズパイで自作することにしました。AirPlay2のメリットである低遅延やマルチルーム再生は捨て、できる限り音質重視となるよう構成してみます。途中でALACにしただけではビットパーフェクトにならないこともわかったので、その対策も行っています。




ハードウェア選定

AirPlayの受信用にWi-Fi、オーディオ出力用にUSBが1本あればよく、今回はラズパイシリーズの中でも小型の

Raspberry Pi Zero 2 W

を使います。定価$15、国内でも3,000円以下で買え「た」ボードですが、半導体不足のため品薄が続いています。Amazonなどは転売ヤーか！って位の価格になってしまっていて、今買うのはおススメしません。
ラズパイで似たスペックなら3A+あたりはまだ良心的？な価格で入手でき、この後紹介するOSのページにあるハードウェアを試すのも面白いかも。（次のブログでNanoPiを使いました。）

Zero 2でCPUがクアッドコアとなり、ラズパイ3に近い性能があります。ただしRAMが512MBと少ないのでPCのようにウィンドウをパカパカ開いて動画を見たりするには向かず、デスクトップレス（GUI無し）で使うのが良いと思います。
USB（片方は電源）がmicro、HDMIがminiと小型コネクタになっており、変換ケーブルか変換コネクタを用意しておきます。microSDカードは現在購入できる最小クラスの4GBか8GBもあれば十分で、逆に64GBとかだと不具合の可能性も。




起動用microSDカード作成

OSとして、今回は「純正」のRaspberry Pi OSよりさらに軽量（＝RAMの使用量が少ない）の

DietPi
をインストールしました。

ライトウェイトにこだわり32bit版のARMv7用を選択。公式サイトからダウンロードした7zipを展開して取り出したimgファイルで起動用カードを作成します。

microSDカードへの書き込みにはRaspberry Pi Imagerを使用しました。Raspberry Pi OSなどをダウンロードから書き込みまでこれ一つで実行できるアプリですが、

一番下、予めダウンロードしておいたimgファイルを焼くこともできます。




接続と初期設定

こんな環境で設定してゆきます。完成したらラズパイとiPhoneを別のネットワーク（車載ルーター・モバイルルーターなど）に持ち出すイメージです。
（家の中でRoonだけ使うならAirPlayよりRoon Bridgeの方が高音質です。）

カードを基板にセット、ケースに入れてケーブル類を接続します。このksy製ケースも後で入手したflirc製も同じで、ケースに入れるとカードを交換できないのは誤算でした。基板を外す時は無理な力をかけないよう要注意。

最初はHDMIポートにモニターやTV、USBポートにキーボードをつないだ「ローカルコンソール」で設定してゆくのが確実です。
少し慣れた人なら、カード作成時に設定ファイルを編集しておきキーボード無しでWi-Fiに接続させる「ヘッドレスインストール」に挑戦しても良いでしょう。その場合でも設定中HDMIだけはつないでおいた方が起動時の挙動を把握でき安心かと。USB接続のHDMIキャプチャーボード（2,000円くらいで買える）も使えます。


起動しました。DietPiはDebian系LinuxなのでコマンドなどRaspberry Pi OSに近い感覚で使えます。
表示されている初期ユーザーとパスワードでログインすると、


最初にOS更新が走りますがネットワーク接続がないとして中断します。この状態では何か設定を変更するとネットにアクセスしようとして数10秒タイムアウト待ちとなることがあります。「フリーズした！」とあわてて電源を落としたりせず、まずは家のWi-Fiアクセスポイントに接続します。
「Network Settings」を選択して「OK」（カーソルキーとTABキーが使えます）


IPv6はOFFで良いでしょう。ONにする時は外部から侵入されないようルーターの設定を確認しておきます。


Wi-Fiを有効にして設定に入ります。


アクセスポイントを５つまで登録できます。複数登録した場合は起動時に見つかったAPの中で最も電波の強いものに接続するので、家以外のモバイルルーターなどもここで登録して大丈夫です。（後で追加も可能）
SSIDとパスキーを入力、完了すると再起動を促され、再度ログインするとOS更新を行って続行します。


サーベイ（情報提供）に参加するかどうか


ソフトウェアインストール用のパスワードを変更するか
この時点ではまだキーボードを設定していないのでキーと文字が一致していない可能性があり、スキップした方が良いでしょう。（2023/4/23追記）最新のv8.16で対策されたようです。


rootおよびdietpiユーザー用のパスワードを変更するか。ここも飛ばします。


UART（シリアル）は使用しないので「Yes」で無効にします。


ここがメニューの最上位、DietPi-Softwareです。
SSHサーバーは軽量の「dropbear」がデフォルトで有効になっています。今回の使い方ならこのままで良いですし、ファイルのアップロードなどを行う場合はOpenSSHに変更することも可能です。


最初にDietPi-Configを選択し、地域とキーボードを設定します。


キーボードは使っているものに合わせます。日本語キーボードあるあるで、設定が違うとパイプ文字「｜」が入力できなかったりします。


USBオーディオを使うため「Audio Options」でALSAをインストールしておきます（DietPi-Softwareからのインストールも可能）。その他、先ほどスキップしたパスワード変更なども行えます。


全て設定し終えたらDietPi-Softwareまで戻って「Install」


ソフトウェアを選択していないので「最小インストールでいいか？」と聞かれています。「OK」でインストールが始まります。

ここまでコマンド入力も設定ファイル編集も一切なく完了です。至れり尽くせりですね。
ローカルコンソールでの設定はここまで。インストールが終了しコマンドプロンプトに戻ったら、logoutしキーボードを外してOKです。




USBオーディオ接続

キーボードをつないでいたUSBポートを空けるため、ここからはネットワーク上のPCからリモートコンソールを開いて設定してゆきます。


コンソール用アプリのPuTTYでラズパイのIPアドレス（ローカルコンソールの画面左上に表示されていた数字。スマホアプリのFingなどで調べることもできます）を指定し、接続タイプ「SSH」でコンソールを開きます。
PCのキーボードとモニターを使ってローカルコンソールと同じように操作できます。


ビルトインユーザー「dietpi」でログイン。（以降、プロンプトが$となっているものは「dietpi」、#は管理者権限「root」でのログインを示しています。）

空いたUSBポートにUSBオーディオ機器をつなぎます。
ユーザーをaudioグループに追加。
$ sudo adduser dietpi audio 
$ sudo reboot 
再起動してSSHで再度ログインし、以下のコマンドで機器のIDを取得します。USBの接続状態が変わるとIDも変わったりするので、最終状態で確認します。
$ aplay -l 
**** ハードウェアデバイス PLAYBACK のリスト **** 
カード 1: U20F1 [USB Audio 2.0(F1)], デバイス 0: USB Audio [USB Audio] 
サブデバイス: 1/1 
サブデバイス #0: subdevice #0 
「カード」と「デバイス」の番号を覚えておきます。




shairport-syncのインストール

AirPlayレシーバーとして

Shairport Syncを使います。

Appleの非公開技術であるAirPlayを独自に解析して作られたのがオリジナルのShairport（現在は開発停止）で、Shairport Syncはそのフォーク（分家）の一つとなります。
公式のガイド：Build and Install Shairport Syncに従ってインストールしてゆきます。

旧Shairport Syncのクリーンアップ
実はDietPiでは先ほどのDietPi-Softwareから簡単に導入できるのですが、今回はロスレス伝送を確実にするため手動でインストールします。
DietPi-Software用の設定が残っていると不具合の元になるため、ガイドの 1.Prepare の手順に従いクリーンアップを実行しておきます。（DietPi-Softwareからを含め初回のインストールであればおそらく不要です。）


ビルド用ツールとlibalacのインストール
Shairport Syncの作者さんが公開しているApple純正のALACデコーダをビルドします。
$ sudo apt-get install build-essential git autoconf automake libtool 
$ git clone https://github.com/mikebrady/alac.git 
$ cd alac 
$ autoreconf -fi 
$ ./configure 
$ make 
$ sudo make install 
$ sudo ldconfig 
$ cd 
長いコマンドはここで選択・コピーしてSSHのウィンドウ上で右クリックするとペーストできます。


ライブラリのインストール
ガイドで「classic」と書かれている手順でAirPlay1対応に必要なライブラリをインストールします。
$ sudo apt-get install --no-install-recommends libpopt-dev libconfig-dev libasound2-dev avahi-daemon libavahi-client-dev libssl-dev libsoxr-dev 
（2023/5/7追記）畳み込み演算を行う場合は以下のライブラリを追加しておきます。
libsndfile1-dev libglib2.0-dev 

ん？なんでリサンプル用のライブラリであるsoxrが必要なんだ？
公式のReadmeと掲示板のスレッドに説明がありました。

Bit perfect stream for a DAC through USB?

AirPlayでは1/44100秒ごとの各サンプルにタイムスタンプが付加されていて、受信側ではこれを自分の時刻と比較することでサンプル数の調整（補間・間引き）を行っているそうです。
例えば受信側のクロックが遅ければデータを間引きし、352個のサンプルを351個に作り直すといったことが行われます。それを高品質に実行するためのsoxrとのこと。なるほどHomePodを２つ使ってステレオにできるのはそういう仕掛けか。

確かに、USBオーディオのようにDACのクロックに合わせてデータを送っていたら複数の機器で同期再生なんて無理ですよね※。ガチのオーディオマニアの人達にはAirPlayが格下に見られるのも、ストリーミング系プロトコルの音質が（ファイル再生に比べると）どこか100%に思えないのもこのあたりの要因があるのかも。
でもAirPlayが劣っているということでは決してなく、ビットパーフェクトとタイムパーフェクト、目指すもの・設計思想の違いでしょう。（自分は前者を取りますけど。）
※USB Audio Classのアシンクロナス-アイソクロナス転送ではUSBのバスクロックでデータが「送りつけられる」わけですが、このモードでは受信側から送信側に対してリアルタイムにデータ量を増減させる通信経路（パイプ）が存在し、DACのクロックスピードに同期してデータを供給できるようになっています。
対してネットワークオーディオの場合、UPnP/DLNA/OpenHomeは受信側がデータを「取ってくる」プロトコルなのでDACのスピードで伝送可能、RAATも詳細は不明ながらクロックのオーナーシップがDACにあることを明言しています。


ビルドとインストール
続いてShairport Sync本体をビルドします。ALACおよびAirPlay1対応を指定しています。
$ git clone https://github.com/mikebrady/shairport-sync.git 
$ cd shairport-sync 
$ autoreconf -fi 
$ ./configure --sysconfdir=/etc --with-alsa --with-soxr --with-apple-alac --with-avahi --with-ssl=openssl --with-systemd 
$ make 
$ sudo make install 
$ cd 
（2023/5/7追記）畳み込み演算を行う場合は、configure 時に以下のオプションを追加します。
--with-convolution --with-dbus-interface 


設定ファイルの編集
/etc にある設定ファイルを好みのテキストエディタで開いて編集します。
$ sudo nano /etc/shairport-sync.conf 
ほとんどの行がコメントアウトされています。設定する行のみ行頭の//を消してパラメータを指定します。自分は以下のようにしました。

general =
{
    name = "Shairport Sync(DietPi)";
    interpolation = "soxr";
    output_backend = "alsa";
    alac_decoder = "apple";
    ignore_volume_control = "yes";
};
alsa =
{
    output_device = "hw:1,0";
    output_rate = 44100;
    output_format = "S16";
    disable_synchronization = "yes";
};

"hw:1,0"が先に調べたUSBオーディオ機器のIDです。
ボリュームを100％に固定、ALAC指定、バックエンドの出力フォーマットを16bit/44.1kHzとしてビットパーフェクトを目指しています。当然ですがiPhoneからのボリュームコントロールは効かないのでUSB以降のアンプなどで音量を絞れるシステムでないとスピーカーが壊れます。
ライブラリも入れていないのでAACでの伝送はやんないんじゃないできない仕様です（どや！）

soxrは高音質なリサンプラですがリサンプル自体無い方が望ましいので、スレッドの情報に従い同期を無効に設定しています。
この場合iPhoneとラズパイのクロックの誤差が補正されないためバッファが次第に埋まってor減ってゆき、いつかは必ずオーバーフロー・アンダーフローすることになります。その時は音が途切れるのかエラーで止まってしまうのか、不具合覚悟の音質優先設定というわけです。

（2023/4/6追記）
USBオーディオ機器によって曲の頭がミュートされる場合は、alsaセクションに以下の設定（autoまたはalways）を加えます。
    disable_standby_mode = "auto";

（2023/4/16追記）
いっそ明示的にsoxrを使わせないよう
    interpolation = "basic";
としても良いかも。soxrの場合はnサンプルから（n±1）サンプルを生成するのに対して、basicでは単純に時刻が合わなくなったサンプルの補間・間引きとなります。このためsoxrの方が高音質とされていますが、そもそも同期を無効化している以上サンプル数の調整は発生しないはずです。


動作確認
最初はコマンドラインで起動して動作確認します。
$ shairport-sync 
※畳み込み演算を設定した場合はここでワーニングが出ますが気にしなくて大丈夫です。


Roon ARCの場合は再生画面の下にあるAirPlayアイコンから


簡単に選択できます。


シグナルパス表示ではAirPlayはロスレスとは見なされないようです。Wi-Fiの向こうの処理がどうなっているかはRoonの知る範囲ではないはずで気にすることもないでしょうけど、実際どこまで出来ているかは気になります。
（2023/6/5追記）気になったので次のブログで設定を追い込みました。音質に特にこだわる方はご覧ください。

再生確認できたら、Ctrl + Cで終了します。

（2023/4/28追記）

Roonでは再生機器に合わせたフォーマット変換をサーバー（コア）が実行しますが、AirPlay用の変換は現在Roon ARC側で行われています。コアと同様64bit浮動小数点の高精度な演算です。
シグナルパス表示を見ていると、レート変換を行う時などAirPlayに対して24bitで渡しているようなので、（AirPlayが24bitで送信しているかは不明ですが）バックエンドの出力フォーマットも24bitにしてみました。
Audiophilleo2の場合は
    output_format = "S24_3LE";
Singxer F-1では
    output_format = "S32_LE";
が使えました。

（2023/5/3追記）
16bitを超えて指定できるパラメータはUSBオーディオデバイスによって異なり、次のコマンドで調べることができます。数字は環境に応じて変更してください。
$ cat /proc/asound/card1/stream0 

24bit用、16bit用、DSD用の３つのセットがあることが読み取れます。


サービス化
電源ONで自動起動するよう設定します。
$ sudo systemctl enable shairport-sync 
$ sudo reboot 
再起動して、ラズパイに何も触れずに再生できれば成功です。


Wi-Fiのスリープ無効化
（2023/5/10追記）長時間再生しないとWi-Fiが省電力モードになることがあります。Wi-Fiが「寝て」しまうとAirPlayに応答できなくなり今回のようなヘッドレス構成では「起こす」ことも難しいので、パワーマネジメントを無効化しておきます。
rootでログインし、以下のコマンドを入力。
# iwconfig wlan0 power off 

「Power Management」がOFFであることを確認します。




ファイルシステムのROM化

「電源ブチ切○」は登録商標らしいです。気に入らんな。
車載運用する場合シャットダウンコマンドなんてやってられないので、突然電源が落ちてもファイルシステムが破損しないよう対策します。
以前ラズパイサーバーを製作した時にはスーパーキャパシタによるUPSを準備しましたが、今回は楽曲用のSSDもなくラズパイだけなのでもっと簡単にします。

overlayroot、オーバレイされた（重ねた）ルートファイルシステムという意味で、RO（Read Only）としてマウントしたmicroSDと、RW（Read/Write）属性のRAMディスクを「重ねた」ファイルシステムです。読み出しは普通にSDカードから行い、カード上のファイルに書き込みが発生した時はRAMディスクに書き込みます。書き込み中に電源が切れてもRAM上のデータが消えるだけなのでSDカードは元通り、つまりoverlayrootの動作中に更新したファイルは電源OFFで全て無かったことになります。

DietPi用のoverlayrootはまだありませんが、こちらのスレッドの方法でインストールできました。
Samba Fails on RO filesystem - dietpi.com
rootでログインし以下の通り入力
# apt update 
# apt install initramfs-tools 
# git clone https://github.com/chesty/overlayroot.git chesty 
# cd chesty 
# ./install.sh 

.bashrcファイルを開きスクリプトを追加
# cd /root 
# nano .bashrc 
if [ ! -z "${IMCHROOTED}" ]; then
    PS1="chroot(${IMCHROOTED})\w:# "
fi

リブートして有効化。
# reboot 

mountコマンドでoverlay関連の表示があれば動作しています。
$ mount 
overlay on / type overlay (rw,relatime,lowerdir=/overlay/lower,upperdir=/overlay/upper,workdir=/overlay/work) 
tmpfs on /overlay type tmpfs (rw,relatime) 
/dev/mmcblk0p2 on /overlay/lower type ext4 (ro,relatime) 

設定変更などファイルを更新する時は、/boot/config.txtファイルを開き「initramfs init.gz」の行を#でコメントアウトして再起動するとアンインストールされます。
# nano /boot/config.txt 
再度有効化するにはインストールスクリプトinstall.shを（1つ前のcdコマンドから）再実行します。安易にconfig.txtだけ戻したら起動不能となりOS導入からやり直す羽目になりました。




車載！

ファイルシステムをROM化しても、起動中それが有効になる前に電源が落ちたらやっぱりファイル破損の原因になります。
車載ではエンジン始動時が問題で、ACCONして起動が始まったちょうどいい（まずい）タイミングでイグニッション＝電源OFFとなるので対策します。
以前PCの車載用に製作した、タイマーリレーによる遅延起動回路を使用し、イグニッション終了後に電源ONとなるようにします。

ラズパイの電源電圧に合わせ、この後に接続するDC/DCコンバータを5V出力品に変更しています。

シガーソケットからの12Vをタイマーリレーに接続、DC/DCコンバータ、電源ノイズフィルターのiPurifier DCを通してラズパイに入力しています。USBはプロセッサー近くのDDCへ。
ラズパイは放熱性能に優れデザインも良いflirc製のメタルケースに入れてみました。こちらもカードスロットに開口部が無く、ケースとCPUを放熱パッドで貼り付けたり基板の取り付けにドライバーを使ったりでカード交換はksy製以上に面倒です。




以上で完成です。
AirPlayはOSの標準機能だけあって、UPnPなどネットワークオーディオのように配信と相性が悪かったりすることもなく

YouTubeの音声も飛ばせたり


ネットラジオを流してみたり、手軽に使えるのが良いですね。

AirPlayの仕様上CD品質までとはなりますが、ハイレゾ音源はRoon ARCで再生すればうまいことダウンコンバートしてくれるので意外に「使える」印象です。
AirPlayもMac相手（AirPlay to Mac）ならハイレゾを通すようなので、いずれラズパイでも可能になるかもしれませんし、これは願望ですがRoon ARCからRAATで出せるようになれば理想的ですよね。




（2023/4/2追記）
追記にさらっと重要事項を書くことの多いブログでごめんなさいｗ
Shairport Syncはコンボリューション（畳み込み演算）をサポートしており、一部界隈で話題の音響補正ができます。これ楽しそう。
再生側に近い非同期ドメインで演算するので音質的にも有利なのではないかと。




（2023/4/8追記）
RAMの使用量を確認してみました。

・・・極小です。ただでさえ少ないラズパイZeroのRAMの半分をoverlayrootが使うので軽量化を心がけたのですが、これなら64bit版のOSでも全く問題なさそうです。




（2023/4/9追記）
Roon ARCをモバイル回線で使う時などiPhoneとラズパイの間にネットワーク接続がない場合は、iPhoneのテザリングを有効にするとAirPlayで再生できます。

iPhoneの「設定」－「インターネット共有」で表示されるSSIDとパスキーをラズパイに登録します。ただしiPhoneのDHCPではうまくアドレス配布されず、ラズパイのIPアドレスを固定しました。よくある192.168...ではなく画像のような設定になります。
DietPiで静的アドレスにする場合SSIDの登録は一つだけにする必要があるとのことで、家や車載のルーター環境と切り替えて使うことはできません。最近ドコモの車載ルーターの速度が低下していてモバイル回線との併用を目論んでいたのでちょっと残念。




（2023/6/18追記）
Roonについては中の人が見ているんじゃないかと思う位（まさか）改良が進んでいて、不満はほぼ無くなってきたので、細かな要望を一つ。
Roon ARCの「Original Format」設定でストリーミング、またはダウンロード再生したハイレゾ音源をAirPlayに出力した場合、こんなシグナルパスで一発でレート変換されるのですが、


「CD Quality」設定だといったん48kHzにダウンサンプルされて配信され、ARC側で44.1kHzに再度変換されます。


64bitフロートで行われるとはいえ変換処理が２回入るのはちょっと嫌ですね。Roonは音声処理をきっちりやる印象があるので、ここも最適化して頂きたいです。

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位のファイルサーバーならスマホで用が足りる時代なんだし。




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