abk1's scratched blog 3

現在のうちの環境では、Daphileでmpdサーバーに送るDeezerの音は、同じCD水準のデータでもNAS音源の音には及ばない。

前回のエントリーで、ストリーミング音源はupmpdcliがボトルネックになっていると考えたら、mpdサーバーへの対策が有効ではないか、銅メッシュをmpdサーバーのノイズ対策に使えば負荷が減るのではないか、と考えた。
ここでふと、mpdの負荷を減らしたいなら、アップサンプリングしなければいいんじゃないか、と思い付いた。

Daphileからmpdに送られるのは44.1kHz/16bitのPCMだ。それを何もせずPPAPで送れば、どう聴こえるだろう。
mpdサーバーの負担は減ると思う。
過去に試したときは、アップサンプリングした方が良かった。
今はどうだろう、ストリーミング、いや、UPnP音源だったら、どうなのか。

もともと、僕がアップサンプリングを使うようになったのは、コンピューターをオーディオに使い始めた頃に、SRC2496という機器を使ってアップコンバートして鳴らしていたことがある。これは音が良くなった。あと、壊れかけたNASの音源は、mpdによる非力なアップサンプリングでも音が良くなった。

こうしたことから、ジッターが多い環境では、アップサンプリングしたほうが音が良いのではないか、という仮説を思い付いた。なんでアップサンプリングで音が良くなるんだろう、というところから考え始めている。
つまり、そうした現実の理由付けとして考え始めた仮説だ。

そのうち、アップサンプリングと一言で言ってもいろんな手法があり、音も違うことが分かった。
手法で音が違うということは、DACに入力されるデータが異なっているということだ。
そして、DACチップ内でアップサンプリングするという知識も得る。

アップサンプリングによる音質改善の根拠は、DACチップ自体でアップサンプリング（オーバーサンプリング）するより、良質なアップサンプリングが出来る高スペックのPC等で代行したほうが良いという説明に、比重が移った。
というか、世の中でそういう説明が見られるようになった。
SRC（libsamplerate）などを使って良質なアップサンプリングを行うと音が良くなるのはなぜなのか、という問いの答えが、DACチップはナイキスト定理通りの理想的なDA変換が出来ないのでオーバーサンプリングして精度を高めるより他なく、DACへのデジタル入力前に、より良質なアップサンプリングを行うことが可能なら、そのほうがDA変換の精度が上がるから、ということに現在はなっている。
というのが僕の理解。

音の情報量自体はCDで充分だが、DA再生で充分な精度を出すには技術的限界があるから、理論だけで固めた理想論では済まない。だから高品質なアルゴリズムでアップサンプリングすることが有効ということだ。
精度が要らないなら、この限りではない。精度が出てなくても良い音はざらにある。精度が出ていさえすれば良いというものでもない。

そういうわけでアップサンプリングの品質は重要だと思うけど、ジッターを如何にして減らすかも同時に重要だ。
以前は、アップサンプリングすることでジッターの影響を少なく出来るのではと考えていたけど、今はそれだけで事足りるとは考えない。
ジッター対策は音色に効いてくる気がする。
というか、映画に例えてみると、サンプリング周波数やビット深度がフィルムの大きさ、つまり情報量に影響し、ジッター対策はピントに効いてくるとでもいうか、出てくる音の鮮度、色彩感、陰影に影響する。
両方を高めるのが、今のデジタルオーディオで高音質を得る近道だと思う。

正攻法は、安定して高精度なクロックだ。
しかしクロックを生かすには、ノイズや電源の対策が必須になる。ノイズや電源の上でクロック素子が動いているからだ。当然、デジタル信号そのものも、それらの上で動いている。デジタルで01だと言っても実体は電圧変動なのだから、ノイズや電源の影響を受けないわけがない。その影響こそがジッターということだ。

話が広がりすぎか。話を戻す。
何が言いたいのかというと、アップサンプリングを止めることで、音質は低下する。
しかしmpdサーバーの負担、仕事量が減るので、ジッターの減少、音質の向上に繋がるのではないか、ということ。

逆も言えることで、アップサンプリングを行えば音質は向上する。
しかしmpdサーバーの負担、仕事量が増えるので、ジッターの増加、音質の低下に繋がる。

では、どうすれば一番良い音になるのか、良好なバランスとなるのはどんな設定なのか、という考え方だ。
実際に聴いてみて、確かめるしか術はない。

さて。
うちでは2台のmpdサーバーが動いていて、1台はメイン使用で384kHzへのアップサンプリング用、もう1台はテスト用兼768kHzへのアップサンプリング用になっている。なんでわざわざ2台なのかというと、そのほうが設定切り替えの手間がないからだ。
PPAP Back-Endで両方の設定に対応するコマンドが動いていて、どちらのFrontからでも直ぐに音を出すことが出来る。
Back-Endでtopを打つとこんな感じ。

Mem: 93208K used, 3936688K free, 18376K shrd, 5560K buff, 34180K cached
CPU:  0.0% usr  0.0% sys  0.0% nic 99.9% idle  0.0% io  0.0% irq  0.0% sirq
Load average: 0.00 0.00 0.00 2/109 1319
  PID  PPID USER 	STAT   VSZ %VSZ CPU %CPU COMMAND
 1318  1290 tc   	R 	4016  0.1   0  0.0 top
 1208  1092 root 	S	15484  0.3   0  0.0 /usr/local/bin/ncat -kl 4400 -e /usr/local/bin/aplay -D hw:0,0 -M --period-size=2048 --buffer-size=16384 -t raw -f S32_LE -r384000 -c2
 1242 	1 tc   	S	15484  0.3   1  0.0 /usr/local/bin/ncat -kl 4444 -e /usr/local/bin/aplay -D hw:0,0 -M --period-size=4096 --buffer-size=32768 -t raw -f S32_LE -r768000 -c2
 1286  1202 root 	S 	5872  0.1   0  0.0 sshd: tc [priv]

まず、テスト用サーバーの設定をいじって、アップサンプリング無しの音を出すことにした。
mpdサーバー（Front）をアップサンプリングしない設定に変更。
Back-Endでは、上記のtop表示だったら「kill 1242」で、テスト用のデータを受信するコマンドを止める。
改めて以下、コマンドを打つ。

/usr/local/bin/ncat -kl 4444 -e "/usr/local/bin/aplay -D plughw:0,0 -M --period-size=64 --buffer-size=512 -t raw -f cd" &

メインサーバーからのデータを受けるコマンドはrootで起動。テスト用サーバーからのはtc（ログインユーザー）で起動している。
コマンドは２つだが、aplay自体は、もともとひとつだ。

音源がCD同等だと、バッファーの数値はずっと小さくなる。音源データが小さいのでコマンドの設定もそれに合わせている。
しかしメイン用の方はもともと、大きい数値がバッファーに振られている。
多分、テスト用からの音源を鳴らしている時も、メイン用のコマンドが同時に動いているから、バッファーの設定がそっちのまま、大きいままなのではないか。
CD相等の音源にとって、それは過剰なバッファーとなる。
結果、操作に対する反応が遅くなる。mpdサーバーの出音を止めても、バッファーに溜まったデータが切れるまで、暫く音が出続けるのだろう。それが20秒前後にもなる。

どうするか。
そもそもの目的、サーバーの負荷を落とすということなら、アップサンプリングの「質」の設定を落とせばいいという考えもある。
テストサーバーのlibsamplerateの設定は「Medium」なので「Fastest」にしたら負荷は下がる。
そしてメインの384kHzに近い値で低めに設定したら、バッファー数値の影響は回避できないだろうか。
ままよ、やってみた。

/usr/local/bin/ncat -kl 4444 -e "/usr/local/bin/aplay -D hw:0,0 -M --period-size=1024 --buffer-size=8192 -t raw -f S32_LE -r192000 -c2" &

これだと反応の遅れは数秒で、使用に耐える。
音色は良い。
768kHzよりも艶っぽい気がする。
しかし情報量は少なくなる。音像間で分離していた空間が、グラデーションで埋まる。まあ、768kHzと192kHzでは、デジタルデータの情報量は4倍の差があるので、仕方がない。768kHzは良くも悪くもモニター的になる。これは、どちらがいいのかという話になりそう。
テスト用といいながら僕が768kHzで鳴らす環境を維持しているのは、これはこれで捨てがたい面があるからだ。

しかし192kHzだと、USB-HDD音源とストリーミング音源の音の差は、かなり縮まったような気がする。
いや、ほんまかいな、と自分でも思うけど、たぶん縮まってるんじゃないかな（でも、こういうときの自分ってあてにならないんだよな、、）。
Fastest、192kHzの設定だけで比較したら、もうストリーミング中心でいいかもと思うかもしれない。

Back-Endで、メイン用の設定のほうを見直すという方法論もある。
大きいバッファーを小さく出来たら、テスト系への影響を小さく出来るのではないか。

そもそもなぜ、「--period-size=2048 --buffer-size=16384」という設定になっているのか、記憶にない。
たぶん、アップサンプリングするmpdサーバーの増大したバッファーの設定に、合わせて増やしただけだと思うのだ。
減らせるかもしれない。
とりあえず、「--period-size=512 --buffer-size=2048」まで減らした。
問題なく音は出ている。あらー、、、

この状態で、テスト系のアップサンプリングをやめて、まともに使えるかどうか、試してみる。
音の出方は、以前よりは良くなった。
しかし、不安定だ。途切れやすい。
mpdサーバーの方を調整。「audio_buffer_size」を増量、"2048"に。多少は安定したが、再生停止に10秒程かかる。
なんでかわからんが、mpdが音源データをどんどん先走って取り込んでいるようなのだ。Daphileなどのインターフェイスで見ると、曲の時間表示が実際よりもどんどん先に進んでいく。
これでは困る。

結局、多少はアップサンプリングしないと安定しないという、よくわからない状態で、今回はけりをつけることにした。
libsamplerateは「Fastest」、負荷軽減優先だ。
サンプリング周波数は、とりあえず192kHz。
テスト系を受けるBack-Endの設定は「--period-size=256 --buffer-size=2048」に、今はしている。
なんだか、あちこちバランス取りながらの設定で、詰めきれないままのことが今までにもよくあったような気がする。

気のせいかもしれないけど、Fastest、192kHzは、昔よりも良い音が出ている気がする。
ノイズ対策などを経て、ジッターが減っている分、改善があるのかもしれない。
USB-HDD音源とストリーミング音源の音の差も、Fastest、192kHzだったら前述したとおり、差異が少ない。なんとなく、バランスがいい音という印象で安心感がある気がする。

もともと、差異が少なければいいというものではない。
ストリーミングの音を底上げするにはどうしたらいいか、というところから始まった話だ。
しかしここに来て、設定による音の違いは無視できないような気がしている。ノイズ対策が落ち着いたら、どのような設定でどのような音になるのか、ゆっくり時間がある時に、確認したいと思うが、設定の要素が多いので、比較すると言っても単純な話ではない。
大仕事になる。あんまり突っ込んだことはしないかもしれない。

最後にちょっと、温度の比較（CPUだと思うんだけど、はっきりしない）。
テスト用サーバーでコマンドを打って確認してみた。

tc@box:~$ cat /sys/class/thermal/thermal_zone0/temp
44000

こんな感じ。
ただ、今回確認してみて、音を出している時の温度は、かなり変動することが分かった。負荷が多いときは上がるのだろう。

データ取得のために下記コマンドを使用。
5分間のデータを取得する。

tc@box:~$ watch -t -n 3 cat /sys/class/thermal/thermal_zone0/temp > temp.txt

数値だけ得られるならよかったんだけど、行頭に余計な文字列が付くのが残念。
このファイルを、普段使いのノートPCに移して、エディタで要らない文字列を削除して、下記のコマンドで数値を合計して、電卓で平均を計算する(小数点以下は四捨五入した)。
せっかくLinux使ってるんだから、もう少しスマートにやれそうだけど、スキルがない。

[ab@fedora1 Documents]$ awk '{sum+=$1}END{print sum}' temp.txt

44000

Fastest、192kHz
47267 (min:47000 max:48000)

Fastest、768kHz
53019 (min:47000 max:58000)

Medium、768kHz
59670 (min:51000 max:65000)

一番上は音を出していないとき、続いて、それぞれの設定で音を出したときの温度だ。
アップサンプリングの設定、負荷の違いで大きく温度が違うのが分かる。
驚いたのは、音を出していないときの温度は、ずっと44000で5分間一定だったこと。そういうものなんだろうか。あと、負荷が少ないと温度の変動も小さい。

