RPi4版 v1.0系のサポートはこちら

---

@kan さん

ご感想ありがとうございます。
3GB設定でも正常動作する事例を報告いただいていますが、環境によるのかもしれませんね。メモリは1GBでも余裕を持って動作いたしますので、2GB設定が安定動作するのであれば、その状態でお使いいただければと思います。

i2c-devの読み込みについてですが、modules.confで起動時にロードする替わりに、SB32+PROコマンドを使うときだけmodprobe i2c-devを実行していただくのが良いかと思います。

i2c-devをロードした状態で動作が不安定になるというのは初の事例になります。

SB32+PROコマンドで設定を変更した場合、再起動が必要になる設定項目があります。例えばMasterモード/Slaveモードの切り替えは、一度電源を落として電源の再投入が必要になります。
OS再起動は不要でも、再生ソフト(aplay-rtやmpd)を再起動しないといけない設定項目もあります。
そういった点を考えると、SB32+PROコマンドで設定変更した後は、少々面倒ではありますが一度再起動していただくのが確実かと思います。

SB32+PROに関するご質問も歓迎いたします。このスレッドでも結構ですし、新規にスレッドを立ててもらっても問題ありません。当フォーラムをご活用いただければと思います。

kanさま、

SB32pro と、IAN-FifoPiQ2/D90改を使っているmikeです。

SB32pro の出力MELF抵抗をVAR(金属箔抵抗)に変更されているのを知り、その方法があったのかと驚嘆しおります。
もっとも今までHAT基板をいくつも壊してきたものとして基板の表面実装チップの改造はハードルの高すぎる方法でもあります。

実は、SMPDver 1.0.10 に至って、IAN-FifoPiQ2/D90改のダイナミックな音に大好きなSB32proが追いつけなくなり、出力バッファの増設でもしなければいけないかなあ、と思いつつ、でも、ver 1.0.9 ではいい響きしていたよなあ、と戻してみて聞いてみると、IAN-FifoPiQ2/D90改とは違う、穏やかで奥の深い音が戻ってきました。もちろんver 1.0.10 で手に入ったダイナミックさとか生々しさとは異なる、でもとても気持ちの良い音です。

というわけで、今では２台をパラで鳴らし、気に入った曲、気に入った音の方に切り替えては気ままに聞いております。
kanさまのなした技とは全く異なるのんびりゆるい対処ですが意外に気に入っております。
まあ、こういう聞き方もあるということでご容赦くださいませ。

@パパリウスさん

4GB Revision 1.2なのですが諸々の不具合や技適の適用時など過渡期の際に個々の違いが有るのものかと思われます。

リブート時に固まり起動しない事も度々ありましてSDカードにイメージに書き直しどの手順が問題なのかとか何度か繰り替えまして、お陰で様でSymphonic-mpdの理解が深まりました（笑）

ただ、Installation GuideはRpi-3(0.9系)とRpi-4(V10系)と分けていただけますと私の様な初心者には安心感があるとかと思います。

初めからこちらで時系列を追って理解すれば良いものを、ネットで得た情報の先入観で空回りと云いますか、遠回りしてしまいました（笑）

よろしくお願いいたします。

@mike さま

さま

SB32proの出力抵抗については、たかじん氏とメールのやり取りの際にこのDACの能力が生かして切れていないものかと感じましてその旨話しちゃいました。（失礼な奴です）

たかじんさんは以前にアルファ抵抗に変えた事が有るというお話でしたので（どうでも良い事ですが、私の出身が秋田でして秋田工場で生産されるアルファの箔抵抗には思いが有ります。が）Symphonic-mpdとSB32proの音を生かすにはVARが適切かと思い交換いたしました。

mikeさまは切り替える環境がお持ちなのは良いですね。
私はRpiが初めて触りましたのでDACにLineケーブルを直結してヘッドホンアンプに接続してしまいました（極力良い音で聴けるかなと）

