RPi4版 v1.0系 不具合報告スレッド

---

@hiroget9 さん

ブートローダのバージョンに左右されることから、ハードウェアの初期化処理が何らかの形で関わっているのだろうと思います。
ただ、初期化処理の詳細を知る術がないため、原因を探るのは容易ではありません。。。

例えばですが、GPUブートローダを古いものから順に試していき、現象が解消するバージョンを特定することができれば、ブートローダのリリースノートから原因を推測することはできます。
新しいGPUブートローダを採用できれば話は早いのですが、2019/11/18版のGPUブートローダに追加された省電力機能が曲者で、これはかなり音質が悪くなります。
（うまい設定方法を見つければ新バージョンでも音質を確保できるのかもしれませんが、確証はありません）

できれば、一つ手前の2019/11/15版か、それよりもさらに古いブートローダを採用したいというのが正直なところです。

gpuboot.v106.tar.gzで改善がみられた方にお願いなのですが、試しに2019/11/15版も検証していただけませんでしょうか。こちらでも改善がみられるならとても助かります。

wget https://www.symphonic-mpd.com/release/gpuboot.191115.tar.gz

@パパリウス さん

nzatoです

v106.GPUブートローダーをあてました。

今まで、しばらくするとDashboard表示でWebUIがフリーズをしていたのが、今のところ起こっていません。再起動しなかったrebootも、問題なく再起動してきます。

このまま一晩様子を見てみます。

@パパリウス さん

gpuboot.v106.tar.gzで改善がみられた方にお願いなのですが、試しに2019/11/15版も検証していただけませんでしょうか。こちらでも改善がみられるならとても助かります。

DigioneとSabreBerry32で検証しました。
Dashboardを表示させても、WebUIフリーズしません。
リブートでも問題は起きません。
これで一晩様子を見てみます。

パパリウスさん

gpuboot.v106適用後の確認にて再発はありませんでした。
（まだヘビーにはテストできていませんが、air play切断後の挙動やshutdownにも問題は起きません）

ところで、これはV1.0.3まのでものとは差異があるのでしょうか、為念。

なお、2019/11/15版での確認はすみません、明日行います。

「省電力機能」の詳細の中身は判っていませんが、かってPCオーディオでこの手の対応で音が良かった経験はありません。今後うまく纏まると良いのですが、、、

いろいろとご苦労をお掛けして申し訳ないです。

@パパリウス さん

さっそく前言撤回です。
DigioneでDashboardを表示させて、WebUIフリーズしました。
sshログインからの“shutdown -h now”を試しましたが、すぐには接続が切れません。背面LEDも点灯しません。
SabreBerry32では問題ないようなんですけどねぇ。

ジャイアンさん

HATにより事象発生の有無、頻度が異なることがあるのかもしれませんね。

もう少しテストを重ねる必要もありそうですが、もしそうだとすると、多様なHATが存在していますので、対応がかなり難しくなるかも。　ほぼどれでも問題無く稼働するという最大公約数的なブートローダーのバージョンを絞り込まねばなりませんので。

@パパリウス さん

nzatoです

v106.GPUブートローダーをあてました。

８時間ほど動かしましたが、Dashboard表示でWebUIがフリーズをしません。rebootも、問題なく再起動してきます。
　SabreBerry32です。

@パパリウス さん

gpuboot.v106.tar.gzで改善がみられた方にお願いなのですが、試しに2019/11/15版も検証していただけませんでしょうか。こちらでも改善がみられるならとても助かります。

一晩動かして、結局二台ともDashboard表示でフリーズしてしまいました。

ジャイアンさん、パパリウスさん　　　　　　CC.皆様

おはようございます。

2019/11/15版はどうもヒットしないようですね、、、従い当方はV1.0.5&gpuboot.v106.tar.gzの組み合わせの確認を継続することといたします。（現在まで不都合事象なし）

なお、V1..0から順を追って確認しようとして気が付いたのですが、V1.0から順次バージョンを上げること（あるいはV1.03へあげること）などはupdate処理の制約からできないんですね。
新しいSDカードイメージが出た場合など「現行のバージョンのSDカードバックアップ取得（各種設定済の状態で）」を為念行っておくことが望ましいな～と改めて感じました。

（注記）SDカードのイメージバックアップにつきましては、先にディスカッションテーマとさせていただきました。

パパリウス さん

最近、R&D Clubに参加させて頂いて初めての投稿になります。

Donuts Shopさんのx86_64-upnpgwと組み合わせて、SMPD-1.0.5βをupnp rendererとして聴いています。
新しいβドライバの音色は素晴らしいですね。各音が伸びやかに響くようになって立体音像が更に素晴らしくなったように感じました。

今までは複数台のi5,i7PCにWS2019,AO3,Diretta,MinorityCleanとてんこ盛りにしたシステムでJplay dualやHQPe-NAAを聞いておりましたが、Pi4で同等かそれ以上の音色を出せるとは驚異的です。