メイン用サーバーは、Best、384kHzの設定で固定している。こっちも少し測ってみた。
データは載せないが、テスト用よりも若干温度が高いようだ。

早々に追記だけど、テスト用サーバー下記設定でデータを取ってみた。
アップサンプリングの周波数が低いと、温度の変動が少ないのかな。負荷の大きさとの関連は小さいのか。どうなんだろう。

Best、192kHz
58452 (min:57000 max:62000)

前回のエントリーでは、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

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

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

設定変えたら、ほとんど動いていなかった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は、それらの水準を超えると思う。

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

前説

今回は、いよいよオーディオからは縁遠いので、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を動かそうとしたらどうしたらいいのだろうか。何か方法はあるんだと思うけど、未確認。

うちには無線機能がない古いRaspberry Piが幾つか、使わないままになっている。
以前のエントリーで、これらにUSB無線アダプターを付けて、piCoreで使えるようにしようという話を書いた。
Raspberry Pi + USB WiFiアダプターで piCore 起動時に自動的に無線LANに接続させる
http://blown-lei.net/endive/blosxom.cgi/pc/20211109a.htm

その後、考えた。
piCoreに拘らなくてもいいのではないか。
そういうわけで、今回はRaspberry Pi OSで、あらかじめIPアドレス固定だ。
ただ、ネット上の他のサイトを読んでいたら、今回うちでやった手法は古いやり方であるらしい。とりあえず動いてるからいいのかな、という感じだ。

今年の4月にRaspberry Pi OSは以前よりもセキュリティが厳しくなって、初期設定のpiユーザーがなくなった。
An update to Raspberry Pi OS Bullseye
https://www.raspberrypi.com/news/raspberry-pi-bullseye-update-april-2022/
いろいろやり方が変わって面倒なので、使っているのは最新のBullseyeではなくてBusterだ。

以下、忘れるので備忘録。処置を列記。

まずraspberrypi.comで、「Raspberry Pi OS Lite (Legacy)」と書いてある処からBuster Liteをダウンロードする。うちではモニターを使うのは想定していないのでLiteを使う。
https://www.raspberrypi.com/software/operating-systems/#raspberry-pi-os-legacy

マイクロSDに焼く。
sshが使えるようにbootパーティションにsshファイルを作って、Raspberry Pi（B+と初期型の2）に刺す。
LANケーブル、USB無線アダプターも刺して、電源に繋いで起動。
IPを確認しsshでログイン（ユーザー：pi、パス：raspberry）。

sudo raspi-config で設定した項目は以下の通り。他は触らない。下手に触ると上手くいかなくなるようだ。うちだけか？、、。

1 System Options / Hostname
5 Localisation Options / L2 Timezone
6 Advanced Options / A1 Expand Filesystem 

書き忘れていたが、どこかで sudo apt-get update、sudo apt-get upgrade している。

lsusb でUSB無線アダプターをラズパイがどう認識しているかを確認。
下記のように認識している内容が表示される。

pi@raspberrypi:~ $ lsusb
Bus 001 Device 004: ID 0bda:8179 Realtek Semiconductor Corp. RTL8188EUS 802.11n Wireless Network Adapter
Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp. SMSC9512/9514 Fast Ethernet Adapter
Bus 001 Device 002: ID 0424:9514 Standard Microsystems Corp. SMC9514 Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

1番目の行に「Realtek Semiconductor Corp. RTL8188EUS 802.11n Wireless Network Adapter」と詳細が表示されている。どうやら使えそう。

次に、無線LANルーター認証の設定ファイルを記述する。
まずPSKの生成。下記コマンド使用。
SSID（ネットワーク名）とPassphrase（パス/暗号化キー）は、ローカルの無線LANネットワークで決まっている筈である。

wpa_passphrase SSID Passphrase

network={
ssid="Your_SSID"
#psk="Your_Passphrase"
psk=bca18993a64219d23b7b4cf1214d999d812b5... ＊snip＊
}

こんな設定の文面が表示される。
pskとは事前共有鍵（Pre-Shared Key）というもので、暗号鍵を事前に設定しておくということらしい。
これを「wpa_supplicant.conf」に追記記載する。

sudo vi /etc/wpa_supplicant/wpa_supplicant.conf

network={
ssid="Your_SSID"
#psk="Your_Passphrase"
psk=bca18993a64219d23b7b4cf1214d999d812b5... ＊snip＊
key_mgmt=WPA-PSK
proto=RSN
pairwise=CCMP
group=CCMP
}

更にkey_mgmt、proto、pairwise、groupも追加。これらは認証方式と暗号方式によって記載内容が変わる。
うちの無線LANルーターで設定を見たら「WPA2-PSKとAES(AES)」と書いてある。
これは、認証方式がWPA2-PSK、暗号方式がAES、という意味らしい。
記載をこれに合わせる。

次に下記ファイルに固定するIPアドレスなど設定を記載。

sudo vi /etc/network/interfaces


auto wlan0
allow-hotplug wlan0
#iface wlan0 inet manual
iface wlan0 inet static
address 192.168.1.xxx
netmask 255.255.255.0
gateway 192.168.1.1

# wpa-roam /etc/wpa_supplicant/wpa_supplicant.conf
wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf
iface default inet dhcp

sudo reboot　で再起動、設定したIPアドレスで無線LANにつながるはず。

しかし有線LANのほうはつながらなくなる。
USB無線アダプターを外して有線LANをつないでも、つながらない。考えてみたら上記設定は無線しかしていない。
有線も使いたかったら、wpa-confの行をコメント化してwpa-roamで設定する方法もあるようだが、よく分かっていない。

今回はLinuxの話になる。

前回のエントリーは、Raspberry Pi2をAP化、オーディオプレーヤー化しようとしたところ、なんだかよく分からないことになったという話だったんだけど、未だにどうなってるのか分からない。
とりあえずAP化の詳細は置いといて、初歩的なとこから、家庭内LANに無線でつなぐとこから始めよう、と思ったら、意外に嵌ったので備忘録化しておく。

まず使ったpiCoreは、piCore13.0.3 /armv7。つまりRaspberry Pi B2用の最新版。
うちで余っているRas Piは、B+、B2が多く、無線を使うならUSB WiFiアダプターを使うのが前提となる。入手しやすいのは最近の製品となるので、新しいOSじゃないと対応できないんじゃないかと思ったので、piCore7に拘るのは止めたということだ。

今回、それでもUSB WiFiアダプターはLinuxで使えないことが少なくないことを初めて知った。機材自体をpiCoreで認識できなかったり、Linux対応と書いてあってもドライバーをCDからインストールしないといけないのとかあって、ちょっと手間が掛かりすぎる。
何種類か試したけど、今のところ使えているのは、前回エントリーのBUFFALO WLI-UC-GNM、TP-LinkのTL-WN725N、エレコムのWDC-150SU2MBKだ。
Aigital AC600、Rich AC1200M、BUFFALO WI-U2-433DMSは、現在のところ使えていない。

環境構築のインストールに使ったコマンドは以下のとおり。
hostapd、dnsmasqはまだ使わないけど、今後の使用を考えて入れてある。関連があるtczも同時にインストールされる。

tce-load -wi ntp.tcz
tce-load -wi wifi.tcz firmware-brcmwifi.tcz firmware-ralinkwifi.tcz firmware-rpi-wifi.tcz firmware-rtlwifi.tcz
tce-load -wi wireless-5.10.16-piCore-v7.tcz wireless_tools.tcz
tce-load -wi usbutils.tcz usbutils-doc.tcz libusb-dev.tcz libusb.tcz usb-ids.tcz
tce-load -wi hostapd.tcz dnsmasq-doc.tcz dnsmasq.tcz

あれこれネット上で迷ったが灯台下暗しで、最終的に参考にしたのはtceコマンドで見ることができるwifi.tczの説明書き。

Comments: A console based tiny wifi scan access point tool.
 Select from menu or type sudo wifi.sh
 Creates wifi.db in HOME directory.
 Can auto connect to first db entry with use of -a flag, e.g.,
 /usr/local/bin/wifi.sh -a 2>&1 > /tmp/wifi.log
 Add above to bootlocal or bootsync for quick auto connect.
 When mobile, use menu for select list of APs.
 wpa_supplicant driver is defined by /etc/sysconfig/wifi-wpadrv
 default is wext. Add it to backup if changed.
 Available drivers wext,nl80211

加えて「/usr/local/bin/wifi.sh」に書かれているwifi.shのヘルプ。
これはコマンド「sudo wifi.sh -?」でも見ることができる。

Usage:
 Default select AP from menu and request IP via DHCP.
 -a Auto connect to first wifi.db entry via DHCP.
 -p Select AP from menu and prompt for IP configuration type.
 -w Wait indefinitely until lease is obtained
 -? Displays this help message.

これらを参考にして実際に行った手順を、以下に記録しておく。

まず「/opt/bootlocal.sh」に無線LAN有効化のコマンドを書き込む。これで電源を入れたときに、無線LANが有効になる。

tc@box:~$ vi /opt/bootlocal.sh

ifconfig wlan0 up

設定ファイルを書き換えたので保存のコマンド「filetool.sh -b」を打って保存。
sudo reboot で、再起動。

USB WiFi アダプター（今回はTP-Link TL-WN725N）を刺し、ハード認識確認のコマンドを打つ。

tc@box:~$ lsusb
Protocol spec without prior Class and Subclass spec at line 23179
Bus 001 Device 004: ID 0bda:8179 Realtek Semiconductor Corp. RTL8188EUS 802.11n Wireless Network Adapter
Bus 001 Device 003: ID 0424:ec00 Microchip Technology, Inc. (formerly SMSC) SMSC9512/9514 Fast Ethernet Adapter
Bus 001 Device 002: ID 0424:9514 Microchip Technology, Inc. (formerly SMSC) SMC9514 Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
tc@box:~$


tc@box:~$ iwconfig
lo  no wireless extensions.

eth0  no wireless extensions.

wlan0 unassociated  ESSID:""  Nickname:""
  Mode:Auto  Frequency=2.412 GHz  Access Point: Not-Associated 
  Sensitivity:0/0  
  Retry:off RTS thr:off Fragment thr:off
  Power Management:off
  Link Quality:0  Signal level:0  Noise level:0
  Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
  Tx excessive retries:0  Invalid misc:0 Missed beacon:0

tc@box:~$ 
tc@box:~$ ifconfig
eth0  Link encap:Ethernet  HWaddr B8:27:EB:39:F8:15  

      ＊snip＊

lo    Link encap:Local Loopback  

      ＊snip＊

wlan0 Link encap:Ethernet  HWaddr 7C:C2:C6:1B:53:D2  
      UP BROADCAST MULTICAST  MTU:1500  Metric:1
      RX packets:0 errors:0 dropped:0 overruns:0 frame:0
      TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
      collisions:0 txqueuelen:1000 
      RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

tc@box:~$

こんな感じ。機材は認識されているけど、wifi (wlan0)は機能していない。

wifi.tczの説明書きに沿って設定していく。
sudo wifi.sh を打って、WiFiでローカルのLANに接続する。以下、流れを記載。

tc@box:~$ sudo wifi.sh

Select Wifi Network

    ESSID           Enc	Qual	Channel Type		
 1. ssssssssssss    on	  0	  2	WPA
 2. oooooooooooo    on	  0	  5	WPA
 3. AAAAAAAAAAAA    on	  0	 12	WPA

Enter selection ( 1 - 3 ) or (q)uit: 3

Enter password for AAAAAAAAAAAA (8 to 63 characters): zzzzzzzzzzzz
Sending credentials to requested access point AAAAAAAAAAAA..
deleting routers
adding dns 192.168.1.1
tc@box:~$ 

tc@box:~$ ifconfig
eth0  Link encap:Ethernet  HWaddr B8:27:EB:39:F8:15  

      ＊snip＊

lo    Link encap:Local Loopback  

      ＊snip＊

wlan0 Link encap:Ethernet  HWaddr 7C:C2:C6:1B:53:D2  
      inet addr:192.168.1.42  Bcast:192.168.1.255  Mask:255.255.255.0
      UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
      RX packets:19 errors:0 dropped:82 overruns:0 frame:0
      TX packets:4 errors:0 dropped:0 overruns:0 carrier:0
      collisions:0 txqueuelen:1000 
      RX bytes:89869 (87.7 KiB)  TX bytes:3824 (3.7 KiB)