アンプ側は切り替えSWの音質劣化を避けて外してしまいましたのでケーブル差替えの必要があるため聴き比べの環境がありません（汗

IAN-FifoPiQ2/D90改（←この改辺りが良くわかっておりません）が、Symphonic-mpdはスタジオレベルの音質で良いと思います。
スタジオの仕事が長かった私にはSymphonic-mpdはプロユースに十分な音だと思います。

スタジオでもデジタル化が進んでありますので
SB32proで鳴らす分には（まだVARが鳴らし込み途中ですが）バランスの取れたピラミッド型で落ち着いた音で良いと思います。
が、モニター用途ではもう少し帯域バランスがフラットで（言葉にするのが難しいですが）高域がスーッと延る感じの方が高い音が掴み易いかと感じます。

ですが、逆にマスタリングでオーディオユースに仕上げるには色付けのない硝子を通す様Symphonic-mpdがデジタルトランスポートとしてアナログに渡すのは最適と思います。

（お前は何を言っているんだ風になってる気がしますが）

これまでDigitalなPure Audio機器を聴いてナンが違うと思い、お気楽オーディオの藤原さんのDACを組んだり悶々としている時にiBassoのDAP改造などをしていておぼろげながら出口が見えて来ました、

そうしてSymphonic-mpdに辿り着きました。
今幸せな気持ちで一杯です。

これから落とし込む部分がまだまだございますが、どうぞよろしくお願いいたします。

@パパリウス さん

新機能の話で恐縮ですが、以前このスレッドでセパレート構成のお話をされていたので、便乗させてください。

現在、セパレート構成 (Audio Over Ether) の開発に鋭意取り組んでおられるものと想像していますが、一つお願いしたいことがございます。

物理的な接続については特に制限を設けず、ハブ（ルータ）経由での接続をサポートしたいと思います。

直結に限定すれば、IPヘッダ・UDPヘッダを省くことも技術的には可能です。
もし通信のスループット向上が狙いなら、そのような実装を目指したかもしれません。
今回は負荷の低減と平滑化が狙いであり、それは直結に限定しなくてもLinuxカーネルのTCP/IPスタックをバイパスするとともに緻密なフローコントロールを実装することで実現可能です。

通信の平準化により、ハブ(ルータ)への要求スペックも大幅に引き下げることになり、通信経路上の機器がボトルネックになる可能性は低くなると思います。

フロントエンド/バックエンド直結でなく、LAN 経由での接続を検討されているとのお話ですので、可能でしたら、一台のフロントエンドから複数のバックエンドへの接続を構成できる仕組みにしていただけると大変ありがたいのですが、いかがでしょうか。というのも、システムごとにフロントエンド+バックエンドの Rpi のセットを準備する必要がなく、また、1台のフロントエンドで複数のバックエンドへの出力をコントロールできるのは、LAN 経由ならではの利点かと思ったからです。

セパレート構成の目的は音質向上のただ一点のみでしょうから、マルチルーム対応 (複数バックエンドで同時に再生) のような複雑で冗長な構成は一切不要で、予め手動で選択された一台のバックエンドのみで再生するシンプルな構成で構いません。また、複数のバックエンドは全て同一バージョン/パッチレベルの必要ありなど、自由度の高くない構成でも仕方ないと思っています。

もし、パパリウスさんが現在考慮されている設計/実装から許容できる変更で対応可能なのでしたら、是非ご検討いただけないでしょうか。

@norinori さん

ご意見ありがとうございます。

当初とは設計も変化してきておりまして、ルータ超えは出来なくなる予定です。

IP, TCP, UDPは使わず、Ethernetフレームに独自プロトコルのパケットを直接載せる予定です。
フロントとバックは同一ネットワーク上に置く必要があります。

このような設計としたのは、IPのチェックサムを避けたいという意図があります。
Audio over Etherでは冗長なメモリアクセスを極力排除したいと考えています。チェックサムを計算するためだけにメモリ上のパケットをCPUのレジスタに読み込むようでは、AoEの旨味が半減してしまいます。

