abk1's scratched blog 3

前回のエントリーで、LANの構成図をアップした。
今回は、引き続きLANネットワークを見直し、DACの電源も見直した。
現在のLAN構成図は以下。

上流には、HuMANDATA LNX-007Lを追加している。
音が激変した（最近、激変が多い）。
下記に、JS PC Audio オンラインショップから画像を引用。JS PC Audio Blogから説明を引用。

LANアイソレーター LNX-007L
https://www.shop-jspcaudio.net/shopdetail/000000000136/

JS PC Audio Blog
http://blog.jspcaudio.net/?eid=403
「LANアイソレーター LNX-007Lの挿入はもうひと押し欲しいという方にお勧めです。LNX-007Lはフレームグラウンドが繋がっていませんが、端子を使って短絡することも可能な製品です。改善の効果としては、薄いベールが1～2枚剥がれるようなイメージです。」

薄いベールが1～2枚、、、
うちでは1個使用でいきなり、なんというのか、耳から鱗が落ちるというような、それほどの違いがあったように思う。
最初は、PPAP middle-endの手前で使用した。
２つ目はback-endの手前で、そこまでの大きな効果は無かった。
しかし、更に2個、追加して見ようと思い、ONUの周囲で追加した。まあ、取り敢えず、ここらあたりまでかな、、、でも追加の副作用は全く感じないので、更に追加したら何か変わるだろうか、という気持ちはある。
どこで使うのが一番有効なのかは確認していない。一旦付けたらもう外せないと思った。

最近、MFPCが複数台使用から1台に集約されたという話があって、どういう意味だろうと思っていたんだけど、今回、このようなことがあって、音声データがネットワークを経由する弊害から逃れられることには、僕が思うより大きい利得があるのかもしれないと思った。
まあ、見当違いかもしれないけど。

僕の場合は、Daphileは使っているしmpdアップサンプラーはマシンパワーを食うしPPAPは1台に出来ないしで、集約するという方法論は無理なので、暫くは複数台連携でやっていくことになるだろう。

あれこれするうちに、若干だがPPAPサーバーの配置が変わった。
middleとbackの間にハブとアイソレーターが入っている。
実際のとこ、どう配置するのがベストなのか確認していないんだけど、悪化はないのでこの配置で暫く使うつもりだ。

さて、同時に、下流も久しぶりに少し変わっている。

ADI-2 DACと、Pegasus R2R DAC、以前は安定化電源のBY50Sから電源を取っていたが、PB-500-2に繋ぎ変えた。
昔、大して変わらないと思った筈なのだけど、今回繋ぎ変えてみたら、音の陰影がまるで違った。絵で言えば黒が深く色が鮮やかに、空間への浮き方がくっきりして、実体感が増したように思う。
我ながら迂闊だったが、気が付いてよかった。

思い当たるのは、BY50Sのバッテリーがヘタってきてるのが原因ではないかと。
違うかもしれないが。
BY50Sは数年に1回、バッテリー交換しないといけないのだ。そろそろ、そういう時期になる。考えてみたら、そういう配慮をしないといけない電源は、配慮が行き届くしっかりした人じゃないと扱いにくいかもしれない。というか、僕のようなずぼらな人は気を付けないといけないのだろう。
そういう意味で、PB-500-2のほう管理が楽かもしれない。

些事だが、今回からサブシステムは図から外した。
CDはメインシステムで聴くようになり、殆ど使わなくなって久しいので。

前回のエントリーで、システム構成図をアップした。
そこでも書いたけど、上流はゴチャゴチャして整理がついていない。
今回は、家庭内LANの構成を図にしてみた。以前にも作ったことがあるけど、そのときには描いてない部分も書き込んでみている。

追記。
せっかく作った図ではあったんだけど、ONUをOMUと書き間違えている。直すのも面倒なのでこのままにする。

6月下旬の時点で上図のような構成。
黄色がノートPC。紫枠がボードPC。緑枠がNAS。白がスイッチングハブ。グレイがその他のサーバー（DHCP、AP。スイッチングハブと兼用だ）。
なんでこうなってんの、という感じに建て増しの跡がある構成図だ。

ネットワーク上のノイズはオーディオに悪影響がある。今回、問題と思われる場所に手を入れていくことにした。

まず、5GHzで動いているAP。
これは、最初に動かしていたAP（AtermWG300HP）に接続エラーが多かったのを、接続が集中しているせいかもと考えて追加した物だ。
それで状況が改善した印象はなかったが、せっかくあるのだからと使っていた。
こんなところにシステム構成上重要なmpdサーバーが繋がっているのは、置き場が他に確保できなかったからだ。APはノイズ源なので音に影響するかもしれない。

実際のところ、5GHz APは近くにしか電波が届きにくくて使いにくく、いらないと判断し止めることにする。理由は分からないが、エラーもなくなってることだし。
更に、敢えて機能が多い機械であるATERM-16E2EDを此所に使う必然性はないので、NETGEAR GS105に替えて、接続の配置も変える。

音は、変更していくに連れて改善したように思う。ベールがはがれていくような感じ。
しかし、ブラインドで聴き分けるのは難しいかもしれない。

次に、mpdサーバーで処理されたデータ信号がOMUONU、DHCPサーバー（ノイズ源）であるPR-500MIを通るのは良くないのではないか、ということで、3通り接続を変えて試してみた。

ストリーミングの音楽データは、ウェブからPR-500MI、Daphile、PR-500MI、mpdサーバーであるHP PB 450G9、と流れて処理される。
そこから、GS105E、PPAP Back End、と流れていく。

3番目の接続は、ProBook 450G9で処理された信号がPPAP Back Endに向かう際にPR-500MIを通らないのでノイズの悪影響が少なく音がいいのではないか、と予想したのだけど、1番目と変わらない感じ。
意外なことに、信号がPR-500MIを通る2番目が一番良かった。
耳のいい人だったらブラインドでも区別出来るかもしれない。

2番目と1、3番目で何が違うかといえば、NETGEAR GS105Eに繋がっているLANケーブルが２つか３つか、ということだ。
ハブの負担が少ないことに意味がある、のかな、、、

次は、PPAP back-endの近くに音源用のNASが2台あるのがどうなのかと。

これも置き場の確保が難しくて現在の場所に置いてある。
外してみたら音は良くなるのかどうか。
単純に、LANケーブルを外して接続を切って聴き比べた。音源はストリーミングのDeezer HiFiを使った。
これは、意外に差が出なかった。違うような違わないような、、、

NASを移動できる場所もないので、このままで様子を見ることにした。

そういうわけで、現在は下図のような接続になっている。
大して変わっちゃいないが。

あれこれ試みる前と後で、ベールが1枚ぐらい剥がれたぐらいの違いはあるような気がする。
今すぐにできるところはこんなところか。整理がついたとは言いにくいけど、マシになってはいると思う。

前回の状況報告から1年経っている。若干システム上流に変更がある。下流は全く変化がないと思う。
最近のシステム構成は下図のような感じ。

上流は、本来すっきりしている方がノイズが少なくていいのだけど、ごちゃごちゃしている。
mpdサーバーが2機、Daphileサーバーも2機。
これが、恒常的に続くのかどうかもはっきりしない。というか、外すことに意味が見出せないというか、いや、ノイズは減るんでしょう?と思うんだけど、なんか動かしときゃいいじゃないの、大して変わらんじゃないのというか。

Daphileサーバーは其々、メイン機とテスター機で、Youtubeプラグインはテスターにしか入っていない。Youtubeは頻繁には使わないので、今更、メイン機にインストールする気がしない。

mpdサーバーは、1台は先代メイン機で、SRCの設定はMediumで、サンプリング周波数は768kHz。
もう1台は現在のメイン機で、SRCはBestの設定で動かしている。サンプリング周波数は384kHz。なんで２つ動かしているかというと、いちいち設定を書き換えてmpdを再起動するのが面倒だから。

そういうわけでPPAP Back-Endでは、PCM信号を受けるncatコマンドを２つ動かしている。
今後、SRCの効き方を聴き比べようかというようなことになったら、さらにncatを追加して動かすかもしれない。

PPAPの設定は、FrontとBack-End、ペアでしないといけない。設定変更する際に、いちいちFrontのmpdとBack-End、両方の設定を書き換え再起動するのはめんどうだ。
Back-Endで複数のncatを動かして、其々に受け取るPCM信号を予め設定しておけば、設定変更して再起動するのがFrontのmpdだけになる。
そうなると、比較視聴の運用が相当手軽にできる。

まあ、先のことになるだろうけど。
なんというか、こんな感じで気が抜けた状態で、聴き専状態になっている。

Medium/768kHzとBest/368kHzを比較して、はっきり後者の方が音がいいといえる音源は、環境音を録音した音源だ。
例えば下記のようなもの。
Walter Tilgner - Waldesrauschen (Whispering Forest)
https://www.discogs.com/ja/release/8318592-Walter-Tilgner-Waldesrauschen-Whispering-Forest

鳥の鳴き声が、なんというか、人間が作る楽器よりも複雑な音を出せるということがより明らかになるというか。キツツキが木を叩く音のリアルさが、こんな言い方したくないが、激変するのだ。
一方、人が作る音楽は、そこまでの差は出ない。
もちろん差はあるのだけど、大抵の音楽の場合、キツツキほどの差は出ないし、音楽を聴いての感動の質には大差がない。デリケートな音色をした音源は違いが大きく出るように思う。とか言ってるが、まだそんなに多くは聴き込んでいないというのが実際のところ。

世の中がわけがわからないので疲れぎみ。コロナにも注意がいる。頑張っていかないといけない。

前回のエントリーでは、TC64-11.1 mpdサーバーをHP Probook 450 G9で動かした。
どこまでやれるか試しているのだが、ここで問題がある。

カタログ上、450 G9のCPUは最高4.9GHzで動く筈だが、3.7GHzまででしか動いてくれない。
インテルのCPUにはターボ・ブースト・テクノロジーというのがあって、負荷がかかると自動的にクロック周波数を上げるのだけど、それが充分に機能してない？ようなのだ。
原因が分からない。

ネット上で調べたところ、原因として考えられるのは、熱の問題、電力の問題、BIOSのバグ、これらは該当しないだろう。
あと、AVX2、AVX-512のような遅いSIMDがクロックを下げるとか。
これはよく分からない。アクティブなコアが増加するとクロック周波数の上昇率が下がるということらしいが、mpdサーバーで動いているプロセスは少ない。
ほとんどのコアは仕事をしてないようにすら見えるので、これも違う気がする。

うちのmpdサーバー EliteBook 820 G2の状況をメモ。

tc@box:~$ grep MHz /proc/cpuinfo
cpu MHz		: 2886.755
cpu MHz		: 2831.833
cpu MHz		: 2697.611
cpu MHz		: 2694.282

tc@box:~$ cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor
powersave
powersave
powersave
powersave

tc@box:~$ grep 'model name' /proc/cpuinfo
model name	: Intel(R) Core(TM) i5-5300U CPU @ 2.30GHz
model name	: Intel(R) Core(TM) i5-5300U CPU @ 2.30GHz
model name	: Intel(R) Core(TM) i5-5300U CPU @ 2.30GHz
model name	: Intel(R) Core(TM) i5-5300U CPU @ 2.30GHz
tc@box:~$ 

powersaveで動いている。
CPUは2.30GHzだが、動くときには2.8GHz以上で動いている。i5-5300Uのターボ・ブースト利用時の最大周波数は2.90 GHzであり、ブーストが機能している。
（powersaveでもブーストは効くんだね）

そういうわけで、Probook 450 G9のi7-1255Uでターボ・ブーストが機能しない？のが残念な状況だ。
正直、買って試してみないと分からないな、というのはあったので想定内といえばそうなんだけど、820 G2で動いてるんだから多分いけるだろう、と甘い判断をしたわけだ。、、

Probook 450 G9をmpdサーバーとして動かしてみたときの状況。

tc@box:~$ grep MHz /proc/cpuinfo
cpu MHz		: 2608.375
cpu MHz		: 2643.276
cpu MHz		: 3700.000
cpu MHz		: 3700.000
cpu MHz		: 820.543
cpu MHz		: 1357.115
cpu MHz		: 2889.705
cpu MHz		: 1141.198
cpu MHz		: 2205.000
cpu MHz		: 2569.790
cpu MHz		: 1859.254
cpu MHz		: 888.040

tc@box:~$ cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor
powersave
*snip*

tc@box:~$ grep 'model name' /proc/cpuinfo
model name	: 12th Gen Intel(R) Core(TM) i7-1255U
*snip*

tc@box:~$ 

こんな感じで3.7GHzが上限になっている様だ。なんでかねえ、、、

