v0.9.4 リリース (v0.9.4 release)

パパリウス

v0.9.4をオンラインアップデートで配信いたしました。

v0.9.3のSDイメージで新規インストール済みの方は、Web UIのSETTINGSからアップデートすることができます。
v0.9.2以前のバージョンからオンラインアップデートすることはできませんのでご注意ください。

不具合報告はv0.9系不具合報告スレッドにお願いいたします。

＜主な変更点＞

ドライバの更新(rtalsa/xsink)
Web UIにダークテーマを追加しました。( @sunatomo さんご提供)

メニューの「COLOR THEME」を開いて、darkを選択してOKボタンを押してください。
ブラウザをリロードするとダークテーマが反映されます。

デフォルトのテーマに戻す時は、lightを選択してください。

IE11はサポート対象外となります。ご了承ください。

＜その他変更点＞

Web UIの不具合修正(consume設定がボタン表示に正しく反映されるようになりました。)
TerraBerry DAC2プラグインの不具合修正(パスの修正)
SUPPORTプラグインを更新(ネットワーク関連のログを追加

v0.9.4 has been published for online update.

If you have already installed v0.9.3 with the SD image, you can update it through SETTINGS of Web UI.
Please note that you are unable to use online update from v0.9.2 or earlier versions.

Please use v0.9 stream problem report thread for problem report.

[Major changes]

Update of drivers (rtalsa/xsink)
Addition of dark theme to Web UI ( provided by @sunatomo -san)

Please open "COLOR THEME" of menu, select "dark" then click OK button.
Dark theme is reflected after browser reload.

Please select "light" to revert to the default theme.

Please note that IE11 is unsupported.

[Other changes]

Defect fix for Web UI (Consume setting is now reflected correctly in button display)
Defect fix for TerraBerry DAC2 plug-in (Fix of Path)
Update of SUPPORT plug-in (Addition of network related log)

出不精

こんばんは。正式版リリース有難うございます。
β版からバランスそのままに全体的にブラッシュアップされよりクリアーにシャープに陰影豊かになったと感じます。洗練という言葉がピッタリですね。スバラシイ。ダークテーマもいいですね。
更なる発展願ってやみません。これからもよろしくお願いします。

flyingace

@パパリウスさん

v0.9.4の正式リリース有難うございます、早速聞かせていただきました。
安定感（安心感）抜群です、きれいな透明感もよいですね。
airplay,spotifyが更に良くなったように感じるのですがなにか手を入れられたのでしょうか？。
これから色々聴き込んでいきたいと思います、有難うございました。:clown_face:

mike

パパリウスさま

お気に入りの 0.9.4b4 Peach Tune のまま update をかけました。

試聴したのは、いつものとおり、
Kali Reclocker/D70
Allo digione
Sabreberry32pro
の３機種です。

標準の状態で聞く限り、Spotfyの再生を始め順調に動作しております。

Latency は更に改善されているようで、Kali Reclocker(slave) では、0から4本目（200未満？）がピークです。
なお、ちょっとずつ変動しますが、Master設定の digione は6本目がピーク、SB32pro は7本目（250mmあたり）がピークでした。

音は、最初もしかしたら 0.9.4b4 に比べわずかに響きが増えているかなとも思いましたが、聞きこんでも差はよくわかりませんでした。

Ver 0.9.4 の音は送り出しのハード、DACの違いを本当によく出してきます。

実は、Kali Reclocker/D70 の onoffshim のサービスを切り忘れ試聴したところ、なんだが音がゆるくスリリングでなくなっていました。調べると、サービスの切り忘れです。サービスを切って立ち上げ直すと、b4のときのスリリングな感じを取り戻しました。

小さなサービス一つではほとんど差は出ないと思っていましたがそうではないことを実感しました。
Latecyのグラフといい、それだけシステムのチューンの度合いが上がってきたということだと思います。

安定してこの音が楽しめるのは素敵ですが、DACのupdate欲がむくむくと起き始めたのは困ったものです。
それだけ音楽をもっと楽しく聞こうという意欲の湧くバージョンになったと合点しています。
超多忙な中、ver0.9.x を完璧に仕上げていただきありがとうこざいました。

hiroget9

@パパリウスさん、一聴して、低域から高域にかけて全般的に再生能力が格段に向上したように感じています。
これから家族に聴かせて、どんな反応が返ってくるか楽しみにしています。
sunatomo さんによるインターフェースがとても使いやすく、アルバム単位でプレイリストを操作できるのは、とても嬉しいです。

音質も操作も洗練され、これまでより更に心地良く音楽に浸れそうです！
ありがとうございますm(__)m

追記
家族の感想ですが、これまでで最高の音だと言っております。
埋もれていた繊細な音まで楽に聴き取れ、生で聴いているようだという反応です。

パパリウス

@出不精さん @flyingace さん @mike さん @hiroget9 さん

β1〜β4の動作確認にご協力下さいまして、誠にありがとうございました。
皆さんの声に背中を押していただき、v0.9.4の配信にたどり着くことができました。

mikeさんも触れてらっしゃる通り、v0.9.3に比べてレイテンシーも改善されています。
（スレーブモードはマスターモード向けの内部処理をバイパスする分、僅かにレイテンシが良好です。）

v0.6系の頃のレイテンシーグラフを覚えてらっしゃる方はいらっしゃいますでしょうか。
当時は3〜4個の山が連なっており、それぞれの山が大きなボトルネックの存在を示唆しておりました。

v0.7系、v0.8系、v0.9系と大胆な方式変更を加えながらボトルネックの解消を進め、最新のv0.9.4では大きな山がただ1つ、理想的な美しい確率分布を映すようになりました。

今後もRPi3向けのバージョンアップは継続し、Web UIの改善や不具合の修正、動作の安定化など、洗練させていきたいと思います。

今後、音質追求の舞台はRPi4版に移します。
現在はヘッドフォンで音出ししながら作業を進めておりますが、1ヶ月程度で主要な移植作業を終えてメインシステム（スピーカー環境）に組み入れることができるだろうと思います。
公開できる完成度になるまでには相応の期間が必要になると思いますが、定期的に開発状況を発信していきたいと思います。

pogeline

v0.9.4早速聞かせていただきました。

v0.8からのアップデートですが、
静寂の中の響きがとてもよく、分離感、透明感も素敵です。

markaudio（付録）
firstwatt f6 diy
平衡型FETプリ（ぺるけ式）
Sabreberry32+raspberryPi3B+

という全て自作の環境で聴いております。
スピーカーを強化したく選定中です。

じっくりと聴き込みたいと思います。
ありがとうございました。

henzajima

@パパリウスさま
初めて投稿させていただきます。yoさんやpassさんに勧められて（そそのかされて）、何もわからぬままsymphonic mpdに取り組んでいます。
当方は Rpi3 b に FifoPi を挟んで HDMIpi からキツネDACにつないでいます。最初に聞いた時から、皆さん書き込んでおいでのように、抜けの良い透明感のある音に感心しました。
v0.9.4になってその感がますます強まりました。さらに印象的なのは音楽性の高さです。一音一音のきれいさだけでなく、フレーズとしての音に歌心がより強く出ているように思います。
今後 Rpi 4 向けが出るとうかがっていますので、それに向けてお願いがあります。それはハイレゾ音源についてです。もうご承知かと思いますが、96khz以上のwav音源だと音が途切れ途切れになります。flacでも192khzになると途切れることがあります。
DSDはキツネDACとでは、音がでないと聞いていました。ところが現状で音は出ます。DSD64では数秒音が出た後途切れ、また音が出ての繰り返しになります。DSD128ではまさに途切れ途切れになります。
symphonic mpd の音が気に入っただけに、ハイレゾ、DSD音源についても安定的に聴けるようになれば言うことなしです。よろしくお願いします。

パパリウス

@henzajima さん

ハイレゾ再生の件、ご意見いただきありがとうございます。
RPi4版で改善できるかもしれません。ご期待くださいませ。

ラズパイに搭載されている最も高速な記憶領域はCPUのレジスタで、次に高速なのはCPUキャッシュ(L1キャッシュ)です。

物理メモリ上のデータが処理に必要となるときは、処理に先立って数マイクロ秒早くキャッシュ指示を出しておき、メモリアクセスがボトルネックとならないよう注意深く設計しています。

（物理メモリから数KBのデータを読み込むだけでも数百ナノ秒〜1マイクロ秒の時間がかかりますので、キャッシュミスは致命的です。）

L1キャッシュに次いで高速なのはL2キャッシュです。これは全体で512KBの容量がありますが、4つのCPUコアで共有していますので、特定のコアで大きなデータの読み書きがあると、他のコアが使用しているデータをキャッシュから追い出してしまう可能性があります。
このL2キャッシュはI2S出力するデータをシリアライザのFIFOにDMA転送するのに使われるため、大変重要です。

シリアライザのFIFOは、僅か64x32bitの容量しかないため、symphonic-mpdは『FIFOへのDMA転送が遅延しないこと』を最優先に設計しています。

DMAのバースト設定や、DMAデータリクエストのタイミング指定、DMAチャネルの優先度を調整した上で、PCMデータがリクエストに遅延しないようリアルタイムカーネル(Xenomai)を使って±100ナノ秒のタイミング精度でバッファへの書き込みを制御しています。
これらはCPUキャッシュヒットが大前提となるため、巨大なサイズの読み書きによってCPUキャッシュが汚染されないよう、各種バッファのサイズは可能な限り小さく設定しています。

このような設定は、ハイレゾやDSDのような巨大な音源の取り扱いを難しくしています。

RPi4のハードウェア性能でどこまでカバーできるようになるか、私自身、とても楽しみにしています。

yo

@パパリウスさん、こんにちは。

キャッシュに関する興味深い解説ありがとうございます。一つ質問です(見当違いの質問かもしれませんが、ご容赦を)。
SMPDのようにギリギリの世界でコントロールを行っていないが、I2S接続は出来るアプリ(たとえばVolumio)の場合、この部分はOSとハード任せということになりますね。この場合、192KHzでも問題なく再生出来ます。これはOSとハードが多少のレイテンシーは無視して、しっかり排他制御を行い、音切れをさせないことを優先して処理しているから、音切れは発生しないのですかね。

パパリウス

@yo さん、こんにちは。

音切れを無くすには、PCMデータのバッファ(謂わゆるALSAバッファ)を十分大きくしておくのが効果的です。

mpdなどALSAを使う再生ソフトの場合、44.1KHz/16bit再生時の典型的な設定値は以下のようなものです。

ピリオドサイズ 4096バイト (=1024サンプルx4バイト)
ピリオド 4
バッファサイズ = 4 x 4096 = 16384バイト

symphonic-mpdの場合、44.1KHz/16bit再生時のデフォルト設定は以下の通りです。

ピリオドサイズ 588バイト(=147サンプルx4バイト)
ピリオド 2
バッファサイズ = 2 x 588 = 1176バイト

symphonic-mpdでは音質を優先して試行錯誤する過程でこのような極端に小さなバッファ設定に至りましたが、44.1KHzをメインターゲットとして開発していますので、ハイレゾ向けのバッファ設定値はあまり試行錯誤できていません。

バッファ設定は
/home/pi/configs/environment に記載していますので、これを変更することでハイレゾ再生が安定する可能性はあります。

＜environmentファイルのバッファ設定＞
# period, alsa-buffer, sync-period, prefetch-ns

MPD_SETTING_44100=147,2,13,2300
MPD_SETTING_48000=144,2,13,2300
MPD_SETTING_88200=147,2,7,2000
MPD_SETTING_96000=144,2,7,2000
MPD_SETTING_176400=147,2,7,2000
MPD_SETTING_192000=144,2,7,2000
MPD_SETTING_352800=147,2,7,2000
MPD_SETTING_384000=144,2,7,2000

バッファ設定は、サンプリングレート毎に設定できます。

例えば44100Hz用のデフォルト設定は以下のようなものです。

MPD_SETTING_44100=147,2,13,2300

147・・・ピリオドサイズ(サンプル数)
2・・・ピリオド
13・・・ALSAリングバッファのレジスタをチェックする周期
2300・・・プリフェッチウィンドウ(ナノ秒)

この場合、44.1KHz/16bit音源再生でのバッファサイズはピリオドxピリオドサイズx16bitステレオのバイト数 = 2 x 147 x 4バイト= 1176バイトとなります。

小さなバッファをターゲットにドライバ(rtalsa/xsink)を設計しているため、environmentファイルでハイレゾ向けのバッファ設定を大きくしたとしても安定再生できるとは限りません。ご注意ください。

なぜ44.1KHz系のピリオドサイズが147かというと、44.1KHz(=2 x 2 x 3 x 3 x 5 x 5 x 7 x 7)の周期処理をラズパイのオシレータ(19.2MHz=2^11 x 3 x 5 x 5)で実行する場合、147サンプル(=3 x 7 x 7)の倍数で扱うとうまく割り切れるようになり、時間の誤差が生じないためです。

yo

@パパリウスさん、お答えありがとうございます。大変に参考になります。

やはりバッファ設定の問題はあるのですかね。henzajimaさんのシステムでバッファ値の変更をやりましたが、mpd.confを直接弄る形で試したので、効果はありませんでした。もう一度、教えて頂いた方法でトライしてみたらと思います。alsaのバッファ管理に関してはここのサイトの解説が参考になります。

ただ、別のスレッドで話題になっていますが、flacであれば、192KHzであっても問題なく再生できますので、単純にパッファの問題だけでもないような気がします。その意味では、flacで管理というのが正解かもしれませんね。

Pass

@yo さん

environmentファイルのバッファサイズを2倍、3倍、4倍と徐々に変更してみましたが、wav再生では192k、96kともに聴感ではほとんど変化なしです。

また、大きくし過ぎるとsshからは操作できますが、ympdから応答しなくなりました。mpdがフリーズするようです。

@パパリウスさん

smpdの音の良さのポイントはドライバの設計にあるようですね。rpi4版に期待しています。

yo

@Passさん

僕のところでも同じような状況です。ハードの差には関係ないようですね。
flacでは上手く再生出来ることを考慮すると、どうもlinuxのwavフォーマットのデコードに伴う問題のようです。ただ、他のプレーヤでは指摘されていないことから判断すると、SMPDの高音質化のためのギリギリの処理に起因する問題なのでしょう。となると、ラズパイ4にすれば解決するという問題ではないかもしれませんね。

hiroget9

@パパリウスさん、お世話になります。
私の場合、ハイレゾ音源に関しては、CDで再販されなかった音源しかないので、ほとんど関心がないというか、ハイレゾ自体が衰退しつつあるオーディオ業界のまやかしとしか思っていません。異論のある方はいらっしゃるでしょうけど・・・
44100Hz　１６BITの音源をraspberry pi3でここまで再生能力が高いのであれば、raspberry pi4でもハイレゾにこだわられる必要はないのかなと思ってしまいます。むしろ、今のパパリウスさんの開発方針を貫かれることを願っています。

Pass

@yo さん

flacでは上手く再生出来ることを考慮すると、どうもlinuxのwavフォーマットのデコードに伴う問題のようです。

V0.7系のころにwmaファイルの再生で同様な現象になった事もありましたので、デコーダ系の問題の可能性は確かにありますね。
ただ、henzajimaさんは音が途切れ途切れと仰っていますが、拙宅では音切れというよりブツブツといったノイズが混じった再生となります。
wavはflacに対してデータ量が大きくなる為、ネットワークからデータを受け取る際のバッファに起因する問題なのかもしれませんね。

@hiroget9 さん

私もほとんどCDからのリッピング派です。ただ、クラシックファンにはCDで購入できない音源を多数ハイレゾ音源で購入されている方もいらっしゃるようですね。
なので、いずれにしても原因を特定するところからですかね。その結果で行われる対策が44.1kフォーマットの音質を損なわないようであれば、より多くの方がsmpdの高音質を享受できるので、是非ともハイレゾのwavにも対応して頂きたいですね。

ゴンザエモン

当方の事例ですが、ご参考となれば幸いです。

プツノイズ的なものの発生は3B、3B+というプラットフォームの違い、あるいは最適化の差異もあるかもしれませんが、当方の音源はFLAC（uncompressed）で、3B、3B+いずれにおいても192KHz/24bitまでの再生で全く問題ありません。CPUクロックはいずれも1152，1200で、（3B+のみ）1368，1400でも試しましたが変化はありませんでした。

ただし、UPnP化して、サーバーからWAVにtranscodeして送り込むと3Bではプツノイズが入り始めハイレゾに向かって症状は顕著になります。ちょっと不思議なのですが３B+では全く入りません。（この点は稼働状態の差異にもあると思いますが）

なお、他のディストリビューションでは3BでもWAVのハイレゾ系音源でもプツノイズ発生はない（Stand Alone、UPnPいずれでも）ケースもありますので、WAVデコーダーの課題以外の要素として44.1KHz/16bitへ最適したSymphonic-MPDのコアの部分も何かしら絡んでいるのかもしれません。

この辺りはハードウエアのパワーである程度解決できるものもあるような気がいたします。

yo

皆様

切り分けのためのデータです。

GentooPlayerのラズパイ3版を使い、ハード側はSMPDと同じ構成(SDカードを入れ換えただけ。rpi3B+hifi-dac-hat+GLA I2S-TX-C1+キツネDAC)で確認しました。ハイレゾのPCMデータはあまり持ち合わせはないので、雑誌の付録、WAONのサンプル版に入っている88KHz、96KHz、192KHzを使いました。
全て問題なく再生できました。GentooPlayerはgp-update後、Mpdと UpMPDcliを有効にしただけのディフォルト状態です。

ということで、問題は「PCMデータがリクエストに遅延しないようリアルタイムカーネル(Xenomai)を使って±100ナノ秒のタイミング精度でバッファへの書き込みを制御しています。」が間に合っていないということなのでしょう。GentooPlayerはここまでのシビアな追い込みは行っていないので，alsaのバッファに助けられ、音切れなく再生できるようです。

GentooPlayerはイタリア産のソフトですが、SMPDの良きライバルだと思います。ラズパイ3版も素晴らしい音がしますね。
もちろん僕はラズパイに関してはSMPDの肩を持ちますが。

パパリウス

@yo さん @ゴンザエモンさん @Pass さん

情報提供ありがとうございます。
いまPi4版の作業を進めておりますので、ハイレゾの安定性という面も意識していきたいと思います。

ゴンザエモン

「direct_io」に関連してちょっと判らない事象が起きていますのでご教授いただければ幸甚です。

古いテーマで恐縮なのですが、ジャイアンさんの「NASな部屋」のスレッドの中にこのdirect_ioに関する記述があり改善効果への言及もありましたので試してみました。

ところが、MPD Client（当方の場合はiOS上のyaMPC）を使える設定にしますと、数十秒程度再生したところで次の曲へどんどん飛んで行ってしまいます。

6600ポートを閉じて、WEB UI（ympd）だけで操作しますとこの現象は起きません。また、6600ポートを開けてyaMPCからの操作でも、direct_ioをコメントアウトしておけば、発生いたしません。

MPD Client（yaMPC）側の問題かもしれませんが、direct_io設定とも関連もありそうでしたので質問させていただきました。

なお、当方今までずっとdirect_ioをコメントアウトしておりましたが、過去のバージョン（記憶が定かではありませんが）でこの機能を有効にすると、音源（Server PC上の共有フォルダをNASの代用）がうまく読み込めず？再生できない、という状況があったため、このようにしてきました。現状は再生できない、ということはありませんが、、、