これから更にどの様に進展されるかとても楽しみです。
これからも宜しくお願いいたします。

パパリウスさん　　　　　　　　　　　　　　CC.皆様

経過報告です。

１．V1.0.5とgpuboot.v106.tar.gzの組み合わせ
　　そこそこの時間再生して確認いたしましたが事象再発無しでした。（mpd、air playとも）

２．上記に加えて以下の設定を行い確認いたしましたがこちらもOKです。
　　・マスターHAT用dt-blob.binの改訂版
　　・ベータ版ドライバー（1番目の方です、2番目は未）
（注記）この組み合わせが本来のものなのか判りませんが、ベータドライバーで起こっていたプチノイズの発生が無い？ような。また音も存外にイケてます。

@ジャイアンさん
検証いただきありがとうございます。
11/15版はNGということですね。
この結果を踏まえ、最新に近いGPUブートローダを採用する前提でチューニングすることにしたいと思います。

@ゴンザエモン さん
gpuboot.v106に同梱したGPUブートローダは「2020/7/2版」で、現時点での最新となります。

RPi4のファームウェアは週1ペースで更新されておりまして、そのなかでもGPUブートローダは高頻度で更新されているファームウェアの一つです。

2019/11/18版に追加された低消費電力機能は性能低下無しに消費電力を低減するという触れ込みのもので、大半のRPi4ユーザにとって歓迎すべきものです。
ただ、ここで言う性能というのはあくまでスループットの話です。

smpdのようなリアルタイム性能が重要なシステムにとってクロックの動的変更は最も避けるべきものです。
PLL周波数と各種クロックの算出ロジックも大幅に変わり、これと同時にconfig.txtのクロック設定もそれ以前のバージョンとは挙動が変わってしまいました。
2019/11/18以降のGPUブートローダを採用するには、これらのノウハウを1から構築して再度チューニングする必要があります。

@minuree さん

ご感想をいただきありがとうございます。

smpdのようにI2S出力を行うシステムの場合、比較対象はAmaneroやXMOSといったUSB-I2Sを行うDDCであったり、SPDIFレシーバ、FPGAで実装されたFIFOが該当するかと思います。

USB出力のPCトランスポートとは役割が異なりますので、直接の比較はできないものの、、、お使いになっている「USBレシーバ + PCトランスポート」と同水準の音質を達成できていることを嬉しく思います。

おそらくはより低ジッターなUSBレシーバに切り替えることでボトルネックが解消されるのではないかと思いますが、レシーバとDACチップの間にSRC/ASRC ICが挟んであったりすると話は簡単ではありませんね。

smpdに次のブレークスルーが訪れるのは、セパレート構成用の新ドライバを搭載するタイミングになるかと思います。

うまく実装が進めば、年内に面白いものをお見せできると思います。ご期待くださいませ。

パパリウスさん

お忙しいところ、コメントを頂きましてありがとうございます。

パパリウスさんが仰られる通り、PCオーディオとRasPiオーディオでは音質を左右する機器構成は異なりますので単純に音楽再生ディストリビューションの客観的な比較は出来ませんね。特に近年はディストリビューションも再生装置も目まぐるしく進歩しており「音質の絶対値」は流動的で、自分の主観的な経験による「絶対値」も振り回されているのが現状です。（笑）

最近はAmazon Music HDをHQPe-NAA-Direttaシステムで聞いている時間が長くなりました。HQPeは本来、yoさんが最近ご自身のホームページで紹介されておられる通り、DLNAレンダラーとして使われることが一般的かと思いますが、UAC2.0入力機能が有って簡単にAmazon Music HDのソースをHQPeの音に変換出来ます。私の音楽ライブラリーは殆どが96KFlacなのでAmazon Music HDソースと音質的には変わりがありません。実際にAmazon Music HDとDLNAサーバとの大きな音質差は感じられず、どちらもHQPeの音質です。（何故かAmazone Music HDの方が澄んだ音色で、無限のライブラリが魅力です）HQPe-NAA-Direttaシステムが大きなDDCとなったと思っています。私にとって音楽ソース入力からDAC入り口までが1つのDDCと言う感覚です。

このスレの「不具合報告」に該当しない内容を書いてしまいましたが、私の場合SMPD-1.0.5βをレンダラーとして6時間ほど視聴しましたが問題はなく快適でした。

今後のSMPDのセパレート化を楽しみにしてお待ちしております。

パパリウスさま、みなさま、

のんびりした報告で恐縮です。

