Raspberry Pi 4 Model B

オーシャン

おはようございます、オーシャンです

https://www.switch-science.com/catalog/5680/
スイッチサイエンスもP4を扱い始めました
element14製らしいのですが、7700円になった様です
何かメリット有りましたっけ
1100円の差は大きい

パパリウス

残念なお知らせですが、Pi4版の開発を中断しようと思います。

64bit版Xenomaiカーネルを作成してドライバ等の移植を進めましたが音出しできなかったため、問題の切り分けを兼ねて32bit版を作成してみました。

32bit版ではaplay-rt/rtalsa/xsinkでの音出しに成功しましたが、

音声に大きなノイズが混じる
曲の変わり目でハングアップする
rebootすると、OSが立ち上がらない(電源の抜き差しを繰り返すと、稀に正常起動する。）
USBに外付けSSDを接続するとハングアップする

など、64bit版Xenomaiカーネルと全く同じ課題を抱えており、安定とは言い難い状態でした。

Pi4に期待する理由は数多くあります。

LPDDR4のSDRAMを搭載(LPDDR2のPi3に比べて帯域が4倍)
CPUキャッシュの強化
Pi3比2〜3倍の整数演算性能
54MHzのオシレータを搭載し、18ナノ秒精度でXenomaiスレッド/RTDMドライバを制御可能
割り込みコントローラ GIC400を搭載
USBから独立したイーサネットレシーバ(BCM54213PE)を搭載

将来的にカーネル/ドライバ/Xenomaiのサポートが改善することを期待し、その時が来るのをじっくり待つことにしたいと思います。

Xenomaiの開発元がPi4Bを評価ボードに加えてくれれば大きく前進するものと思いますが、、、評価ボードの選定基準は明文化されておらず、実現性は定かではありません。

ジャイアン

@パパリウスさん

私はPi4版開発中断を支持します。
Pi4はスペックを思うと非常に魅力的ですが、開発者がパパリウスさん一人という圧倒的なリソースの低さに加え、開発環境が整っていないという現状を考えれば、致し方ないと考えます。
私個人的には、追加の投資をしなくて済むので、チョット安心しております。

パパリウス

@ジャイアンさん

私個人はなんとしてもPi4版を実現させたいと思っています。

各種ベンチマークでPi4の性能の高さを目のあたりにし、Pi3版が突き当たっている壁(メモリ性能の壁)を突破した先にある音を聞かせてくれるものと期待しておりました。

Pi4はハードウェア周りの進化が著しい分、ソフトウェア(ドライバ・Xenomai)のサポートが追いつくには相応の時間がかかりそうですね。

Pi4で音出しできる環境・条件が整うことを祈るばかりです。

Xenomaiが正式にサポートしていないプラットフォームに労力を注ぎ込むのは、とてもリスキーだということを実感しました。（精根尽きました。。。。）

少々保守的ですが、当面はPi3Bをメインに据えて取り組んでいこうと思います。

eric

パパリウスさん　Pi4B版の開発中断は仕方が無いと思います。Pi4Bの仕様に惚れ込んで大きな期待を抱いた一人ですが膨大な関連ソフトが現状でサポートされないのもやむを得ないでしょう。当面購入したPi4BでNAS作って使ってゆこうかとおみます。そのうちにソフトも充実してくると思いますので気長に待ちたいと思います。パパリウスさんの貴重な開発力を今までのPi3Bに振り向けてください。

hiroget9

@パパリウスさん
Pi4の性能の高さについては、volumioで実験してみましたが、pi3より格段に良くなっていますね。
でも、今のsmpdの音質には及ばないと思います。やはり設計思想の違いなのかと思います。
pi3で聴かせていただいているsmpdの音はとても心地良く、他に浮気する気になりません(^^)/
smpdがPi4に対応されれば、さらに心地良い音になるのではと期待しつつ、気長にお待ちしています。

yo

@パパリウスさん

Xenomaiの無いSMPDなんて、某のない某々のようなものですから、一時的撤退に賛成です。

課題は、海外展開はrpi4対応を前提に本格展開したらどうかと作戦をたてていましたので、シナリオの修正が必要ですかね。
もう一つ、MPDのヴァージョンアップによるDSDネイティブへの対応ですが、これも気長に待ちます。急ぐものではないので、綺麗な形で対応して頂ければと思っています。

sunatomo

Raspberry Pi 4 Model Bで@パパリウスが発言 :

将来的にカーネル/ドライバ/Xenomaiのサポートが改善することを期待し、その時が来るのをじっくり待つことにしたいと思います。

正面突破で先駆者になるのもあるとは思いますが、そのために割かれるリソースはかなり重たいですよね。
（パパリウスさまレベルの開発能力のある方が最低でも3人は必要そう...）

皆さんがお書きの通り、開発方針についてはパパリウスさまのご意向で全く構いません。
（パパリウスさまお一人のプロジェクトですので当然だと思います。）

あと、ここでぶら下がるのはちょっと変かもしれませんが、yoさま記載の海外展開について1点だけ
お聞きしたい事項があります。
ympdのダークテーマ化（背景を黒もしくは暗灰色にしたもの）、構想はお有りでしょうか？
白色人種の場合、虹彩の色素が不足しているため通常のモニターの輝度が高いのを嫌がりダークテーマを好むようですし、海外の競合ディストリも私の知っている限りは全てダークテーマだったはずです。

ざっとgithubのympdのリポジトリサイトを見ましたが、CSSを外出し出来ない（実行ファイルに全てアーカイブ化？）構造のように見受けられます。
もし、何かお手伝い出来ることがありそうでしたらお声がけ下さい（期限を切られると対応出来るか難しいですが...）。

yo

@sunatomoさん

ympdのダークテーマ化（背景を黒もしくは暗灰色にしたもの）、構想はお有りでしょうか？
白色人種の場合、虹彩の色素が不足しているため通常のモニターの輝度が高いのを嫌がりダークテーマを好むようですし、海外の競合ディストリも私の知っている限りは全てダークテーマだったはずです。
ざっとgithubのympdのリポジトリサイトを見ましたが、CSSを外出し出来ない（実行ファイルに全てアーカイブ化？）構造のように見受けられます。
もし、何かお手伝い出来ることがありそうでしたらお声がけ下さい（期限を切られると対応出来るか難しいですが...）。

貴重なアドバイスありがとうございます。是非お願いします。
パパリウスさん、CSSを外だしする方法のご教授、よろしくお願いします。

パパリウス

@sunatomo さん

ympdのソースをアップします。
~~プラグイン機能を修正中の中途半端な状態ですが、ご容赦ください。~~
~~ympd.v093b.tar.gz~~

ympd.v092.tar.gz
（色々と不備がありましたので、v0.9.2のソースをアップしなおしました。）

要らないファイルが混入していたり、ビルド用スクリプトが入っていたりと混沌としていると思います。
何か質問があればなんなりと。

バイナリに埋め込まれていないファイルがリクエストされると、/var/lib/mpd/music以下のファイルを返すような改造を行なっています。
（カバーアートの表示はこの仕組みを使っています）

htdocs下にあるファイル(index.html、css、js等)のうち、バイナリに含めたくないファイルをどこかに退避した状態でビルドしてください。

例えば

index.html
js/*

を退避してビルドしたなら、

/var/lib/mpd/music/index.html
/var/lib/mpd/music/js

に配置すればOKです。

配色については、htdocs/css/bootstrap-theme.cssに定義されているように見えます。

Xenomaiのメーリングリストで64bit対応について質問してみました。
なにかヒントが得られるかもしれません。

sunatomo

@パパリウスさま、お手数おかけしました。

配色については、htdocs/css/bootstrap-theme.cssに定義されているように見えます。

ソースコードご提示前に実は我が家のブラウザで表示された状態でhtmlを生成し、
F12開発者モードでちょっとだけ触りを見ていました。
（スタイルシートはbootstrap.css・bootstrap-theme.css・mpd.cssの3本立てですね）

という訳で、年末進行中のため、おおよそのスケジュール予定は以下の通りで進めます。
・CSSを解析し、ダークモードのたたき台＋解析資料を作る　12/13目標
　あくまでたたき台です。正直私にはデザインセンスは無いので、
　そっちが得意って方に是非腕を奮っていただきたい
　（そのための情報提供ですね）。

・ympdのビルド（CSS外部ファイル化）＋提供　年末目標
　恐らくビルドはあっさり出来るかもしれないですが、
　まずはCSSを調べてみたいという個人的な優先度です。

以降、進捗については私のスレッドで報告します。

Xenomaiのメーリングリストで64bit対応について質問してみました。
なにかヒントが得られるかもしれません。

良い回答が出ることを期待します。

yo

@sunatomoさん

以降、進捗については私のスレッドで報告します。

納期はありませんので、のんびり、マイペースでやって下さいませ。

eric

パパリウスさん
当面使う事も無くなったラズパイ4BをNASとして使う事にして４TBのハードディスクをUSB3で繋いでOpenmediavaultをインストールして使う事にしました。ファイルの移行に時間がかかりましたが無事ラズパイNASが稼働を始めました。

sunatomo

@パパリウスさま
もし知っていたらゴメンナサイですが、Raspberry Pi４からはeepromとUSBコントローラのファームウェアがかなり頻繁にアップデートしているしているようです。
release-notesへのリンク
symphonic-mpdのデフォルト設定ではUSBは無効化するでしょうけど、初期のファームではUSBコントローラのチップ発熱が大きく問題になったため、修正されたらしいです。

パパリウス

@sunatomo さん

USB3 Host controller (VIA VL805)の
ファームウェア変更で発熱が大きく抑えられることを確認しています。
実測で5度前後の変化がありました。

正式リリース(?)されましたら、こちらのフォーラムでも情報共有したいと思います。

パパリウス

RPi4版は、Xenomaiの後継ソフトであるEVLを採用することにしました。

https://evlproject.org/

Xenomaiのメンテナの1人であるPhilippe Gerumさんが開発を進めているソフトです。
PhilippeさんはXenomaiのarm/arm64向けパッチの大半をコミットしてきた方で、メーリングリストで"今後はEVLに注力する"と発言されてらっしゃいました。

XenomaiカーネルではPi4でUSB利用時にハングアップする現象を回避することができませんでしたが、EVLではカーネルにパッチを当てることでUSBも動作するようになりました。（あくまで応急処置に過ぎず、安定動作とまではいきませんが、、、外付けSSDが実用レベルになりましたので開発が捗ります）

年末年始に、aplay-rt/rtalsa/xsinkをEVLに移植する作業に取り掛かりたいと思います。

RPi4版のスペックは

Linuxカーネル 5.x系を採用
リアルタイムカーネルにEVLを採用
カーネル/アプリケーションは全て64bitでビルド
RPi4専用のビルドオプションを使用
コンパイラにgcc9.2 (またはgcc10)を採用
EVL向けにデバイスドライバを新規開発

となりそうです。

eric

@パパリウスさん　ソフトの変更で-5℃は大きいですね是非対応をお願いします。

sunatomo

@パパリウスさま
EVLの件、ちょうどXenomaiのメーリングリストでご本人がその話を投稿していたところは見ましたが、
そこまで真面目に英語を読み込んでいなくて「新しいリアルタイムカーネルが出来るんだー」くらいしか理解していませんでした。
改めてご紹介頂いた内容を見る限り、Raspberry Pi4で開発するには最適解かと思います。

正直、EVLについてはまだ日本人がブログなどで解説記事を書いたものを私は見たことがないため、先駆者となると思いますが頑張って下さい（正直Xenomaiを音楽再生で使いこなしたという意味でも既に先駆者ですけどね）。

私事になりますが、Raspberry Pi4 の2GB版とファンレスのメタルケースを注文しました（個人的には１GBで充分だろうと思いましたが、まだサイトにないため）。恐らく今年中に届くと思います。
もし、何かお手伝いが必要な際はお声掛け下さい（とりあえず年末年始はympdの方、仕上げます）。

パパリウス

@sunatomo さん

Pi4向けにEVL版のカーネルをビルドしてみました。

aplay-rt/RTDMドライバの移植はなんとかなりそうで、ビルドも通ってあと少しで動きそうなんですが、、、
I2Sのドライバをロードするとハングアップするという現象があり、これがなかなか解消できません。

EVLでもXenomaiでもどちらでもいいので、Pi4への対応を開発元に要望してみようかなと思っています。
ハードウェアの対応がままならない状態では、どうにも歯が立ちません

sunatomo

I2Sのドライバをロードするとハングアップするという現象があり、これがなかなか解消できません。

え、マジですか...
symphonic-mpdは「リアルタイムカーネルによる超低レイテンシー」が他の競合他者には絶対マネができないところだと思いますので、
動くようになるまでは現行版で気長に待たせて頂きます。
（私の感想ですが、Pi3の現行版でもPi4での競合他者には到達できない領域まで充分来ていると思います。
Pi4の良好なハードウェア構成で更なる高みが望めると期待しますが、
カーネルが対応しなければ難しいですよね。）
↑
ゴメンナサイ。私の現状での技術レベルではクロスコンパイルによるカーネルビルドくらいまでが限界です（というわけで、ympdの方はお手伝いはできると思いますのでご容赦ください）。

ちなみに、リアルタイムカーネルのかなり大きなターゲットであるロボット制御とかではもしかしたらPi4までのパワーは必要ないのでしょうか？
それとも発熱を考慮してそのような用途では使いたがらないのでしょうか？