なお、チェックサムを省く通常モードと、チェックサムを計算して転送エラー発生率を記録するネットワーク品質評価モードを用意しようと思っています。
まずはネットワーク品質評価モードで数時間の再生をしてエラー発生率が0%であることを確認してもらい、ネットワーク品質に問題ないことがハッキリした後で通常モードを使ってもらえればと思います。

現状では、フロント側でAoEクライアントを起動するとブロードキャストパケットを飛ばしてバックエンドのAoEサーバを自動で探索します。同一ネットワーク内に複数のAoEサーバがあることは想定していませんでした。
バックエンドが複数あるケースを考慮して、接続先を指定することもできるような作りにしたいと思います。

@パパリウス さん

詳しい説明及び前向きなお答えいただき、感謝感謝です！

IP, TCP, UDPは使わず、Ethernetフレームに独自プロトコルのパケットを直接載せる予定です。

おおお、標準的な (OSI モデル or TCP/IP モデル) ネットワークプロトコルを超えた実装ですね。
結果として、ルーターは超えられず、同一ネットワークとなること理解しました。私の環境では問題ありません。

なお、チェックサムを省く通常モードと、チェックサムを計算して転送エラー発生率を記録するネットワーク品質評価モードを用意しようと思っています。
まずはネットワーク品質評価モードで数時間の再生をしてエラー発生率が0%であることを確認してもらい、ネットワーク品質に問題ないことがハッキリした後で通常モードを使ってもらえればと思います。

詳細説明ありがとうございます。具体的に2つのモードを準備されているということは、実装/動作確認もかなり進んでいるんですね！
期待で胸が膨らみます。

現状では、フロント側でAoEクライアントを起動するとブロードキャストパケットを飛ばしてバックエンドのAoEサーバを自動で探索します。同一ネットワーク内に複数のAoEサーバがあることは想定していませんでした。
バックエンドが複数あるケースを考慮して、接続先を指定することもできるような作りにしたいと思います。

対応いただける方向で方針変換していただき、本当にありがとうございます。
SMPD ファンの皆様はセパレート構成機能を首を長〜くして待っておられると思いますので、このような要望でリリースが遅延しようものなら袋叩きに合いそうです。。。くれぐれも無理のない範囲でご対応いただきますよう、お願いいたします (負担が無視できぬレベルでしたら、即却下いただければと思います)。

@パパリウス さん

新しいRPi4の基盤を購入したので、SDカードにOSのイメージを書き込んでOSを起動しようとしたところ、起動がうまくいきません。赤ランプ点灯、緑ランプ点滅です。

もう一台RPi4を持っていて、そちらはsmpdを起動できていますが、そのSDカードを使っても、同じ事象になります。

他のOS(volumioとrasbian)は起動できたので、smpdの問題だと思いますが、どのように対処すればよいでしょうか？

@なーくん さん

新しく購入したRPi4なので、EEPROMファームウェアが推奨バージョンよりも新しいのだと思います。

FAQに「Q. EEPROMファームウェアを更新する」というエントリがありますのでご一読ください。
https://www.symphonic-mpd.com/forum/topic/108/よくある質問と答え-frequently-asked-questions-and-answer/

他のディストリビューションで起動させてからsudo rpi-eeprom-updateを実行し、EEPROMファームウェアのバージョンを確認してみてください。

＜出力例＞
BCM2711 detected
BOOTLOADER: up-to-date
CURRENT: Tue 10 Sep 10:41:50 UTC 2019 (1568112110)
 LATEST: Tue 10 Sep 10:41:50 UTC 2019 (1568112110)
 FW DIR: /opt/rpi-eeprom/firmware/critical
VL805: up-to-date
CURRENT: 000137ad
 LATEST: 000137ad

さて、推奨バージョンのEEPROMファームウェアをインストールする前に、以下の場所にファームウェア(pieeprom-2019-09-10.bin, vl805-000137ad.bin)が格納されていることを確認してください。