https://www.intel.co.jp/content/www/jp/ja/products/sku/226259/intel-core-i71255u-processor-12m-cache-up-to-4-70-ghz/specifications.html
インテル® Core™ i7-1255U プロセッサー

上記のインテルのサイトによると、
Performance-coresの数　2、Efficient-coresの数　8
Performance-core最大ターボ・フリークエンシー　4.70 GHz
Efficient-core のターボ・ブースト利用時の最大フリークエンシー　3.50 GHz
とある。

https://xtech.nikkei.com/atcl/nxt/column/18/02268/111800001/
最新のインテルCPU、第12世代Coreシリーズは何が違うのか
日経クロステック 2022.12.12

上記記事によると第12世代のインテルCPU、つまりi7-1255Uは、PコアとEコア、2種類のコアを積んでいると。
高い性能が必要な処理はPコア、負荷は低いが常時実行するような処理はEコアが向いているそうだ。
性能を重視した従来のCPUコアがPコアであり、性能よりも電力効率を重視したのがEコアで物理的サイズはPコアの4分の1と。
そんな構造なので、スレッドごとの処理を適切なコアに割り振る「スレッド・ディレクター」というのがCPUに組み込まれていて、負荷が高い処理はPコアに振り分けされるらしい。

実際、topでの挙動を見ると、mpdの処理は専ら「CPU0」と「CPU2」、２つのスレッドが代りばんこに受け持っているようだ。CPU0～3がPコアのスレッドなのかな。
これは、４つのスレッド全てでリレーする、820 G2のi5-5300Uの挙動とは異なる。
しかしそれなら、4GHz以上で動いてもいいと思うのだが、、、

ネット上を調べていたら、CPUの動作クロックを設定する「cpufreq」というツールがあり、Tiny Core 11では「cpupower.tcz」という形でリポジトリ上にあるらしいということが分かった。
インストール。

tc@box:~$ cpupower
Usage:	cpupower [-c|--cpu cpulist ]  []
Supported commands are:
	frequency-info
	frequency-set
	idle-info
	idle-set
	set
	info
	monitor
	help

Not all commands can make use of the -c cpulist option.

Use 'cpupower help ' for getting help for above commands.

tc@box:~$ cpupower frequency-info
analyzing CPU 0:
  driver: intel_pstate
  CPUs which run at the same hardware frequency: 0
  CPUs which need to have their frequency coordinated by software: 0
  maximum transition latency:  Cannot determine or is not supported.
  hardware limits: 400 MHz - 4.70 GHz
  available cpufreq governors: performance powersave
  current policy: frequency should be within 400 MHz and 4.70 GHz.
                  The governor "powersave" may decide which speed to use
                  within this range.
  current CPU frequency: Unable to call hardware
  current CPU frequency: 405 MHz (asserted by call to kernel)
  boost state support:
    Supported: yes
    Active: yes
tc@box:~$ 

tc@box:~$ sudo cpupower frequency-set -g performance
Setting cpu: 0
Setting cpu: 1
Setting cpu: 2
Setting cpu: 3
Setting cpu: 4
Setting cpu: 5
Setting cpu: 6
Setting cpu: 7
Setting cpu: 8
Setting cpu: 9
Setting cpu: 10
Setting cpu: 11

tc@box:~$ cpupower frequency-info
analyzing CPU 0:
  driver: intel_pstate
  CPUs which run at the same hardware frequency: 0
  CPUs which need to have their frequency coordinated by software: 0
  maximum transition latency:  Cannot determine or is not supported.
  hardware limits: 400 MHz - 4.70 GHz
  available cpufreq governors: performance powersave
  current policy: frequency should be within 400 MHz and 4.70 GHz.
                  The governor "performance" may decide which speed to use
                  within this range.
  current CPU frequency: Unable to call hardware
  current CPU frequency: 657 MHz (asserted by call to kernel)
  boost state support:
    Supported: yes
    Active: yes
tc@box:~$ 

tc@box:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
performance

「powersave」を「performance」に変更。
これで、CPUがパフォーマンス優先にセットされた。

これでどうかというと、やはり、3.7GHzまで。
どうしたものかな、と思いながら使っていたら、ときに3.7GHzより少し上が出る。コンスタントには出ない。しかし、どうやら出せないわけじゃないんだろうなと。

そこで、BIOS関係で節電に関する設定を調整してみることにした。

ネット上に公開されているHPのマニュアルから引用。
HP PC Commercial BIOS (UEFI) Setup
Administration Guide
For Commercial Platforms using HP BIOSphere Gen 7-9 2020 -2022

5.9 Power Management Options Menu

Runtime Power Management	When checked, enables the processor to run at lower frequencies (P-states) when higher performance is not needed. When unchecked, the processor always runs at maximum frequency.
Extended Idle Power States	When checked, enables the processor to rest in lower power states (C-states) when idle.
Power Control	When checked, enables the notebook to support power management applications such as IPM+ that help enterprises reduce power costs by intelligently managing the battery usage of the notebook.
Battery Health Manager	Sets charging policy based on optimizing for battery life or for battery duration. The possible settings are: • Maximize my battery health • Let HP manage my battery charging

しかし設定できる項目が少ない。こんなもんなのかなあ。
ネット上の日本語マニュアルは古いので英語の方を読む。日本語版には書いてないようなことが書いてある。

とりあえず、下記のように設定してみた。

Runtime Power Management	on → off
Extended Idle Power States	on
Power Control	on → off
Battery Health Manager	Let HP → Maximize

設定変えたら、ほとんど動いていなかったEコアたちが一斉に動きだし、音が途切れるように。
Pコアに重要な仕事を降るということをしなくなったようだ。
変更した設定を戻していく。
Power Controlを「on」に。

Pコアに仕事を降るようになった？ようだが、それでも音が途切れる。

tc@box:~$ cpupower frequency-info
analyzing CPU 0:
  no or unknown cpufreq driver is active on this CPU
  CPUs which run at the same hardware frequency: Not Available
  CPUs which need to have their frequency coordinated by software: Not Available
  maximum transition latency:  Cannot determine or is not supported.
Not Available
  available cpufreq governors: Not Available
  Unable to determine current policy
  current CPU frequency: Unable to call hardware
  current CPU frequency:  Unable to call to kernel
  boost state support:
    Supported: no
    Active: no
tc@box:~$ 

tc@box:~$ grep MHz /proc/cpuinfo
cpu MHz		: 841.518
cpu MHz		: 1462.869
cpu MHz		: 1700.000
cpu MHz		: 1703.346
cpu MHz		: 634.992
cpu MHz		: 1034.485
cpu MHz		: 1013.223
cpu MHz		: 1197.852
cpu MHz		: 1119.194
cpu MHz		: 977.032
cpu MHz		: 1196.461
cpu MHz		: 1198.542
tc@box:~$ 

なんか、すごく上手くいってないっぽい。IntelのCPUだという認識が出来ていない。
クロック周波数も上がっていない。

Runtime Power Managementを「on」に戻す。
Power Controlを「off」に。
これで、まともに音が出るようになった。

tc@box:~$ cpupower frequency-info
analyzing CPU 0:
  driver: intel_pstate
  CPUs which run at the same hardware frequency: 0
  CPUs which need to have their frequency coordinated by software: 0
  maximum transition latency:  Cannot determine or is not supported.
  hardware limits: 400 MHz - 4.70 GHz
  available cpufreq governors: performance powersave
  current policy: frequency should be within 400 MHz and 4.70 GHz.
                  The governor "powersave" may decide which speed to use
                  within this range.
  current CPU frequency: Unable to call hardware
  current CPU frequency: 966 MHz (asserted by call to kernel)
  boost state support:
    Supported: yes
    Active: yes

tc@box:~$ sudo cpupower frequency-set -g performance
Setting cpu: 0
Setting cpu: 1
*snip*

tc@box:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
performance
tc@box:~$ 

これで700kHz台を出そうとしたが、やはり10秒ほどでぶちぶち途切れる。
300kHz台だと問題なく音が出る。
音が出ているときのCPUのクロック周波数の上限は3.7GHz付近で変わらない。
まともに音が出ていないときは、クロック周波数も上がっていない、ということがある。ここの辺り挙動が謎だ。

ちょっと気になったのが、BIOSの説明書に出てきた「IPM+」というもの。
電源管理を行うソフトらしい。
Windowsで起動したら設定できるらしいので、セキュリティブートを有効にしてWindowsを起動し確認してみたら、インストールされていないようだったので、ほっとくことにする。

結局、BIOSの電源関係はあまり関係ないように思われた。

もしかして、Tiny Core OSの問題？とも思ったりもするが、調べてもはっきりしないし、確信もない。

この件は、当面、保留である。

そういうわけで、HP Probook 450 G9 mpdサーバーは、libsamplerateの設定を「Best Sinc Interpolator」、アップサンプリング設定を384kHzで動かしている。

そこそこ余裕を持って動いているように見える。
というのは、topで見るとmpdを担当するCPU0、CPU2、2つのスレッドがともに休んでいる時間がそこそこ見えるからだ。
比較したら、820 G2でMedium、768kHzで動かす方がもっと余裕がある挙動で動く。
Bestの設定は、やはり相当、重いのだと思う。

音はそれに見合うものがあると思うのだけど、音質の確認は流し聴きだけで、十分にはしていない。
音源によってはリアリティがMedium、768kHzより高いと思う。
Medium、768kHzと、Best、192kHzだと、どっちがいいかは好みにもよるかも、みたいな感じだった。これらも真剣に比較しないまま今に至ってるんだけど、Best、384kHzは、それらの水準を超えると思う。

今後、余裕がある時に確認していこうと思う。
課題はいろいろ残っているけど、無理せず、焦らず、という感じ。

今月は、TC64関係のエントリーを２つ上げている。
HP Probook 450 G9で起動できるTC64-14を作るところまでこぎつけた。
今回は、450 G9でmpdサーバーを動かそう、というものだ。

動かすといったって、いちからmpdなどなどをインストールしてサーバーを構築しようというのではない。けっこう大仕事なので、そこまでする余裕はない。
現在、使っているTC64-11.1 mpdサーバーと同じものを、450 G9で動かそうということだ。

もちろん、そのままでは起動できない。
ブートローダーが新しいBIOSである「UEFI」に対応してないからだ。
しかし、Tiny Core Linuxというのは、かなり融通無碍なディストリビューションだ。
タイトルにあるように、過去の資産を使って、動くものを設えようというのが今回の話。
そんなに長い話にならない。

準備するのは、
１）　インストールするためのUSBメモリ、１つ。
２）　現在のPCオーディオシステムに使っているmpdサーバーTC64-11.1のイメージファイル。
３）　先日作った450 G9で起動できるTC64-14のイメージファイル。

さて、手順だ。

上記の２）、３）を日常使いのPC（うちのOSはFedora）上に準備する。
（今回の場合、２）は過去にバックアップしたimgファイルがある。３）も先日作ったのをパーティションイメージとして保存している。）

USBメモリを日常使いのPCに刺し、インストールするパーティションを作る。
mpdサーバーのimgファイルの大きさは500MB強なので、1GBもあれば十分以上。
使うソフトはユーティリティの「ディスク」。
ファイルシステムは「FAT」を選択。
パーティションが出来た時点で、自動的にシステム上にマウントされファイルブラウザに表示される。ここにmpdサーバーをインストールしていく。

次に、mpdサーバーTC64-11.1のイメージファイルを「ディスクイメージマウンター」でマウントする。ファイルブラウザ上に表示されたimgファイルアイコンを右クリックで、メニューからアプリ選択するので手軽で簡単だ。
マウントしたmpdサーバーTC64-11.1のボリュームから、「tce」フォルダをコピー、USBメモリの1GBのボリュームにペーストする。

次に、TC64-14のイメージファイルを同様にしてマウントする。
マウントしたTC64-14のボリュームから、「EFI」フォルダと「syslinux.cfg」をコピー、USBメモリの1GBのボリュームにペーストする。

以上で出来上がりだ。
450 G9でブートできる。

こういうコピー＆ペーストでOSインストールする方法は、Tiny Coreの入門書に書いてある。
http://tinycorelinux.net/book.html

過去にこうしたやり方は何回か試みたことがあったんだけど、なぜかついぞ上手くいったことが無かった。
だから今回、これで動くようなので、僕自身がびっくりしている。
（ファイルシステムに無頓着だったから上手くいかなかったのかもしれない）

そのうち、暇が出来たら使ってみようと思う。
しかし、使えるのかな、これ、、、

（使えました、、取り敢えずBest Sinc Interpolatorで384kHz、この音はいいかもしれない、、、）

前説