tc@box:~$ 

こんな感じでLANのアクセスポイントにWiFiで接続できた。
アクセスポイントをセレクトし（上の例だとAAAAAAAAAAAA）、パスワードを入力（上の例だとzzzzzzzzzzzz）、「ifconfig」でIPアドレスを確認すると、wlan0に「192.168.1.42」が振られている。

こうして1回接続することで、接続設定ファイル「wifi.db」が、ホームディレクトリに作られる。このファイルにはアクセスポイントとパスワード、暗号化について記述されている。これを「filetool.sh -b」を打って保存。

wifi.tczの説明書きには、
/usr/local/bin/wifi.sh -a 2>&1 > /tmp/wifi.log
Add above to bootlocal or bootsync for quick auto connect.
とあるのだけど、、、
このコマンドをそのまま使うと、理由は分からないが上手くいかなかった。LANに接続できないままコマンドが指示を出し続け、ログが積み重なるような状況に至る。
そういうわけで、うちではbootlocal.shに下記のようにコマンドを書き込んだ。

tc@box:~$ vi /opt/bootlocal.sh

/usr/local/bin/wifi.sh -a

保存のコマンド「filetool.sh -b」を打って、sudo reboot で、再起動。
これで、Ras Pi電源オン、piCore起動と同時に、wifi.dbに記載されたアクセスポイントに自動的に無線でつながる。

これで、OS起動と同時に自動的に無線LANにつながるpiCore13ができた。といっても、アクセスポイントは予め設定されていて変更するには再設定する必要があるので、いつでも何処でも使えるというのではないけど。あと、USB WiFiアダプターを替えたら設定し直ししないといけないようだ。

ともあれ、これでうちで余っているRaspberry Piを無線でつないで、オーディオ以外でも活用することができるかもしれない。

うちのカーステレオ用音楽プレーヤーとして使っているBlackberry Bold 9000が最近あやうい。
というのは、内蔵電池が膨れてきている。
そのせいで本体の蓋が閉まらない。それでも使えて音も出るけど、じきに使えなくなるだろう。

交換用の電池は一応ネット上で売っているけど、何時売られなくなるか分からないし、過去には使ったら本体を壊した電池もあった。別の意味で危ういのだ。博打である。

当時、本体が壊れたので、普通の音楽プレーヤーで代替になれる製品を探したんだけど、試聴できた範囲ではいいのがなかった。音が良くないのと、操作性が良くないのと。
音が良いのになると高価になる。Bold 9000の中古が8千円で手に入るのに、数万以上で使いにくいプレーヤーを買う選択枝はなかった。

9000は物理キーから触覚で操作できるので、カーステレオ用として非常に使い易い。
必要となれば、ボタン１つで鳴っている音楽の曲名なども液晶画面に表示出来る。曲のランダム再生も、本体の電源を入れて諸々の操作で5秒以内で音楽が流れ出す。物理キーとトラックボール、いちいち目で見て確認しなくても出来てしまう。

しかし今や、9000は中古も売ってない。
あと、入手してもOSのバージョンアップが出来ないかもしれない。昔はなんとかしてやっつけたが、やり方を正確には覚えていないのだ（うちのサイトに備忘録があるんだけど、殆ど役に立たなかったんだよね、、）。
使い易くするにはバージョンアップしないといけないんだけど、これが出来ないかもしれないとなれば、、、

そういうわけで、代替機を作ることにした。
引き出しの奥で眠っているRaspberry Pi 2と、i2s DAC、piCore7 + MPD 0.19.9、追加投資はバッテリーぐらいで、なんとかしようというのだ。
少々梃子摺って、問題もないではないが、なんとかなった。

コンセプトはこんな感じで。

１．車のRCA入力端子につなぐ
２．電源オン・オフはコード（USBケーブル）の接続で行う
３．操作はWiFiでスマートフォンから行う（piCoreをAPモードで動かす）
４．USBメモリに収めた音源をランダム再生する

うちの車は、運転席左後ろの収納ボックス内にカーステレオのRCA入力端子が付いている。
9000は、専用のケーブルを自作して、イヤホン端子からRCA端子につないでいた。
ふつうのケーブルだと太すぎて、9000本体を収納ボックスから出せないのだ。出せなかったら操作できない。収納ボックスの蓋を開きっぱなしにしていたら運転の邪魔になる。そんなわけで、極細のRCA-イヤホン端子のケーブルが必要になったということだ。
Ras Piはスマホから操作するので、収納ボックス内に置いてかまわない。i2s DACと普通のRCAケーブルでつなげばいいということになる。

piCoreは電源コード抜去で電源を落としても大丈夫なOSなので、今回はなんとしてでも使うことにした。
車から降りるときにプレーヤーをシャットダウンする必要があるんだけど、raspbianベースのOS（例えばVolumioなど）だと、OSにログインしてシャットダウンの操作をしなければならない。手順を踏んでシャットダウンしないとOSが壊れるからだ。
その場で電源を落とせるほうが使い易い。piCoreはこういった用途に適している。

音声再生の操作はスマホからWiFiでアクセスして行う。
piCoreを所謂APモードで起動するのだが、過去に何回か手を付けたけど、分からなくて途中で投げてばかりだった。ネット上にはpiCoreでやってるケースは見つけられなかった。Raspbianベースで同様のことをやってる作例はあるのだけど、それでも随分参考になった。

操作性は、9000と比べたら低下している。
WiFiでRas Piとつなげて（これはスマホに自動設定できるけど）、MPDクライアントを起動し、音楽フォルダを選択してプレイリストに登録して再生、ランダム設定、、、
画面を見ながらじゃないとできないことがあれこれとある。たぶん操作に慣れても30秒はかかるのではないか。
あとアートワークを表示しない。これはMPD 0.19の仕様上、仕方がないのだけど。

うだうだ書いてきたけど、実際に行った建付けは右往左往だったけど、出来た結果を整頓して分かりやすく備忘録にしておこう。

参考にさせていただいたサイトは下記。多謝。他にも参考にしたけど忘れた。

https://itmedia.co.jp/news/articles/2008/14/news042.html
https://qiita.com/JhonnyBravo/items/5df2d9b2fcb142b6a67c
https://katona.hatenadiary.org/entry/20071101/p2
http://flac.aki.gs/bony/?page_id=1085
https://wiki.archlinux.jp/index.php/Music_Player_Daemon
http://kitatokyo2013.blogspot.com/2014/02/picoreplayerip.html
http://soramimi.jp/raspberrypi/mpd/
https://qiita.com/hoto17296/items/2e638fa28597b18505cd
https://gadget-live.net/raspberry-pi-self-made-router/
https://raspida.com/wifi4raspbian
https://herb.h.kobe-u.ac.jp/raspiinfo/raspiAP.html
https://armadillo.atmark-techno.com/blog/615/1830

piCore7はここからダウンロードした。
http://tinycorelinux.net/7.x/armv7/releases/RPi2/

piCore7を使う理由は、MPDのインストールが楽だから。
うちで余っているRas PiはB+と初期型の2なので、B+だったらarmv6、初期型2だったらarmv7となる。
3B+も1台予備があるんだけど、piCore7は対応していない。新しいバージョンのpiCoreだとMPDをソースからインストールしないといけないので、けっこうな手間なのだ。

ダウンロードしたイメージをマイクロSDカードに焼いて、i2s DACの設定を書き込み、Ras Piに刺して家庭内有線LANにつないで起動。パーティションを拡張。
ここら詳細は過去のエントリーを参照のこと。
http://blown-lei.net/endive/blosxom.cgi/audio_diary/20180103a.html
piCore7にmpdをインストールする方法

今回、完成後のonboot.lstは下記。

mc.tcz
openssh.tcz
wifi.tcz
firmware-rtlwifi.tcz
firmware-ralinkwifi.tcz
usbutils.tcz
net-usb-4.1.13-piCore_v7+.tcz
net-usb-4.1.20-piCore_v7+.tcz
hostapd.tcz
dnsmasq-doc.tcz
dnsmasq.tcz
rfkill.tcz
libmpdclient.tcz
libmpdclient-dev.tcz
mpd.tcz
alsa.tcz
alsa-config.tcz
alsa-dev.tcz

このリストにあるtczを、tceでインストールしていけば、関連のライブラリ等も含めて同等のものが出来る筈だ。
mc.tczとopenssh.tczは最初からインストールされている。それ以降のtczをインストールしていけばいい。
MPDをインストールしたらalsa関連も一緒にされるものと思い込んでいたら、されなかったので最後に追加でインストールしている。実際にi2s出力で必要かどうかは分からないが、一応入れている。

APモード関連

まずAPモードの設定から。

起動時にAPとなるRas PiのIPアドレスを固定するには、/opt/bootsync.shに「wlan0.sh」の設定をしておく必要がある。
下記、記載。

/home/tc/wlan0.sh &

/home/tc/wlan0.sh に、wlan0の設定を記述する。
下記の記載で、RasPi-APが「192.168.2.1」になる。

pkill udhcpc
ifconfig wlan0 192.168.2.1 netmask 255.255.255.0 broadcast 192.168.2.255 up
route add default gw 192.168.2.1
echo nameserver 192.168.2.1 > /home/tc/resolv.conf

/home/tc/resolv.conf に下記記載。
（このファイルを削除したら、有線LANにつながらなくなる。どういう挙動なのかよく分からないが、、、）

nameserver 192.168.2.1

USB無線LANアダプターを刺して、認識しているかどうかを確認。

tc@box:~$ lsusb
Bus 001 Device 004: ID 0411:01a2 BUFFALO INC. (formerly MelCo., Inc.) WLI-UC-GNM Wireless LAN Adapter [Ralink RT8070]
Bus 001 Device 005: ID 0bda:0109 Realtek Semiconductor Corp. 
Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp. SMSC9512/9514 Fast Ethernet Adapter
Bus 001 Device 002: ID 0424:9514 Standard Microsystems Corp. SMC9514 Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
tc@box:~$ 

ハードの認識はしている。しかし設定をしていない段階では認識していても動いていない。
/opt/bootlocal.sh にiwconfigでスイッチを入れるように設定。

iwconfig wlan0 power on

bootlocal.sh には、hostapd起動の設定も記載。
今回は、tcディレクトリに置いた設定ファイルをhostapdで読み込むようにする。

hostapd /home/tc/hostapd.conf -B

tcディレクトリに置いた設定ファイル、/home/tc/hostapd.confには、下記を記載。

interface=wlan0
ssid=RasPi-AP
hw_mode=g
channel=7
wmm_enabled=0
macaddr_acl=0
auth_algs=1
ignore_broadcast_ssid=0
wpa=2
wpa_passphrase=abcdefghijkl
wpa_key_mgmt=WPA-PSK
wpa_pairwise=TKIP
rsn_pairwise=CCMP

細々したことはよく分からないんだけど、無線LAN(wlan0)を「ssid=RasPi-AP」で動かす設定。
wpa_passphraseは、スマートフォンからRasPi-APネットワークにログインするためのパスワードだ。

dnsmasqでDHCPの設定。
/home/tc/dnsmasq.conf に下記記載している。

interface=wlan0
dhcp-range=192.168.2.2,192.168.2.99,255.255.255.0,24h

udhcpcのdefault.scriptが何処にあるのか探したら、/usr/share/udhcpc/default.scriptが見つかった。中をみたら「RESOLV_CONF="/etc/resolv.conf"」と。
今回はtcディレクトリにresolv.confを置いているので、それを設定してやらないといけないのかな。
/home/tc/udhcpc.script を設定。「RESOLV_CONF="/etc/resolv.conf"」の記述を「RESOLV_CONF="/home/tc/resolv.conf"」に書き換えて設置、、、

実はこの辺り、、、なんでこんなことしたのか記憶がない。何を参考にしたのかもよく分からない。
しかし、/home/tc/udhcpc.scriptを外したらうまく動かなくなる。無線は動いてログインできるんだけど、有線LANがつながらなくなる（まあ、有線LANはカーステレオ使用には無用なんだけど、使える方がメンテしやすい）。なので、何かしているんだとは思うんだけど、、、

よく分からないところもあるが、これでRas PiのAPモードが動く。
APモードなんだけど、同時に有線LANの方も稼働しているので、LANケーブルをつなげばそっちからの設定変更やMPDクライアントでのアクセスも可能だ。
しかし、dnsmasq、udhcpc周りには問題があって（設定がおかしいからだと思うが、、、）、APからクライアントにアドレスが配布されない。クライアント側のスマートフォンで固定IPにすれば運用上の支障はないので、当面このままで使うつもり。