ls -al /lib/firmware/raspberrypi/bootloader/critical/

ファイルが存在することが確認出来ましたら、以下のコマンドでファームウェアをインストールしてください。

sudo rpi-eeprom-update -f /lib/firmware/raspberrypi/bootloader/critical/pieeprom-2019-09-10.bin

sudo rpi-eeprom-update -u /lib/firmware/raspberrypi/bootloader/critical/vl805-000137ad.bin

再起動後、EEPROMファームウェアのバージョンを再確認してみてください。

@パパリウス さん

EEPROMファームウェアは推奨バージョンよりも新しいものになっていました。

古いrasbianのイメージには「/lib/firmware/raspberrypi/bootloader/critical/」にファームウェアがあったので、コマンド実行しましたが、BOOTLOADERは推奨のものに変わりましたが、VL805が「00000000」となり、smpdを起動できません。

また、raspios「raspios_armhf-2020-05-28」のイメージには「/lib/firmware/raspberrypi/bootloader/critical/」にファームウェアはなく、「/lib/firmware/raspberrypi/bootloader/old/critical/」にファームウェアがありました。

oldフォルダにあったファームウェアを使ってインストールしましたが、VL805が「00000000」のままでsmpdを起動できない状態は同じでした。

@なーくん さん

VL805のファームウェアは、最新版を適用してみてください。
BOOTLOADERは推奨バージョン、VL805は最新バージョンという組み合わせでsmpdが起動するか確認してみてください。

これで起動しない場合は、以下の2点を行ったうえで起動するかどうか確認してください。

1. config.txt 内の周波数設定を全てコメントアウトする
2. dt-blob.binをリネーム(または削除)する

これで起動するなら、gravity設定をチューニングした上でマスターモード動作のDAC用に使うという使い方ができます。
（この状態のsmpdをスレーブ動作のDACに使うことはお勧めできません。スレーブ動作の場合はdt-blob.binによるPLLチューニングが音質の肝になるからです。）

gravity設定のチューニングについては別途ご説明します。

参考までに、cat /proc/cpuinfoでRPi4のリビジョンを確認していただけませんでしょうか。
一番下の行に

Model           : Raspberry Pi 4 Model B Rev 1.2

のように出力がされると思います。

新しいリビジョンのRPi4にもいずれ対応したいと思っていますが、すぐには着手する予定はありません。スレーブ動作のDAC用にお使いいただくには気長にお待ちいただく必要があります。

他の使い道としては、セパレート構成のフロントとしてお使いいただくのはいかがでしょうか。

フロント側はRTカーネルが最適と考えています。
（言い換えると、smpdのSDイメージはフロント用には適していません。）

もしフロントにお使いになりたい場合は、よく使うディストリビューション（または使いたいディストリビューション）があれば教えてください。
こちらでRTカーネルとモジュール類(netmap, vsound, aoe)をビルドしてご提供可能です。

@パパリウス さん

VL805に最新版を適用しても「00000000」ままで、変更できないようです。

また、VL805が「00000000」のままで、smpdの1と2を実施しましたが、起動はできませんでした。

「cat /proc/cpuinfo」の結果は以下でした。
Model : Raspberry Pi 4 Model B Rev 1.4

簡単に解決できないようであれば、他で使いますので、smpdの利用はあきらめます。

なーくんさま、

新しい Raspberry Pi 4 boot EEPROM のマニュアルには、

vl805.bin: The VLI805 USB firmware EEPROM image - ignored on 1.4 board revision which does not have a dedicated VLI EEPROM.

とありますので、ver. 1.4 の基板ではこの VLI805 USB Firmware は使えません。それと組み合わせて使う、Raspbian 時代の firmware も使えません。（β版のkernel, firmware も試してみましたが起動しません。）

つまり ver. 1.4 基板は、SMPD ver 1.0.x の前提となっている firmware では動作しないので、パパリウスさまに対応していただけるまで使えないようです。