今回は、いよいよオーディオからは縁遠いので、pcのカテゴリーに入れている。
（17日の時点で、読みにくいな、分かりにくいな、と思ったところを多少書き直した。内容は変わっていない。）

前回、うちで使っているTiny Core 64-11.1をインストーラーに転用して、UEFI対応のTC64-14をUSBメモリにインストールした。
しかし簡単にインストーラーに出来るTCを持っている人はそういない。
Tiny Core Linuxのサイトからダウンロードできるものと最小限の機材で、UEFI対応のTCを作るにはどうするのがいいのか、今回はそういうことを考えてみた。

つまり、TinyCorePure64-14.0とPC１つと有線LANのネット環境で、どうしたらいいかということだ。
下記urlからTinyCorePure64-14.0.isoをダウンロードできる。

http://tinycorelinux.net/14.x/x86_64/release/
USBメモリなりに焼いて、ブートする。

HP ProBook 450 G9だとgrubのブート画面が出るんだけど、そこでenterを押したらモニターが真っ暗になる。
ここで「sudo reboot」を打つとPCが再起動するので、OSは起動していることが分かる。 しかしこれでは使えない。

http://forum.tinycorelinux.net/index.php/topic,25015.msg159414.html#msg159414
TCのフォーラムに似たような事例が上がっている。
BIOSの設定で解決した事例のようだけど、うちのケースはどうも違うようだ。
ここではgrub画面から設定変更して起動させる方法も書かれている。これも、うちでは効果は無かった。
結局、今までのところ、450 G9でTinyCorePure64-14.0を起動したときに正常に表示させる方法は発見できていない。

ProBook 450 G3だったら、BIOSのBoot Menuから「Legacy」を選択すると普通に起動できる。
実は450 G3、普通に起動できた後、ちょっとした手数で比較的簡単にUEFI対応のTC64をUSBメモリにインストールできることが分かった。こうして作ったTC64-USBメモリは、450 G9で普通に正常にブートできる。

だから今回は、ProBook 450 G3で、450 G9でも使えるTC 64-14.0を作る方法の記録、ということになる。
以下に記載。

インストールに使うTinyCorePure64-14.0を450 G3で起動

先ず、「TinyCorePure64-14.0」のisoファイルをダウンロードしUSBメモリに書き込みPC（450 G3）に刺す。
下記からダウンロード。
http://tinycorelinux.net/14.x/x86_64/release/TinyCorePure64-14.0.iso

今回は、インターネットに有線LANでつながる環境が必要。
TCのサーバーからダウンロードするものがあるからだ。

PC起動、escキー、f10キーからBIOS設定画面に移行。
Advanced画面を開く。
Secure Boot Configurationから、Configure Legacy Support and Secure Boot を「Legacy Support Enable and Secure Boot Disable」に設定。
Boot Optionから、起動優先順位でUSBを上げる。
Main画面を開き「Save Changes and Exit」を選択。「Yes」をクリック。
PCが再起動。
grubの起動画面が表示される。
（BIOSを設定済みであれば、f9キー、Boot Menuからだけで起動できる。）

今回、450 G3だからBIOS設定はこんな流れだが、当然他の機種なら違ってくる。

画像はスマホで撮った写真からトリミングしたもの。
ブートする方法が４つ選択できる。画像では「waitusb=5」を選択している。
そのほうがゆっくり慎重に起動するので無難、という感じ。

今回は、command line onlyではなく、GUIで操作するウィンドウマネージャを使う。
使えるPCが1台なので、sshで遠隔操作できない。
そうなると日本語キーボードを使えない。TinyCorePure64素のままでは設定できないのだ。USキーボードの設定のままで操作するので、キーボードを打つ操作は極力減らしたい。なしには出来ないが。

「enter」キーで、Tiny Core 起動。
ブート画面は以下。

上の画像は、OS起動後の画面キャプチャしたファイルなんだけど、実際の画像ファイルは、ブラウザ上の表示よりも縦尺が長い。
というか、実際のPCモニター上で、表示画面の縦を圧縮した表示になっているのだ。
だからスマホのカメラでとったBIOS画面と、OS起動後にデスクトップ（というのか？）をキャプチャした画像ファイルで、縦横の尺が違う。上下圧縮していない画像が、キャプチャ画像ファイルとして保存されるからだ。

今回、キャプチャ画像を、実際にPC上に表示された縦横比に近い感じで、ウェブブラウザ上で表示するように設定している。つまり、ブログ上ではキャプチャ画像ファイルの上下を縮めて表示している。
キャプチャ画像が大きすぎて読みにくいということもあったので。

インストールの準備　マウントツール、ターミナルを起動

まず、いくつかのソフトを起動。

上の画面、下の方、アイコンが７つ並んでいる。
右から２つ目、マウントツールをクリックしたら左上のカラフルな小さなウインドウが開く。これで、パーティションやドライブのマウント、アンマウントを管理できる。
OS起動の時点で、起動しているTCのディスク「sdb」が緑、マウントされていることが分かる。

sda1～3は、450 G3のHDDで、普段使っているOS（うちの場合Fedora。世間一般的なPCだったらWindowsが多いか）がインストールされている。
やろうと思えば、ここにTCをインストールできる。
もちろん、そんなことをしたら、HDDの内容はすっかり上書きされて消えてしまう。
つまり今回、ここは触ってはいけない領域、ということだ。
慎重を期すなら「fdisk -l」コマンドでドライブ構成を確認したほうがいいのだけど、今回は省略した。1～3があるのが普段使っているOSのドライブで、マウントされてるsdbで1しかないほうが現在起動しているTCだというのは分かるから。

画面の下、一番右の四角いアイコンで、ターミナルが起動する。上の長四角い灰色のウィンドウがそれだ。
ここからいろいろ操作する。

キャプチャ画面上、ターミナルに「tce」と入力している。入力後、enterキーで、ターミナル上でtceが動く。
tceは、Tiny Coreのソフトウェア管理・インストーラアプリだ。

インストールの準備　OSインストーラー（tc-install）と、grub2をインストール

キャプチャ画面、ターミナルウィンドウの表示。
tceが、スタンバイモード（とでもいえばいいのか）で起動されている。
Search、Provides、Keywords、Quit、と表示されているが、キーボードのキーを打つことで操作する。
Search の「s」を入力。

tce が検索モードになる。「tc-install」と打って、enter。

TCのリポジトリ上で、検索に引っかかったソフトが表示される。
（マウスの操作でターミナルのウィンドウを大きくしている。）
1. tc-install-GUI.tcz
2. tc-install.tcz

tc-installは、TC-OSのインストーラ。これがないとOSをインストールできない。
ちなみに「tcz」は、TCで使うソフトウェアを個々にパッケージ化したもの。tczの形でリポジトリに置かれているのをダウンロードするということだ。

今回使うのは「2」、ターミナル上で操作していく。「1」ならGUIで操作できるはずだが、今回は使ってない。意外と、ターミナル上で操作するのも簡単で不便ではない。

2 を入力し、enter。

tc-install.tcz の簡単な説明が表示される。
このソフト説明表示画面は、しばしば重要な内容が記載されていることがある。

ここで「q」を打つと説明表示からスタンバイモードに移行する。「i」キーで、先に検索表示したソフトのインストールが始まる。
インストール作業が進むに連れて文字列が上に上がっていく。

必要なアプリやライブラリのインストールが終わると、スタンバイモードに戻るんだけど、キャプチャはしていない。

tc-installのインストールは終了し、tceスタンバイモードから「s」で検索。
上のキャプチャ画面は、tceから「grub2」を検索し結果が表示された場面。

検索で引っかかるのは「grub2-multi.tcz」だけなので、ソフト選択画面は表示されず、すぐに説明画面が表示される。
この説明画面の文面は、あとで使う。詳しくは後述。

「q」キー、「i」キーで、grub2-multiをインストール。
関連するソフトも同時にいろいろダウンロード、インストールされる。

インストールが終わったら、「q」で、tce を終了。
これで、USBメモリにTC-14をインストールするために必要なアプリケーション２つを、TC-14にインストールした（ややこしい）。

ターミナル一番下の「clear」はターミナル画面を埋め尽くした文字をクリアし掃除するコマンドだ。
これでenterを押したら、画面がまっさらになる。

インストーラを起動、TC-OSをダウンロード

PCに、TCをインストールするUSBメモリスティックを刺す。
キャプチャ画面上、左上、マウントツールに、自動的に「sdc1」が追加される。
「sdc」がUSBメモリスティック、「sdc1」がUSBメモリスティック上のパーティションということだ。

ターミナルから、OSインストールのコマンド「sudo tc-instoll.sh」を打つ。

キャプチャ画面、ターミナル上、tc-instollが起動している。
インストールの設定開始。
Install from [R]unning OS, from booted [C]drom, from [I]so file, or from [N]et. (r/c/i/n): n

今回、ネット上のTiny CoreのサーバーからOSをダウンロードしインストールする。
ターミナル上、「n」を入力し、enter。

ネットインストールを選択したら最新のOSが自動的に選択されるらしい。
古いのを使いたければ、isoファイルをダウンロードして、USBメモリに書き込んだ上でPCに刺し「i」を選ぶんだけど、キーボードから手打ちでisoファイルの場所を指定しないといけないので手間がかかる。今回はしない。

Running OSという選択もある。
今回、インストールに使っているOSはTC64-14で最新なので、もしかしたらこっちの方が手軽だったかもしれない。
（実際やってみたら、全く手軽ではなかった。ネットインストールがずっと楽だ。）

ネットインストールで、OSを32bitか64bitか選択できる。今回は「64」で、enter。

ネットインストールなので、OSがダウンロードされる。

TC-OSインストール設定、インストール

ダウンロード終了したら、インストール方法を設定していく。

説明が英語で表示されている。Frugal、HDD、Zipの3通り。
Frugalが通常のインストールらしいが、説明を読むと、HDDがUSB接続のデバイスにインストールする場合で、今回はこれを選択。
ちょっと、まぎらわしい。
「h」、enter。

インストール先をどこにするか設定。
ここは要注意。
前述したが、本来インストールすべきではないところにインストールしたらすっかり上書きされて失くしてはいけないものが消えてしまう。
sdbとsdcは「On a removable device.」と表示されている。
間違えないように注意換気しているようだ。

今回は「sdc」にインストールするので、「3」、enter。
そうしたら、下記表示される。

Install Extensions from this TCE/CDE Directory:

追加インストールするものを、動かしているTCから移行できるらしい（触ってないので実は知らない）。
過去に使ってきた資産から使えるようにという配慮なのだろう。ただ、インストールするOSが異なるバージョンだった場合、tczのバージョンも違う可能性があるので、すんなり使えるとは限らないと思われる。
今回は何もないので、enterキーでいい。

フォーマットの選択。
今回はTCをインストールしたUSBメモリを起動ディスクにするので、あとから「grub2」をインストールする。
そのためにはフォーマットが「vfat」でなければならないようだ。
前に「HDD」を選択しているが、説明書きに「A single FAT partition will be made」と書かれてあった。だから、ここでvfat以外を選択したらどうなるのか分からない。
4. vfatなので、素直に「4」、enter。

Enter space separated boot options:
Example: vga=normal syslog showapps waitusb=5

これは、ブートローダーの設定らしい。
入れておいた方が無難かな、と思って僕はこのままコピペして設定している。
入力後、enter。

今回、GUIでTCを操作しているのは、マウスでこうした文面をコピペして入力できるのが便利だからだ。
繰り返しになるが、USキーボード設定なので、日本語キーボードでは使いにくい。
コピー＆ペーストで済むのはかなり楽なのだ。
ただし、「ctrl + c」「ctrl + v」ではコピぺできない。マウスのホイールボタン、中央クリックでコピペする。これは個別の環境によって違うかもしれない。

Last chance to exit before destroying all data on sdc1
Continue (y/..)?

「y」、enter。
これでインストール開始。

キャプチャは、インストール終了した画面。
Press Enter key to continue.とあるので、enter。

UEFIに対応できるGrub ブートローダーをインストール

キャプチャ画面、ターミナルウィンドウが２つに増えている。
下のターミナルウィンドウで、tceを起動。

「grub2」を検索。
何をしようとしてるかというと、grub2の説明画面を表示しようとしている。
そこに記載された文面が必要なのだ。

表示を拒否された。
「can't open '/tmp/select.aus': Permission denied」とある。権限が無いということだ。
一旦、「q」を打ってtceを閉じて、「sudo chmod 777 /tmp/select.aus」と打ち込んで権限を変更してから、再度、tceを起動しgrub2を検索したら表示されるようになる。
ここらはキャプチャし忘れた。

