パパリウスさま
VideoCore電圧、ゴンザエモンさま、nzatoさまのご報告にきちんと書き込まれているので個体差の大きさに気が付きました。みなさまの的確な方向性ご提示に感謝です。
-
-
@パパリウス さん
その後、over_voltage=1で10時間以上稼働しましたが、ダッシュボードの表示は問題ありませんでした。
電圧を測りました。バージョン1.0.5ノーマル。
電源は窒化ガリウム電源アダプタからストレートです。マスターモード環境 hifiberry digi+pro
over_voltage=1
0.8771V
over_voltage=2
0.9035Vスレーブモード環境 HAT無し
over_voltage=1
0.8789V
over_voltage=2
0.9087Vうちの環境だと、マスター、スレーブモード共にover_voltage=2も魅力的に聞こえます。
音楽の生気を感じます。
デフォルトで2である必要は無いと思いますが、選択出来るようになったのは嬉しいです。ありがとうございます。mikeさんのご報告を拝見すると、外部供給電圧が上がるにつれコア電圧も上がるということなのでしょうか。
外部供給電圧を上げて聴かれていた皆さんは、この音を聴いていたのかなあ、と思いました。 -
@パパリウス さん
beta4をアップしました。
プチノイズの頻度を教えていただければと思います。短時間ではありますが試してみました。
使用環境
Rpi-4B Ver.1.2(2GB)
SB32+PRO DoP:Master mode
Spotify発生頻度に波があり数値での表現が難しいですが前バージョンよりも発生頻度は高いように感じます。
β3ドライバーの報告です。
β3ドライバー適用前は曲ごとに頭の部分にプチノイズが３~４回発生していました。
適用後は３~４曲ごとに１~２回発生と大きく減少しました。β3ドライバーで上記の報告をさせていただきましたが、β4では曲毎に、プチ、プチプチ、と連続で発生する場合もありました。
私の環境では他の方よりも発生しやすいようです、、、。 -
@パパリウス さん
beta4のプチノイズ評価になります。
私もflyingaceさんと同じ結果・感想です。Rpi4B+FifoPi, Rpi4B+msberryDAC の両方とも発生し、FifoPiはhifiberry-dac, rpi-dacの両方のドライバーで発生します。
確認方法としてはSpotifyで20秒くらい聞いて次の曲に飛ばしています。最初の5秒以内くらいにプチノイズが発生し、一回だけの時と複数回発生する場合があります。次の曲に飛ばしても発生し、これが連続します。しかし発生しなくなると、３－４曲くらいは発生しなくなります。
このような状況です。よろしくお願い致します。 -
-
-
-
-
皆さんからご報告いただいたCore電圧を元に、OK/NGの境目をまとめてみました。
over_voltage 1あたり0.025Vで引き算をしてテーブルを埋めている箇所があります。0.8500VだとOK/NGが混在、0.8600Vなら安全圏といったところでしょうか。
HATによって事情は異なってくると思いますが、目安としては分かりやすいですね。HAT over_voltage Core voltage stats owner SabreBerry32 0 0.8275 NG nzato SabreBerry32 1 0.8525 OK nzato inno 0 0.8605 OK nzato Digione Signature 0 0.8416 NG ゴンザエモン Digione Signature 1 0.8666 OK ゴンザエモン スレーブ 0 0.8539 NG? DYNA81 スレーブ 1 0.8789 OK DYNA81 digi+pro 0 0.8521 NG DYNA81 digi+pro 1 0.8771 OK DYNA81 スレーブ(Fifopi) 0 0.8578 OK mike SB32+PRO DoP 0 0.8648 OK mike inno 0 0.8525 OK パパリウス SB32+PRO DoP 0 0.8662 OK hiroget9 -
-
@flyingace さん
ご報告ありがとうございます！
タイミングが絡む問題でして、何かの拍子にプチっとすることはあるかもしれません。
実用上、ほぼ気にならないレベルになれば良しとしたいと思います。（100%完全に防ぐためには性能面で犠牲にしないといけない部分があり、悩ましいところがあります。よいアイデアが浮かんだら今後も手直ししようと思っています）
-
パパリウスさま
Sabreberry32pro (master mode) を ver 1.0.6 に up し、 NAS/44.1KHz/16bit とspotifyで一時間ほど再生しましたが特に問題は生じませんでした。
レイテンシーグラフもきれいです。core voltage とともに over_voltage の設定内容が表示されるのもわかりやすいです。
updateはカーネルのアップデートに少し時間がかかるようです。またマスターモードなのでご注意書き通りチェックサムNGと出ましたがリブートプロンプトが出ますので気にならず先に進められました。
音に違いがないように思いますがしばらくいろいろ聞いて確認するつもりです。
（IANCanadaは電源スイッチ改良中のためまでテストできていません。） -
-
-
-
-
-
パパリスさん CC.皆様
V1.0.6、air playを含めて快調です！ （ベータドライバーの課題は解消されているように思います）
vcgencmdに係る問題もover_voltageの設定によって一段落して正直ホっとしています。お疲れさまでございした、、、
（電圧が低いと挙動不審が起こるというように単純にも理解してみましたが、正しい理解なのか判らずにいますが）なお、ちょっと解説していただければと思うのは「core_freq」の設定についてです。
2019年8月1日（？）バージョンのブートローダーではcore_freqの指定通りのcore clockで稼働するようですが、2019年11月19日のバージョンではこの設定がconfig.txtにあるにも関わらず指定のcore clockにはなりません。不思議に思ってドキュメントなど確認したところ、後段のような記述がありました。core clockが想定の設定値にならない場合、どのような内部処理と絡んでの音への影響が出来るものなのか当方中身が判っておりませんが、一方で何らかの内在された問題を抱えているファームウェアを継続するというのも少し気になるところです。音質に係るファクターが大きい部分にようにも思われますので後学の為にも簡単にご教授いただければ幸甚です。（あるファームウエアのバージョン以降は固定クロックではなく、自動的に可変クロックになってしまう、ということなのでしょうか？）
（記載場所）
https://www.raspberrypi.org/documentation/configuration/config-txt/overclocking.mdに記載されている「Overclocking op;tions in config.txt」に次のような一文があります。
---引用開始
Specific to Pi 4B
The core_freq of the Raspberry Pi 4 can change from the default if either hdmi_enable_4kp60 or enable_tvout are used, due to relationship between internal clocks and the particular requirements of the requested display modes.
Display option Frequency
Default 500
enable_tvout 360
hdmi_enable_4kp60 550Changing core_freq in config.txt is not supported on the Pi 4, any change from the default will almost certainly cause a failure to boot.
It is recommended when overclocking to use the individual frequency settings (isp_freq, v3d_freq etc) rather than gpu_freq, as since it attempts to set core_freq (which cannot be changed on the Pi 4), it is not likely to have the desired effect.
---引用終了
-
@ゴンザエモン さん
検証にご尽力いただき誠にありがとうございました。
vcgencmdが応答しなくなる問題、ダッシュボードが表示されない問題、シャットダウン・再起動に時間がかかる問題の原因は全て同じです。
内部の電圧のミスマッチでVideo Coreの動作が不安定になっていたと言うことです。これはv1.0.0から（もっと正確に言えば正式リリース前のベータテストの段階から）内在していた問題ということになります。
smpdのconfig.txtで指定しているcore_freq=598というのは、RPi4のデフォルト値からみてもかなり高い設定です。
電圧不足がおきても不思議ではありません。
たまたま当方の環境で問題の発生率が低かったためそのまま見過ごしていましたが、今回問題提起いただいたことで原因を深掘りできたという次第です。
RPi4のファームウェアは省電力・低発熱を優先して改良が続けられています。
config.txtでのクロック指定はRaspberry Piの保証外の使い方となります。
例え動いていたとしても、将来に渡ってその動作が保証されるわけではありません。そして実際に、2019-11-18版のGPUブートローダで後方互換の無い仕様変更が行われ、config.txtでのクロック指定が従来のようには動作しなくなってしまいました。
つまり、「クロックや電圧は必要最小限に自動設定してあげる。全部ファームウェアに任せろ。configを弄るな。」と言うわけです。
新ファームウェアの採用には次のようなメリットがあります。
- 省電力化
- 新機能の追加 (例えばネットワークブートの強化など)
- 不具合の修正
- 新ハードのサポート (例えば8GBモデルへの対応など)
smpdは他のディストリビューションと比較して消費電力は低く抑えられており、空冷で40℃〜50℃に保つことも容易です。
今後、smpdが新バージョンのGPUブートローダを採用することは恐らくないでしょう。2019-08-01版を使い続けることになると思います。
その他のファームウェア（EEPROMファームウェアやドライバ）に関しては、音質に影響しない限りは必要に応じて追従していきます。
-
smpdでなぜcore_freqを高く設定しているか、補足いたします。
Raspberry Piに搭載されているGPUとその周辺機能はVideo Coreと呼ばれています。
Video CoreはただのGPUではなく、Raspberry Pi本体のレジスタを読み書きするインターフェースとしての機能が動いています。GPU・メモリの一部を間借りして、マイコンのような機能を実装してしまったというわけです。
ラズパイ内部の温度や電圧、CPUクロックなど、様々な情報をVideo Core経由で読み取ることができます。
そのためのフロントエンドとなるツールの一つがvcgencmdです。Video Coreの動作が不安定になると、vcgencmdからの問い合わせに応答がなくなり、フリーズしたような状態になってしまいます。
core_freqはVideo Coreの周波数を設定するパラメータです。
このcore_freqは、GPUの処理速度に影響するのはもちろんですが、もう一つ重要なのがメモリバスの速度でもあるという点です。smpdで高いcore_freqを設定しているのは後者の性能を引き上げるために他なりません。
RPi3版を開発していたころにDMA性能のベンチマークを行ったことがありますが、core_freqの影響は無視できないものでした。
（実際にメモリバスの速度がDMA性能に効いていたのか、それともDMAアクセスそのものではなくて何らかの周辺処理の性能に影響していたのか、、、簡易的なベンチマークだったため、細かい切り分けはできておりません。また、RPi4ではDMA性能の実測はできておりません。RPi3版と比べ、core_freqの重要性は変化している可能性があります。）
