• RPi4 Edition ベータテスト

    パパリウスさん

    β13~β16のアップデート有難うございます。

    最初に昨夜SB32PRO DoPから試しました。
    β13の状態ではすんなりと再生までこぎつけましたが
    それからのアップデート時に、リブートが出来なかったり
    Float PCM Format関連で再生が出来なかったりしましたが
    β13のSDイメージから、何の設定変更もせずにβ16にアップデート後
    各種設定をしましたら、問題無く動作しています。

    こちらのPi4はrev1.2の2G版で最新のファームウェアにアップデートしていたので
    sunatomoさんの情報を参考にさせて頂いて、000137adに戻してからインストールしました。
    情報有難うございました。

    そして今日Terraberry DAC3を載せているPi4(rev1.1 1G版)でも試しました。
    こちらもβ13イメージからそのままβ16にアップデートして
    Terraberryプラグイン等の各種設定をしましたら、プラグインを含め
    問題無く動作しています。

    音についての感想ですが、一音一音の力強さが増して(強いだけで無く、強弱のメリハリも素晴らしい)
    低音の量感がUPして締まりも良く、聞いていて音楽に引き込まれる感じで、酔いしれています。
    こんな素晴らしい再生環境をご提供頂きまして有難うございます。

  • パパリウスさん

    b12、b16をかなり入れ込んで聴き較べています。音のことなので多分に主観的要素大とは思うのですが、b16は音数多く、メリハリも申し分ないのですが、b12の持つしなやかさが薄れているように感じて悩んでいます。

    内部の差異などはもちろん判らないのですが、b12ではdsctlが有効で、b16は(b15から)dsctlが停止されています。b13以降のdsctlではHATによっては不具合があったようですが、当方のHAT(Hifiberry Digi+pro、ならびにその互換)では特段の問題はありませんでした。

    そこで為念、b16でdsctlをstartさせてみると、何とは無くですがb12のしなやかさが戻る感じなのです。b12時点のdsctlでは各種HATにも問題が無かったようなので、そちらにフォールバックするという可能性はございませんでしょうか。(dsctlによるGPIOの電圧調整の詳細が理解できている訳ではありません)

    何分にも感覚的なところの話で申し訳ないです。このあとはもう正式リリースなのかもしれませんが、、、

  • nzatoです

    私は、Sabreverry32からI2Sを出して、D70で聞いています。

    β12で、dsctlによる電圧調節を利用していました。最小の2の、筆か細く細かいところまで表現されるような感覚が、4や8の差として常用していました。

     私としては、一般的な機能でなくても、以前、話題にあった、コマンドとしてでも公開していただければと期待しています。

  • @ジャイアン さん

    AirPlayの接続切れが起きましたら、ログを取得してお送りいただけませんでしょうか。

    @ブルー さん

    再度検証いただきありがとうございます。
    仰る通り、consumeが切り替わるより早くOKボタンを押すと失敗してしまいますね。
    ちょっと不便な点はあるものの、許容範囲かと思いますのでこの仕様でいこうと思います。ご了承くださいませ。

    @ゴンザエモン さん @nzato さん

    dsctlについては別途取り組みたいと思います。
    RPi4はRPi3以前とは相違点が多く、互換性が無くなっているものがたくさんあります。
    GPIO Drive Strengthのレジスタアドレスもその相違点の一つなのですが、ファームウェア更新で動作が変わったりすることがあったため、仕様の変化に追従するのが難しい部分でもあります。
    RPi4とそのファームウェアの仕様が固まり、正確な情報が入手できるようになりましたら改めて実装したいと思います。

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

    昨晩b16をじっくり聞き込み、あの素晴らしかったb12よりさらに音が強靭になりスリリングになっていると感じ、今回はチューニングなしでも行けるぞと思っていました。

    そんなおり、みなさまのb12高評価のご意見に、今晩、b12に戻し、そしてb16と聴き比べてみました。
    このところメインになりつつある、IAN-Canada FiFoPi2 + HDMIpi れ+ D90MQA です。

    もうこのレベルの高さは好みの領域としかいいようがありません。

    その好みでいくとやはりb16です。
    b12 のひたすら美しく響く、特に微細な消えいく響きが例えようもなく美しいことを確認しました。
    このひたすら美しい音たちにも心を惹かれますが、b16のリアルで強靭な音はとてもスリリングです。
    ジャズではそれがリズムの確かさ楽しさにつながり、古楽器では強くスリリングな響きの魅力となります。

    これまでも、大きなバージョンアップでまずこれまでにないひびきの美しさから始まり、そして強さとリアルさを身に着けていくというチューニングの順であったように思います。

    ファンとしていつもこのリアルさと強さを心まちにしつつチューニングが進むのを固唾を呑んで見守っておりました。

    そしてSymphonicMPDの美点の一つであるチューニングの範囲の広さに感謝しつつ、試行錯誤を重ねて好みの音に近づけていく楽しさに浸ることが通例になっておりました。

    今回もそのながれにあると感じております。

    今回のb16はたまたまかもしれませんがチューニングする余地はないと思っておりました。
    しかしながら、皆様のおっしゃるようにチューニングの余地を残していただけるとこの先のことを考えるととても嬉しいです。

    以上、個人の感想とチューニング余地のお願いまで。

  • 本スレッドの241件目のコメントで、最適化の進め方をご紹介いたしました。

    その内容を再掲しつつ、どのバージョンでどこまで作業が進んでいたか振り返らせていただきます。


    再掲ここから

    第2段階 GCOV

    gcovというカバレッジの測定を行うソフトを活用し、何度も繰り返し実行されているホットスポットをリストアップします。

    特定したホットスポットについては、以下の観点でパッチをあてていきます。

    1. 条件分岐ヒントの指定 ⇨β12
    2. 関数呼び出しのインライン化 ⇨β12
    3. セクション指定 ⇨β12
    4. restrict キーワードの指定 ⇨未着手
    5. 不要コードの削除  ⇨β16
    6. アルゴリズムの見直し ⇨β16
    7. インラインアセンブラによる高速化 ⇨未着手

    上記の1〜3はカバレッジデータから修正方針を判断することができ、機械的に作業を進めることができます。
    1箇所改善すれば、1CPUサイクルを稼ぐことができます。
    これを数百、数千と積み重ねていくことで、マイクロ秒オーダーの改善に繋げていきます。

    4〜7の作業を行うケースは稀ですが、性能上のボトルネックになっている箇所についてはここまでやることがあります。現状では、aplay-rt、rtalsaドライバ、xsinkドライバが該当します。

    再掲ここまで


    v0.8系でRTDMドライバー(rtalsa)を新規開発したときも、v0.9系でCross-domain shared buffer(xsink)を新規開発したときも、安定動作が確認できた後はこのような流れでチューニングを進めました。

    新方式の導入直後は『粗が目立つものの、総じて一段上の音質』、上記1〜3のチューニング作業を経ると『高域の粗が取れ』、最後に4〜7のチューニングによって『低域の再現性が向上』するということをこれまで何度か経験してきました。

    その後も計測を続けながらボトルネックを潰していくことで、細かな粗が取れてバランスが整っていきます。


    最後の「細かな粗を取る作業」は、かける時間に対して音質向上の幅は大変小さく、あまりコストパフォーマンスの良い作業ではありません。また、新たなボトルネックを作り込むことが無いように注意を払う必要があります。10個のアイデアを試して、そのうちの2つか3つが採用に至るというような、終わりが見えない作業でもあります。

    v1.0.0正式リリース後にゆっくり気分転換しながらブラッシュアップしていければいいなと思っています。

  • パパリウスさま

    チューニング最適化の進め方再掲載と解説ありがとうございます。

    解説頂く前にはわからなかったチューニング手段と音との関係がよくわかります。
    みなさまのご意見、私の実感、ともにとても良く納得できました。

    これからは大きなバージョンアップの過程でもあまりハラハラせずにじっくり各段階を楽しみながら味わえると思います。

    いつもいつも素人の疑問に丁寧に解説いただき感謝いたします。

    mike@流れてくるいろいろな曲を気持ちよく楽しんでいます

  • @ジャイアン さん

    ログをお送りいただきありがとうございます。
    残念ながら、原因を特定するには至りませんでした。

    より詳細なログを取得するために、
    /lib/systemd/system/shairport-sync.service
    を以下のように修正していただけませんでしょうか。

    変更前
    ExecStart=/usr/bin/shairport-sync
    
    変更後
    ExecStart=/usr/bin/shairport-sync -v
    

    修正後に再起動してAirPlayをお使いください。
    現象が発生しましたら、改めてログを取得いただきたくお願いいたします。

  • @パパリウス さん

    了解です。
    当該箇所の修正は行いました。
    後はエラーが出るのを待つだけです。

  • 音質面で好みが分かれてきましたね。

    dsctlに拘らず、何か好みで音質調整が出来るようなツールがあると良いですね。

    soxrだけでなくlibsamplerateも使えると、音が変えられて面白いかもしれないですが、確か重いんですよね。smpdの方針とは合わないですかね。。。