どうも表示を拒否される場合とされない場合があるようで、理由がよくわからない。
拒否された場合は権限を変更したら対処できる。

下のターミナル画面、grub2-multiの説明が表示されている。
ここから、上のターミナル画面に、ブートローダーのインストールコマンドをコピペする。
前述したが、コピペはマウスの中央クリックで行う。

コピペしたコマンドはこれ。
sudo grub-install --target=x86_64-efi --boot-directory=/mnt/sdc1/EFI/BOOT --efi-directory=/mnt/sdc1 --removable

コマンドには「--target=x86_64-efi」と記述されている。
これは「UEFI」に対応するブートローダーをインストールする設定だ。
今回は、Legacy BIOSに対応しない、UEFIでしか動かない新しいPCで起動できるTCを作るのが目的なので、対応できるブートローダーをインストールする必要がある。

コマンドの文面には、インストール先が「/mnt/sdc1」と記載、設定されている。
今回、ブートローダーのインストール先はOSインストール先の「sdc1」なので、コマンドの文面を書き換える必要がない。当然、違うのであれば書き換える必要がある。

さて、enterキーでインストール開始する前に、sdc1をマウントする必要がある。

キャプチャ画面左上、マウントツールで「sdc1」をクリックし、緑に。
これでsdc1が「/mnt/sdc1」にマウントされ、インストールが可能になる。
これをしなかったら、インストールできないので注意。

enterキーで、インストール。
警告は表示されるが、「Installation finished. No error reported.」で、問題ない。
これでブートローダーがインストールできた。

しかしまだやることがある。

grub.cfg を設定

grub.cfg を設定しておかないと、ブートしてもうまくいかない。
新規OSインストールした「sdc1」にはgrub.cfgがないので作る。これも「sdb」のgrub.cfgから可能な限りコピペしていく。
一般的にはgrub.cfgはユーザーが弄るものではないようなんだけど、Tiny Coreの場合はユーザーが作る。

下のターミナルは、「sdb」側を表示。lessでgrub.cfgの内容を表示。
less /mnt/sdb/EFI/BOOT/grub/grub.cfg

上のターミナルは、「sdc1」側を表示し、ここでgrub.cfgをviエディタで作る。
vi /mnt/sdc1/EFI/BOOT/grub/grub.cfg

下から上に、コピペできるところはコピペして作る。
（viの使い方はここでは触れない。
と言いながら、書き忘れ。USキーボードなので「:」は「; + shift」で入力する。これで「:wq」が打てる筈。）

しかし実は、後で気付いたのだけど、vfatのフォーマットで作っているので、ふつうにUSBメモリをWindows PCとかにでも刺してファイル作成、編集が出来る。
viを使ってやるよりも、そっちのほうが楽な場合もあるかもしれない。

インストールに使ったTCをシャットダウン、インストールしたUSBメモリスティックから起動

これで一通り、作業終了。
上のキャプチャ画面下、一番左のアイコンをクリックするとPCをシャットダウンできる。

上の写真は新規インストールしたOSから起動したところ。

しかし、本当に出来るようにしたいのは、450 G9によるTC64インストールだ。
起動画面表示の方法は、今後、暇なときに探していきたい。

前説

最新のコンピューターを使うには新しい知識が必要だ。それらはどんどん古くなる。
アップデートしないといけないんだけど、僕の場合はどこかに書いておかないと忘れるので備忘録として書いておく。
今回、オーディオの話はないんだけど、Tiny Coreはうちではオーディオ以外で使うことはあまりなさそうなので、オーディオのエントリーにしておく。

まず今回、HP ProBook 450 G9を入手した。
HPのネットショップで注文。
メモリはデフォルトの8GB DDR4-3200のままだが、CPUを「Intel(R) Core(TM) i7-1255U」に変更。最大4.7GHzで走る。
新品のPC購入、しかも10万円以上なんて、たぶんMacBook Pro (Mid 2010)以来じゃないかな。

450 G9、とりあえずTiny Coreを走らせようとして分かったこと。

ブートはセキュリティがかかっている。
流石、最新型だ。
セキュアブートをOFFにしないとUSBからは起動しない。
OFFにしていたら、元々インストールされているWindows11からは起動できなくなる。ONに戻したら起動可能になる。
ちょっと、ややこしい。
側から見ただけではONなのかOFFなのか分からない。覚えておくか、BIOSの確認が必要だ。

32bit OSは起動しない。
つまり、Tiny Coreのインストール用イメージである「CorePlus」は起動できない。
2019年10月のエントリー（http://blown-lei.net/endive/blosxom.cgi/audio_diary/20191027a.htm）に書いてある手法は、そのままでは使えないことが分かった。

途中、ProBook 430 G5も弄ってみた。

先ず、「TinyCorePure64-14.0」のイメージをUSBメモリに書き込み、PCに刺す。
PC起動、escキー、f10キーからBIOS設定画面に移行。
Advanced画面を開く。
Secure Boot Configurationから、Configure Legacy Support and Secure Boot を「Legacy Support Enable and Secure Boot Disable」に設定。
Boot Optionから、起動優先順位でUSBを上げる。

Main画面を開き「Save Changes and Exit」を選択。「Yes」をクリック。
PCが再起動。
grub2の起動画面が表示される。
この時点で「tc」が選択されている。enterキー。
Tiny Core 起動。
こんな感じ。
このようにBIOSを設定したら、起動できる。

f9キーからのBoot Menuではどうかというと、USBからの起動で「UEFI」と「Legacy」を選択できる。
UEFI-xxxx（USBスティック名）からだと、f9を推さなかった時と同じ流れで起動。
Legacy-xxxx（USBスティック名）を選択したら、grubの起動選択画面が表示される。enterで起動。UEFIで起動したときと表示のされ方が違う。

こんな感じで、TinyCorePure64は起動するんだけど、「CorePure64-14.0」は起動できない。
違いは「EFI」ディレクトリの有無。
このディレクトリの奥にはefiboot.imgやgrub.cfgがある。CorePure64には、これがない。
どうやら、新しい機械で起動するには、EFIに対応している必要があるようだ。

こうして起動した「TinyCorePure64-14.0」だけど、「読み出し専用」でブートされるので実質的には使えない。ソフトのインストールや設定が出来ない。
理由は分からないのだけど、これらのイメージは元々CD-R用らしく、使えるようにするには「インストール」する作業が必要なのだろう。

インストール用イメージである「CorePlus」はどうか。
電源ボタンを押すだけでは起動できない。
BIOSから起動する必要がある。
f9キーを押してBoot Menuを表示。
UEFIからは起動しない。「TinyCorePure64-14.0」とは挙動が違う。
Legacyを選択すると、TinyCorePure64と同じ流れで起動できる。違うのは、どのようなOS、window managerを使うかとか、CLI（最近はCUIって言わないのかな）で起動するか、などを選択して起動させることが出来ることだ。

ProBook 450 G3ではどうか。
これは以前から普段使い用になっている古めのノートPC。

TinyCorePure64、CorePlusは起動できる。 BIOSからのBoot Menu。
UEFI-xxxx（USBスティック名）を選ぶと起動しない。
Legacy-xxxx（USBスティック名）を選ぶと起動できる。OS起動の選択画面表示、選択、enterで起動。 CorePure64は、起動しない。

さて、新型のProBook 450 G9ではどうか。「TinyCorePure64-14.0」の起動を試みる。

PC起動、escキー、f10キーからBIOS設定画面に移行。
Advanced画面を開く。Boot Optionから、起動優先順位でUSBを上げる。
Secure Bootの設定はここにはない。
Security画面を開く。
ここにSecure Boot Configurationがある。クリックで設定画面に移行。「Secure boot」のチェックを外す。
Main画面、「Save Changes and Exit」。
再起動。
f9キーで起動を選択。
legacy UEFIという選択肢は、ない。
UEFIから起動したら、grub起動画面が表示される。430 G5のときと同じような画面だ。
enterキー。
画面が真っ暗なままになる。
家庭内LANを確認したらIPアドレスは振られていてpingは通る。だけどこれでは手も足も出ない。ブラックボックスみたいなものでOSが起動しているのかどうかも分からない。

（5月9日追記。真っ黒な画面のまま「sudo poweroff」を打ったらPCがシャットダウンした。OSは動いている。）

他に手は無いか。
Security画面から、TPM Embedded Securityの設定画面に。
TPM Deviceを「hidden」に。これで起動してみたら、「Tpm Ppi」という画面が表示される。
TPMが切れるけどいいか？AcceptならF1だと。F1キーを押す。
再起動。
grub起動画面表示、enterキー、画面真っ暗。同じである。
関係ないのなら、危なっかしいのでTPMの設定は戻しておく。

他にも、grub起動画面から選択項目を変えてみたり、grubコンソールからの起動なども試みたが、同じ。
CorePlus、CorePure64は起動しない。f9から選択しても結局蹴られる。

試みにFedoraのインストール用イメージをUSBメモリに書き込んで起動を試みたところ、Secure boot有効でも起動する。流石、Fedora。
ままよ、なにはともあれ、起動できるTiny Coreをインストールできるか、やってみよう、、、

やってみたらなんとかなった。
前説、ここまで。

最新のTCを、最新のPCで動かす

まず、うちのオーディオシステムに使っているTiny CoreをOSインストーラーにする。
うちのPPAPシステムは、Tiny Core Pure64-11.1で作られている。
それらはimgファイルにバックアップしてあって、USBメモリに書き込めば利用できる。これに「tc-install.tcz」をインストールしたら、OSインストーラーとして使える。

インストールに使うハードはUEFI、Legacy、両方使える環境が必要。
ProBook 430 G5を選択。

mpdサーバーのimgファイルをUSBメモリに書き込んで、ProBook 430 G5で起動。
BIOSからLegacyを選択。
sshでLAN経由でログインし操作する。
tceコマンドで「tc-install.tcz」をインストール。

もう1本、USBメモリを用意してFATでフォーマット。なぜFATかというと、grub2をインストールするから。
これを430 G5に刺して、fdisk -lでデバイスを確認。
コマンド「sudo tc-install.sh」を打ち、このUSBメモリにTCをインストールする。ネットインストールを選択したら、最新のTiny Core Pure64-14をインストールできる。
以下、経過。

tc@box:~$ sudo tc-install.sh
>

Core Installation.
Install from [R]unning OS, from booted [C]drom, from [I]so file, or from [N]et. (r/c/i/n): n
>
The latest version is 14.0
Enter architecture (32)bit, (64)bit or (q)uit: 64
>

Select install type for /tmp/net_source/corepure64.gz

Frugal
* Use for frugal hard drive installations.
Note: You will be prompted for disk/partion and formatting options.

HDD
* Use for pendrives. Your BIOS must support USB-HDD booting.
* A single FAT partition will be made.
Note: Requires dosfstools extension.
Warning: This is a whole drive installation!

Zip
* Use for pendrives. Drive will be formatted into two FAT partitions.
* One small one for USB_ZIP boot compatibility, and used to hold Tiny Core.
* The remaining partition will be used for backup & extensions.
Note: Requires dosfstools and perl extensions.
Warning: This is a whole drive installation!

Select Install type [F]rugal, [H]DD, [Z]ip. (f/h/z): h
>

Select disk for corepure64
	 1. sda
	 2. sdb	On a removable device.
	 3. sdc	On a removable device.
Enter selection ( 1 - 3 ) or (q)uit: 3
>
Install Extensions from this TCE/CDE Directory:
>

Select Formatting Option for sdc1
	 1. ext2
	 2. ext3
	 3. ext4
	 4. vfat
Enter selection ( 1 - 4 ) or (q)uit: 4
>

Enter space separated boot options: 
Example: vga=normal syslog showapps waitusb=5 

vga=normal syslog showapps waitusb=5 
>

Last chance to exit before destroying all data on sdc1
Continue (y/..)? y
>

Writing zero's to beginning of /dev/sdc
Partitioning /dev/sdc
Formatting /dev/sdc1
mkfs.fat 3.0.26 (2014-03-07)
1+0 records in
1+0 records out
440 bytes (440B) copied, 0.005070 seconds, 84.8KB/s
UUID="E84A-CD33"
Setting up corepure64 image on /mnt/sdc1
Applying syslinux.
Installation has completed
Press Enter key to continue.
tc@box:~$ 

さて、最新の64-14をインストールしたUSBメモリが出来たら、ここから起動。
まだUEFIからは起動できない。
Legacyを選んで起動する。
パスワードを設定。 tceからopensshをインストール、設定、起動。 filetool.sh -bで保存。

