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 さんの会話に啓発され、再度試してみようかと思いたった次第です。
というわけで、早速、賢者の方に質問させていただきます
上述した gravity チューニング指針は、現在の v0.9 系でもそのまま使用できるのでしょうか?W.Peach さんが
ここ最近のバージョンは、従来のgravityチューニングのノウハウとは異なる挙動をするので、傾向を探るのに少し難儀しました。
とおっしゃっていたのが気になりました。別のアプローチが必要でしたら、ご教授いただけると助かります。