MPDの設定

MPDは、Ras Pi起動と同時に自動起動させる。
これがなぜか、今までのうちでのやり方で上手くいかなかった。ネット上にはrootでは起動しないと書いてあったり（そうなの？！、、、）。
なので、/home/tc/.profile の末尾にコマンドを記載することで起動させるようにした。

/usr/local/bin/mpd /home/tc/.mpdconf

mpd.confは/home/tc/.mpdconfで設定。下記の通り。

music_directory "/mnt/music"
# playlist_directory "/mnt/music/mp/mpd/playlists"
playlist_directory "/home/tc/.mpd/playlists"

log_file "/home/tc/.mpd/log"
pid_file "/home/tc/.mpd/pid"
state_file "/home/tc/.mpd/state"
sticker_file "/home/tc/.mpd/sticker.sql"

db_file "/usr/local/share/mpd/database"

auto_update "yes"
#auto_update_depth "3"

audio_output {
 type "alsa"
 name "My ALSA Device"
 device "hw:0,0" # optional
 mixer_type "software" # optional
## mixer_device "default" # optional
## mixer_control "PCM" # optional
## mixer_index "0" # optional
}

samplerate_converter "Fastest Sinc Interpolator"
audio_buffer_size "8192"
buffer_before_play "20%"
audio_output_format "192000:24:2"

filesystem_charset "UTF-8"
id3v1_encoding "UTF-8"

カーオーディオの使用でライブラリを保存する操作は基本的にはしないので、MPD起動と同時にライブラリのアップデートを行うように設定。
auto_update "yes"
データベースファイルをMPD起動と同時に作るので、filetool.sh -bに記載されていない場所に設定した（これは工程作業の都合で使用上には関係ないけど）。
db_file "/usr/local/share/mpd/database"

/opt/bootlocal.sh に下記記載し、OS起動時に/mnt/musicやデータベースファイルを置くディレクトリなどを作る。
音源となるUSBメモリ／マイクロSD＋USBアダプターをOS起動時に認識、マウントポイント「mp」にマウントさせる。

mkdir /usr/local/share/mpd
chmod -R 777 /usr/local/share/mpd

mkdir /mnt/music
mkdir /mnt/music/mp
mkdir /mnt/music/ram
touch /mnt/music/ram/dummy.cue
chmod -R 777 /mnt/music

mount -w /dev/sda1 /mnt/music/mp

以上で、MPD関連の設定は完了。

スマートフォンの設定

インストールと設定を終えたRas Piは、電源を入れて起動したらAPモードで動いている。MPDも自動的に起動し音源データを読み込みライブラリを形成し、クライアントからの指示があれば音声再生が可能な状態になっている。

MPDクライアントを動かすスマートフォン（当方はAndroid 11）を設定する。

WiFiからアクセスポイントRasPi-APを選択。
前述したとおり、Ras Piの方から自動的にIPアドレスを振ってくれない。
Ras PiのDHCPサーバーが問題なく動いていればスマートフォンに自動的にアドレスを振ってくれるはずなんだけど、これが機能していないのだ。

できないものは仕方がないので、スマートフォンのほうでIPアドレスを設定。IPアドレス固定で設定する。
APモードのRas Piが「192.168.2.1」でネットマスクはnetmask 255.255.255.0 なので「192.168.2.xxx（xxxは2から254の間の任意の数でいける筈）」でスマートフォンを設定。
インターネットに繋がりませんと警告？が出るけど、繋げなくてもいいということで設定する。
これで接続、MPDクライアントから操作ができるようになる。

うちではM.A.L.P.を使っているけど、クライアントソフトによって設定や使い方は違うと思うので、これ以降は省略。

そんなこんなで、取り敢えずRaspberry Piベースでカーオーディオ用のポータブルMPDプレーヤーが出来上がった。
音の方は、試しに車のシガーソケットからUSB電源をとって試聴したところ充分過ぎる音が出たので（シガーソケットでこの音か？と驚いた）、問題があるとか何とかは置いといて速やかに日常使用に移行させようという感じ。
接続が問題かな、RCAケーブルとか電源ケーブルをどうするかとか。
当初はバッテリー駆動するつもりだったが、シガーソケットから電源をとれるようにすることも検討している。

DHCPの問題は、今後あせらずに対処していこうと思う。

Pulseaudioによる音声データ転送は快適で、サブスクストリーミング音源を聴くのにすごく重宝している。
だけど、どうにも気になっているのが、pulseaudioサーバーへのデータ転送量が余りにも大きいことだ。

過去にアップしたエントリーから引用してみる。

Pulseaudioを使ってRaspberry piにAmazon Prime Musicを転送再生する（9月8日追記）
http://blown-lei.net/endive/blosxom.cgi/audio_diary/20200906a.htm

6730bのネットワーク出力をモニターしてみたら、400KiB/s前後でデータ転送されている。
youtubeの音源だとどうなるか確かめたら、s32le 48000。サイトや音源によって変化するようだ。
DACをRAL-2496ut1に換えると、s16leにフォーマットが変わる。こういう調整はRaspberry Pi2がやってくれているみたい。

最初にRaspberry Piで試みた時には「400KiB/s前後」の転送量だったようだ。
それが現在は「3 MiB/s」で転送されているのが、通常の運用だ。
3 MiB/s、って、動画じゃないのかという容量だ。
いつのまにそんなことになったのか、、、

最初は、メモリ使用量も気になる程ではなかった筈。
それが注意していないとクライアントPCのメモリがウェブブラウザのキャッシュで溢れて、PCのシステム自体が不安定になるようになった。そういった理由で、昨年秋にクライアントPCを変更したのだ（前の機種は既に古すぎたという理由もあったのだけど）。
今はそういうことはなくなったけど、、、

Deezerを使った場合の音声データ量は音楽データはCDと同等。
1秒あたりのデータ量を計算してみる。

44100×16×2 = 1411200 bit =「176.4 KiB」
s32leだったらx2で、350 KiB前後のデータ量になる。

3MiB/sは、その10倍近い。なんでこんな大量のデータ量を転送しているのか全く分からない。
たぶん音楽データだけではなくてブラウザ表示の画像表示データなんかも一緒くたにして送っているんだと思う。pulseaudioサーバーでは、そのデータの中から音声データだけを抽出して処理しているのではないだろうか。
ほんとうは、音声データだけ送るほうがサーバーの負担も小さくなるのではないか、と思うのだけど、、、

さて。
ものは試しだと思って、クライアントPCのHDDに保存してあったflacファイルをウェブブラウザで開いて、再生、転送してみた。
その結果をキャプチャ。
なんと、、
データ転送量は「1.7 Mb/s」、200 KiB/s前後で、CD相当の音楽データ＋α、で納得できるデータ量になった。

そこで、、、同じそのウェブブラウザで、Deezerウェブプレーヤーを開いて再生、転送してみた。
なんとまあ、、、データ転送量は「1.7 Mb/s」のままだ。設定を引き継いでいる、ということなのか、、、

ウェブブラウザを閉じて、再起動して、Deezerウェブプレーヤーを開いて再生、転送。
データ転送量は「26 Mb/s」つまり、3 MiB/s強になった。
ウェブブラウザを閉じたら、設定を引き継いでいない。

先刻とは逆の操作も試してみた。
つまり、Deezerウェブプレーヤーを開いて再生、転送した後、HDDのflacファイルをウェブブラウザで開いて、再生、転送。
データ転送量は「26 Mb/s」、3 MiB/sで変わらず、設定を引き継いだ。
ブラウザ画面にはflacを意味する横棒が表示されている。いったい、どんなデータがサーバーに転送されているんだろう、、、

Deezerウェブプレーヤーを開く前にflacファイルを開く操作をしておけば、その後で開くDeezerウェブプレーヤーからもほぼ音楽データだけを転送できるかもしれない。ウェブブラウザを閉じない限り出力の設定を引き継ぐということは、何処かに設定保存している一時ファイルがあるということだ。そのファイルを見つけられたら、何か手掛かりが得られるかも、、、

しかし、ことは簡単ではなかった。
繰り返し試してみた結果、この挙動には再現性がないことが分かった（おい、ここまで書いてきてそれかよ）。
いつも転送量を減らせるとは限らない。
転送量を減らせるのは、ターミナル端末画面に「××が拒否されました」という感じのエラーが表示されるときのようなのだ。
拒否されてるときに、上手く行ったら音楽データのみの伝送が出来る、という感じ。拒否られて音が出ないときもある。こんなんじゃ使えない。

転送量が3 MiB/sだろうが200 KiB/sだろうが、音質は変わらないみたいだ。
十分使える。
だったら、もういいんじゃないかなあ、って感じ。

Pulseaudioは、Pipewireというサウンドサーバーシステムに移行が検討されているようで、うちで使っているFedoraにはいつの間にかインストールされていた（たぶん、アップデートの告知に僕が気付かなかったんだと思うけど）。
うちの現状のシステムはいつまで使うことになるのか分からないけど、将来的にはPipewireに移行することになるのかな。
Pipewireはもう少し扱いやすかったらいいと思う。

以前のエントリーでブレイクスルーは無いだろうと書いたことがあったが、以外なところからノイズの解決策が見つかった。
ソフトを起動する順番を変えることで、ノイズが消えてしまった。

思えば、Pulseaudioによる音声データ転送を今のシステムで始めた頃は、いつノイズが出るのか分からないような状態で、対策も闇雲な感があった。
しかし、daemon.confの「nice-level」を設定して以降から状況が変わってきた。使用開始時の再生音はノイズが増えたが（考えてみたら、これも原因不明なんだよね、、）、Pulseaudio serverを再起動したら、その後はノイズがすっかり消えてずっと安定するようになったのだ。

ただ、最初の起動時点からノイズ無しに再生できるようにする方法が見えなかった。
再起動しなければずっとノイズが続く。
サーバーで「top」を打って確認したら、再起動前後ではCPUの使用％も違う。ノイズが出ているときの方が負荷が大きい。

設定を弄るばかりで行き詰まってしまったので、操作方法とノイズの有無について再確認してみようと思い付いた。

まずサーバー起動し、Firefox、Deezerを起動し音を出したら、ノイズまみれの音になる。
ここでサーバーを再起動したら、ノイズが無くなる。 サーバー再起動の変わりにFirefoxの再起動やDeezerの再起動では、ノイズは無くならない。改めてサーバーを再起動したら、そこでノイズは無くなる。サーバーを再起動しないことにはノイズは無くならないようだ。

手順についてあれこれ考え試みているうちに、最初のサーバー起動と再起動とで何が違うのかというと、FirefoxとDeezerが動いているかどうかだ、ということに気付いた。
ここで最初の音出しに際しての手順については、今まで全く検討していないことに思い至った。
つまり、サーバーを起動した後にクライアントを動かすものだという、固定観念があったのだ。

試しに、先にFirefox、Deezerを起動して後に、サーバーを起動してみたら、ノイズがない音が再生された。
ちょっと呆れてものも言えない。

何時またノイズが出始めるか分からないので、これで最終型と言い難いのだけど、本当にこれで完成して欲しい。そんなこといいながら、実はノイズの原因とか、ほとんど原因不明なままだ。そんなことでいいのかな、という気持ちもないではないのだけど。でも解明するには分からないことが多すぎかな。

はああ、しかし取り敢えず、何とかなったぜ、、、

しかし、ここまでの記載内容は、2020年度までのシステム運用上で大事だったことで、21年春からDaphile経由でDeezerを再生できるようになってからは、pulseaudio経由で音源をアップサンプリングすることはなくなった。pulseaudioサーバーは別建てになり、Raspberry Pi2ベースでシンプルな運用になり要求する内容も軽くなって、サーバーとクライアントどっちが先かなんて、気にしなくてもよくなった。
本来あるべき、無理のない運用だと感じられる。まあ、いろいろ勉強になったかな、、、

取ってつけたようだが、取り敢えずまとめ

Pulseaudio関連のエントリーは、以下のとおり。

1. Pulseaudioを使ってRaspberry piにAmazon Prime Musicを転送再生する（9月8日追記）
   http://blown-lei.net/endive/blosxom.cgi/audio_diary/20200906a.htm

2. 音楽ストリーミングサービスのウェブプレーヤーを使う
   http://blown-lei.net/endive/blosxom.cgi/audio_diary/20200927a.htm

