RPi4 Edition v1.0.0配信スタート (RPi4 Edition v1.0.0 release)

---

@純米大吟醸 さん、こんにちは。

大変覚えやすいハンドルなので、登録時に分かりやすくて助かりました 。
Squeezeliteのサポートをご希望の理由はLMSのプレーヤーとしてお使いになるためでしょうか。であれば、Q&AにSMPDのupmpdcli化の方法が紹介されていますので、これを使い、SMPDをレンダラー化すれば、LMSから再生プレーヤーとして選択出来るのではないかと思います。よろしければ、お試し下さい。

@純米大吟醸 さん、こんにちは。

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ドライバ)とシームレスに連携するものになる予定です。

@パパリウス さん

v1.0系のセパレート化！！
楽しみにしております。
この構成の推奨環境/機材って有りますか？
Pi3+3でもPi4+4でも良いとか、
フロントPi4_4g・バックエンド4_2gがお勧めとか
予算的には、Pi4_2g+4_2gだと安上がりで嬉しいですね。
まだ、時期早々ですか？

@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に飛び移る。音楽を聴くのを忘れて、グラフを見つるということになりますです 。

@パパリウスさま
いつもお世話になっています。
一つお願いがあり、RPi4 Edition v1.0.0配信スタートページのFAQのリンク先がUser Guide (v0.9.6)になっており、知らない人はSSHログイン時、ユーザー名がpiではなくrootやSDカード領域拡大方法などなど、どこに書いてあったっけ？と探すのに時間がかかります。
お忙しいとは思いますが、訂正のほど宜しくお願いいたします。

@toshi300 さん

ご指摘ありがとうございます。うっかりしていました。
インストールガイド・FAQのリンク先をv1.0.xに修正いたしました。

@パパリウス さま
とんでもございません！
訂正、ありがとうございました。