squeezelite 検証スレッド
@パパリウス さん
ネットワーク処理での音質悪化要因の分析、とても参考になります。
なるほど、そういうことでしたか。僕は、今まで、通信処理と再生処理で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の選択肢があると。よろしくお願いします。
@純米大吟醸 さん
いま取り組んでいるテーマが一段落しましたら、また改めて検討を進めてみたいと思います。
@パパリウス 様
ありがとうございます。
動作検証のお誘いが届くのを期待して待たせてください。
すみません。
mpdと置き換えできるのものかという認識で簡単にビルド出来ますとよと言った本人が何もしないもの酷くいい加減な気がしますので参加させていただきます（＾＾；）
まずは、playerが必要と思いますので探してみます。
ArchにsqueezeliteとLogitech Media Serverを入れてみました。
LMSはlogitechmediaserver-7.9.2.arch2-1-aarch64.pkg.tar.xz
のパッケージを作りました。
（中身は、slimserver-7.9.2.arch2.tar.gz
slimserver-vendor-7.9.2.arch2.tar.gzでした）
パッケージの作成にはperl関連が山盛り必要でした。
良くわからずWindows PCに
squeezelite-X、Logitech Media Server
など入れてみましたがどれも「プレーヤーが見つかりません」に悩みました。
ArchのLMS立ち上げたらそういう事なのかと。分かり難いですね＾＾；
簡単に設定しただけでは音質的に厳しいと思いました。
piCorePlayerなどfrontを別にした方が好ましいのでしょうか。
取合えず設定内容は以下の通りです。
何故か、squeezeliteのperiod_size設定値は64付近を境に減らすと、ALSAの値が上がる
という逆仕様の様でした。
[root@archlinux64 ~]# systemctl status squeezelite
● squeezelite.service - Squeezelite Player
Loaded: loaded (/usr/lib/systemd/system/squeezelite.service; enabled; vendor preset: disabled)
Active: active (running) since Mon 2021-01-04 19:39:00 JST; 44min ago
Main PID: 847 (squeezelite)
Tasks: 4 (limit: 4254)
CGroup: /system.slice/squeezelite.service
mq847 /usr/bin/squeezelite -o sysdefault:CARD=vsound -n Squeezelite -s 192.168.1.50 -a 128 64 -m 58 27 8c bf 51 4b
Jan 04 19:39:00 archlinux64 systemd[1]: Started Squeezelite Player.
[root@archlinux6 ~]# cat /proc/asound/card0/pcm0p/sub0/hw_params
access: MMAP_INTERLEAVED
format: S32_LE
subformat: STD
channels: 2
rate: 44100 (44100/1)
period_size: 64
buffer_size: 5645
@純米大吟醸 さま
私の環境ですと[ -a ]オプションにサンプリングレートの指定を
しなくても16/24bitの再生が出来ています。
何処かにbit指定しないといけない様な記載がありましたので
純米大吟醸様の指定が正しいのかと思います。
何分にも拾い読み出来る情報が古いですので検証あるのみですね。
色々触ってみましたら元ファイル 24Bits/96kHz FLACですが
Squeezeliteに[ -c flac:pcm ]を追加しましたらLMSの表示が以下になりました。
ファイルフォーマット: FLAC
長さ（時間）: 3:56
Volume Adjustment: -7.91 dB
ビットレート: 3119kbps VBR (以下のフォーマットに変換されました 4608kbps PCM)
Sample Rate: 96.0 kHz
Sample Size: 24Bits
結構まともな音になりましたが毎回設定ファイルを書き直してserviceをリスタート
するのは面倒ですのでSqueezeliteのコントロール出来るモノを探してみます。
PC側のLogitech Media ServerでSqueezeliteのオーディオセッティングで
Crossfabe : None
Smart Crossfade : None
Crossfade Duration : No
でフォーマット変換しない事がわかりました。
（使い方はまだまだ手探りです）
この状態でArchにloginしてみるとmpdは生きていますが、ympdはコアダンプしたのか
プロセスから表示されません。
続いてsystemctl stop mpd.socket mpdと停止すると約0.06mA程解放されました。
再生してみると
NASのFLACデータをLibFLAC 1.3.2 200170101が受けてSqueezeliteが処理しています。
squeezeliteの起動パラメタは変更していませんが音はAoEクオリティです。
mpdとは違うDaphileに近い、音が迫り来るanalogの様な力強さが感じられます。
まだまだ設定の数値的に落とし込む余地がありますが・・・
aoestatの結果は（同時比較出来ませんので採取時間は違いますが）
〇Arch smpd
period_us : 3333
poll_timeout_ms : 213
receive packets : 15719607 (AoE 15718602, Others 1005)
poll total : 9431797
poll/chunk x100 : 60
dreq/chunk x1000: 20
trip us/chunk : 20
act ns/chunk : 1497
〇Squeezelite
period_us : 3333
poll_timeout_ms : 213
receive packets : 2725904 (AoE 2725821, Others 83)
poll total : 1341403
poll/chunk x100 : 49
dreq/chunk x1000: 20
trip us/chunk : 18
act ns/chunk : 1336
と数値的にはsqueezeliteの軽さが少し生きているみたいです。
驚いたのはDACは進化しても20年も前のコーディックライブラリなんですね。
それがTubeの様な良い雰囲気を出しているのかも知れませんがオーディオは不思議です。
Analogは最新技術 vs シンプルで懐古な趣きがありますが面白いと思います。
私が出来る事はこの程度です。
たまには気分を変えて
AoEのRev.が上がっていくなか、44.1kHzだけ音飛びする現象がβ11.ex(だけだったかな?)にてありましたが、今はβ12.2でいい感じに聴けています。
Squeezeliteのパラメータ、ALSAのバッファサイズとピリオドサイズを一杯まで上げてます(-a 480:48::1)。あと安定につながるものか定かではありませんが、moOdeのSqueezelite設定で内部ストリームと出力バッファのサイズを
-b 40000:100000
としていましたので、これもおまじない(?)でつけています。
QNAPのNAS上に常駐させたLMSをサーバーに使用していますので、サーバー側の力不足があるのかもしれませんが、今日は3台プレーヤーを並行して走らせてもいい感じです。
@kan さん
おはようございます。私は今一杯
やりながらです。
教えていただいたようにSqueezeliteのALSAの設定に24bit指定は不要みでした。/etc/asound.confのS32をS24への編集はしています(hifiberry digi+ pro使ってます)。
USBのbus power落とす方法、参考にさせていただきました。RPi3はLANのLEDを消せないみたいで、何とかできないものかググってます。
@パパリウス さま、みなさま
いつも開発、検証お疲れ様です！
sqeezeliteについての報告ですが、β12はi2sの信号のインジケータが高速点滅して音が出ず、β12.1では途切れ途切れの再生でしたが、β12.2で再び通常の再生が可能になりました。
って、書いているうちに@純米大吟醸 さまと報告が被りましたね…、すみません。
うちは(-a 320:4:*:1)で再生しておりました、@純米大吟醸 さまの設定を参考にさせて頂いて、バッファサイズを増やしてみます！
うちは余ったtinkerboard sにarmbianを載せてNASとLMSと音楽セグメントへのルータをやらせているので、もっと非力かもです…。
@kan さま
自分もいろいろと情報を参考にさせて頂いております。
いつもありがとうございます！
私はMaterial Skinがお気に入りです。(笑)
@純米大吟醸さん
RPi3はLANのLEDを消せないみたいで、何とかできないものかググってます。
pi-3を持っていませんので確認出来ませんがコントロールチップが違うだけですので
dtparam=eth_led0=14
dtparam=eth_led1=14
でLEDは消灯しないでしょうか。
掲載場所を忘れましたがラズパイ公式（本国だったかな）で仕様が公開されているのを見た記憶があります。
こちらにも少し記載がありました。
https://github.com/ccrisan/motioneyeos/wiki/Turn-Off-LEDs
@tsumireが発言さま
私はMaterial Skinがお気に入りです。(笑)
色々なskinがあるのですね。
透過型のskinは初めてみました。
私は最近、Squeezerというアプリを見つけてスマホから UPnP風な感覚で使っています。
@kan さま
私は最近、Squeezerというアプリを見つけてスマホから UPnP風な感覚で使っています。
SqueezerはAndroidのアプリなんですね、iphone用のipengを見た時も色々と触れる場所があってワクワクしましたが、こちらも楽しそうなアプリですね！
自分はwindowsからSqueezelite-Xで操作することが多いです。