ただ、いままであまり評価しなかった moode r671 もslave で動かし、リクロック基板を通してやると予想外なほどしっかりした音になるので、ver. 1.04 基板とそれと組み合わせる新しい RaspiOS/Firmware はそれほど悪くないかもしれません。

ご参考まで。

@mike さん

VLI805 USB Firmwareが書き換わらないのは、そういう理由だったのですね。
ご教示頂き、ありがとうございました。

ちょっと気になったのは、これからsmpdを始める方は、この壁に直面すると思いますが、RPi4購入時に基盤のversionを確認する方法はあるのでしょうか？
ご存知でしたら、ご教示頂きたいです。

なーくんさま、

私の知る限りでは箱や基板上ではわかりません。立ち上げてコマンドで確認する以外ないようです。
私のver1.4基板でも製造日は2019年ですからハードの違いはないのかもしれません。

確かに外から確認できたらいいんですが・・・

１０月の半ばにdigikeyから購入したものは、ver1.2 で１１月に入ったところで購入したものは、ver1.4でした。２GB版は売れてないという話でしたから、市場にあるものはもうすべてver1.4の可能性大ですね。

@なーくん さま、@ mike さま
確かに新しく始めたい方や、増設したい場合、手元のpi4が故障した場合など困りますよね。

残念ながらOS絡みは私にはまだまだ知識が少なく、ちょっとすぐにはお手伝いは難しいです。
(個人的な理由になりますが、
昨年末にシリアルデバッグ環境を作ろうとした際に信号ラインに電源を混触させてPCと3B+壊してからは
sshで行える範囲しか手は伸ばしていません。)

現状の私の出来る範囲で考えると、
もしかしたらv0.9系に今のwebuiを移植する対応必要かも知れませんね。

@mike さん、@sunatomo さん

ご返信ありがとうございました。
楽にversionを確認する方法があれば良かったのですが、コマンドで確認する以外はなさそうとのこと、承知しました。

sunatomoさま、

いつも使いやすい web interface をありがとうございます。

さて ver. 1.4 基板については、firmware と kernel が変わってしまったので、なにより Xenomai がきちんと対応してくれるまでは焦っても仕方がないと思っています。

まずはいまパパリウスさまと donuts.shop73さまが精力的に進めていらっしゃる Audio over Ether を楽しむのが良いように思います。ここならフロントエンドとしてver. 1.4 基板も活かせると思います。

もうすぐのようなので期待してお待ちしましょう。(^^)

カーネル・ファームウェアのバージョンアップには適宜追随したいと思っています。

ただ、RPi4の仕様変更スピードはもの凄いものがありますね。RPi3のころはハードウェアの変更はほとんど無く、長期間に渡って互換性が保たれていました。

rev1.4でいったん落ち着くようならいいのですが、まだまだハードが更新されるのだとすると、ボランティアを募るなどして開発体制を強化しないと追随が難しくなってきます。

AoEについては今週末にはバックエンド(smpdplayer)のβ2を準備できるだろうと思います。
フロント側のセットアップも簡単にできるように順次整備していきたいですね。
smpdがサポートしていない再生ソフトについてもAoEの実験をしてみたいので、パッケージ管理が充実しているディストリビューション(Arch Linuxなど)をベースにしたフロントエンドもそのうち準備したいなと思っています。

パパリウスさま、

AoEはすごそうで期待が膨らみます。
フロントエンドの自由度も上がりそうですし、トライできることも増えそうです。

ver1.4基板、firmwareとKernel の組み合わせを試していてあまりの数にめげました。

しかしながら、ver1.4 board と最新の firmware の組み合わせは結構安定している感じです。もっとも動作するplayerはmoodeくらいしかないのですが、きちんと動いていて音質も悪くありません。

落ち着くまでじっくり待つのが得策ですね。それまではフロントサイドで色々使ってみようと思っています。