3. Pulseaudioの備忘録
   http://blown-lei.net/endive/blosxom.cgi/audio_diary/20200930a.htm

4. ストリーミング音源をpulseaudioで転送しアップサンプリング再生する（10月15日、追記）
   http://blown-lei.net/endive/blosxom.cgi/audio_diary/20201011a.htm

5. pulseaudioサーバーを強化する（10月24、25日、11月01、05、10日、追記あり）
   http://blown-lei.net/endive/blosxom.cgi/audio_diary/20201017a.htm

6. pulseaudioサーバーを強化する（その２：12月11日、追記あり）
   http://blown-lei.net/endive/blosxom.cgi/audio_diary/20201115a.htm

7. pulseaudio クライアントのFirefoxを強化する
   http://blown-lei.net/endive/blosxom.cgi/audio_diary/20201212a.htm

8. ソフトを起動する順番を変えてみる　～　pulseaudioによる音声データ転送 使い方まとめ（2021.01.31. 06.26. 追記）
   http://blown-lei.net/endive/blosxom.cgi/audio_diary/20201219a.htm

   (当エントリー)

9. PulseaudioによるLan経由音声データ転送のデータ量が大きすぎる（未解決案件）
   http://blown-lei.net/endive/blosxom.cgi/audio_diary/20210216a.htm

2020年末時点での運用は、図のようなイメージ。
普段、日常的な用途に使っているProbook 450G3を、pulseaudioクライアントとして運用。
音楽ストリーミングサービスdeezerのデータはCDと同等の音質で、ロスレスだ。
だから、これをpulseaudioサーバーにしたElitebook 2570pにLANを経由して送って、libsamplerateでアップサンプリングしてusb DACに送ることで、高音質再生を目指す。

このときの音質だけど、CD音源同等のストリーミングデータを、libsamplerateで384kHzにアップサンプリングし、SMSL M500、Brooklyn Ampで出力している音として、全く不満がない再生音が得られていた。Pulseaudioといえば、昔は音が良くないといわれていたようだけど、本当にそうなのかな？と思うだけの音が出ていた。
ADI-2 DAC、SM-SX100で鳴らしてみても、その印象は変わらなかった。

そういうわけで、Pulseaudio運用の記録を残しておく。

Pulseaudio クライアント

クライアントの扱いは前回のエントリーのとおり。
pulseaudio クライアントのFirefoxを強化する

しかし、2020年末、再生時にノイズが無くなった頃からは余り細かいことを気にしなくなった。前回エントリーの内容、クライアントの強化についても気にしない。
firefox以外のウェブブラウザを使ってみたりしたが、操作性以外に大きな差異はないようだ。

基本的に、一般的なワークステーション用Linux PCであればクライアントとして運用できるはず。大抵、pulseaudioはインストールされているからだ。
ウェブブラウザも一般的なので大抵は問題無いだろう。というか、問題があったら他のを使うだけだ。

クライアントの使い方は、過去のエントリーから一部引用し書き変えて記載しておく。

クライアント側の設定。設定というか、使い方だ。
先ずターミナルソフトでコマンドを打つ。

$ export PULSE_SERVER=192.168.1.xx

これで、このターミナルウィンドウから起動させるプロセスが、赤字のアドレスのpulseaudioサーバーに音声データを伝送できるようになる。
同じターミナルウィンドウからコマンドを打ってウェブブラウザ（例：firefox）を起動させる。

$ firefox

firefoxが起動したら、Deezerやyoutubeなど、聴きたい音源のサイトを開く。
続いて、pulseaudioサーバーでpulseaudioを起動した後、firefoxで音源を鳴らす操作を行う。
このfirefoxが出力する音声が、lanを通じてpulseaudioサーバーに転送される。うまくいけばサーバーで設定された出力から音が出る。

この順序が重要で、順序を間違えたら再生音にノイズが乗る。

以上、ざっと引用。

この順序を間違えたらノイズが乗るという案件なんだけど、Raspberry Pi2をpulseaudioサーバーにして、アップサンプリング無しで運用した場合には、まったく見られないようだ。
つまり、サーバー側でpulseaudioを起動したままにして（daemon.confに関連して後述）、好きな時にクライアント側の操作をしたら、サーバー側から音が出る。
扱い易いのはありがたい。
だけど、理由は分からないままになっている。

引き続いて、サーバーについての説明。
音質の追求や不具合への対処に付いては、複数のエントリーに渡ってああでもないこうでもないと色々やっていて、わけが分からない。

サーバー運用にあたって、最も大事なことが書いてあるのは最初のエントリー（Pulseaudioを使ってRaspberry piにAmazon Prime Musicを転送再生する（9月8日追記））かもしれない。ここにはpulseaudioのインストールとサーバー運用に必要な初期設定、pulseaudioで使うコマンド（音量調整など）についても幾つか説明を書いてある。

うちではデフォルトでは使用できないlibsamplerateを使えるようにする必要があったので、pulseaudioをソースから再インストールする必要があり面倒だった。顛末は下記エントリーに記載。
ストリーミング音源をpulseaudioで転送しアップサンプリング再生する（10月15日、追記）
libsamplerateでアップサンプリングするなら、ハードにはそれなりのスペックが必要になる。

アップサンプリングに拘りがないのであれば、もっと簡単に運用できる。
基本的に、pulseaudioがインストールされているLinux PCであれば、設定さえすればサーバーとして機能する筈だ。うちでは21年初夏の時点でRaspberry Pi2に回帰した。簡単な運用であればそれでまったく問題ない。

使用前に「default.pa」ファイルで出力先と入力先を設定。「daemon.conf」ファイルでpulseaudioの優先度やアップサンプリングなど設定。
sshを使ってLan経由でサーバーの起動終了、音量とかを操作する。
しかし、慣れない人にはハードルが高いかも。
サーバーの設定は以下。

Pulseaudio サーバー default.paの設定

「/home/tc/.pulse/default.pa」の設定は下記の通り。

#load-module module-alsa-sink
load-module module-alsa-sink device=hw:0,0

.ifexists module-udev-detect.so
load-module module-udev-detect
# load-module module-udev-detect tsched=0
.else
### Use the static hardware detection module (for systems that lack udev support)
load-module module-detect
# load-module module-detect tsched=0
.endif

#load-module module-native-protocol-tcp
load-module module-native-protocol-tcp auth-ip-acl=127.0.0.1;192.168.1.0/24

あれこれ運用した結果、「tsched=0」の設定を止めてデフォルトに戻している。
もともと特定のサウンドボードに対応するための設定だった筈で、実際、戻しても不具合は感じなかった。

出力先の設定が「load-module module-alsa-sink device=hw:0,0」。
aplay -lで音声データ出力先を確認し記載。

入力の設定が「load-module module-native-protocol-tcp auth-ip-acl=127.0.0.1;192.168.1.0/24」。
この記載だと、LANネットワーク内のipアドレスが「192.168.1.xxx」であるクライアントから、音声データを受けることができる。

Pulseaudio サーバー daemon.confの設定

「/home/tc/.pulse/daemon.conf」の設定は以下。
項目が多いので分けて記載。

; shm-size-bytes = 0 # setting this 0 will use the system-default, usually 64 MiB
shm-size-bytes =32000000

; high-priority = yes
; nice-level = -11
high-priority = yes
nice-level = -18

libsamplerate(SRC)で高いサンプリング周波数にアップサンプリングするために「shm-size-bytes」は大きくとっている。
しかし、どの程度の数値が良いのかは、はっきり分からないままだ。
アップサンプリングしないなら設定不要だと思う。

優先度も「nice-level」で設定する必要がある。
設定して以降、384/32が問題なく鳴らせるようになった。

; realtime-scheduling = yes
; realtime-priority = 5
realtime-scheduling = yes
realtime-priority = 88

; rlimit-nice = 31
; rlimit-rtprio = 9
rlimit-nice = 38
rlimit-rtprio = 88

このあたりの設定は、結局よく分からないままだ。
過去のエントリー（pulseaudioサーバーを強化する（その２：12月11日、追記あり） ）によると、あちこち他のサイトを参考にしながら計算した筈だけど、読み返しても何をやってるのか分からない。実際、分からないまま設定したのだ。
ちょっと引用。

GETRLIMIT https://linuxjm.osdn.jp/html/LDP_man-pages/man2/getrlimit.2.html

RLIMIT_NICE (Linux 2.6.12 以降, 下記の「バグ」の節も参照)

This specifies a ceiling to which the process's nice value can be raised using setpriority(2) or nice(2).
The actual ceiling for the nice value is calculated as 20 - rlim_cur.
The useful range for this limit is thus from 1 (corresponding to a nice value of 19) to 40 (corresponding to a nice value of -20).
This unusual choice of range was necessary because negative numbers cannot be specified as resource limit values, since they typically have special meanings.
For example, RLIM_INFINITY typically is the same as -1.
For more detail on the nice value, see sched(7).

nice-levelは、-20から19の間に設定。realtime-priorityは、0から99の間。
rlimit-niceは、20-(nice-level)で設定。
なんだか分からないが、20から引くということらしい。
rlimit-rtprioもよく分からないが、realtime-priorityに数値を合わせてみた。

このあたりは効果があったかどうかもはっきりしなかった。

; exit-idle-time = 20
; scache-idle-time = 20

exit-idle-time = -1
scache-idle-time = 180


; default-script-file = /usr/local/etc/pulse/default.pa
default-script-file = /home/tc/.pulse/default.pa

上の例では「exit-idle-time」に「-1」を設定している。
デフォルトは「20」で、クライアントからの音声データが20秒間途切れたらシャットダウンする設定だ。
この数値をマイナスに設定したら、データが途切れてもシャットダウンせずに待機するようになる。
以下、ネット上のマニュアルから引用。

IDLE TIMES

exit-idle-time= Terminate the daemon after the last client quit and this time in seconds passed. Use a negative value to disable this feature. Defaults to 20. The --exit-idle-time command line option takes precedence.
scache-idle-time= Unload autoloaded sample cache entries after being idle for this time in seconds. Defaults to 20. The --scache-idle-time command line option takes precedence.

1つのハードでmpdサーバーとpulseaudioサーバーを切り替えて使うような環境だったら自動的にシャットダウンする設定もそれなりに意味があるけど、pulseaudioサーバー専用ハードでサーバーを建てた場合はむしろずっと動いてくれている方が運用しやすい。

「default-script-file」は「default.pa」のパス設定。
意外に設定する方が安定すると過去のエントリーに記載がある。

; resample-method = speex-float-1
resample-method = src-sinc-fastest

; flat-volumes = yes
flat-volumes = no

リサンプリングにlibsamplerate(SRC)を使う設定を「resample-method = src-sinc-fastest」で記載。

flat-volumesは一応、noに。
入力と出力のボリュームを合わせるということなのでデータが変わるかもしれないと思ったので。
設定する方がいいのかどうかは確認していない。

; default-sample-format = s16le
; default-sample-rate = 44100
; alternate-sample-rate = 48000

default-sample-format = float32le

default-sample-rate = 384000
alternate-sample-rate = 384000

アップコンバートの設定。
default-sample-formatに「s32le」ではなく「float32le」を設定することで、音質改善があった。

; default-fragments = 4
; default-fragment-size-msec = 25

default-fragments = 2
default-fragment-size-msec = 20

; enable-deferred-volume = yes
enable-deferred-volume = no

これはあれこれやったけど、結局よく分からなかった。 pulseaudioのマニュアルから引用。

DEFAULT FRAGMENT SETTINGS

Some hardware drivers require the hardware playback buffer to be subdivided into several fragments.
It is possible to change these buffer metrics for machines with high scheduling latencies.
Not all possible values that may be configured here are available in all hardware.
The driver will to find the nearest setting supported.
Modern drivers that support timer-based scheduling ignore these options.

default-fragments= The default number of fragments. Defaults to 4.
default-fragment-size-msec=The duration of a single fragment. Defaults to 25ms (i.e. the total buffer is thus 100ms long).

Modern drivers that support timer-based scheduling ignore these options. とある。
タイマーベースのスケジューリングをサポートする最新のドライバーは、これらのオプションを無視します、と。、、、、

過去のエントリーから引用。

