• Gravity のチューニング

    v0.9.4b1 のアンケートのスレッドで、@W-Peach さん、@mike さんが gravity のチューニングのお話をされておりました。

    v0.6〜v0.8 の時代には、Phileweb にて gravity チューニングの意義深い議論が交わされていましたが、あいにく、そうした情報にアクセスできなくなってしまったため、いい機会かと思い、本スレッドを立ち上げました。

    まず、以下が、当時パパリウスさんから教えていただいたチューニング指針です(自分の参照用にメモとして残しておきました)。

    パパリウスさんによる gravity のチューニング方法

    g 0 0 0
    でgravity設定をクリアし、
    ./util-latency.sh
    で素のレイテンシーを計測します。

    計測時は、airplayかmpdで音楽を再生しておいてください。負荷をかけていないと、レイテンシーが小さすぎて有益な情報が取れません。

    計測結果のファイル(lat#xx.log)には3つのデータが記録されます。
    上から、
    ユーザスレッド、
    カーネルスレッド、
    割り込み
    のデータとなっています。

    真ん中のカーネルスレッドのデータ(Test mode: in-kernel periodic taskで始まるブロック)から、RTSで始まる行の一番左のデータに注目します。
    これは、計測期間中で最も小さい遅延時間です。
    例えば、それが2500(ナノ秒)だったとしますと、カーネルスレッドのgravityを2500近辺に設定します。
    これはレイテンシーグラフをぎりぎり左まで寄せた状態と言えます。
    この状態で再測定すれば、カーネルスレッドのレイテンシーの最小値はゼロ近辺になると思います。

    割り込みのgravityも同様に、
    Test mode: in-kernel timer handler
    で始まる3つめのブロックからRTSで始まる行の一番左の値を見て、gravityを設定します。

    カーネルスレッドと割り込みのgravityは、レイテンシの最小値がゼロ近辺になるところがベストの値があるように思っています。

    最後にユーザスレッドのgravityですが、「無負荷状態で計測して、RTSで始まる行の左から2番目の値が、ユーザスレッドとカーネルスレッドで概ね一致するように」ユーザスレッドのgravityを設定します。
    RTSの行の左から2番目の値は、計測期間中のレイテンシの平均値です。

    このようにユーザスレッドのgravityを設定すると、ユーザスレッドのレイテンシの最小値は、おそらくマイナスに突入しているかと思います。
    (β5は思いっきりマイナスに突っ込んでいます。#65のカーネルだと、ぎりぎり0近辺で留まります。)

    ここまでで、gravity tripletの大まかな目安がきまります。

    ここからさらに細かな調整を行います。

    ダッシュボードのレイテンシーグラフを見ると、一番左の山(サンプル数1万前後の山)に続いて、2つほど小さな山があるかと思います。
    あの小さな山ができるだけ小さくなるようなgravityの組み合わせを見つけます。
    これは、負荷の大きなmpdを再生中に計測して
    lat#xx.logのヒストグラム部分の値を見て判断することができます。

    gravityの組み合わせが噛み合うと、β5の活きの良さが再現されますので、ここでチューニング完了です。

    このような流れでgravityを決定したあと、各カーネルの測定結果を横並びで眺めると、「レイテンシーの分散」が音質と強く相関しているということが見えてきました。


    私自身、当時は Rpi 2B+ を使用していたため、gravity チューニング必須でしたが、3B+ に移行してからはデフォルトのままでも Dashboard の latency グラフが望ましいと思われる形で表示されるようになったため、横着して gravity チューニングを実施しておりませんでした。今回、@W-Peach さんと @mike さんの会話に啓発され、再度試してみようかと思いたった次第です。

    というわけで、早速、賢者の方に質問させていただきます:flushed:

    @パパリウス さん
    @W-Peach さん

    上述した gravity チューニング指針は、現在の v0.9 系でもそのまま使用できるのでしょうか?W.Peach さんが

    ここ最近のバージョンは、従来のgravityチューニングのノウハウとは異なる挙動をするので、傾向を探るのに少し難儀しました。

    とおっしゃっていたのが気になりました。別のアプローチが必要でしたら、ご教授いただけると助かります。

  • @norinori さん

    スレ立てありがとうございます。

    具体的な手順の説明に入る前に、gravityチューニングの2つの流派についてご紹介しておきます。

    W.Peach流
    gravityをレイテンシーの平均値付近にセット

    パパリウス流
    gravityをレイテンシーの最小値より少し小さくセット


    朝7時に起きて、すぐに仕事に取りかかりたいとします。
    7時ピッタリに仕事を開始するには、目覚ましを何時にセットするとよいでしょうか。

    RPi3氏は、目覚ましの音を聞いてから仕事に取り掛かるまでに、少なくとも2600ナノ秒程度かかることが分かっています。

    答えは6時59分59.9999974秒(朝7時の2600ナノ秒前)です。

    予定時刻よりも2600ナノ秒早く起きれば、予定時刻ピッタリに作業を開始することができるというわけです。

    これがgrarvityチューニングです。


    RPi3氏が2600ナノ秒で起床するのはたいへん稀で、実際にはもうすこし時間がかかるそうです。
    平均3000ナノ秒だとすると、目覚ましを何時にセットするべきでしょうか。

    答えは、「予定時刻の3000ナノ秒前」ですね。


    3000ナノ秒前に目覚ましをかけておきましたが、今朝は運良く2600ナノ秒で起きることができました。

    予定時刻よりも400ナノ秒も早く目が覚めてしまったRPi3氏は、もう一度目覚ましをかけ、すぐさま2度寝してしまいました。

    事態を察した目覚ましはすぐに音を鳴らしましたが、時既に遅し。
    RPi3氏が起きるには少なくとも2600ナノ秒かかります。
    RPi3氏が目を覚ました時、予定時刻から2200ナノ秒が経過しておりましたとさ。


    パターンA) gravityをレイテンシーの平均値付近にセット

    予定時刻ピッタリに起きる可能性が高まります。
    しかし、予定時刻よりも早く起きて「2度寝」してしまい、数百ナノ秒程度のオーバーヘッドが生じる可能性があります。

    パターンB) gravityをレイテンシーの最小値より少し小さくセット
    2度寝のオーバーヘッドを回避することができます。
    ただし、予定時刻ピッタリに起きることはできません。


    gravityの最適値は、パターンAとパターンBの間のどこかにあります。
    上の例で言えば、2600ナノ秒から3000ナノ秒までしらみつぶしに試していけば、最適値を探り当てることができるはずです。

    symphonic-mpdのデフォルトであるパパリウス流は、パターンBの設定です。

    より積極的に最適値を探るW.Peach流はパターンAとパターンBの間(ややパターンA寄り)の設定です。

  • @パパリウス さん

    わかりやすい説明ありがとうございます。なるほど、流派があるんですね。最後は自分の耳で判断することが大切なんでしょうね。手順説明、楽しみに待ってます。

  • @norinori 様
    @パパリウス 様

    返信が遅くなり申し訳ございません。

    gravityの追い込み方に、そういった違いがあることを知り、大変興味深いです。全く自覚なくやってました(笑)

    私が設定値を決める際に、まずは、これまでの設定値を打って試聴し、前バージョンとの違いを探します。
    ※慣れないうちは、レイテンシーグラフを見て、ある程度良さそうな所まで持ってきても良いかもしれません

    オーバヘッドがどうこうとかいう知識がないため、あとはひたすら聴きながら、聴感に従って調整するのみ、という単純作業の繰り返しです(笑)

    ただ、環境には少々拘ってまして、まずは、追い込む際にスピーカーは使わないです。これは、色々な要因により安定した環境を保ちにくいためです。ヘッドホンやイヤホンは、ある程度条件を固定できるので、調整に没頭しやすいですね。

    あと、ちょくちょく、全く異なるシステムで試聴する時間を挟みます(チェイサーみたいなものですね)。

    リファレンス音源ですが、基本的には個々の好きなものに合わせれば良いと思いますが、私的には最近の良録音盤ではなく、アナログ録音時代の良録音とされている盤で追い込むことをオススメしたいです。最近のものは、割と鳴らしやすいミキシングをしてくれているので、微調整するにはアナログ録音時代のもの(良録音と言われているものも、きちんとセッティングできていないと鳴らしにくい)が良いと考えています。
    少人数編成のジャズ(50年代後半から60年代の録音)で、合わせておいて、大編成のオケ(70年代の録音)でも、きちんと鳴らせるか確認し、粗があればジャズに戻って微調整して…の繰り返しです。
    一旦決まったら、新しい録音のものも含めて、色んな盤を聴いて最終確認を行います。この段階で初めてスピーカーからも音を出します。

    ※新しい録音のもので手をつけ始めると、行ったり来たりの回数が多くなるので、ある時期からは、必ず古い録音をベースにしています。

    設定値が決まった後は、ただただ音楽に浸るのみです。なので、アップデートの間隔が長い方が浸れる時間が長くなるので、ありがたかったりします(笑)

  • パパリウスさま

    詳細な仕掛けを教えていただきありがとうこざいました。

    やっとなんとか理解できたように思います。

    闇雲に調整していると、良い音の小さな丘がいくつもあり途中の勾配がなだらかという、最適値を割り出すには総当りしかないとんでもなく難しい仕掛けだと思っておりました。

    お聞きした内容から、その結果もその時点のマシンの働き方によりランダムにばらついていて更に難しいことがわかります。

    つまり、自分のソースと好みを勘案しながらひたすら聞き続けてやっとこれならいけると納得できるものにたどり着くというわけです。

    W.Peachさまの費やした時間と集中力はいかばかりかと恐れ入ってしまいます。

    私のような根気のないものには、パラメーターの総当たりの組み合わせから得られた結果の超大な記録から評価して良いところの山をいくつか割り出す評価システムが不可欠ですね。

    それが途方も無く難しいものだとすると、やはり W.Peachさまの努力の結果をありがたくいただくという虫の良いお願いを聞き届けていただくのが一番です。

    W.Peachさま

    評価に使うソースは「アナログ時代の良質な録音」というのは心から賛同いたします。

    デジタル録音はとてもばらつきがあります。そのばらつきも聞くシステムによって違う結果が得られるという種類のものまであるように思います。

    自宅で素晴らしい録音だと思ったソースを、音響効果が素晴らしい空間に持ち込むとなんだかつまらないということはしばしば経験します。

    その時、素晴らしいと思える録音は、アナログ時代の好録音と、デジタルなら良いホールや音響空間で響きを重視して録音された1995年以降の録音ものが多いように思います。

    でも自宅では好きなプレイヤーならどんな録音でも聞きたいのでそうばっかりは言ってられません。

    SMPD 0.9.3 W.Peach Tunes は、悩めるものにとってノアの方舟です。この中にいる限り安穏と音楽と楽しく暮らせます。多少録音が悪くとも好きなプレイヤーの音楽を安心して楽しめます。

    ほんと、この安楽な時間が続きますように。

  • W.Peachさんがお書きになっているとおり、Gravityチューニングは総当たりです。

    デフォルト設定が概ね最小値ですので、そこから値を大きくしていきます。

    最小値〜平均値までの幅は、
    irq・・・150ナノ秒
    kernel・・・250ナノ秒
    user・・・400ナノ秒
    ぐらいになります。

    設定値は52ナノ秒刻みですので、
    irqは3パターン、kernelは5パターン、userは8パターン。
    その組み合わせを総当たりで試聴すると、約120通りということになります。

    平均値に近すぎる設定値を対象から外せば、2x4x7で全56パターン。
    irqをデフォルト値に固定するなら、1x4x7で全28パターンです。

    (しかし、、、mpd/AirPlay/Spotify Connectで最適値は異なりますので、これらの設定も個別に追い込みたいなら労力は3倍ということになります。)


    デフォルトからgravityを大きくしていくと、
    高域が良化、低域が悪化していきます。

    そして、gravityを大きくしすぎると高域も悪化に転じます。

    ですので、高域の良化によるメリットが低域の悪化を上回り、総合的により好ましいという状態を探すことになります。

    高域の良化・低域の悪化というのは大雑把な表現ですが、重要なことはgravityを変えるとメリット・デメリットの両方が現れるということです。そして、その変化は連続的なものではありません。mikeさんがお書きになったように、良い音の小さな丘が断続的に出現します。
    さらに言えば、バージョンによっては総合的により好ましい組み合わせが存在しないということがあり得ます。(gravityが52ナノ秒刻みのため、最良のポイントを飛び越えてしまう)
    あったとしても、ピンポイントで数パターンのみということもあります。

  • 0.9.4b4を試聴いたしました。
    b3は時間が取れずスキップしてしまいました。

    安定、安心のsymphonic-mpdサウンドです。

    gravityチューニングネタとしては、(クロックは0.9.3と同じで)677 1666 2708がお気に入りです。
    面白いもので、677 1614 2708にすると音が痩せてしまいます。

    0.9.3よりもやや小さい設定値が合うということは、以前よりも処理能力が向上しているのでしょうか。

  • @W-Peach さん

    お試しいただきありがとうございます。

    β1からβ4では、xsinkドライバ上のリングバッファからデータをコピーする処理の高速化を進めてきました。

    v0.9.3で約500ナノ秒かかっていた処理を、β4では350ナノ秒まで短縮しています。

    リングバッファの読み書きではバッファの境界を跨ぐ処理が複雑になりがちで、処理時間のばらつきの原因となりますが、β4では実装を工夫し、ばらつきを1チック(52ナノ秒)未満に抑えています。

    また、β1〜β2ではコードサイズが肥大化してCPUキャッシュヒット率が悪化していたのですが、β4ではv0.9.3と同程度のコードサイズに納めることができました。

    v0.9.3の完全上位互換と言える出来栄えです。

  • Gravityチューニングの話題で盛り上がっているところに水をさすようで気が引けるのですが、core_freqを変更する際にはdot-blob.binの編集も必要なのではと思っておりまして、ずっと「一言言っとくべきなんじゃ」とムラムラしておりました。

    W.Peachさんはconfig.txtでarm_freqを1203、core & sdram_freqを401に編集された上でグラビティのパラメーターを操作されていると理解しております。それにならって、同様にconfig.txtを編集している方もおられるのではと、ちょっとヒヤヒヤしながら話の流れを読んでいました。

    W.Peachさんもご存知のとおり(この話題、以前もありましたから)、デフォルトのdt-blob.binはcore_freq=576をベースに編集されています。そのdt-blob.binをデフォルトのままにしてcore_freqだけを編集すると、SMPDが本来の性能が発揮できないことになります。ですのでcore_freqを変更する際には、併せてdt-blob.binのソースのダウンロードと内容の編集、ならびにビルドとdt-blob.binの置き換えが必要になります。でないと、せっかくの音質アップ作業の足を引っ張ることになりかねません。そのことが話題に上らないまま話が進んでいくことに、ちょっとだけ危機感を覚えました。
    ただしこれはconfig.txtを編集した場合の話であり、編集しない場合は全く関係のないお話です。その場合は笑って読み飛ばしてくださいませ。

  • ジャイアン 様

    クロック変更と、dt-blob.binは毎回の事なので端折ってしまいました。
    改めて補足いただき、ありがとうございます。

    環境によっては置き換えが上手くいかない(起動しなくなる)こともありますが、その場合は、削除したまま(dt-blob.binなし)でも、特別聴感上の問題はないように感じます。

  • パパリウスさま、
    W.Peachさま
    ジャイアンさま

    すみません、dt-blob.binの編集もせずにクロックをいじっているのは無精者のmikeであります。

    師匠ジャイアンさまのご指示通り、dt-blog.binをきちんと編集しdtcして、さらに余計なサービスも止め、新しいver0.9.4b4 Peach Tune をきちんと聞いてみました。

    素晴らしいです! Ver 0.9.4b4 の自然でどれを聞いても美しい、しかしながら私には少し抑制的に聞こえた音が、新らしい Peach Tune では、もともとある美しい響きと、切れの良さ、クリアさ、そして強さが両立し、リズムもさらに鮮明に表現してくれるようになりました。

    つまり、Kit Armstrong、Bill Evans、Lief Ove Andsnes、Maria Joan Pires、Eva Knardahl、内田光子のタッチの違いとそれぞれ異なる美しさがとても良くわかって楽しくなります。素晴らしいです。

    Latency もブルーのラインのピークは150~200程度、なおかつ(ちょっと寒いせいもありますが)cpu温度は39.7℃と低位安定しています。

    そしてその後、新旧そしてジャズとバロックを取り混ぜていろいろな曲を聞き続けてておりますが、少し問題のあると思われる録音も破綻なく楽しめ素敵です。

    パパリウスさま、M.Peachさま、ジャイアンさま、ありがとうございました。

    これからも面倒がらず、きちんと環境を整備して王道を歩いてまいりますので、ご指導よろしくお願い申し上げます。

  • みなさま

    先ほどの ver.0.9.4b4 Peach Tune 試聴記お詫びして訂正いたします。

    dt-blob.bin をきちんと置き換えて、と書きましたが、その後チェックすると削除されただけで /boot にはdtcされたものがコピーされておらず、dt-blob.bin なしでの試聴結果でした。

    さて、そのことに先ほど気が付き、dtc したものをbootに書き込むと、きちんと立ち上がりませんでした。起動音は鳴るのですが少し歪んでいます。そしてSSHからympdも接続できません。

    この dt-blob.bin を削除するときちんと立ち上がり、試聴した通りの美しい音で再生をはじめました。
    今までで最上の結果ですから、私にとってはこれでなんの文句もありません。

    Ver 0.9.4b4 でdtcがうまくでききちんと稼働されている方はいらっしゃいますでしょうか?

    ジャイアンさまマニュアルに従っているように思うんですが、どこで間違っているかは発見できていません。

  • mike様

    dt-blob.binですが、環境によっては起動しないことがありますね。
    当方の環境でも、所謂普通のNASを使用している方は問題なく起動しますが、カードリーダ機能付きのポータブルルータの方は起動しなくなります。なので、ポータブルルータのほうは削除して動かしています。
    理想はポータブルの方もきとんと当てがって鳴らしたいですが、聴感上そこまで気にならない(気づかない)ので、とりあえず良しとしています。

  • W.Peachさま

    夜遅くにもかかわらずお声をかけていただきありがとうございます。

    風呂に入りハット思い出しました。私のつかっているボードは、Allo Reclocker で、これは slave として動作しslave dac にmaster clock を提供するものです。

    つまり、dt-blob.bin はsloveのものを使ってdtcしなければならないのです。

    ほんとにお騒がせいたしました。

    いま、取り合えず、pll c のみclockを1203に書き直し、dtc したものを dt-blob.bin として立ち上げてみると、無事立ち上がりました。

    slave における pll d 設定については理解していないのでとりあえずはデフォルトのままで放おってあります。

    いや、お恥ずかしい限りです。
    音が変わったかについては明日検証することにいたします。

  • パパリウスさま、
    W.Peachさま
    ジャイアンさま

    ver0.9.4b4 Peach Tune の最適設定を求めて、dt-blob.bin をconfig.txtでの設定に合わせて修正するというトライアルをした結果です。

    昨日からドタバタとゴミのような報告でご迷惑をおかけしましたが、Kali Reclocker(slave) dt-blob.bin を slabeベースに修正し、以下のような結果となりました。

    PLLC を 1203 に設定した dt-blob.bin でも、default の dt-blob.bin にしても、dt-blob.bin なしで立ち上げても、latency グラフの様子は変わらず、音も変わりなく、とてもいい感じで気分良く楽しめます。
    (設定の切り替えに時間がかかるため細かい違いはわかりませんが、参照用の別DACの音と比較しても変化はわからない程度のようです。)

    これはおそらく、Kali Reclocker でclockの変動を吸収してしまうため、僅かな変化であればその変化が音に出てこないためだと推測できますが、latencyグラフに変化がないのはもともとの変化も小さいということなんでしょうか。

    次に master系もトライしようと、SB32pro(master) の dt-blob.bin の PLLB、PLLC、の修正にもトライしてみました。

    config.txt で設定したclock 1203 合わせて dt-blob.dts.v08x.master に、ジャイアンさまのマニュアルを参照しつつ修正し、dtc して作成した dt-blob.bin ファイルで立ち上げようとしても立ち上がりません。
    PLLCのみの修正にとどめても結果は同じでした。

    正確には、起動音はなりますが、SSHもympdも接続できません。

    有線LANのランプのつき方がゆっくりと点滅するパターンのままなので、device tree がうまく構成されていない可能性があり、それでLANがきちんと接続されていないように思います。

    また dt-blob.bin なしで立ち上げても、deaufltの msater系の dt-blob.bin で立ち上げても latency グラフの様子に差が殆どなくどちらもきれいです。

    きちんと設定し直したファイルで再生したいとは思いますが、現状ではうまく働かずどこが悪いのかわかりません。
    音の比較はできませんでしたが、default の dt-blob.bin で気持ちよくなりますのでまあこれでいいかという感じです。

    SB4Bのプロジェクトが進行し始めたようでこちらはこれくらいで止めようと思います。

    以上、役に立たない報告でみなさまの貴重な時間を潰してしまい申し訳ありません。