@パパリウス さん、今日はクラシックやジャズの初回プレス盤を持っている方にSMPDで聴いていただきました。同じ音源での聴き比べは少し先になりそうですが、ほぼ最高といえるアナログ再生と肩を並べる音質になっているようです。また試聴できる機会がありましたら、ご報告させていただきます。まずは嬉しいご連絡をさせていただきます。
-
-
-
-
少し遅れましたが、raspberry-Pi4b(2GB)とInnoMaker HiFi DAC HATの組み合わせで問題無く動いています。SMPDのバージョンは1.0.3です。
RasPiの変更と合わせて電源をモバイルバッテリーに切り替えているため、RasPi3との厳密な比較はできていないですが、再生される音が力強くなるとともに、いままでだとじっくり耳を傾けないと聞き取れなかった音もきっちりと、それでいて奥ゆかしさはそのままに再生されています。
電源をDC-Arrowに切り替える予定があるので、どこまで素晴らしい音で再生できるか楽しみです。
このようなシステムを配布されているパパリウスさんに感謝しています。 -
-
-
UPnPとRoonBridgeのセットアップ手順をv1.0.xのFAQに追加しました。
UPnP
https://www.symphonic-mpd.com/forum/topic/108/よくある質問と答え-frequently-asked-questions-and-answer/11
upmpdcliパッケージにupnpdcli.confとupnpdcli.serviceも同梱しています。
RoonBridge
https://www.symphonic-mpd.com/forum/topic/108/よくある質問と答え-frequently-asked-questions-and-answer/12
-
-
-
-
-
-
@純米大吟醸 さん、こんにちは。
Squeezeliteをサポートできるか調べてみますね。
しばらくお待ちください。
セパレート化は、v0.4系で考案・実装した負荷分散構成です。
フロント・バックエンドの2台構成に分け、フロントのRPiでデコードしたPCMデータをバックエンドのRPiにLANで転送して再生する方式です。
I2S出力を担当するバックエンド側のプロセスを大幅に削ることができ、シングルコア動作が可能で、SMP由来のオーバーヘッドを避けることができました。
v0.4系当時、 @donuts-shop73 さんが開発したバックエンド専用SDイメージはCPU負荷が極めて低く、RTカーネルを凌ぐほどのリアルタイム性能を持っており、最高峰の音質を誇っていました。
Direttaは、独自プロトコルによる通信の最適化と、バッファコントロールによる通信の平滑化を目指したものであると伺っています。
いま私が取り組んでいるv1.0系のセパレート化も同じ目的を目指したものですが、通信負荷の低減、平滑化、再生負荷の低減、遅延の最小化という観点ではさらに先に進んだものになります。
v1.0系に実装しているドライバは、Linux標準のALSAドライバを使った再生に比べ、処理に必要なCPUサイクルを95%程度削減しています。
また、大きな遅延（処理時間の揺らぎ）の原因となるようなシステムコール呼び出し、コンテキストスイッチ、CPUキャッシュミスが発生しないよう、注意深い設計を行なっています。セパレート構成の通信には専用ドライバを用意する予定です。
最大の特徴はLinuxカーネルのネットワークスタックをバイパスする点で、NICのFIFOからカーネルスペースへのパケットのコピーや、カーネルスペースからユーザスペースへのパケットのコピーといった、冗長なメモリアクセスのほとんど無くし、symphonic-mpdの再生エンジン(rtalsaドライバ/xsinkドライバ)とシームレスに連携するものになる予定です。 -
-
@duf4 さん、こんにちは。
v1.0系のセパレート化の実装アイデアはずっと暖めてきたものでした。
RPi4版の開発が成功し、ようやくセパレート構成に着手できる準備が整いました。
私自身、このアイデアが実際に動くようになる瞬間をとても楽しみにしています。開発はRPi4 2GBモデルを2台使っています。
メモリ搭載量には依存しないように留意しますので、お好きなモデルを用意していただければと思います。
特にこだわりがなければ、私と同じ2GBモデルを用意いただくとトラブルを避けることができるかと思います。おそらくプロトタイプが動くようになるのが2〜3ヶ月後、ベータ版として公開できるのはさらに1〜2ヶ月後ではないかと思います。
フロントにRPi3も使えるようなアーキテクチャになるかどうかはまだ分かりません。
結果的に移植性の高い実装を実現できた場合は、RPi4用フロントをリリースした後に、RPi3への移植作業も検討したいと思います。 -
@パパリウス さん
direttaは試しましたが、面白いですね。Windows側のasioドライバが(diretta.syncということになるのですかね)、普通とは逆の発想で、Windows側はCPU負荷を無視して、ループさせて、正確なデータ送信のタイミングを調整するという方法をとっているようです。
さらに、このドライバが凄いのは動いているマシンのCPUコア数をチェックして、2以下だと100%CPUを使い切るのではなく、ループを時々中断してタイミングを調整し、他のプロセスがちゃんと動けるように配慮していることです(当然、平準化の精度は悪くなります)。また、JPLAYのような最初からネットワーク負荷の低減を実現している音楽再生ソフトが相手の場合は余計な邪魔はしないというプログラミングがされているようです。
まあ、Windows10配下では時間の精度が保てないので、考案された奇策だと思います。しかし、こういうソフトは初めて見ましたので、驚きました。 -
@yo さん
OSのプロセススケジューラにコンテキストスイッチを任せると数ミリ秒の遅延が生じることもあり、リアルタイム処理に支障がでます。
対策として敢えてビジーループさせるというのは、合理的な設計だと思います。symphonic-mpdのrtalsaドライバでもビジーループを活用しています。
Xenomaiのタイマ処理は高精度で、99.99%以上は200ナノ秒未満の精度で指定時刻に処理を開始することができます。
ですがこれも完璧ではなく、低頻度ながら、最大で2マイクロ秒程度の遅延が生じることがあります。
そこで、予定時刻より2マイクロ秒早く起床させて、指定時刻までビジーループさせてクロックをチェックしています。
この方式により、18ナノ秒(RPi4のオシレータの1チック)未満の精度でPCMデータの書き込み処理タイミングを揃えています。 -
@パパリウス さん
対策として敢えてビジーループさせるというのは、合理的な設計だと思います。
symphonic-mpdのrtalsaドライバでもビジーループを活用しています。
なるほど、そういうことでしたか。
direttaのコア毎のCPU負荷のグラフを見ていて面白いのは、ある間隔の間は、100%CPUを使い切るのですが、時々、ヒラリヒラリと京都五条大橋の欄干を飛び回る牛若丸のようにCPUを飛び移るのですよね。そこから、また暫くビジーループし、弁慶の太刀(多分、OSの割り込み)が入ると別のCPUに飛び移る。音楽を聴くのを忘れて、グラフを見つるということになりますです:face_with_rolling_eyes: 。 -
-