default-fragments関係の設定は初心に還って、計算値に合わせた。
20だろうが500だろうが、数値を何にしても大して挙動は変わらず、pulseaudioが最適値を勝手に決めているのだろうと思うに至ったのだけど、じゃあ、詳しいサイトに載っている計算に合わせた設定を書き込んでおいてもいいだろう。もうこれ以上は弄らないことにする。
参考にしたのはarchlinuxのサイト。
https://wiki.archlinux.jp/index.php/PulseAudio/トラブルシューティング
計算の仕方は下記。
コマンド「pactl list sinks」でusbデバイスへの伝送の状況が表示されるので、その数値から計算する。

pactl list sinks

Sample Specification: s32le 2ch 352800Hz
Properties:
 device.buffering.buffer_size = "1048576"
 device.buffering.fragment_size = "524288"

32*2*352800 = 22579200 (bps)
device.buffering.buffer_size (1048576) / 22579200 = 0.046439909 (50ms)
device.buffering.fragment_size (524288) / 22579200 = 0.023219955 (25ms) = default-fragment-size-msec

default-fragments = buffer_size/fragment_size = 0.046439909/0.023219955 =2

これも設定による明確な音質変化は分からなかった。まあ、これらのオプションは無視されていたのかも知れない。

Pulseaudioを使ってFirefoxをクライアントにして（こんな言い方でいいのかね？）音声データをコンポに転送しているんだけど、Firefoxのパフォーマンス向上のために何をしているか記録しておく。効いてるかどうかは判然としないけど、端末ソフト上のエラー表示は減るようだ。
ただ、エラーがでていても聴感上は分からないんだけど。
逆にノイズがある時にエラーが表示されるわけでもない。

備忘録なので、何かあったら追記する。

about:config : Firefoxの設定変更

下記の通り設定変更。
firefoxを高速化させるとネット上にあるのをいくつか設定した。

browser.cache.disk.enable　→　false
browser.cache.memory.capacity　→　233016

network.http.pipelining　→　true
network.http.pipelining.ssl　→　true
network.http.proxy.pipelining　→　true

browser.cache.memory.capacityの数値はkb。233016が上限ということらしい。
Firefoxのメモリ使用量が増えていくのを何とか出来ないかと思ってabout:configを調べているのだけど、項目が多くて調べ切れない状況。

優先度の調整

これはFirefoxを起動する度に行う必要がある。
FirefoxのPIDを確認し「renice」コマンドで設定する。

[ab@fedora1 ~]$ renice -n -15 149587
renice: 149587 (process ID) の優先順位の設定に失敗しました: 許可がありません
[ab@fedora1 ~]$ sudo renice -n -15 149587
149587 (process ID) 従来の優先順位は 0 で, 新しい優先順位は -15 です

[ab@fedora1 ~]$ renice -n 0 149587
149587 (process ID) 従来の優先順位は -15 で, 新しい優先順位は 0 です

[ab@fedora1 ~]$ sudo renice -n -20 149587
149587 (process ID) 従来の優先順位は 0 で, 新しい優先順位は -20 です
[ab@fedora1 ~]$ 

こんな感じ。

プロセスの「nice値」でプロセスの優先度を表す。
-20～19の間で値が小さいほど優先度が高い。
優先度を上げるには「sudo」で行う必要がある。下げる分には必要ない。
なお「nice」コマンドを使ってFirefoxを起動と同時に優先順位を上げるのは、Firefoxの仕様で出来ないようだ。

10月17日にアップしたエントリーに追記が積み重なって余りに読みにくいので、その２に移行する。

過去のpulseaudio関連のエントリーは以下のとおり。

運用状況は図のようなイメージ。
普段、日常的な用途に使っているProbook 450G3をpulseaudioクライアントとして運用。音楽ストリーミングサービスdeezerのデータをpulseaudioサーバーにしたElitebook 2570pに送って、アップサンプリングしてusb DACに送る。

上手くいけば、CDと同等のストリーミングデータを、リスニングポイントで扱いやすいウェブプレーヤーを操作しながら、メインシステムのオーディオシステムで良質なアップサンプリングをして再生できる。

ストリーミングサービスを聴くために一般的に必要とされている特別な装置やアプリを走らせる環境を、新たに用意する必要がない。うちにあるもので賄える。うちのメインシステムでデータを処理することが出来れば、音質もそこそこのレベルが狙えるはずだ。
ストリーミング音源のクレジット情報の少なさは本気でどうにかして欲しいレベルだけど、普段から使い慣れているウェブブラウザで音源を探したり再生したりしながら、同時にそのブラウザでその音源やミュージシャンについてウェブで検索することが出来る。まあ、出来ると言っても、限界もあるけど。

しかしノイズを生じることが度々あり、調整を繰り返している。
アナログディスクみたいなものだと思って割り切って聴くというのも、ノイズが増えてきたらそうも言っていられない。
もう弄りたくないと言いながら弄ってきている。

つまり、これを本当の意味で使えるようにしたいという、強い動機が僕の中にあるということだ。

pulseaudioサーバーの現在の設定は下記。

default.paの設定は以前と変わっていない。

vi .pulse/default.pa


#load-module module-alsa-sink
load-module module-alsa-sink device=hw:0,0

.ifexists module-udev-detect.so
# load-module module-udev-detect
load-module module-udev-detect tsched=0
.else
### Use the static hardware detection module (for systems that lack udev support)
# load-module module-detect
load-module module-detect tsched=0
.endif

#load-module module-native-protocol-tcp
load-module module-native-protocol-tcp auth-ip-acl=127.0.0.1;192.168.1.0/24

daemon.confの設定は変えている。

vi .pulse/daemon.conf


; shm-size-bytes = 0 # setting this 0 will use the system-default, usually 64 MiB
shm-size-bytes =64000000

; high-priority = yes
; nice-level = -11
high-priority = yes
nice-level = -15

; realtime-scheduling = yes
; realtime-priority = 5
realtime-scheduling = yes
realtime-priority = 88

; default-script-file = /usr/local/etc/pulse/default.pa
default-script-file = /home/tc/.pulse/default.pa

; resample-method = speex-float-1
resample-method = src-sinc-fastest

; flat-volumes = yes
flat-volumes = no

; rlimit-nice = 31
; rlimit-rtprio = 9
rlimit-nice = 35
rlimit-rtprio = 88


; default-sample-format = s16le
; default-sample-rate = 44100
; alternate-sample-rate = 48000

default-sample-format = s32le
# default-sample-rate = 384000
# alternate-sample-rate = 384000
default-sample-rate = 352800
alternate-sample-rate = 352800


; default-fragments = 4
; default-fragment-size-msec = 25

default-fragments = 2
default-fragment-size-msec = 25

; enable-deferred-volume = yes
enable-deferred-volume = no

以前は出来なかった「nice-level」の設定が、いつの間にか出来るようになっていた。理由は分からない。あれこれ弄ってるうちに何かが変わったのだろう。
しかし今回、これを設定したところ、俄然安定してノイズが無くなった。
今迄右往左往したの経緯から考えたらまだまだ安心出来ないけど、以前はノイズが多すぎて使えなかった384kHzアップサンプリング再生ですら、ノイズが無くなって？いるようなのだ。ノイズがないということはシステムが安定しているということで、音質も改善してPPAP方式に劣らないと思えるレベルになっている。300kHz台の音は出てるけど本当はもう少しいける筈だがなあ、という足りない感が、すっかり無くなった。
これなら安定運用を期待していいと思いたい。
気をよくして「rlimit-nice」「rlimit-rtprio」も設定している。

nice-level = -15
realtime-priority = 88

rlimit-nice = 35
### 20-(-15)=35
rlimit-rtprio = 88

こんな感じで設定。
nice-levelは、-20から19の間に設定。realtime-priorityは、0から99の間。
rlimit-niceは、20-(nice-level)で設定。
参考にしたのは下記アドレスのサイト。
GETRLIMIT
https://linuxjm.osdn.jp/html/LDP_man-pages/man2/getrlimit.2.html
なんだか分からないが、20から引くということらしい。
rlimit-rtprioもよく分からないが、realtime-priorityに数値を合わせてみた。

これで上がれたらいいが、どうだろうか。

shm-size-bytes =32000000

high-priority = yes
nice-level = -18

realtime-scheduling = yes
realtime-priority = 88

default-script-file = /home/tc/.pulse/default.pa

resample-method = src-sinc-fastest

flat-volumes = no

rlimit-nice = 38
rlimit-rtprio = 88

default-sample-format = float32le
default-sample-rate = 384000
alternate-sample-rate = 384000

default-fragments = 2
default-fragment-size-msec = 100

enable-deferred-volume = no

前のエントリーで、pulseaudioサーバー強化について検討中と書いた。
Compaq 6730bからElitebook 2570pに移行したのでエントリーにする。

新規に2570pを入手したのではなく、PPAP方式で使っているmpdサーバーに間借りさせた。
サーバーPCの個体数増加はノイズ源を増やすことになるし、mpdとpulseaudioを同時に使うことはない。
だったら１つの機体で運用してもいいんじゃないか、と思った。
図のようなイメージ。

インストール手順は前回エントリーに書いた通り。
設定は下記。

vi .pulse/default.pa

#load-module module-alsa-sink
load-module module-alsa-sink device=hw:0,0

.ifexists module-udev-detect.so
# load-module module-udev-detect
load-module module-udev-detect tsched=0
.else
### Use the static hardware detection module (for systems that lack udev support)
# load-module module-detect
load-module module-detect tsched=0
.endif

#load-module module-native-protocol-tcp
load-module module-native-protocol-tcp auth-ip-acl=127.0.0.1;192.168.1.0/24

vi .pulse/daemon.conf

; shm-size-bytes = 0 # setting this 0 will use the system-default, usually 64 MiB
# shm-size-bytes = 262144
shm-size-bytes = 131072
# shm-size-bytes = 65536
# shm-size-bytes = 32768

; resample-method = speex-float-1
resample-method = src-sinc-fastest

; default-sample-format = s16le
; default-sample-rate = 44100
; alternate-sample-rate = 48000

default-sample-format = s32le

# default-sample-rate = 384000
# alternate-sample-rate = 384000
default-sample-rate = 352800
alternate-sample-rate = 352800
# default-sample-rate = 192000
# alternate-sample-rate = 192000

; default-fragments = 4
; default-fragment-size-msec = 25

default-fragments = 2
# default-fragment-size-msec = 1000
default-fragment-size-msec = 500
# default-fragment-size-msec = 200
# default-fragment-size-msec = 100
# default-fragment-size-msec = 50

vi .pulse/daemon.conf

; shm-size-bytes = 0 # setting this 0 will use the system-default, usually 64 MiB

# shm-size-bytes = 128000000
shm-size-bytes = 64000000
# shm-size-bytes = 32000000
# shm-size-bytes = 16000000
# shm-size-bytes = 8000000
# shm-size-bytes = 2000000
# shm-size-bytes = 262144
# shm-size-bytes = 131072
# shm-size-bytes = 65536
# shm-size-bytes = 32768

; realtime-scheduling = yes
; realtime-priority = 5
realtime-priority = 99

; resample-method = speex-float-1
resample-method = src-sinc-fastest

; flat-volumes = yes
flat-volumes = no

; default-sample-format = s16le
; default-sample-rate = 44100
; alternate-sample-rate = 48000

default-sample-format = s32le

# default-sample-rate = 384000
# alternate-sample-rate = 384000
default-sample-rate = 352800
alternate-sample-rate = 352800
# default-sample-rate = 192000
# alternate-sample-rate = 192000

; default-fragments = 4
; default-fragment-size-msec = 25

default-fragments = 2
default-fragment-size-msec = 500

; enable-deferred-volume = yes
enable-deferred-volume = no

微妙な調整だけど、これでノイズはなくなった。 ハードによって最適な設定値が異なるようで、試行錯誤しながら詰めていくしかないようだ。
384kHz再生でのノイズはかなり減ったが残存している。だから352.8kHzのままだ。

音質は、PPAPの音とはDACも違うので比較してないけど、十分に使えると判断した。確かに300kHz台の音が出ている、という感じ。
本当は700kHz台で使いたいのだけど、pulseaudioの限界なのか、エラー表示が出てpulseaudio自体が起動しないので設定できない。これは機械を変えても同じだった。

ともかく、かなりやっつけな建て付けだがストリーミングを主力音源にする体制ができたと思う。

vi .pulse/default.pa

load-module module-alsa-sink device=hw:0,0
load-module module-udev-detect tsched=0
load-module module-detect tsched=0
load-module module-native-protocol-tcp auth-ip-acl=127.0.0.1;192.168.1.0/24

vi .pulse/daemon.conf