LAN経由でログインし操作できるようにするのは、本体のキーボードが日本語キーボードとして使えないので不便だからだ。たぶんUSキーボードの設定になっている。「*」を打つのに「shiftと8」、「_」を打つのに「shiftと-」を打たないといけない。
ssh経由で操作したら、使い慣れた日本語キーボードを使うことが出来る。

これにtceで「tc-install.tcz」をインストール（後々、インストーラーとしても使えるようにするため）。
更に「grub2-multi.tcz」をインストール。grub-2.06がインストールされる（因みに64-11だったらリポジトリが異なるのでgrub-2.04だ）。

これだけでは、grub2は機能しない。
ブートローダーインストールのコマンドを打つ。
下記コマンドは、tceで表示されるgrub2-multi.tczの説明の中に表示された記述例に少し手を入れたもの。

tc@box:~$ sudo grub-install --target=x86_64-efi --boot-directory=/mnt/sdb1/EFI/BOOT --efi-directory=/mnt/sdb1 --removable

Installing for x86_64-efi platform.
grub-install: warning: cannot open directory `/usr/local/share/locale': No such file or directory.
Installation finished. No error reported.
tc@box:~$ 

警告出て大丈夫かと思ったが、警告だけでNo errorだからいいらしい。
再起動、UEFIから起動したら、grub2操作画面が表示された。grub2が表示されるということは、前進じゃん？
しかしbootを打っても起動しない。
何かエラーの表示の後で「booting in blind mode」と表示されて文鎮化する。

一般的には「grub.cfg」ファイルは、ユーザーがみだりに編集してはいけないということになっている。
しかしTiny Core Linuxは違う。フォーラムに書き込まれた内容によると、どうやらユーザーが編集して作ることになっているようだ。流石Tiny Core。

grub.cfgがないので、作る。
まずは、TinyCorePure64から流用し、あちこちネット上の情報を集め書き換え、下記の通り。
置き場は「EFI/BOOT/grub」でいいのだろう、と。 Legacy BIOSから起動して書き込む。「filetool.sh -b」を打たなくても保存される。

vi /mnt/sdb1/EFI/BOOT/grub/grub.cfg

# Load Graphical modules
insmod efi_gop

set gfxmode=auto
set gfxpayload=keep
set gfxterm_font=unicode
terminal_output gfxterm

linux /boot/vmlinuz64 loglevel=3 vga=791
initrd /boot/corepure64.gz

これで、UEFIから起動したgrub2操作画面から「boot」を打つとOSが起動するようになった。
insmod の設定がないと、blind mode になるらしい。

ところが、Legacyで起動し動かしていた間にインストールしたopensshが起動していない。パスワードも失くしているようだ。
どうも、UEFIから起動するかLegacy BIOSから起動するかで、挙動が変わるらしい。
/opt/.filetool.lstも見当たらない。どこに行ったのか。というか、何で無くなってるのだろう。

仕方ない。
UEFIから起動したところから、環境を１から作り直してみる。どうなるんだろう、、、
残念。
何故か解らないが、構築した環境を保存できない。
これでは使えない。どうなってるんだろうかな、、、

ここからフォーラム等々調べて、grub.cfgの記載は下記の通りになった。

loadfont unicode

insmod all_video

terminal_output gfxterm

linux /boot/vmlinuz64 loglevel=3 waitusb=5 vga=791
initrd /boot/corepure64.gz

boot

waitusb=5 が無かったら、OS起動時にUSBメモリから読み込まないものが出るらしい。あるべきものが無いままにOS起動するので、パスワードを紛失したりtceでインストールが出来なくなったりするらしい。
記載追加することで、Legacyで起動したときと同じように問題なく動くようになった。

最下行に「boot」を追加。
これで、grub2操作画面にならずにOSが起動するようになった。
sshからrebootを打てば再起動してそのままsshで再ログインできる。棚の下に押し込んだままで再起動をかけることが出来るということだ。利便性は大きく向上する。

ProBook 450 G9でも動くかな、、、動きました！ミッションクリア！

しかし今回、なんとかなったけど、UEFIから起動するしかない、最新の機械しかない環境で、TCを動かそうとしたらどうしたらいいのだろうか。何か方法はあるんだと思うけど、未確認。

今回は、ちょこっと。

リッピングは相当の配慮をしないといけないという意見もある。
うちではけっこう、ざっくばらんだ。
しかし、こだわってる部分もあるので、このたび書いておく。

うちでは、リッピングしたファイルはNASに保存している。
こだわっているのは、リップしたファイルをどういう行程でNASに保存するか、だ。
つまり、リッピングするハード、ソフトには殆どこだわらない。

ソフトは、使い慣れているのでWindows / EACを使っている。
EACの使い方に付いては、１台のノートPCにUSB-DVDドライブを２つつないで、EACを２つ起動していっぺんに2枚のCDをリップしたりしているので、お世辞にも丁寧な扱いとは言えない。
AccurateRipがEACにはあるので正確性はある程度担保されるが、比較データなしとか他のデータと合わないと表示されることもある。そういうときは、エラーなしなら良しとしている。割り切ったもんである。

こだわり処はNASに保存する行程だ。

1. リッピングしたファイルは最初に、PCのハードディスクに保存される。
2. これをUSBメモリスティックにコピーする。
3. USBメモリスティックを、普段使用のノートPC（OSはLinux Fedora、家庭内LANにつながっている）に刺しなおす。
   このノートPCには予め、NASの音楽ファイル用共有ディレクトリがLAN経由でマウントされている。
4. USBメモリスティックから、NASの音楽ファイル用共有ディレクトリに、音源をコピーする。
   コピーには「cp」を使用する。
   cpとは端末ソフト上で使うコマンド。つまりファイルブラウザは使わないということだ。

こんな感じ。

僕の経験では、というか印象では、USBメモリを使わずハードディスクから直接にNASにコピーしたり、cpを使わずファイルブラウザ上でドラッグドロップしてコピーしたりするのは、音が悪くなる。所謂、デジタルくさい音と昔に言われたような、くぐもったような透明度の低い切れが悪い音、要するにジッターが多いんだろうな、という音になる、、、ような気がする。
気がするというのは、本気で試聴して比べたことがないからだ。
経験的に、こうしたらこうなったような気がするな、という印象である。

そういうわけで、ネットからダウンロードした音源なども同様で、いったんUSBメモリにコピーして、そこから「cp」でNASに保存するという行程を採っている。
ちゃんと確認してないけど、そういう気がするのでその行程は外さない。保守的である。というか、あつものにこりて、か。

以上、まじないのような話だ。

今回のエントリーは前回エントリーの続きだ。
（http://blown-lei.net/endive/blosxom.cgi/audio_diary/20230214a.htm）

Deezer hifiのMQAを、Daphile経由でpiCorePlayerに送って再生しようとした顛末を書いている。
有線LANで音が途切れて、WiFiでつないで改善したのは前回エントリーに書いたとおり。
問題は、なんで有線LAN経由だったら途切れるのかということだ。

有線LAN　Deezer, 2LのMQA（352.8kHz）	とぎれる
有線LAN　Deezer, Fairytales MQA（176.4kHz）	とぎれない
有線LAN　NAS音源のMQA（352.8kHz）	とぎれない
WiFi　Deezer, 2LのMQA（352.8kHz）	とぎれない

Deezer MQA音源の352.8kHzで音切れし、176.4kHzではしない。
これはどういうことなのか、最初はM500が行うエンコードの負担が352.8kHzと176.4kHzで違うのかと思った。だから、その上流にあるSqueezeliteの設定を変えることで、多少でも負担を減らせないかと考えた。
しかしNAS音源のMQA 352.8kHzでは音切れしないことが判明。
Squeezeliteの設定は関係ないだろうと判断して、そこを弄るのは止めた。

Deezer音源とNAS音源、ともにMQA 352.8kHzであり、flac 44.1kHz/16bitの同一のフォーマットとして伝送処理される筈と思いきや、音切れが起きるかどうか差異が生じるのはおかしい。
信号処理経路のどこかで、両者に差異が生じている。
どこかで、って、Daphileサーバーより下流には差異がない。上流のデータ信号の差異が、下流に影響しているということか。

Daphileサーバーを変えたらどうか。
6730bは実はテスト用で運用しているサブマシンで、メインのDaphileサーバーはhp Elitebook 2570pが担当している。6730bよりもずっと高性能だ。こっちを使ったら、ちゃんと鳴る？
やってみた。残念でした。同じである。
ということは、NASかストリーミングか、それこそが問題ということになるのか。

どうにかして問題なく再生出来ないか。
他に弄れるところは？、ということで、有線LANからWiFiに変えたら、音切れがおさまった。

これもまた、理由がよく分からない。
Raspberry Pi上の信号伝達経路を変えたら、Deezer MQA 352.8kHzの音が途切れなくなった。WiFiのほうが、Raspberry Pi、piCorePlayerにとって、信号データの処理がやりやすいのだろうと想像できる。
しかし、ボードPCのUSBポートからUSB DACにデータを送るのに、どれほどの大きな負担の差異が生じるというのだろう。
というか、Deezer MQA 352.8kHzは、有線LANだったらラズパイが処理に困るようなデータの伝わり方をしている、ということになるのだろうか。

しかし、ポイントは絞られた。
MQA 352.8kHzが、ストリーミングで、Raspberry Piに有線LANでデータが送られUSB出力される。この３つの条件が揃ったら音切れが起きる。

いくつかの仮説が導かれる。

まず、うちでのストリーミング信号の伝送は、NAS音源データの信号を伝送するよりも、システムの負担になっているらしい、ということ。
これは思い当たることがある。
というのは、今回とは関係なく、MQAではない楽曲で、NAS音源とストリーミング音源を比べたら、わずかだがNASの方が音が良い。
音が違うのは音源のマスターが違うんじゃないかという疑念もあろうけど、僕が聞くような音源は、そうそうお金をかけてリマスターとかされるような音源は少ない。ほとんどがCD化された時点と同じマスターだと思うので、同じデジタルデータで比較できていると言って良いと思うのだ。
話を戻す。
NAS音源の方が音が良いということは、音楽デジタルデータとして、NAS音源の方が上等でシステムにとって扱いやすいということだと思う。
つまりジッターが少ないのだ。
以前、海外のサイトでジッターの解説が書いてあるのを読んだけど、そこにはジッターが多いと音が途切れると書いてあった。僕は、そんな状況が今時あるのかというようなことを書いた気がするけど、どうも今回は当てはまるのかもしれない。

しかし、そもそもMQAというのは、PCMだと原理的に逃れられないジッターの影響を極力排除しようというフォーマットではないかと思うんだけど、そういうフォーマットであるせいか、音がブチブチと切れるような状態であっても、途切れていないときに出てくる音自体はきれいな気がする。なんとかつなげて聴けるようにしたいと思わせる音がする。

次に、Raspberry Pi 3B+のデータ伝送について。
有線LANからWiFi伝送に変更したら音切れがなくなったということは、有線LANで入力しUSBから出力すると音楽信号が劣化する、つまりジッターが増加すると言っていいのではないか。
これは、異論を挟む余地はほとんどないと思う。
たぶんハードの特性によるものだ。USBと有線LANを１つのチップで処理していると思うので、安定した信号送信が出来ないのだと思う。音楽以外で使う分には問題ないのかもしれないが、音楽データだとジッターが大問題になるのだろう。

以上を踏まえて。

ジッターが多い状況だったら、MQA 352.8kHzと、MQA 176.4kHzとで、伝送結果（音が途切れるかどうか）に違いが生まれる。
MQAは折りたたまれたファイルを展開する行程がある。
たぶん展開後のデータ量が多い方、ファイルが大きくなる方が、フルデコードするDACにとって負担が大きくなる。そしてジッターが多いMQA音楽データの処理は、M500にとって、より厄介な仕事になるのだろう。
そうした違いが、再生音が音切れするかどうかに関わってくるのだと思う。176.4kHzはなんとかなったけど、352.8kHzは無理だったのかな。

デジタルデータ処理というのは、一部で問題が生じたら、他にも問題が飛び火するということがあるのかもしれないと思っている。
一部で生じているジッターが、他の場所のジッターの原因になるというようなことだ。
よく分からないから、いい加減な考えだけど。

以上、想像に過ぎないけど考えてみた。音はいい感じで鳴っている。

趣味のオーディオはBGMで聴くだけになっていたけど、Deezerを日々使ううち、昨年12月に2Lレーベルの音源にMQAがあることに気付いた。
どういう状況で気付いたのかは忘れたけど、、いや、思い出した。何の気なしにDeezerで「MQA」を検索したら2LのMQAサンプラーがヒットしたのだ。
調べたらDeezerはずいぶん前にMQA対応してるのだ。
下記、5年前のネット記事のurl。

https://www.phileweb.com/news/audio/201709/06/19032.html
2017/09/06
音楽ストリーミングサービス“Deezer”がMQA音源の配信を開始　PHILEWEB

そして最近になって、どうやら2Lの音源は多くが（全部が？）MQA、352.8kHzらしいということに気付いた。
今回はこの件についてアップしておこうということ。
下記に関連のurlを記載。

2L - the Nordic Sound All releases - 2L Music Store	https://www.2l.no/ https://shop.2l.no/collections/all
Deezer	https://www.deezer.com/
Daphile	https://daphile.com/
piCorePlayer	https://www.picoreplayer.org/

使用機器の構成は下記のとおり。

Daphile（logitech media server）	Compaq 6730b
piCorePlayer（Squeezelite）	Raspberry Pi 3b+
USB DAC	S.M.S.L M500

6730bは古いノートPCだが、使い慣れていたのであちこちで使っていた。
このスペックでもDaphileは問題なく動く。ストリーミングが聴けてDeezer以外にSpotify、Qobuz、Tidal、Youtubeなど対応しているがAmazon、Appleには対応していない。
DaphileではLMS（logitech media server）が動いている。
Daphileサーバー自体をプレーヤーにすることも出来るが、うちではラズパイのpiCorePlayerをプレーヤーにして、家庭内LAN経由でデータを送信している。
MQAを鳴らすためには、ウェブブラウザでアクセスして、「Settings」、「Advanced Media Server Settings」の画面から、「player」のタグ選択、「Basic Settings」ボタンから「audio」項目を選択して、プレーヤーのボリュームを100%に固定する必要がある。固定していないとMQAがただのPCMになってしまう。
文章にするとわけが分からないけど、実際に触りながらなら分かると思う。

piCorePlayerは、LMSから受信したデータを「Squeezelite」で受けて、USB DACに出力する。
Squeezeliteというのは、Squeezeboxのエミュレーターということだけど、要はmpdみたいなもんじゃないかと思う。
ウェブブラウザからアクセスして、あれこれと設定ができる。現状の設定は後述。

S.M.S.L M500は数万円の中国製DACだが768kHzに対応、MQAをフルデコードする。久しぶりに使っているけど、音も良いように思う。
しかしファームの当て方がはっきりしなかったり、使うのに多少の覚悟がいるかも。
僕が買ったのは数年前で、今はmk2、mk3まで製品が出ているらしい。

Squeezeliteの設定。
備忘録でもあるので、説明なく書き変えるかもしれない。

Audio output device settings	USB Audio（これは必須。設定しないと音が出ない）
Output setting	hw:CARD=AUDIO,DEV=0
ALSA setting <b>:<p>:<f>:<m>:<d>	<8192>:<128>:<f>:<0>:<d>
Buffer size settings	4096:8192
Priority setting	45

他に「Name of your player」と「LMS IP」を設定してある。LMS IPはDaphileのIPだ。

Squeezeliteのマニュアルがネット上にあるので、引用しておく。

squeezelite - Man Page
https://www.mankier.com/1/squeezelite

-a <params>
Specify parameters used when opening an audio output device.

For ALSA, the format <b>:<p>:<f>:<m>:<d> is used where <b> is the buffer time in milliseconds (values less than 500) or size in bytes (default 40ms); <p> is the period count (values less than 50) or size in bytes (default 4 periods); <f> is the sample format (possible values: 16, 24, 24_3 or 32); <m> is whether to use mmap (possible values: 0 or 1). <d> open ALSA output device twice. (possible values: 0 or 1).
For Linux PortAudio, the value <l> is simply the target latency in milliseconds.
For MacOS, <l>:<r> <l> is target latency in milliseconds. <r> open device in Pro Mode or Play Nice (respective values: 0 or 1).
For Windows, <l>:<r> <l> is target latency in milliseconds. <e> use exclusive mode for WASAPI (possible values: 0 or 1).
When the output is sent to standard output, the value can be 16, 24 or 32, which denotes the sample size in bits. Little Endian only.

-b <stream>:<output>
Specify internal stream and output buffer sizes in kilobytes. Default is 2048:3446.

問題は、音が途切れることがままあること。
設定を詰め切れていないせいなのか、ハードの問題なのか、通信環境によるものやら、はっきりしない。せっかく音は良いのだから、もったいない。

そういうわけで、2LのMQAを聴いているのだけど、少ないながら2L以外でもMQAで配信されている音源があるようだ。
例えば、これとか176.4kHzのMQAだ。
Fairytales - Steve Dobrogosz, Radka Toneff
https://www.deezer.com/ja/album/79443672
Radka Toneffはノルウェーの女性歌手とのこと。どこかで2Lと関わりがあるのかな、などと思っていたら、1982年に亡くなっている。これは名盤なのでお薦め。

ところで、この音源だと音が途切れない。ということは、352.8kHzのMQAはM500の処理能力を越えている、ということがあり得るのか。
ところが、うちのNASに置いてある352.8kHzのMQA（MQA-CDからリッピングしたもの）を再生する分には途切れない。ということはストリーミング環境が良くないのか。聴いてる人が多いのかな。
これは様子を見ながら考えていく。

もう一つの問題は、音源の曲名などに記載がなければMQAなのかどうか、分からないこと。
うちだとM500で鳴らしてみて初めて分かる。
これはDeezerのほうで、表記なりをどうにかすべきだと思うんだけど、たぶん気にしてないのだろう。まあいっかあ、である。

あけましておめでとうございます。
いろいろありますが皆様のご健康、ご健勝をお祈りし、今年がより良い年でありますように願っております。
更新は滞っていますが、無理ない範囲で運用してまいりますので何卒よろしくお願いいたします。

そんな感じで、新年の挨拶をこのサイト上でしたことが、今まであんまりない。
昔は書いたこともあったが、なんだかいつの間にか、書かなくなった。ツイッターでも明けおめとか、あんまり書かない。
しかし、なんとなく今年は挨拶ぐらいは書いておくことにした。
そんな感じなので内容はない。

ここ数年、世の中コロナで大変だけど、昨年は輪をかけて大変だった。世の中があれやこれやとありすぎて、気持ちが落ち着かないというのも困った。
日本国内も世界情勢も、どうなるのかまったく先が見えない。そんな中で、コロナ対策は毎日が気が抜けない。昨年の秋以降、僕の職場ではコロナクラスターを生じていないということが殆ど無くなった。あっちで収まったと思ったらこっちで発生するというのを繰り返して、コロナ対策担当の職員はそっちにかかりっきりだ。コロナ対策班っていっても、元々それだけやってる職員じゃなくて、やるべき日常業務、役職は別にあるのに選出されてやってるので、開いた穴は他の慣れない職員が肩代わりしているのだ。そんな中で、家族が発症し濃厚接触者になるとかで仕事を休む者もいる。そのような状況が続いていて、みんなの負担が増している。
それでも、まあ、やるしかないということだ。僕などは三が日休めるんだから感謝である。

そんなこんななんだけど、気がついたんだけど、僕がサイト運用し始めて今年の2月で20年になる。
20年といえば、昔だったら成人式だ。
愚痴みたいなことを書いたりするけど、よくまあ、飽きずに続いているものである。
最初はコピーコントロールCD反対のサイトを作ろうと思いたち、わけがわからないので契約しているプロバイダのサービスを借りたのだった。それ以降、契約継続しながら今に至っている。
昨今はCCCDどころか、CD自体が少なくなった。時代は変わる。音楽の有り様を憂うとか、そんな呑気なことは言っていられない時代になりそうだ。
そうはいっても、継続は力なりといわれる。ぼちぼち続けていくつもり。

みなさま、風邪など召されぬように。

すっかりブログ更新が滞っている。
世の中はほんとうに大変だ。
3年前から続くコロナ。今年2月からわけわからん戦争が始まった。
職業柄もあり生活防衛もありコロナの情報は追わなくてはならない。ウクライナの戦争も世界の向かう方向を知らないわけにはいかないので追いかけることになる。
それでもまだ、6月までは余裕があった。

7月、朝鮮半島に拠点を持つ世界平和統一家庭連合（元統一教会。莫大な献金を日本の信者から強制的と言っていい手法で集め、社会問題化している。その金は北朝鮮に流れSLBM開発の一助になったとか、、、）が、日本の政治、特に自民党に何かしらの影響を与えていたということが白日の下に晒された。

何かしらの影響って、ひとことで済ますには規模が大きすぎる。
国政だけではなく地方行政や草の根の活動まで、あちこちに知らない間に浸透され、教育やLGBTなどの方向性に対して人々が気付かないうちに影響を与え、諸外国の右傾化にも日本から巻き上げた金を以って影響を与えていることが、この3ヶ月で広く知られることになった。
これは、全日本国民にとって課題であり、黒歴史且つ将来への禍根そのものであって、知らないでは済まされない。何が起きているかを追いかけないわけにいかない。

そんなわけで、ブログ更新する暇はなくなった。

趣味のオーディオは、BGMで音楽を鳴らす以外はしていない。
手がかかることは出来なくなった。後回しである。
音源のアップサンプリングをどうしたらいいのかというのは大きな課題なのだが、ある程度落ち着くまでは取り掛かれそうにない。なにしろ、試聴に使う音源の選定すら出来ていないのだ。

以上、近況報告まで。

アップ5分後に追記。
うちの職場では現在4回目のクラスタ発生で、ちょっとバタバタしている。
コロナは早く終わっていただきたいのだけど、あと数年以上続くという予測もある。幸い、オミクロンは重症化は少ない。気を付けながらウィズコロナだ。

前回、libsamplerateの「Best」の設定で音を出すことが出来たというエントリーをアップした。
その後で、ふと我に返る。
192kHzって、ふつーにハイレゾだよなあ、、、

うちのシステムは、CDクラスの音源を768kHzという、いうなればスーパーハイレゾに変換して鳴らすというのが目玉である。
今迄、そうすることでCD音源の音をより良い音で聴くことが出来ると考えていた。CD音源そのままの44.1/16から本来の音を引き出すのは結構大変だという認識で、アップサンプリングする方が引き出し易いだろうという考えでやってきている。
しかし、普通のハイレゾレベルへのアップサンプリングなら、普通にハイレゾ購入してそのまま鳴らすほうが、たぶん良いのではないか。

まあ、CD音源しかないんだよという音源もあるし、Deezer HiFiにハイレゾレベルの配信を期待するわけにもいかないので、意味はあるっちゃあるんだけど。
そんなことを考えながら、Best Sinc Interpolator:192kHz で聴いている。

情報量の比較は出来ていない。
しかし微弱な音とか、倍音成分が聴こえ方にデリケートに影響する音源は、明らかに良いような気がする。
アタックの立ち上がりとか余韻が綺麗。
Medium:768kHzよりも、繊細かつ芯が通った音色という印象。
比べたら、Best:192kHzのほうが、しなやかで柔らかく精密なのだ。

前回のエントリーをアップしたときと、評価がずいぶん変わってしまった（あのときは、短時間の印象だけだったから、、、評価は軽々しくするものではないな、、、）。
しかし、これは、まいったな、、、

libsamplerateで700kHz台にアップするより、普通にハイレゾ鳴らす方が良いということになる。
以前、300kHz台のハイレゾと、CDと同クラスの音源をアップサンプリングしたのとを比較したことがある。当時は、殆ど差がないと判断した。僅差でブラインドでは全く分からないと感じた。
http://blown-lei.net/endive/blosxom.cgi/audio_diary/20170625a.htm
libsamplerateの設定も「Fastest」、それでも充分な性能と判断したのだ。
でも、5年も前のことになるのね、、、
当時、44.1＜96＜192＜384だった。その後、384＜768で、今に至る。

それが、今回、ひっくり返った。
Medium:768kHzのアップサンプリングよりも、Best:192kHzのアップサンプリングのほうが良いということなら、それよりも192kHzのハイレゾファイルの方が良いだろう。それが順当だ。
5年前と今と、何が違うんだろう。

5年前のシステムは、Raspberry Pi2、moode audio3.1 + i2sDACでアップサンプリングしていた。NAS音源も使っていたが、高音質を目指すときはRAMメモリ再生という方式。
ハードもソフトも現在とはずいぶん違う。
ということは、当時してみたことを、今のシステムでもう一度やってみるべきかな。
そして、出力形態の違いでどのように音が変わるのか、確認する必要がある。

高域が正確に再生されるかどうかは、音声再生全体に影響する。
libsamplerateの設定で、Best、Medium、Fastestの違いによって、リサンプリングに際しての高域減衰に差が生じる。
以下、引用。

http://www.mega-nerd.com/SRC/api_misc.html#Converters

SRC_SINC_BEST_QUALITY - This is a bandlimited interpolator derived from the mathematical sinc function and this is the highest quality sinc based converter, providing a worst case Signal-to-Noise Ratio (SNR) of 97 decibels (dB) at a bandwidth of 97%.
All three SRC_SINC_* converters are based on the techniques of Julius O. Smith although this code was developed independantly.

SRC_SINC_MEDIUM_QUALITY - This is another bandlimited interpolator much like the previous one.
It has an SNR of 97dB and a bandwidth of 90%.
The speed of the conversion is much faster than the previous one.

SRC_SINC_FASTEST - This is the fastest bandlimited interpolator and has an SNR of 97dB and a bandwidth of 80%.

Bestの設定はリサンプリングに伴う高域の減衰が小さい（大雑把な言い方だが）。
以前はFastestの設定で使っていて、高域の減衰は大きい。その状況でハイレゾファイルと比較して、再生音に差はほぼ無いと思えた。つまり、そのときは高域の差異に伴う音の違いは、殆ど聴き取れなかったのだ。
恐らく、実際に音が違っているのに聴き取れなかったのではない。両者の再生音の高域に差が無かった可能性の方が高い。

どうして差が生じなかったのか。
ハイレゾファイルの再生が、適切に出来ていなかったのかもしれない。
考えられる原因は、ジッターだ。
再生環境のジッターが影響し、ハイレゾファイル再生の高域が劣化した。
アップサンプリングの方は劣化しないのかというと、既に高域が減衰しているので、受ける影響が少なかったのではないか。
結果的に両者の差が僅差となったのではないか。つまり、再生された音声が劣化していたために区別がつかなくなっていた可能性がある。

そして、再生音が劣化したハイレゾ音源よりも700kHz台にアップサンプリングした音の方が良くなった。
サンプリング周波数が上がっていくのと平行して、ノイズ対策や電源、GNDへの手入れが行われ、PPAPの構成も進化し、恐らくは、ジッターへの耐性も5年前よりも向上した。
そうした変化によって、以前はジッターの影響で劣化していた高域特性が改善してきた。
以前よりも、音源の素性が再生音に反映されるようになっているのではないか。

以上、仮説だ。

専門家は、ジッターはおそらく聴き取れないだろうと言う。
https://www.tonmeister.ca/wordpress/2018/08/30/jitter-part-9-when-do-i-care/
たしかに明確にこの音がジッターだと特定するのは難しい。

しかし、ジッターによる音質劣化はかなりのもので、聴き取れる場合も多いと思う。
例えば、80年代のCDプレーヤーで再生した時は冴えない音しかしなかったCD音源が、今の再生環境ではそれなりの音で鳴ることが珍しくない。ジッターへの対処が30年で進歩しているのだ。あの冴えなさ具合を考えたら、ジッターの影響でハイレゾファイルの再生音が僅かに劣化することなど、十分に有り得ると思う。
プレーヤーが安物だったからだろうって？
確かにその可能性は、否定できないのだが。

主旨は違うけど、サンプリング周波数をあれこれ変えて視聴するという試みを2年前にしている。
http://blown-lei.net/endive/blosxom.cgi/audio_diary/20200524a.htm
CD音源アップサンプリングなしの音質について、仮想アースを使う方が相当良いみたいなことを書いている。
当時は気付かなかったが、たぶん、この時点でも以前とは違っていたのだろう。

あれこれ試聴したとしても、たぶん今更、裏付けは取れない。
でも現在の状況確認は必要だ。

しかしだ、、、これって、体力いるんだよね、、、ゆっくりやるつもりだ。

うちのオーディオの音に、現状、全く不満はない。
しかし不満がないからといって、問題がないわけではない。

明らかな弱点はある。
例えば低音、JBL 4425mk2はバスレフ形式で若干緩い感触があるが35Hz〜20kHz(-6dB)と、体躯の割に低い音域まで出る。8畳の部屋で鳴らしていた時は30Hzが出ていた。しかし部屋が広くなってそこまでは出なくなり、Waltz for Debbyの地下鉄が聞こえなくなった。
部屋の作りのせいで室内音響は左右差があって、だから音像定位は合格点は出せない。
こうした欠点も、僕の要求水準が低いから放置で済んでいる。

要求水準が低いと言ったが、容易に手を出すことができない、というのもある。
現状以上の低音が欲しかったら、もっと大きいスピーカーが必要だし、部屋のレイアウトは変えられない。

うちのサイトがPCオーディオ関係のエントリーばっかりなのは、容易に出来る音質改善策だったからというのが大きいと思う。
経済的にも大きなことにならない。といいながら、PCトランスポートを構成するのにうちではPCが5台動いている。apu2が2台と中古ノートPCが3台、トータルで10万以上はかかっている。それに気付いたら、そんなに安価というわけじゃないのか、とも思ったけど、それでこの音なのだから十分に安いとも思う。

これ以上、することはないか、、、
そういう視点でうちのシステムを見ていて、ふと気付いたのが、エントリーのタイトルにしたようなことだった。
これはmpdのアップサンプリング設定だ。
つまり「libsamplerate」で「PCへの負荷が最高となる設定」だったら、どんな音質を引き出せるのかという、これは考えてみたら、Secret Rabbit Code (a.k.a. libsamplerate) を6年前に使い始めてから、ずっと手を付けないままにしていた宿題なのだ。

今まで手を付けなかったのは理由もある。
というのは「Best Sinc Interpolator」で設定して、mpd + libsamplerateを動かすと、まともに音が出ない。

libsamplerateの設定は、Best、Medium、Fastest、ZOH、Linearの5段階。
これらのうち、音質の優位性が得られる設定はBest、Medium、Fastest の３つである。
参考url
Music Player Daemon documentation » Plugin reference
https://mpd.readthedocs.io/en/stable/plugins.html#libsamplerate
Secret Rabbit Code (aka libsamplerate) - Miscellaneous API Documentation
http://www.mega-nerd.com/SRC/api_misc.html#Converters

Best、Medium、Fastestの設定でmpdを動かすには、負担に耐えられるスペックがPCに要求される。

ZOH、Linearの設定は、かなり低スペックなPCでも動く。
しかしあんまり使う意味はない。
現在のうちの環境では、音質悪化する（以前にアップしたジッターの説明サイトでも、実装が悪いASRCでは往々にしてそういうことが起きると書いてある）。
こうした設定で音質が改善するとしたら、デジタル信号伝送の環境が悪いということがあるので、よくよく見直した方がいい。昔のことだが、うちではNASが壊れかけていたときに、こうした低品質な設定で音が良くなったことがあった。

6年前、うちで使っていたPCトランスポートはRaspberry Pi2だった。
mpdのlibsamplerateのデフォルト設定は「Fastest」で、比較的、負担が少ない設定となっている。それでもRas Pi B+にとっては負担が大きくて無理で、Ras Pi2でようやく可能になった。当時はBestどころかMediumの設定も、PCへの負担が大きくて使えなかったのだ。

それが、アップサンプリングのサンプリング周波数を上げるにはPCトランスポートのスペックを上げざるを得なかった。
Raspberry Piからapu2、ノートPCへとスペックを上げて、768kHzへのアップサンプリングが可能となって、気が付いたら、Mediumの設定が使えるようになっていた。
使えるようになって比較したら、FastestよりMediumのほうが音色が濃厚で厚みがある。以降、うちでの設定は変更になった。Phile webに日記をアップしてレスをもらったのが切っ掛けで気付いたので、ほぼ1年前のことになる。

実は最近、気付いたことがある。
CDをうちのシステム（USB-DVDドライブからmpdに読み込む）で鳴らしていると、特定のCDで音が途切れることがある。Mediumの設定をFastestに変えたら途切れなくなる。
つまり、Mediumの設定でCDを鳴らそうと思ったら、スペックが僅かに足りていないのだ。
mpdサーバーのスペックを上げるに越したことはない。

現在、mpdサーバーを担当しているのは、HP EliteBook 820 G2。
過去の経験からは、最も重要なのはメモリのスピードという認識。
820 G2のメモリは、DDR3L-1600。
メモリクロック:200MHz、バスクロック:800MHz、転送速度:12.800GB/s、データ転送速度:1,600MHz、ということらしい。
参考：
https://ja.wikipedia.org/wiki/DDR3_SDRAM
https://ja.wikipedia.org/wiki/DDR4_SDRAM
見れば全部わかるDDR4メモリ完全ガイド、規格からレイテンシ、本当の速さまで再確認
https://akiba-pc.watch.impress.co.jp/docs/sp/1231939.html

CPUは「less /proc/cpuinfo」で確認した。
Intel(R) Core(TM) i5-5300U CPU @ 2.30GHz、2コアだけどスレッドは4（topから見たらCPUが4個と認識される）。
しかし正直、CPUにどの程度のスペックが必要なのかは、よく分からない。

sshからmpdサーバーにログインしてtopで状況を確認していく。libsamplerateの設定はMedium。
mpdのCPU使用率は、0%から25%を変動する。平均は12～16%ぐらい。
1キーで、CPUのスレッドを表示。
音声信号処理の負担がかかっているスレッドが、数秒で切り替わっているようだ。基本的に演算処理は1つのスレッドが担当し、同時並列で複数のスレッドが演算を分担することはないようだ。一度に動くスレッドが４つのうち１つなので、CPU使用率が最大25%ぐらいまでということかな（つまり、そのスレッドとしては100%使い切っているということだ）。
mpdサーバーは、mpdを動かしてるだけではなく、daphileサーバーやPPAPサーバーとも連携しないといけない。スレッド4つは最低欲しい（2つだとなんだか危なっかしい気がする）。
メモリはというと、使用量はそんなに多くない。8GB積んでいるけど使っているのは500MB程度だ。

libsamplerateの設定を「Best」にしてみる。
音を出すと、音が出るのに10秒近くかかる。数秒間だけ音が出た後、途切れ途切れになってしまう。
topでみたら、mpdのCPU使用率が25%に貼り付いている。つまり、最大限使っている。そして、スレッドが切り替わらない。切り替わるのに数10秒かかる。たぶん演算処理が追いついていないのだ。
メモリの状況は、Mediumのときと変わらない。

しかし、数秒間の音は、悪くはなかった。
ちゃんと鳴らすにはもっと速いPCが必要。

どんな機種にするか、、、
今までのようにノートPCの中古にするか、いっそのことミニPCにするか。
ミニPCのほうが安価だ。しかしミニPCの場合、メモリのスペックがなかなか調べても分かりにくいということがある。DDR4までは分かっても、クロックや速度が分からないままで売られていることが多い。あと、BIOSを触ろうと思ったらモニターとキーボードを用意する必要がある。まあ、すりゃあいいじゃんと言われたらその通りなのだけど、、、面倒だ。そこについてはノートPCのほうが扱いやすい。ましである。

とりあえず扱い易さを優先して、中古ノートPCにした。
機種は、HP ProBook 430 G5。
CPUはCore i5 7200U。定格クロックが2.50GHz、第7世代なのかな。
メモリーは8GB。DDR4 PC4-2400が標準だけど、第7世代CPU以前だと2133で稼働するらしい。どうなんだろこれは。
参考：
インテル® Core™ i5-7200U プロセッサー
https://www.intel.co.jp/content/www/jp/ja/products/sku/95443/intel-core-i57200u-processor-3m-cache-up-to-3-10-ghz/specifications.html

結果。
820 G2より僅かにマシだけど、やはり同様に音が途切れて使えない。
topを打つと、CPUの使用率は4スレッドのCPUで25%。使いきっている。「less /proc/cpuinfo」を打つと「cpu MHz : 3100.001」と表示。Core i5 7200Uは最大クロックで動いているようだが、足りていない。

途中で音が切れるのは、メモリよりもCPUの速度が足りないのかもしれない。3GHzでも遅い。
速いCPUを調べてみたが、ノートPC用だと定格クロックは3GHz台が殆んど。最大クロックだと4GHz台以上に届くのがあるけど、どうなんだろうか、そういうのって。
PassMarkという数値が高いCPUはたくさんあるけど、そういうのはコア数やスレッド数が多い。mpd+libsamplerateは1スレッドを占有し音声信号処理に充てる。つまりスレッド数を増やして性能を上げているCPUは、たぶんあんまり意味がない。1スレッドで、どれだけのパフォーマンスを出せるかが重要な筈。

そんな中で気になったCPUをいくつかメモ。
Intel Core i3-12300、i7-10610U、i3-1115G4、、、まだまだある。最大クロック4GHz台で動くCPUだ。
そして、そういうのが載ってるノートPCは高い。中古も高い。じゃあ、mini PCでどうかとなると機種がない（探すのが下手なのかもしれない）。あっても売り切れてるし、今まで買ってきたのと比べたら高い。

あと、今回の試行で、一点、Tiny Coreのほうに問題が見付かった。
現在運用しているmpdサーバーで動いているシステムは、ProBook 430 G5では起動しない。
EFIというのが入ってないためだ。
仕方ないので、TC64 11.1から移植して何とか起動。しかしf9キーから入ってブートローダーを選択しないといけないし「Wrong EFI」と表示が出る。
TinyCorePure64-13.1そのものからだと、そんな面倒しなくてもUSB起動優先の設定さえしておけば、起動ボタンを押すだけでそのまま起動するので、ブートローダー周りの問題なのだろう。
普通に使えるのを作らないと、再起動が簡単にできないので、システムに組み込みにくい。

ハードルが高い、、、

ここでふと、768kHzだから出来ないんじゃね？と思い至る。
430 G5で、設定を192kHzにしてみたら、比較的スムーズに音が出た、、、、、

topコマンドで状況を確認。
mpdのCPU使用率は、0から25%を変動し、平均はだいたい10%台。メインシステムでMediumの設定で使っているときと同じような挙動だ。そこそこ余裕がある。
スレッドも切り替わる。というか、4つのスレッド全てが0%という瞬間がそこそこあって、スレッドの切り替わりはあるけど、ゆっくりと切り替わる。かなり余裕を持って動いている、、、
これなら安定して使えそうだ。

なんだ、、、Best Sinc Interpolator、できたじゃん！

音は、いい。
ある意味、良いのは当たり前だ。PPAPで直結してるんだから。
Medium:768kHzと比べて、どうなのかというのが問題、、、なんだろうか。

ここまでやってなんだけど、どっちでもいいやん、という気分で、本気の聴き比べは、出来ていない。
ちなみに、384kHzだとぎりぎりで、ノイズが入り、数10秒鳴った後で音が途切れ始めた。もう少しスペックを上げたら384kHzで鳴らせそうだ。
そんなギリギリ状態の384kHzの音よりも、安定している192kHzのほうが良かった。
しばらく鳴らした感じでは、Best:192kHzよりも、Medium:768kHzのほうが良さそうだとは思ったけど、、、ちゃんと比較して、各々の傾向が見えてきたら、意外に面白いことがあるかもしれない、という印象だ。しかし、僕の駄耳でははっきりしたことは分からないかもしれない。
音の表面の感触が違う気がする。
Medium:768kHzのほうが明らかに細かい音が聞こえるんだけど、Best:192kHzのほうが、甘い、気がする。

まあ、今は深く追求はしない。
Bestの尻尾を掴むことができたところで良しとしようと思う。

今回は、興味深いサイトがあったので備忘録に書いておこうという主旨。
サイトのオーナーはB&Oの関係者で、音楽技術分野の研究者とのこと。
https://www.tonmeister.ca/wordpress/about/

個人的には、いい加減な知識のままにしていた部分で、重要な知識だと思うので自分のためにも忘れないように、エントリー3回分で書いておく。
３、２、１の順でアップロードすることで、ブログ上では上から１、２、３と並ぶようにしてみた。そのほうが読みやすいはずだ。
何か必要があったら追記訂正するつもり。追記訂正の断りは入れない。見た目が煩わしいので。

しかし、良く分かっている人には、今更感がある内容だと思う。
というのは、出て来る用語をネット検索したら、10年前から残っている解説記事がぽろぽろ引っかかるのだ。どこかで目にしたなあ、ということがあったりする。
分かってる人には、これらは常識なんだと思う。
しかし僕なんかは系統的な知識になってないので、こういう機会でもないと理解が進まないということだ。あと、目についた記事だけ読んで難しすぎて身に付いてないことが往々にしてあるように思う。勉強不足に加えて、僕には難しすぎるのである。

Jitter – earfluff and eyecandy
http://www.tonmeister.ca/wordpress/category/jitter/

デジタルオーディオ関係でジッターといえば「時間軸方向での信号波形の揺らぎ」とか「信号の時間的なズレや揺らぎ」とか説明される。
そんなひとことで表現されるジッターだが、原因は多種多様と聞いたことぐらいはある。聞いたことはあっても、その内実については詳しくは知らない。
上記サイトでは、そのジッターの分類について専門家側から説明してくれている。
そういうわけで、ちょっと旅しよう。

Jitter: Part 1 – What is jitter?

Jitter: Part 1 – What is jitter?
http://www.tonmeister.ca/wordpress/2018/08/08/jitter-part-1/

ここは初歩的な所から入る。
僕でも読みながら、うんうん、そういう感じだよね、という感じで読めるパートだ。

ひとつだけ、S-PDIFのデジタル信号の仕組みについて、ああ、そういう仕組みなのか、と分かったのは非常に良かった。オーディオ信号にクロックが乗ってるってどういう意味だろう？と昔から思っていたんだけど、説明があった。
簡単にいえば2bitから1bitを抽出するというか、on-onとoff-offが０で、on-offとoff-onが１、そういう信号で伝送したら、そこからクロックが抽出できるという感じ。英語版wikpedia（https://en.wikipedia.org/wiki/S/PDIF）にも書いてあるが、こちらのサイトの方が分かりやすい。

It’s important for me to note that the example I’ve given here about how that jitter might come to be in the first place is just one version of reality. There are lots of types of jitter and lots of root causes of it – some of which I’ll explain in this series of postings.

(translate by Google)
そもそもそのジッターがどのように発生するかについてここで示した例は、現実の1つのバージョンにすぎないことに注意することが重要です。さまざまな種類のジッターとその根本原因があります。そのうちのいくつかについては、この一連の投稿で説明します。

Jitter: Part 2 – Phase and Amplitude Jitter

Jitter: Part 2 – Phase and Amplitude Jitter
http://www.tonmeister.ca/wordpress/2018/08/09/jitter-part-2/

In the previous posting, I talked a little about what jitter and wander are, and one of the many things that can cause it. The short summary of that posting is:
Jitter and wander are the terms given to a varying error in the clock that determines when an audio sample should (or did) occur.

Note the emphasis on the word “varying”. If the clock is consistently late by a fixed amount of time, then you don’t have jitter or wander. The clock has to be speeding up and slowing down.
One of the ways you can categorise jitter is by separating the problem into two dimensions – phase (or time) and amplitude.

(translate by Google)
前回の投稿では、ジッターとワンダーとは何か、そしてそれを引き起こす可能性のある多くのことの1つについて少し話しました。 その投稿の簡単な要約は次のとおりです。
ジッターとワンダーは、オーディオサンプルがいつ発生するか（または発生したか）を決定するクロックのさまざまなエラーに与えられる用語です。

「変化する」という言葉が強調されていることに注意してください。 時計が一定の時間だけ常に遅れている場合は、ジッターやふらつきはありません。 時計は速くなったり遅くなったりする必要があります。
ジッタを分類する方法の1つは、問題を位相（または時間）と振幅の2つの次元に分離することです。

ここで、ちょっと待って、である。
時間と振幅に分けるって、ジッターって時間の問題じゃなかったの？という。

信号の振幅の誤差がデジタル再生に影響するんじゃないのかというのは、僕自身も以前から考えてはいた。
http://blown-lei.net/endive/blosxom.cgi/audio_diary/20200531a.htm
以前のエントリーに書いたのは、DACチップのアナログ信号出力の正確性についての疑いで、それらの誤差も一緒くたにまとめて「ジッター」に括られてるんじゃないのか？という疑問だった。

ここでの話はそういうことではなく、デジタル信号の振幅誤差がデジタル信号のジッターを生むということ。
その内容自体は、納得できる説明だ。
というか、僕にはその知識は無かったが、以前からそうした概念については頭の中に仮説としてあって、しかし実はデジタル技術の世界ではとっくの昔に「振幅ジッター」という概念で説明が成されていたのだと、今回、僕がこのサイトを読んで理解し、得心したということだ。
ここでは「デジタル信号」の解説をしているので、DA変換出力の振幅誤差については関係ない話なので触れられていない、と理解している。

話を戻す。
このエントリーでは、ジッターには「phase jitter（位相ジッター）」と「amplitude jitter（振幅ジッター）」があると書かれている。原因が異なるため、システムの改善を目指すなら、生じているジッターの切り分けをすべき、ということかな。

僕が単純に考えて、
前者には、リクロック含むクロック周り。
後者には、電源とアースの強化とノイズの対策か。
切り分けが困難なら両方に対策するしかない。しかし実際にはもっと複雑な挙動への対策が必要かもしれない。たとえばクロックと言ったって、クロックにも電源があるのだ。キリがないので、どこでカタを付けるかだ。

ちょっとここからうだうだ長くなる。どうでもいい話だ。

僕を困惑させた文面があった。

Wrapping up

If you’re a system developer or if you’re trying to improve your system, you need to know whether you have phase jitter or amplitude jitter in order to start tracking down the root cause of it so that you can fix it. (If your car doesn’t start and you want to fix it, it’s good to find out whether you are out of fuel or if you have a dead battery… These are two different problems…)

However, if you’re just interested in evaluating the performance of a system, one thing you can do is simply to ask “how much jitter do I have?” (If your car doesn’t start, you’re not going to get to work on time… Whether it’s your battery or your fuel is irrelevant.) You measure this, and then you can make a decision about whether you need to worry about it – whether it will have an effect on your audio quality (which is a question that not determined so much by the amount of jitter that you have, but where it is in your system, and how the “downstream” devices can deal with it).

(translate by Google)
まとめ

システム開発者の場合、またはシステムを改善しようとしている場合は、問題の根本原因を突き止めて修正できるように、位相ジッターまたは振幅ジッターのどちらがあるかを知る必要があります。 （車が始動せず、修理したい場合は、燃料がなくなっているのか、バッテリーが切れているのかを確認することをお勧めします…これらは2つの異なる問題です…）

ただし、システムのパフォーマンスを評価するだけの場合は、「どのくらいのジッターがありますか？」と尋ねるだけで済みます。 （車が始動しない場合は、時間どおりに仕事をすることができません…バッテリーか燃料かは関係ありません。）これを測定すると、心配する必要があるかどうかを判断できます。それ–それがあなたのオーディオ品質に影響を与えるかどうか（これはあなたが持っているジッターの量によってそれほど決定されない質問ですが、それがあなたのシステムのどこにあるか、そして「下流」のデバイスがそれをどのように扱うことができるか）。

『システムのパフォーマンスを評価するだけの場合は、「どのくらいのジッターがありますか？」と尋ねるだけで済みます』というのは、大雑把過ぎるのではなかろうか。

電気信号の振幅が正確であるためには、電源やGND電位が安定している必要があると、僕は理解している。
最近は、電源やGNDに気を配るのはデジタルオーディオの「いろはのい」みたいなことになっている。誰が言い出したのか、メーカーや技術者側からなのかユーザーサイドからなのか、よく知らない。
どんな電源がいいとかバッテリーがいいとか電柱がいいとか、ノイズ軽減にはどうしたらいいとか仮想アースがどうとか、いろんな知見や試みがある、その一方でどうして効果があるのか、明確な説明は無かったような、分かるような分からないような、そんな感じではなかったか。

しかし、電気信号の振幅誤差も、時間の誤差とまとめてジッターになるんだよ、と。
今までもジッターといえば実は両方を含んでたんだよ、と。
だったら、デジタル系の電源やアースの強化、安定化を目指す必要があるというのは、ジッター対策と考えたら自明なことだ。いつからそうなった？昔からか。。。

デジタルでの音質の劣化は「時間軸方向での信号波形の揺らぎ」が原因で、それをジッターと読んでいた筈だ。
振幅も問題だということなら、「ジッターだけではなく振幅も問題だ（と分かった）」と表現するべきではないのか。
それか「ジッターは時間軸方向の揺らぎで、振幅の揺らぎはほにゃららと呼ぶのだ」とするか。
いや、結果の実態としては同じだからジッターでくくればいいと、、、いや結果が同じでも切り取り方が違ったら受け取り方も対策も違うでしょうに、、、
しかし考えてみたら、ジッターの定義？が「時間軸方向での信号波形の揺らぎ」ということで、もともと原因が何かは問わないのだ。だったらくくっても問題はないという理屈。

そういうわけで、不勉強な僕の言うことが間違ってるんだと思うが、そういう感じで、納得いかない。
納得がいかないとか言ったって、ずっと昔に御布令が出てるのに、いつの間に出してんだ知らねえんだよべらぼうめぇとか言っても言う方がバカで打ち首である。

以上、どうでもいい話だ。

どうでもいい話で長くなりすぎた。次のエントリーに続く。今回のエントリーは横道に逸れすぎである。