squeezeliteとライブラリ類をビルドしてみました。
どなたか動作検証にご協力いただけませんでしょうか。
インストール手順をまとめて、ご案内いたします。
-
squeezelite 検証スレッド
-
パパリウスさん こんにちは
私のところはメインのサーバーがDaphileですからsqueezeliteは大歓迎です。
動作検証させていただきます。 -
パパリウスさん
こんばんは。
roonではお世話になりました。
今、roonサーバーのsqueezeboxを有効にして聴いてます。
squeezeliteの動作検証させていただきます。 -
squeezelite検討いただけるんですね!
ありがとうございます。
すみません、今週は聞けるところにおらず試すことができませんが、戻りましたら試させていただけると。 -
拙宅ではサーバにpiCorePlayer（のLMS）を使っています。
まず、ALSAライブラリ/ALSAドライバでの音出しには成功しました。squeezeliteやライブラリ類のビルドには大きな問題は無さそうです。
続いて、aplay-rt/rtalsa/xsinkでの音出しを試してみました。
squeezeliteにはstdoutに出力するオプションがあり、/dev/xsinkに直接出力する方式で音出しに成功しました。
ただ、この方法だとサンプルフォーマットの切り替えに対応できません。
例えば、44.1KHz音源に続いて96KHz音源を再生、、、といったことができないので、実用するにはもう一工夫必要です。ALSAライブラリのfileプラグインを使う方式(SpotifyやRoonBridgeと同じ方式)はサンプルフォーマットの切り替えに対応しているのですが、まだ音出しに成功していません。
このあたり、もうちょっと調べて試行錯誤してみようと思います。
サンプルフォーマットの切り替えにも対応できるようになった段階でインストール手順をご案内します。
数日か、、、1週間以内にはご案内できる状態になると思います。
@純米大吟醸 さん
検証へのご協力ありがとうございます。
最低限のセットアップ方法を確立させてからご案内したいと思います。
ちょっと苦戦しています。もうしばらくお待ちください。 -
squeezeliteのセットアップを検証中です。
現時点で実現できているのは下記の2パターンです。- ALSAライブラリ/ALSAドライバーでの再生
- stdout機能で/dev/xsinkに書き込んで再生
(2)の方式の制限として、現状ではサンプルフォーマットの切り替えに対応することができていません。
サンプリングレート・ビット深度は固定され、適宜変換されて再生されます。様々なサンプルフォーマットに対応するためには、squeezeliteのソースを修正する必要があります。
修正候補としては、ALSA出力機能のソース(output_alsa.c)、または標準出力機能のソース(output_stdout.c)と、その周辺ソースとなります。
squeezeliteを少し触ってみた印象として、親サーバ(LMS)との協調動作が特徴的であり、大変多機能であると感じました。
LMS側で特定のサンプルフォーマットに変換し、それをsqueezelite側にストリーミングするという設定にしてしまえば、サンプルフォーマット切り替えの実装に悩む必要もなく、導入がシンプルになりそうだなと思っています。
LMS / squeezeliteの使い方に関して、以下を教えていただけませんでしょうか。
- LMS側でフォーマット変換する方法 (設定手順など)
私個人はSoXなどを使ったサンプルフォーマットの変換は極力避けるほうが良いと考えていますので、フォーマットを決め打ちして変換ありきという設定が皆さんの望んでいるものなのかどうか掴みかねています。
時間がかかってもよろしければ、ソース修正による対応をお待ちいただければと思っています。 -
メンバー参加への承認、ありがとうございました。
よろしくお願いいたします。LMS単体でのSRとビット深度の固定はできないように思います。
プラグイン/C-3POをアクティブにして実験したところパパリウス様の意図することはできそうです。
プラグインを使ってもよいのであれば設定手順をご案内します。 -
@tokkari さん
コメントありがとうございます。
LMSのプラグインを使う方式で結構ですので、設定方法を教えていただけますと助かります。smpdでsqueezeliteをサポートするにあたり、組み込みかたを色々と試しながら引き出しを増やし、最終的な実装方法を決定したいと思っています。
-
ファイルタイプの変換指定は下記のとおりです。
軽くお目通しください。ここからはSR/BDの変換・指定などはできませんLMSの設定画面に入って「Advanced」タブを選択
左上のプルダウンメニューから「File Types」を選択さてC-3POです。最初にお断りしておきますがこのプラグインは
squeezeliteの派生版R2との協調作業を目的に制作されています。
通常版で使用する場合に思わぬトラブルを招く可能性もあるのでご注意ください。LMSの設定画面に入って「Plugins」タブを選択
3rd party plugins項目の「C-3PO Transcodeing Helper」をチェック
右下のApplyボタンを押してしばらくすると再起動を要求されるのでOK押下再起動後に
LMSの設定画面に入って「Player」タブを選択（Player毎に設定・保存できます）
左上のプルダウンメニューから使用予定のsqueezeliteを選択
その右隣のプルダウンメニューから「C-3PO」を選択C-3POの設定画面が表示されればOKです。
後は釈迦に説法ですね。説明など不要かと。再度、確認のため
LMSの設定画面に入って「Advanced」タブを選択
左上のプルダウンメニューから「File Types」を選択
FLACの項目が設定に応じて変更されていればOKです。パパリウス様はPicorePlayer上でLMSを動かしているのですね？
もしpi3以前のモデルをご使用でしたら負荷の高いアップサンプリング設定は避けた方が無難です。
pi4なら余裕かな。 -
素人考えですがBridge系のプラグインを作ることも可能でしょうか？
勿論、SMPDの音質を損なわない方法でというのが大前提ですが。参考までに私の運用方法を記しておきます。
LMSでAirport bridgeプラグインをアクティブにして設定画面からスタートさせる。
SMPDがairport対応デバイスとしてLMSのプレヤー選択欄にリストされるのでそれを選ぶ。メリット 安定しています。
UPnPのインストールも不要、SMPD側は何もする必要はありません。
ハイレゾやDSDは自動でダウンコンバートされますが、問題なく再生できます。デメリット airportの制限でハイレゾ再生は不可です。
-
以下の記述はYo様のSymphonic MPD讃(3)からの引用です。
＞symphonic-mpdでは、Xenomai APIで新規開発したプレーヤーソフト(aplay-rt)を＞使ってPCMを再生しております。
＞mpdはpipeアウトプットプラグイン、
＞shairport-syncはpipeバックエンド、
＞spotify-connectはalsa-libのfileアウトプットプラグインをそれぞれ利用して＞fifo(名前付きパイプ)にPCMデータを送り、aplay-rtから読み込み、RTDMドライバーというXenomai向けに
＞新規開発したデバイスドライバを使ってALSAバッファに書き込む方式としております。これら３つの方法において、音質、負荷などの点で有意な差というのはあるのでしょうか？
-
@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...
-
-
@パパリウス さん
ネットワーク処理での音質悪化要因の分析、とても参考になります。
なるほど、そういうことでしたか。僕は、今まで、通信処理と再生処理で4コア位あれば十分で、無理に2台システム構成にする必要はないのかなと思っていました。しかし、今回のパパリウスさんの説明で、処理の遅延が発生する理由が共用のメモリ(キャッシュ)やOS資源の奪い合いから発生すると分かりました。そうであれば、やはり2台システム構成をとることが正解ですね。
こだわりますが、この意味でdirettaというのは良く考えられたシステムだと、改めて思います。Windows(Diretta Sync)とLinux(Diretta Sink)で処理を分け、Linux側は定期的な通信処理と再生処理以外、何も実行させないようにして処理の安定化を図るというコンセプトは凄いです。
もちろん、ババリウスさんが、現在、開発中のSMPDネットワーク機能対応システムが完成すれば、SMPDも同じ土俵となり、後は、i2sとusb非同期処理の対決となるわけですが。 -
@yo さん
音楽再生時のCPU負荷をみると、大半のコアは1%未満です。
CPU0で動いているrtalsaドライバーを例にすれば、数ミリ秒おきに一回おきて数マイクロ秒だけフルスピードで仕事をして再び次のタイミングを待つのですから、殆どの時間は何もしていません。CPUが何もしていない時間帯も、GPIOからは常にhigh/lowの電圧でI2Sシグナルを送り続けていますから、グランドを揺らしたりノイズを発するような活動を控えてCPUが静かにしているのは良いことなのでしょう。
smpdの開発は、競合を避けて無駄な処理の発生を抑えたり、冗長な処理を取り除いてより短時間で処理が終わるように工夫を続けてきたものと言い表すことができます。
Raspberry PiでI2S出力するのに必要最小限の処理というのはごくごく僅かです。
I2SとDMAの設定が終わってしまえば、あとはDMAコピー元のメモリ領域にPCMデータを書き込むだけです。これをALSAライブラリ・ALSAドライバーで行おうとすると、冗長な処理が多く含まれていることに気付きます。
これらはリアルタイム性の保証されないOSでも動くようにするためは必要な処理ばかりですが、逆に言えばリアルタイムOSの支援があれば、ALSAライブラリ・ALSAドライバーで消費されるCPUサイクルの90％以上を取り除くことが可能です。
そして取り除くことができない必要不可欠な処理についても、メモリのプリフェッチを行ってCPUキャッシュヒット率を上げ、条件分岐のヒントを与えてパイプラインハザードを避けることでハードウェアの理論値に近い性能で処理をさせることができるようになります。これらの無駄を取り去ったあと、、、次に問題になるのが、前のコメントで挙げたような各再生ソフトの挙動に伴うリソースの競合ということになります。
特にRaspberry Piに搭載されたCPUキャッシュはあまりに小さいため、メガバイトのデータを扱うだけであっというまにCPUキャッシュ(L2キャッシュ)が汚染されてしまい、他のCPUコアの処理に影響を及ぼしてしまいます。
処理を複数台で分担することでこのようなリソースの競合を避けることができれば、バックエンドのCPUをより静かに保つことができ、I2Sシグナルを汚す要因を減らすことができるだろうと思っています。
-
@パパリウス さん
CPUが何もしていない時間帯も、GPIOからは常にhigh/lowの電圧でI2Sシグナルを送り続けていますから、グランドを揺らしたりノイズを発するような活動を控えてCPUが静かにしているのは良いことなのでしょう。
なるほど。この辺りがネットワークや非同期のUSB転送でデータを送る場合とは考え方が異なる点なのでしょうね。
これらはリアルタイム性の保証されないOSでも動くようにするためは必要な処理ばかりですが、逆に言えばリアルタイムOSの支援があれば、ALSAライブラリ・ALSAドライバーで消費されるCPUサイクルの90％以上を取り除くことが可能です。
これも言われてみると、「眼から鱗」です。確かに実行権が保証され、絶対割り込まれないリアルタイム処理であれば多くの無駄は省けるという訳ですね。
特にRaspberry Piに搭載されたCPUキャッシュはあまりに小さいため、メガバイトのデータを扱うだけであっというまにCPUキャッシュ(L2キャッシュ)が汚染されてしまい、他のCPUコアの処理に影響を及ぼしてしまいます。
Linuxで動くソフトを使い、インテルマシンで音楽再生すると、ラズパイやBBBと比較して、圧倒的な安定感を感じます。その辺りはこの理由かなと思っています。もちろん、インテルハードにはGPIOがありませんから、i2sダイレクという再生方法はとれなくなるというディメリットはあるわけです。ただ、クロックのしっかりした優秀なDDCを使えばそんなハンディは問題じゃないという意見もあって、このあたりは何が正解かよく分からないですね。
SMPD v1.0はこういう議論を一蹴する音を聴かせてくれます。セパレート構成で、さらに完成度が上がれば、天下無敵でしょうね。ただ、インテルハードでもAMDアーキテクチャのAPUはGPIOがあるらしいので、誰かそれを使った音楽再生システムを開発しないかなと思っています。APUは音に悪いディスプレイ関連のハードは省かれているし、ネットワーク周りは強力ですから、音楽再生用には理想的なハードだと思うのですが、如何せん知名度が低いのが残念です。
-
パパリウスさん こんばんは。
私は音楽をじっくり聞くときはSMPDでBGM的に音楽を流すときはLMSをサーバーに
picoreplayerを使用しているので是非動作検証に参加させてください。 -
@fumufumu さん
検証に手を挙げてくださりありがとうございます。
どういう方向で実装するかまだ思案中ですが、改めてお声掛けさせていただきます。
ぜひsqueezeliteのサポートを実現させたいと思っていますので、何卒よろしくお願いいたします。 -
@パパリウス さま
Squeezeliteの検討は続けていただけそうでしょうか?
今月に入って解説いただいたセパレート構成、ちょっと熱くなりました。
フロントエンドにSqueezeliteの選択肢があると。よろしくお願いします。 -
@純米大吟醸 さん
いま取り組んでいるテーマが一段落しましたら、また改めて検討を進めてみたいと思います。