shm-size-bytes =64000000
realtime-priority = 88
default-script-file = /home/tc/.pulse/default.pa
resample-method = src-sinc-fastest
flat-volumes = no
default-sample-format = s32le
default-sample-rate = 352800
alternate-sample-rate = 352800
default-fragments = 2
default-fragment-size-msec = 25
enable-deferred-volume = no

pactl list sinks

Sample Specification: s32le 2ch 352800Hz
Properties:
 device.buffering.buffer_size = "1048576"
 device.buffering.fragment_size = "524288"

32*2*352800 = 22579200 (bps)
device.buffering.buffer_size (1048576) / 22579200 = 0.046439909 (50ms)
device.buffering.fragment_size (524288) / 22579200 = 0.023219955 (25ms) = default-fragment-size-msec

default-fragments = buffer_size/fragment_size = 0.046439909/0.023219955 =2

ストリーミング音源利用に際して懸案だった、CDレベル音源のlibsamplerateによるアップサンプリングが、一応出来たので、備忘録にしておく。

そこそこ梃子摺ったけど、出来てみればそんなに複雑でもない。
ただ、作業行程で何が足りないのか推測し繰り返し試みないといけなかったので時間がかかった。まあ、僕の手際が悪いんだけど。
なにしろ、ログを読んでも何が足りないとかいけないとか、簡単に分からない。基本的なlinuxの知識が少ないので、初歩的なことを書いているのに気付かず、躓いたまま苦心惨憺の後に気付いたり、ということが多々ある。気付くまでログのあっち読んだりこっち読んだり、あれやったりこれやったりになるのだ。はっきりエラーと明言されていない記述も注意する必要があって、気付いたらそんなことだったのかなんだけど。
そういうときは、もしかして、この記述が怪しいのかな、ポイントなのかな？という、感が頼りになってくる。例えばログの中に「capability」という言葉があって、capability？、、cap?、、libcapというのが要るのかな？、、という感じで追い込む。
コンピューターをいじってるのにそんなんでいいのかという感じだ。

最初はpiCore 9で試みたが上手くいかず、tiny core 64 11.1で作っている。
そもそも、本気でアップサンプリングするならraspberry pi2とかだと限界がある。
ともあれ、以下、手順の要約。

tiny core pure 64 11.1のインストール行程を最初からなぞるのは面倒だったので、PPAP Frontを作る際のベースに使って、バックアップを保存していたディスクイメージを使うことにした。これをSDカードに書込み、Compaq 6730bに刺して起動、sshでログインしbulseaudioサーバーの環境を作っていく。

まず、tceコマンドで足りないライブラリ等をインストール。
alsa関連を足りないことがないように拡充、libcap関連、dbus関連を追加。
あと、以下に経過を記録。

wget http://freedesktop.org/software/pulseaudio/releases/pulseaudio-13.0.tar.xz
tar -xf pulse*xz
cd pulseaudio-13.0

./configure --disable-x11 --enable-alsa --enable-samplerate
make
mkdir ../pulseaudio
sudo make DESTDIR=/home/tc/pulseaudio install

cd

mksquashfs pulseaudio pulseaudio-13.0.tcz
md5sum pulseaudio-13.0.tcz > pulseaudio-13.0.tcz.md5.txt

