@tokkari さん
C-3POの設定手順をご教示いただきありがとうございます。
こちらで試してみたいと思います。
Airport bridgeプラグインでAirPlayする案をご紹介いただきありがとうございます。
この方法ならsmpd側にsqueezeliteをインストールしなくても音出し可能ということですよね。
現在のような再生方式に移行したのはv0.5系からになります。
それ以前は再生ソフトを個別にチューニングする必要があり、ソフトごとの音質差が生じやすい状況にありました。
例えばSpotify ConnectはRustという言語で開発されており、MPDやAirPlayの音質改善ノウハウ(gcc特有の手法)が使えず、音質差が開いていくという状況にありました。
v0.5系以降は再生処理を1箇所に集約できるようになり、全てのソフトを同時に音質向上させられるようになりました。
それでもなお、ソフト毎に有意な音質差があります。
ソフトによって音質差が生じる要因は様々ですが、主なものをご紹介します。
-
ネットワーク通信量
-
ネットワーク遅延
-
メモリアクセス量
-
エンコード/デコードの負荷
-
プロトコル特有の挙動
1) ネットワーク通信量
ネットワーク経由でデータを受け取ると、NICのFIFOからカーネルスペースのバッファにパケットをコピーしてLinuxカーネルに割り込みを通知します。
通知を受けたカーネルはソフトの割り込み処理を呼び出し、カーネルスペースからユーザスペースにパケットをコピーし、不要になったバッファを削除します。
この一連の処理で生じる「バッファ(skb)の確保」「NICからカーネルへのパケットのコピー」「割り込み処理」「コンテキストスイッチ」「カーネルからソフトへのパケットのコピー」「バッファの解放」は、smpdの再生エンジンであるrtalsa/xsinkドライバーの内部処理やシリアライザへのDMA転送と競合します。
このようなリソースの競合は、I2Sシグナル生成に重要な処理に待ちを生じさせたり、処理の再スケジュール、リトライといった無駄な動作の要因となります。
結果としてCPU負荷やメモリアクセス負荷は増大し、電圧の変動やノイズ、ジッタの発生要因となるのではないかと考えています。
ネットワーク通信量が増えるにつれてこのような事象が発生しやすくなるため、wavやaiffのような非圧縮音源、flacのような可逆圧縮音源、ハイレゾ音源では音質が低下しやすく、注意が必要です。
通信量の観点では、Spotify Connectが優秀です。
事前にoggのファイルをメモリにロードしてから再生を開始するため、再生中に大量データの通信は発生しません。
ただし、クライアントソフト(たとえばiOSのSpotifyアプリ)と定期的な通信を行っているようですので、全く通信が無い訳ではありません。
2) ネットワーク遅延
LANのパケット処理にはミリ秒オーダーの時間がかかることが多く、数百ナノ秒〜マイクロ秒で完結するような内部処理とくらべると桁違いに遅い処理になります。
NASやストリーミングサーバからパケットの到着を待たなければならない時、どのように待つかはソフト毎に実装が異なります。
多くの場合、ソケットへのデータ到着をpollやepollといったカーネルが提供する非同期入出力のシステムコールを活用して待つことになりますが、システムコール呼び出しは一般にコストの高い処理であることに加え、pollシステムコールは待ちを行うたびに多くのパラメータを再設定する必要があり非効率(つまり高負荷)です。
そして、パケットが実際に到着してから通知を受けるまでには、数マイクロ秒の時間がかかります。
(音質とは別の問題ですが、、、遅延が酷い環境では音切れが生じることさえあります。)
サーバ性能やネットワーク帯域の問題で遅延が大きくなる環境では、パケット待ち受け処理、タイムアウト監視処理、リトライ処理などの無駄な処理が増え、その結果としてCPU負荷やメモリアクセス負荷は増大し、電圧の変動やノイズ、ジッタの発生要因となるのではないかと考えています。
ネットワーク遅延に起因する無駄な負荷が少ない、、という観点では、再生中の通信が少ないSpotify Connectが優秀です。
To be continued...