RP4B rev1.2 4GB（1GBに制限）に積んだ Sabreberry32pro が、SMPD ver 1.05 に dt-blob.bin.master.v105 を当てたことで起動不良と再起動不良がなくなったことはご報告済みです。
この電源は、Rコア6.3V/1.6A x 2 に DC-Arrow x 2 という絶対的に容量不足であるため、RP4Bに積み替え以降の起動不良は電源容量によるものと信じ込んでおりました。しかし、それが解消され、安心して音楽を聞けるようになりました。そして音も大きく改善されました。

この５日ほどいろいろな曲を、SMPD ver1.05/IANCanada FifoPi(CCHD957)/HDMIpi/D90 と比較しつつ聞きまくりました。
RP4B以降、再生される音は今ひとつだったのですが、完全にSMPD 0.9.6を凌駕し、期待以上の音になっております。

穏やかでピュアです。しかし音に鈍さなどまったくなくリズミカルで強い音もきちんと出してきます。IANCanada/D90 の持つすっ飛んでくるような音とは無縁の、奥に広がるきれいに澄んだ響きは、ver 1.05b に通じるところがありますが、それよりわずかに強さがあります。

IANcanad/D90 の強くスリリングな音に少し疲れたときやうまくあわない曲にぴったりです。

それにしても、ver 1.05 はこういったDACの特性をとても良く引き出して変幻自在です。IANCandaにD70を接続するともっと真面目でストイックな音になります。面白いです。

それにしても、6.3V/1.6A x 2 で、RP4B/SMPD ver1.05 が完璧に再生できるとは、電源問題は深いです。もちろん、たかじんさん仕様のサイズアップしたRコアトランスであること、その後に純正仕様のDC-Arrow が２台つながっているとしても予想できない活躍であります。

マスター用の dt-blob.bin の威力に関するご報告その２でありました。

β3をアップしました。
プチ音の対策がほぼ完了しましたので、ご確認いただければと思います。

V=beta3;cd /run/;wget -O - https://www.symphonic-mpd.com/release/$V.tgz|tar xzf -;$V/install.sh;rm -r $V;cd

申し訳ないのですが、現象が解消するGPUブートローダの特定にご協力いただけませんでしょうか。
（こちらでは再現させることがとても難しく、特定が困難でした。）

GPUブートローダの詰め合わせをアップしました。

wget https://www.symphonic-mpd.com/release/gpuboot.tgz

tar xfで解凍していただくと、20191118版から20200512版までのGPUブートローダが入っています。

現象が発生するバージョンがあればご報告いただけないでしょうか。
発生率の高い環境であれば「発生しないこと」を検証いただいても結構です。

@パパリウス さん

うけたまわりでぇ〜す。
ですが、いまのところ現象再発していません（頭から順番に検証しています）。

この現象、CPU温度が関係している可能性はないでしょうか？
私の環境では、クーリングがうまくいっている個体（41℃ふきん）では発生率が低く、比較的CPU温度が高い個体（50℃後半）では高くなっています。

パパリウスさん

GPUブートローダの箱詰めを頂戴いたしましたが、何と35通りもあるので絶句しております、、、（笑い）

さて、どのように当たりをつけるか、闇雲に順番にやってみるか、などと思案しておりますが、V1.0.3（ここまでは確実に発生していないこと確認済）ではどの日付のバージョンだったのかご教授いただけますでしょうか。

それを軸にある程度のグルーピングをしてアプローチする方が手間や時間的にもベターかな？　とも思案しております。

それにしても「無茶苦茶な」更新状況ですね～　ラズパイ本舗もこの辺り大分苦労されているようにも見受けられます。

なお、このGPUブートローダですが、カーネルなどとの連携の要はあるのでしょうか？　全くないのであれば、逆に今まで動いていたもの（V1.0.3ベース?）を継続することで良いようにも思えるのですが。

@ジャイアン さん @ゴンザエモン さん

2019/11/15版はジャイアンさんが検証してくださいましたので、それ以降のバージョンを箱詰めしました。

v1.0.5で採用しているのは2019/11/15版よりもさらに古く、8月版のブートローダとなります。

箱詰めしている中で最新の2020/05/12版は、問題が解消することをこちらで確認済みです。
従いまして2019/11/18版から2020/05/01版のどこかのバージョンで現象が解消するようになっているはずです。

なお、GPUブートローダとカーネル（内のドライバー）が互いに連携している箇所もあるはずで、GPUブートローダだけを更新しても有効にならない機能もあるはずです。
ただ、vcgencmdが応答しなくなる問題だけに着目するなら、GPUブートローダの差し替えだけで検証は可能ではないかと思います。

再現率の高い環境ならば、バイナリサーチが一番効率的です。

最初は2019/11/18版と2020/05/01版の真ん中にあたる、2020/02/10版を検証します。
これで問題が再現するなら、02/10版よりも前は全てNGということが分かります。
次は、02/10版から05/01版の真ん中にあたる2020/04/07版を検証します。
、、、というように、半分ずつ絞り込んでいくという手順です。