sudo cp *tcz* /mnt/*2/tce/optional
sudo vi /mnt/*2/tce/onboot.lst
(pulseaudio-13.0.tcz)

wgetでpulseaudio-13.0をダウンロード。
展開しディレクトリに入る。alsaとsamplerate（libsamplerate）は使えるように、x11は使わない設定で、インストール。
tczファイルなど作成し、optionalディレクトリにコピー、onboot.lstにOS起動時読み込みの設定を書き込み。

これで、pulseaudio-13.0をインストール終了。
この時点でのインストール済みのtcz一覧は、下記アドレスのファイルに記載。ずいぶん沢山入っている。本来なら要らないものも多く入っていると思う。
http://blown-lei.net/blog/pulseaudio-optional-tcz.txt
onboot.lstは下記のとおり。

less /mnt/*2/tce/onboot.lst

openssh.tcz
i2c-5.4.3-tinycore64.tcz
nfs-utils.tcz
alsa-modules-5.4.3-tinycore64.tcz
alsa.tcz
nmap.tcz
gcc.tcz
boost-1.65-dev.tcz
pkg-config.tcz
bison.tcz
autoconf.tcz
libtool-dev.tcz
bc.tcz
cmake.tcz
compiletc.tcz
squashfs-tools.tcz
ntpclient.tcz
libsamplerate.tcz
libsamplerate-dev.tcz
lame.tcz
lame-dev.tcz
libmad.tcz
libmad-dev.tcz
alsa-plugins-dev.tcz
alsa-config.tcz
alsa-dev.tcz
libcap.tcz
libcap-dev.tcz
dbus-dev.tcz
pulseaudio-13.0.tcz

こんな環境に出来上がった。
pulseaudioサーバーを設定していく。

mkdir .pulse
cp pulseaudio/usr/local/etc/pulse/default.pa .pulse
cp pulseaudio/usr/local/etc/pulse/daemon.conf .pulse

rm -rf pulseaudio*

ホームtcディレクトリに「.pulse」ディレクトリを作成。
設定ファイル「default.pa」と「daemon.conf」をソースからコピー複製し「.pulse」に設置。
インストールに使った残骸は「rm -rf」で削除。
設定ファイルの内容を、使用環境などに合わせて下記の通り変更。

vi .pulse/default.pa

#load-module module-native-protocol-tcp
load-module module-native-protocol-tcp auth-ip-acl=127.0.0.1;192.168.1.0/24

vi .pulse/daemon.conf

; resample-method = speex-float-1
resample-method = src-sinc-fastest

; default-sample-rate = 44100
; alternate-sample-rate = 48000
default-sample-rate = 192000
alternate-sample-rate = 192000

; default-sample-format = s16le
default-sample-format = s32le

以前のエントリーに書いたけど、module-native-protocol-tcpを設定することで、クライアントからの信号を受ける事ができるようになる。 src-sinc-fastestはlibsamplerateの設定。USB-DACの状況に合わせて記載。

filetool.sh -b
sudo reboot

設定を保存。リブート。

再度、sshでログインし、試用を開始。使えるリサンプラーを確認する。

tc@box:~$ pulseaudio --dump-resample-methods
src-sinc-best-quality
src-sinc-medium-quality
src-sinc-fastest
src-zero-order-hold
src-linear
trivial
speex-float-0
speex-float-1
speex-float-2
speex-float-3
speex-float-4
speex-float-5
speex-float-6
speex-float-7
speex-float-8
speex-float-9
speex-float-10
speex-fixed-0
speex-fixed-1
speex-fixed-2
speex-fixed-3
speex-fixed-4
speex-fixed-5
speex-fixed-6
speex-fixed-7
speex-fixed-8
speex-fixed-9
speex-fixed-10
ffmpeg
auto
copy
peaks
tc@box:~$ 

src-sinc-best-quality、src-sinc-medium-quality、src-sinc-fastest、と表示がある。
libsamplerateは使えるはずだ。

さて、鳴らしてみましょうか、、、「pulseaudio -D」で起動し、クライアントのfirefoxから音声信号を伝送する。
さっそく、音がでない。「top」を打つと、pulseaudioは仕事をしている様子。
状況は？

tc@box:~$ aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: IncRAL2496UT1 [RATOC Systems, Inc.RAL-2496UT1_], device 0: USB Audio [USB Audio]
  Subdevices: 1/1
  Subdevice #0: subdevice #0

tc@box:~$ pactl list sinks
Sink #0
    State: RUNNING
    Name: auto_null
    Description: Dummy Output
    Driver: module-null-sink.c
    Sample Specification: s32le 2ch 192000Hz
    Channel Map: front-left,front-right
    Owner Module: 13
    Mute: no
    Volume: front-left: 65536 / 100% / 0.00 dB,   front-right: 65536 / 100% / 0.00 dB
            balance 0.00
    Base Volume: 65536 / 100% / 0.00 dB
    Monitor Source: auto_null.monitor
    Latency: 206 usec, configured 500 usec
    Flags: DECIBEL_VOLUME LATENCY
    Properties:
        device.description = "Dummy Output"
        device.class = "abstract"
        device.icon_name = "audio-card"
    Formats:
        pcm
tc@box:~$

Name: auto_null、Description: Dummy Output、って、何？。
alsaはdacを認識しているが、pulseaudioは認識していない。
というか、クライアントから送られてきた信号が何処かに消えていくように設定されてるらしい。

原因は不明。多分何処かでミスってるのだろう。普通は自動的に読み込まれるのでハードの設定はpulseaudioではしなくていいものらしい。
しかしそんなことは言ってられないので、下記のように設定する。

vi .pulse/default.pa

#load-module module-alsa-sink
load-module module-alsa-sink device=hw:0,0

aplay -lで、「card 0: IncRAL2496UT1 [//], device 0: USB Audio」なので、hw:0,0だ。
これでどうか。

tc@box:~$ pactl list sinks
Sink #0
	State: RUNNING
	Name: alsa_output.hw_0_0
	Description: RATOC Systems, Inc.RAL-2496UT1_
	Driver: module-alsa-sink.c
（... 以下略 ）

一応、認識した、、、
pulseaudioを再起動して、信号伝送すると、、、音が出た。
ようやく一息、これで、なんとかなるのかな？

取り敢えず現状、音質は後回しで、ちゃんと運用できる事が優先なんだけど、いくつか問題が。

まず、192kHzだとブツブツ途切れるようなノイズが入って使えなかった。96kHzだと問題ないんだけど。
DACを変えたら、、、問題なくなったのかな？、、、
一応、384kHzで音は出るが700kHz台だと「Invalid sample rate '768000'.」とかエラー表示される。どうも微妙だ。
しかし、300kHz台が使える。
音は、、、
さすがに768kHzの深淵には及ばないけど、そこそこ良いんじゃないかな。
月にCD1枚程度の金額で、この音で聴けるなら、、、相当安いんじゃないかな。いや、、、使えますよこれ。

次に、ギャップレス再生ができない問題。これは、、、どうなんだろうね。
自宅NASの音源をmpdで聴いてきた限りでは、この問題は全く気にしなくても良かった。まあ、、、仕方がないのかな、、、

もうひとつは、クライアントPCにキャッシュが積み重なるようで、どんどんメモリが消費されていく。つまり、鳴らし始めのうちはいいけど数時間鳴らすとクライアントPCが不安定になるのだ。不可逆圧縮音源を使っていた時には、消費される容量が少なかったので、気付かなかったのだろうか。
しかし、8GB積んでるんだよ？
それが気付けば100%近く使用になりswapまで消費し始める。何にそんなに使ってるんだろう、、、firefoxを閉じると忽ち使用メモリ量は低下する。
一方、、、pulseaudioサーバー側は、ほとんどメモリを使っていない。

tc@box:~$ free
              total        used        free      shared  buff/cache   available
Mem:        3946904      239024     3592700       20636      115180     3440612
Swap:        959968           0      959968
tc@box:~$ 

何がどうなっているのやら。
素直にNode2iあたり導入するほうが楽なのかもしれない、、、（でもあれ、Linux用の操作アプリはないんじゃないかな、、、）
まあ、もうちょっと弄ってみましょうか、、、

弄れるかな、、、
弄れるかどうかはともかくとして、メインソースとして充分に使えそうなのが非常にありがたい。CD購入も減らせそうだ。

vi .pulse/default.pa

#load-module module-alsa-sink
load-module module-alsa-sink device=hw:0,0


### Automatically load driver modules depending on the hardware available
.ifexists module-udev-detect.so
# load-module module-udev-detect
load-module module-udev-detect tsched=0
.else
### Use the static hardware detection module (for systems that lack udev support)
# load-module module-detect
load-module module-detect tsched=0
.endif

#load-module module-native-protocol-tcp
load-module module-native-protocol-tcp auth-ip-acl=127.0.0.1;192.168.1.0/24

vi .pulse/daemon.conf

; shm-size-bytes = 0 # setting this 0 will use the system-default, usually 64 MiB
# shm-size-bytes = 131072
# shm-size-bytes = 65536
shm-size-bytes = 32768

; resample-method = speex-float-1
resample-method = src-sinc-fastest

default-sample-format = s32le
default-sample-rate = 352800
alternate-sample-rate = 352800


; default-fragments = 4
; default-fragment-size-msec = 25

default-fragments = 2
# default-fragment-size-msec = 500
default-fragment-size-msec = 200
# default-fragment-size-msec = 100
# default-fragment-size-msec = 25

9月初旬のエントリーで、Pulseaudioのエントリーを上げた。
http://blown-lei.net/endive/blosxom.cgi/audio_diary/20200906a.htm
Pulseaudioを使ってRaspberry piにAmazon Prime Musicを転送再生する

今回は、Pulseaudioについて、知見追加のメモ中心。
PulseAudio
https://www.freedesktop.org/wiki/Software/PulseAudio/

まず、アップサンプリングについて。
使っている音源はストリーミングサービス、ウェブプレーヤーからの256kbpsの不可逆圧縮とはいえ、するとしないでは音が違う。多少でも768kHz PPAPの音に近付けていかないと、僕のことだから最終的に飽いてしまいそうなので、試みないわけにいかない。
方法はサーバーの「~/.pulse/daemon.conf」に設定を以下のように書き込む。

; resample-method = speex-float-1

# resample-method = src-sinc-fastest
resample-method = src-sinc-medium-quality
# resample-method = src-sinc-best-quality

default-sample-format = s32le

default-sample-rate = 384000
alternate-sample-rate = 384000

1行目のspeexがデフォルト。下がlibsamplerateとその他の設定。
というはずなんだけど、libsamplerateは2015年頃に「意味が無い」ということになって非推奨になっていて、設定しても反映されない。
https://www.freedesktop.org/wiki/Software/PulseAudio/Notes/6.0/
実際、mediumやbestに設定しても、CPUの負荷が変わらない。「pulseaudio --dump-resample-methods」というコマンドで利用可能なリサンプラーを表示できるのだけど、libsamplerateはインストールしてあっても表示されない。
https://bbs.archlinux.org/viewtopic.php?id=217672
こちらのサイトによると「auto」でリサンプリングされているらしい。autoってなんだか分からないのだが。たぶんデフォルトの「speex-float-1」の設定になるのだと思うのだけど、はっきりしない。

それでも使わないよりは音がいい。
768kHzは設定できない旨が表示されて使えないので、384kHzにアップサンプリングして聴いている。
デフォルトの「speex-float-1」は、数値を上げるとぶちぶち音が切れる。2でもときに途切れるので、結局、1のままだ。「speex-fixed-1」でも悪くない。少し音の感触が変わる。好みで選択できる感じ。
個人的には、いずれはlibsamplerateを使えるようにしたい。他所では意味がなかったのかもしれないが、うちでは音がいいのだから。

アップサンプリングした結果、SM-SX100の光入力（44.1-48/16-32）は使えなくなった。
取り敢えずUSB-DACにSMSL M100を使っている。いつどういう経緯で入手したか覚えていない。RCA出力をSX100に入力している。

他にはリアルタイム化。daemon.confで設定。下記サイトを参考にした。
https://pulseaudio.blog.fc2.com/blog-entry-1.html
http://yougateau.blogspot.com/2019/11/pcmx-linux.html
https://wiki.archlinux.jp/index.php/PulseAudio#.E8.A8.AD.E5.AE.9A.E3.83.95.E3.82.A1.E3.82.A4.E3.83.AB
https://wiki.archlinux.jp/index.php/PulseAudio/%E3%83%88%E3%83%A9%E3%83%96%E3%83%AB%E3%82%B7%E3%83%A5%E3%83%BC%E3%83%86%E3%82%A3%E3%83%B3%E3%82%B0

; high-priority = yes
; nice-level = -11

; realtime-scheduling = yes
; realtime-priority = 5

high-priority = yes
# nice-lebel = -19
realtime-scheduling=yes
realtime-priority=99

「nice-lebel」は、なぜか、
E: [pulseaudio] conf-parser.c: [/home/tc/.pulse//daemon.conf:40] Unknown lvalue 'nice-lebel' in section 'n/a'.
と表示されてエラーになるので、コメントアウト。
音の透明感が出てきた気がする。

ここで、Deezer hifiに借り登録。
1ヶ月無料体験で、ウェブプレーヤーで44.1/16のロスレス音源を聴ける。
Tidal、Qobuzもウェブプレーヤーでロスレス以上を聴けるらしいんだけど、こっちは海外登録へのハードルが高い。

ロスレス音源を鳴らしたらどうなのかやってみたら、なんだか歪んだ感じでノイズっぽい。アップサンプリングしないほうがいい。
アップサンプリングなしだと、まっとうな音で鳴る。さすがロスレスで実直で至極まっとうな音ではあるんだけど、不可逆圧縮をアップサンプリングしたのより地味で残念だと思った。
まあ、派手じゃないけど、落ち着いて聴ける。
女房なんかはこっちのほうが音がいいという。
実際、CDリッピング音源をそのまま鳴らしたような音で、うち的にはポテンシャルを引き出せてない感じ。
上を目指せるのはこっちだ。ハードを改善したら問題なくなるのか、libsamplerateを使えるようにすべきなのか、その両方が必要なのか。

Deezer hifiのデータを転送してると、クライアントの6730bもギリギリっぽくて普段使いがややままならない。何か用事で触ると音が途切れることがある。古い機械だからな。
いろいろ考えないといけないようだ。

9月初旬に音楽ストリーミングサービスをPulseaudioで転送するエントリーを上げた。
http://blown-lei.net/endive/blosxom.cgi/audio_diary/20200906a.htm
今回は、その後の話だ。

以前から時々、Spotifyの無料サービスやAmazon Primeを普段使いのノートPCなどで鳴らすことはあった。
しかしメインのオーディオシステムで中心的な音源として使うことはなかった。今回は重い腰を上げての試みだ。

Pulseaudioでの転送だけど、当初は、amazon prime music、数日後から、Spotify Freeも使用開始している。 ともにFirefoxのウェブプレーヤーで鳴らしている。

音楽ストリーミングサービスの聴き方についてネットで検索しても、ウェブプレーヤーというのは殆ど出てこない。一般的な聴き方は、まずDAPやスマートフォン。次に受信能力を持つコンポがあって、そういう解説は多い。パソコンを使う場合、忽ちは専用アプリケーションという話になる。
ウェブプレーヤーは脇役だ。 しかし、Linux PCでも使えるという優位性があって、うちではここから入ることにした。

音は、あんまり良くなかった。
いろいろ聴いていると、もう少し高音質で聴きたいと思う音源がある。
そういうのは、、、CDを買ってしまった。
なんというか、こうなるんだっけ？、何かが違うという感じだ。
ストリーミングならこの程度で良かろう、とはならない。このままでは財布に負担で置き場もない、という事態になってしまう。

もっと本腰を入れて考えないといけないと思い、Amazon HDを3ヵ月間無料でお試しできるというので登録した。
Amazon HDは、CD音源やハイレゾのような高音質で聞くには専用のアプリが必要で、WindowsとMacしか対応していない。つまり、ウェブプレーヤーからだとUnlimitedと同等で不可逆圧縮音源ということだ。
それでも曲数が増えて、なるほど、見える世界が変わってくる。
音質は、ウェブプレーヤーの高音質設定が256kbps、ファイル形式はAACらしい。
amazon primeの時より音は良くなっている感じがして、意外に気軽に聴く分には十分以上な感じだ。

しかし、実は、自分が何処の段階で音質調整の設定をしたのかが、はっきりしない。
ウェブプレーヤーでは「ストリーミングの音質」を、自動、高、中、低、の4項目から設定できる。デフォルトは自動だったか低だったか、、、それを現在は高にしているのだけど、これがPrimeの段階で使えていたかどうか、記憶が定かでなく分からない。
ちなみに3ヶ月HD無料キャンペーンなので「HDおよびUltra HD」の項目も表示されているのだけど、グレイアウトしていてウェブプレーヤーでは設定できない。下記の説明が併記されている。

HDおよびUltra HD: HD音質の再生はウェブではサポートされていません。HDおよびUltra HD音質で音楽をお楽しみいただくには、デスクトップアプリを{インストール/使用}してください。

Spotify freeも3か月間無料キャンペーンでPremiumに変更。
こっちはウェブプレーヤーの場合、freeだと128kbps、Premiumだと256kbpsで、固定ということらしい。ファイル形式はAACらしい。

Spotifyには、Linux用にも専用アプリが用意されている。こちらはファイル形式はOGGで、最高音質（320kbps）の設定ができる。
しかし、残念ながらpulseaudioによる音声転送が出来なかった。止まってしまって音が出ない。ノートPCローカルで音を出す分には鳴るけれど、それでは最高音質で鳴らす意味が殆どない。
結局、amazon同様にウェブプレーヤーで聴いている。

あれこれと書いておいて、なんなんだけど、ストリーミングの音質、ビットレートなどを調べるのが何故かすごく分かりにくかった。
あちこち調べて、断片的な情報から書いている。
調べ方が悪いのかもしれないが、こんなことはストリーミング提供元のサイトのすぐに見つかるところに書いてあるべきだと思うけど。
そのうち、信頼に足りそうなソースがあったら追記するつもりだ。

さて、ここで問題が出てきた。
同じ256kbps？でも両者の音にかなりの違いがある。
spotifyが、amazonより地味で埃っぽいのだ。いろんな音源で聴き比べたけど傾向は同じで、何が影響しているのか、、、

一方、Amazonのほうは、言い方が悪いけど、音が良すぎる。
うちではNASに保存した不可逆圧縮音源（10数年前にiTunes Storeなどからダウンロード購入した音源が多い）をメインシステムで聴くことがあって、不可逆圧縮音源はこんな音で鳴るだろうという個人的イメージがあるのだけど、それを越えた音がする。
ウェブプレーヤーが何かしている？、、それとも音源か？、、他にも条件が違うところはあるけど、、、

こういう話は聞いたことがない。
分からないなりに、topコマンドを打ってみた。
Amazonで聴いてる時は「Web Content」の%CPUが、35%前後。
Spotifyで聴いている時は、25%前後。
少なくとも、負荷は違うらしい。
あと、プレーヤーが表示されているウィンドウで他のタブを開くと（ウェブプレーヤーが背後に回って非表示になる）、Amazonのほうは%CPUが25%まで下がる(音質は変わらない)。Spotifyのほうはというと、数%下がるだけだ。
ということは、インターフェイスの表示に使っているものが違うということか。

表示の違いが影響するということなら、OS画面表示の方式を変えてみようと思った。
Fedora 32は、アカウントのログインに際して、画面表示の方法を選択できるようになっている。
１つ目がGNOME（Wayland）、２つ目がGNOME classic、3つ目がGNOME on Xorg。
うちでは普段は、1つ目のWaylandで使っていた。いったんログアウトし、3つ目のGNOME on Xorgに変えて再ログイン、Spotifyのウェブプレーヤーを使ってみる。
音が良くなった。
amazonと同等かも？
正直、こんなに変わるとは思ってなかった。
topコマンドを打ったら「Web Content」の%CPUが45%前後に上がっている。ここでプレーヤーが表示されているウィンドウで他のタブを開くと、%CPUが20%前後まで下がる。
一方、amazonのウェブプレーヤーの音には、大きな変化は感じられない。%CPUも40%弱で変化が少ない。他のタブを開くと、%CPUが25%程まで下がる。Waylandのときとほぼ同じかな。

アプリによって音が変るというが、同じFirefox上のウェブプレーヤーでも、提供元によって音が違うという事が分かった。
あと、OSの状況がウェブプレーヤーの挙動に影響するということも。
考えてみたら、そんな事が起き得るのは十二分に想定可能なことだ。しかしこれは、思った以上に複雑で難しいね、、、
そんなこんなで、ストリーミングサービスによる音の違いがどの程度あるのか、ぼちぼちと聴いてみようかなどと思っている。

しかし、、、なんというのだろう、、、 最初のうちは、想定以上にストリーミングの音がいいので有り難いなあ、とか思っていた。
それが、段々、集中して聴くには物足りない部分もあるけど、気軽に聴く時の音源としてなら問題なさそうかな、とか。

今後、CDレベル、ハイレゾレベル音源のストリーミング利用を考えていくのか。
分からないことが多い。この方面では完全に初心者なので、急がずに考えようと思う。取り敢えず、現状で回していく。

それでも良かったのは、2020年リアルタイムのポップミュージックに多く触れることが出来たこと。今の音だという実感が得られた。本当に久しぶりに、最新型のポップを追いかけようかという気持ちが芽生えたような気がする。実際にどの程度できるかは分からないけれど。