abk1's scratched blog 3

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

思えば、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の仕様で出来ないようだ。

最近のシステム構成は下図のような感じ。

8月にSM-SX100が修理から戻っている。ピンチヒッターだったBrooklyn Ampも使っている。
アンプセレクターにORB MC-S0 NOVAを導入した。
こんな構成になるとは以前には考えもしなかったけど、苦肉の策というか必然的にというか、上手く嵌っているとは思うのだけど。

SM-SX100の上流は、768kHz/32bitのPPAP（piped pcm audio play）方式。
今年の春から運用している構成だ。自分で書いてちょっと驚く。もっと昔から使っていたような気分なのだけど。
音声データの流れは下記の通り。

SX100は修理ですっかり回復して、なんとなく音も良くなったかのような気がする。傷んでいたセレクターのリレーなども替えたので、それも良かったのかもしれない。
700kHz台を鳴らすならこっちの方がいいかなという感じ。

Brooklyn Ampはストリーミングサービスの音源を再生するのに使っている。
ストリーミングサービスを比較的まともに鳴らせるようになったのは最近だ。
音声データの流れは下記の通り。

8月の時点で、Brooklyn Ampの音色についてSX100に近付いてきていると書いている。
上流の条件が変遷してきているので単純には言えないのだけど、情報量は感覚的にはSM-SX100の97～99%ぐらい？というのか、遜色ない程度に出るように思う。以前は埋もれる傾向だった微細な音も聞こえるようになった。SX100よりも暖色系で音源を選ばない傾向は変わらない。

普段使っているhp ProBookのFirefoxで再生するストリーミングサービス音源のデータを、Pulseaudioで転送してメインシステムでアップサンプリングして鳴らしている。以前はノイズを生じることが多かったが、今のところ1週間に1回ぐらいになった。まだ完璧ではないが、ほぼ不満なく使えるようになった。

SX100が帰ってきた当初は、2台のアンプをとっかえひっかえ使っていた。Brooklyn Ampを中古屋に売る気になれず、仕舞い込むのは勿体ない。一時はサブシステムの方に廻したけど、あまりにも役不足感が半端なくて辛かった。
一方で、ストリーミングサービスの運用検討も同時並行で行っていた。こっちはこっちで300kHz台へのアップサンプリング運用が出来そうだったが、700kHz台まではpulseaudioは対応していないので出来ない状態だった。 これらを、どう組み合わせるか。

２つの上流からの入力を使い分けるのに、当初はSX100のプリ機能を使うことも考えていた。
SX100のXLR入力はPPAP系で埋まっているので、ストリーミング系はRCA入力を使うことになる。しかしM500のRCA出力をSX100で聴いていると、どうも物足りない感ばかりが募る。もともとM500はXLR出力の方が良くてRCAは細身になるし、700kHz台より300kHz台は情報量も劣る。700kHz台、ADI-2 DACのXLRの音と比べて、見劣りする音という印象しか残らなくなる。
そんなときにBrooklyn Ampを試してみたら、XLRを使うことが出来るし、300kHz台の弱点をカバーして鳴らしてくれる。言ってみれば違う土俵の音になるので、比べてどうこうという気持ちにも全くならずにストリーミング音源を楽しんで聴ける。
そういった経緯で、上流に合わせてアンプを切り替える方向性が図らずも確定していったと思う。

アンプを換えるのにスピーカーケーブル抜き差しを繰り返すのは手間だったので、試しに手持ちのセレクターを使ってみることにした。5年前にamazonで買った5000円ぐらいのプラスチック製の製品で、今となっては購入動機は不明。
https://www.amazon.co.jp/gp/product/B00KLWOCBU/
これが意外に使えた。この程度でもそこそこ使えるんだな、と思うぐらいの音が出た。
しかし長く使うには音質劣化が気になってくる。情報量がやや減るのもあるんだけど、それよりも抵抗を通したような若干くすんだ音色になるのが問題だった。うちのシステムは透明度が高い音が出る。そういう美質がスポイルされる。長期間使う気にはなれなかった。
考えてみたら、スーパーツイーターのネットワークからアッテネーターを排除したのも透明度が落ちるという理由からだ。僕のオーディオで最も外せないポイントはここなのかもしれない。

セレクターは自作しようかとも思ったんだけど、問題が無いレベルのものが作れるかどうか自信がない。作った結果が5000円のよりも悪かったら、、まあ、それも勉強にはなろうけど。
この際、力を入れて作られた製品を聴いてみようと思ってORB MC-S0 NOVAを入手した。
ORB Audio / MC-S0 Nova
https://www.orb.co.jp/audio/products/mcs0nova.html
ネット通販で注文してから届くまで1週間ほど。
アンプからセレクターまでの接続には1.6mmのVVFにバナナプラグを半田付けして使用している。
使ってみての印象は、音質劣化は無い、というか聴き取れない。音色がやや深みがある方向に変わる。これは多分、NOVAの重量、造りが効いているのだと思う。個人的には好ましい変化だと思った。製品自体にそれなりに高級感があって、正直、使ってみて感心しているところがある。
出音には文句がなく自作の必要は無くなった。

Brooklyn Ampはパワーアンプなので音量調整機能が必要。
XLRアッテネーターにBehringer MONITOR1を使っている。
MONITOR1 ベリンガー公式
https://www.electori-br.jp/products/625.html
こちらも音の劣化は無いように思う。ボリュームノブの動きがスムーズで、大きくて扱いやすく使用感が良い。これが5000円前後で売られているのは脅威的CPだと思う。
ストリーミングも音源によって適正な音量が違ってくるが、Web Playerのボリュームは基本100%で使用し、微調整にMONITOR1を使う。音量調整するためにはコンポのところまで歩かないといけないのだけど、まあ、しかたないだろう。
大雑把な調整が急に必要な時はWeb Playerの操作で事足りる。

ひそかに気になっているのは、Web PlayerがPulseaudioサーバーに転送しているflac由来のデータは、ビットパーフェクトなのだろうか、ということなんだけど、確かめる術を知らないので気にしないことにしている。DeezerはCDと同等と謳っていることだし。

サブシステムのほうも若干の変化がある。

Mac mini、M100が追加になっているのは、ここからAmazon Music HD（現在、3ヶ月のお試し期間中）のハイレゾ音源を出力再生するためだ。
意外に、こんな安普請なシステムでもHD音源やSuper HD音源のほうが音がいいのが分かる。
本当はメインシステムで鳴らせる方がいいんだけど、データを送る方法が見つからないので、とりあえずサブシステムで鳴らせるようにしたということだ。

Windows用のAmazon Music AppをLinux/Wineで使おうとしてみたけど、上手くいかなかった。
MacからLinuxにデータ転送できるようなら、メインの音源の１つとして使えるかもしれないけど、そこまでは手が回らないか。

最近、サブスクストリーミングサービス利用の比重が高まっている。
なにしろ新しい音源を次々漁る方向についつい行ってしまうというのがある。その要因として、ストリーミングの音質がそこそこ良いからというのがあったりするようだ。

音が良くなかった頃は、あれこれと次々に聴いて回るという使い方は、出来たらいいとすら思わなかった。気になる音源があったときにフリーのストリーミングサービスでちょっと確認する、というような聴き方で終わっていた。
それが、今の音質で出来るようになったら、中心的な使い方になってしまった。
そのうち飽きるだろうか。どうだろう。

それにしても、結局、音が良くないと使わないということだ。
音が良くなくてもいいというのには簡単には戻れないと再認識している。

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

今回は、時代の変化に付いていけない人間が違和感について書いている。
久しぶりにNoCCCDのカテゴリーでアップしたのは、ここにアップするのが相応しかろうと思ったからだ。

まず、気楽な話から。
ストリーミングサービスだとライブラリが作りにくいということ。

ストリーミング再生では、画面に表示されているものから選択するか、自分の意識に上がっている選択肢を検索して聴くことになる。
新しい音源を探して直ぐ聴く分には便利至極だ。そして気に入った音源があれば、それを「お気に入り」に登録することでライブラリ化することはできる。

だけど、本格的で使い易いライブラリとして構築するのは根気がいるし複雑な作業で難しい。
今現在、そういう作業を進めているんだけど、先が長そうで途方に暮れる。
なんというか、ただ詰め込んだだけでは日常的に音楽に接する使用に適した音楽用ライブラリにはならない感じがする。 そういうことしてる人って、どのぐらい居るんだろうか。
スマートフォンで流行を囓るように聴いて、忘れてしまっていいのなら、ライブラリなんて要らないけど。
こっちは衰えつつある記憶力を補完してくれるライブラリが欲しいのだ。

以下、一般的ユーザーを想定して考えてみる。自分はちょっと一般的じゃないから。
ライブラリが欲しいと思ったら、どうするか。

スマートフォンの画面で構築するか。
お気に入り頼りのライブラリは、ないよりはずっといい。記憶頼りの補完にはなるけど、画面が小さすぎるのがちょっと辛い。
音源をダウンロードしたらライブラリになる？
ストリーミング音源のダウンロードは、基本的にライブラリ構築のためではなく、電波状況が悪いところでの使用などを想定している。micro SDカードの容量こそずいぶん増えているが、何時壊れたり紛失するか分からないし、やはり機械の操作画面が小さすぎて、扱いが難しい。

じゃあ、パソコンで使うのか。うちでの基本的な使い方だが。
操作画面は大きくなるが。
しかし画面が大きいから快適かといえばそうでもない。Web経由だからかどうか分からないけど反応や動作が遅いのだ。
うちのmpdサーバーのライブラリと比べたらだけど。あ、cuiだから速くて当然か。一般的にはこんなものなのかな、、、
そこで、最近の若い人たちのパソコン離れという話を思い出す。
パソコン自体を持ってないということは、考えてみたら、携帯プレーヤーの音源もバックアップできないのだ。アカウントさえあれば、ハードを無くしても問題ないというのであれば合理的だけど。

CDを買う？
今更？
海外ではCD自体がリリースされないケースも多いという。ユーザーはプレーヤー自体を持ってないし、パソコンがないとリッピングもできない。

じゃあ、いっそのことアナログだ。
本棚にずらりと並んだアナログディスクは、個人のライブラリそのものだ。検索して探すのではなく、並んだ音源を見比べて聴きたい物を選ぶ事ができる。
選択肢を眺めながら、ときに見比べたり、流し見たり、記載を読んだり、何か思い付いたり、気分次第で五感を使って選ぶことは、検索ウインドウに何か打ち込んで提示された選択肢から選ぶこととは、全く違う自由度がある。
やっぱり時代はそっちなのか？

ストリーミングとアナログが主流になるというのは、そういう感じでそうなるのかな、というイメージに帰着した。
つまりユーザーの選択というより、そっちに流されているんじゃないかという。
結果、僕には多少不便な感じ。

ライブラリの問題はRoonとか使ったら違ってくるのだろうか。
かもしれないけど、ストリーミングはtidalとQobuzしか対応してないようだ。
まあ、なんとか使いやすい手法を探していくしかないだろう。

次、ストリーミングサービスの音源管理がいい加減すぎる。
先のライブラリが作りにくいという話とも関連するかもしれないけど、サービス側の音楽データ管理が杜撰だ。

例えば、サイモンとガーファンクルのアルバム。
phile-webで間違いが指摘されていて、amazon musicに見に行ったのだけど。

一見、デビューアルバムだが、収録曲が違っている。
実体はベスト盤「The Definitive Simon and Garfunkel」で、クレジット表示やアートワークがデビューアルバムのものになっているようだ。デビューアルバムだと思って聴いた人は仰天するだろう。知らない人が初めて聞いたら、そういうものだと思い込んで何処かで恥をかくこともあるだろう。

この事態をamazonのチャットに書き込んだら、対処するとの返事はもらったが、部署が違ったみたいでもあってか、その後の音沙汰なし。11月7日、amazon musicのヘルプをクリックしたら「Amazon Music のフィードバック」という通信欄が表示されるようになっているのを発見。

そこから以下の文面を送信してみた。

コンテンツの表示に間違いがあります。
具体的には、下記アドレスで表示される音源です。
https://music.amazon.co.jp/albums/B013099KM6

「Wednesday Morning, 3 Am」と表示されていますが、実際は「The Definitive Simon & Garfunkel」というベスト盤の音源と思われます。
訂正が可能なのであれば、したほうが良いと思われます。
知らない人は、誤解したまま音源を聞くことになります。

はたして訂正されるだろうか。
ちなみに上のS and Gの画像は、11月8日にチャプチャーしたもの。

ということで、ここまでは単なる愚痴だ。

どうも最近、ストリーミングサービスの在り様自体に不信感を抱くようになってきている。

サイモンとガーファンクルの件はアーティストは間違っていないので、まだ問題は小さいかもしれない。
検索すると、同名異人のミュージシャンが一緒にされている例が見られる。
区別がつくならまだいいんだけど、簡単には区別がつかないことも多い。
表示画面にミュージシャンや音源の情報自体が少ないのだ。同名のものがあったときに区別、判断するには名前以外の情報が必要なのに、それが殆どストリーミングサービスの画面には併記されていない。

このキャプチャー画像は、10月21日に取得したもので、amazon musicで「Ride」というバンドを検索し、ディスコグラフィを表示した画面。
一見何の変哲もないが、左下の「Preface」という作品は、同名異人のミュージシャンである。
Spotifyのほうでも以前は同一アーティストの作品として表示されていて（その後、別になっている）、僕は聴いた後におかしいと思って調べて、別人らしいと気付いたのだ。
キャプチャー画像には、他にも関係がないと思われる音源が表示されている。

次の画像も10月21日に取得、Deezerで「The Big Pink」というバンドを検索し、ディスコグラフィを表示した画面。
これも左下の「Plays the Band」という作品の得体が知れない。
タイトルだけ見たら、The Big PinkがThe Bandをカバーした作品に見える（そんなことがあったら、すごく意外だけど）。
ネット上を軽く調べただけでは、来歴がはっきりしない。再生回数だけで言えば、一部の他のBig Pinkの作品の再生回数よりも上位に食い込んでいる。
そりゃあ、新譜かなと思ったら聴く人もいるだろう。
再生されたということは、それに見合っただけの金額が、この音源をここに置いた何者かに支払われるということだ。

それにしても、何者だ？
ネット検索で引っかかった。
The Big Pink-The Last Waltz Tribute
https://www.facebook.com/BigPink13/

なるほど、、、実際、The Band関係なら再生回数が多いのもむべなるかな、、、なのかな？
しかし、だったら別のミュージシャンとして登録されているべきだよね。
関連アーティストにThe Bandは出てこない。
いや、、みんな、分かって聴いているのかな、、、
そもそも、The Big Pinkと、このトリビュートバンド、アートワーク写真の風体も音も違いすぎるもんな、、、
違いすぎたら、おかしいと思うけど、違和感がなかったら気付かれないかもしれないということだ。

こういうネットニュースの記事もある。
2020年09月23日 Spotifyを悪用して全く無名のアーティストが再生回数を稼ぎまくる方法とは？
https://gigazine.net/news/20200923-cheater-make-money-spotify/

記事の記載を引用すると「Spotify上では「Relaxing Music Therapy」や「Pro Sound Effects Library」、「Yoga」といった奇妙な名前のアーティストの曲を、1カ月当たり数十万人ものリスナーが聞いているとのこと。」と書かれている。
要は「手軽に使える音源」へのニーズが一定数あって、それで稼いでいるということだ。そういうことは、起きるべくして起きていると思う。

この記事を読んで、余計な考えが浮かんだ。
同名異人ミュージシャンがいっしょくたに陳列され、どれが誰の作品なのか分からないように表示される環境で、誰がどのように意図してどんな風に利用しようとしたら何が出来るのか。
こういうことは多分、例に挙げたケースやGigazineの記事の内容に限定されたことではないのだろうと思う。

更なる問題は、これが現在のミュージックコンテンツ配信の主流ということだ。

そんなこんなで、音楽のストリーミングサービスとは何なのかという気持ちが生まれている。
誰でも音楽で稼ぐことが出来るって、こういうことじゃなかったと思う。
少なくとも、僕が若い頃、子供の頃から慣れ親しみ、夢中になってきた音楽とは、在り方の様相が違うと感じている。レコードやCDのように小遣いで音源を買ってきて、鳴らし方も簡単で、単純に楽しめるという物では無くなった。

え？、スマホで簡単に聞けるって？
それはそうだけど。
なんかね、すごく違うんだよ。
簡単に聴けるというのと、安心して聴けるというのは違うんだよ。

たしかに、簡単に気軽にいろんな音源が聴けて、音源の貯蔵庫としては滅茶苦茶に巨大になっていて、恩恵も受けている。
でも、こんなんで大丈夫なのかな、という気持ちになる。
大事なところが蔑ろにされているんじゃないのか、という気持ちは、ダウンロード配信が始まった頃にも感じたのだけど（一番大きかったのは、この頃もクレジットの多くがが欠如してるということだった）、あの頃よりも強く感じるようになった。それは個々の音楽家の責ではなく、ストリーミングサービスのあり方が生み出した現状に対して感じるものだ。
音が鳴ればいいってもんじゃないんだよ、というか。
不正の温床じゃないのこれ、というか。
どこに金が行くかとなると、この時代、冗談ではなくなってくるというか。

音楽ストリーミングサービスとどう付き合っていくのがいいのかな。
割り切って聴かないというのもありだけど、せっかく手を付けたのに残念な気もするし。

とりあえず、クレジットを真っ当にするところから改善があればいいんだけど。
正確で詳細なクレジットがコンテンツに付いているというのは、不正を防ぐ第一歩だと思うからだ。

前のエントリーで、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月から定額制音楽ストリーミングサービス利用への対応を試みている。検討しやすいように、サービスの一覧表を作っておこうと思った。
あれこれ調べても何処かに記録しておかないと忘れてしまう。
間違いに気付いたら随時修正するつもり。
しかし、放置するエントリーになるかもしれない。

Nuvola Player
https://nuvola.tiliado.eu/

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

今回のエントリーは、音楽とどう向き合うか、という話だ。
オーディオも関係してくるけど、たいした内容はない。
他人にはどうでもいい話だ。

僕は中学の頃からラジオでポップミュージックを聴き始めた。
高校でビートルズに嵌ってプログレ、レッドゼッペリン、パンク、大学に入った頃にインディーズブームがあり、それからは最新のポップミュージックをずっと追いかけていた。
オーディオセットがましになってからは、クラシックやジャズなども聴いていたけど、メインの音源はロックなどポップミュージックだった。

それが、あの311以降、がらっと変わってしまった。
新しいポップミュージックを聴かなくなったのだ。
昔から追いかけているミュージシャンの作品は入手するが、新人はほとんど聴かなくなった。

この心境、志向の変化は、うまく説明できなかった。
災害当初は、新しい音楽なんか聞いていられるかという気持ちだった。それならば分からなくもなく、そのうち聴く気になるかなあ、などと思っていたんだけど、その後、年月が過ぎても、聴く気になれない。

では、手持ちの音源ばかり聴いていたのかというと全くそんなことはなく、主に新たに入手した音源を聴いていた。
クラシックの比率は大幅に増えた（これはオーディオシステム上流の改善に牽引されたと思う）。ポップミュージックは、聴いたことがなかった過去のミュージシャンが中心で、特に多かったのは安価なCDボックスセットで販売されているものだ。
つまり、クラシックが増えたとはいえ、ポップミュージックもあれやこれやと聴いてはいたのだ。逆に最先端中心に追いかけていた頃より、幅が広がったかもしれない。

10年経っても、最新のポップミュージックは聴く気になれなかった。
飽きたんだろうか。
年をとって付いていけなくなった？
なんというか、聴いたら面白いと思う瞬間はあるんだけど、なかなか追いかける気になれないのだ。
じゃあ、ストリーミングで十分じゃない？
、、、、、、

ここ数年、ストリーミングが音楽配信の主流になったと言われている。そこそこ良好な音質で聴ける環境も整ってきているらしい。
CDは古いのだそうだ。
新しい音源は、ストリーミングじゃないと聴けなくなるのかもしれない。
最近聴いているのはクラシックが多いけど、クラシックだって多分そうなるんだよ？ひと月に千円とかなら安いじゃないか。だいたいCD置く場所、なくなってるじゃないの。

しかし、だ。
そういう理屈は分かるけど。
全くそっちに行く気になれなかった。

今回、Amazon Prime Musicがある程度まともに鳴るようにセッティングしてみようと思ったのは、僕にとってストリーミングがどういう位置付けになるのか、試してみないことには分からないと思ったからだ。

やる気が起きないからと手を付けなかったら、たぶんずっとこのままだ。
HDとかUnlimitedとか、高音質や曲数が多いのもあるけど、無料で試せるのは短期間で、とてもじゃないけど見極められない。
そんなわけで、まずはPrimeで良かろうと割り切って手を付けてみた。
曲数なんて大して問題にならないだろう。ストリーミングは最先端ばかりではない。古くてCD入手困難な音源がしれっとおいてあったりもする。もちろん無い音源も多いけど、聴いたことがない音源には困らない程度の量はある。

だが、そんなにあれこれ聴こうという気に、自分はなるのだろうか。

昔は、とにかく広く浅く大量の音源を聴こうとしていた。聴いたことがない音楽があるということ自体が聴く理由だった。
何時頃からか、そんな無闇なやり方とは折り合いをつけて、今はずいぶん様変わりして物理的時間的限界で量を聴けなくたって別に困らない。
そうはいっても、興味がある音源があれば入手しようとするのだけど。

最近は何に興味が？
改めて考えてみたら、、、気が付けば、高音質音源だ。

先日、アンプが故障して痛感したことがある。
僕は良い音で鳴ってるオーディオがないと、もたないようだ。
短期間なら音が良くなくてもいいが、長くなると息が切れたような気分になってくる。不足感が半端ない。そしてたぶん、音が悪いなら聴かない方がマシだ、というようなことに、最終的にはなりそうな気がしたのだ。
高音質な音源は、鳴ってるだけでも気持ちがいい。癒される。どういうんだろうね、まるでドラッグ、依存症だ。

昔、僕にとって、世界と音楽は重なり合って存在するものだった。いや、音楽は世界につながるためのプラグの一つだった、というべきか。世界を音楽で彩ることで、僕は世界の中で息をしていた。
それが、最近そういう感覚がない。
311以降、世界と音楽は、僕の中で切れてしまった。
僕自身が、切ってしまったのかもしれない。
あの数年後、僕はツイッターに「伝説を語ることが空々しく感じられるけど、歴史に触れることには逆にリアリティがあるような気がする」とツイートしている。そんな感じで過去のポップミュージックばかり聴いていたんだね。

そして、切れたままなのだ。
僕から見える世界は、この10年で、ずいぶん変わってしまったと思う。こんな世界を彩ることが出来る音楽を、僕は見つけられなくなったのかもしれない。
まあ、それでも息をしていられるようになったということだけど。

だから別にそれでいけないことはない、とも思う。
昔の僕にとって音楽は空気や水のようなものだったが、今の僕にとってはドラッグだということだ。はたから見たらやってることはほとんど同じで、見分けがつかないだろう。
それが僕にとって問題なのかといえば、大した問題ではないっちゃないので、別にいいっちゃいいんだけど。

それとは別に。
音質希求の方向性は、オーディオシステムに影響する。
何が言いたいのかというと、つまり、ストリーミングは現状、768kHzにアップサンプリングできないのだ。

ストリーミング音源ではそれが出来ない。
僕にそのスキルがない。
そうした音源が主流になっていくとき、どう僕の中に位置づけるのかということになる。
昔は今ほど音質は大きな要素ではなかった。
今はそうではない。

ふだん、パソコンで音源を鳴らして平気でいたりすることもある。カーオーディオは現状の音質で全く不満がない。
しかしそれは、メインに高音質なオーディオがあるからこそ一時的に我慢できるのであって、それがなくてパソコンでしか聴けなかったら、車でしか聴けなかったら、、、
僕は聴くのをやめるだろうか、それとも、聴き続けるだろうか。
聴き続けるとしたら、何を聴くだろう。
それは世界を彩ることができる音楽なのか。それとも、もっと違う聴き方になるのか。

Prime MusicをPulseaudioで鳴らしてみようなどというのは、そういう疑問に対する一種の足掻きということだ。
そんなこんなで、うちでもストリーミングの利用が本格化？しつつある。今回のエントリーは一種の定点観測記録のようなものだ。
次回は、ストリーミング自体について、オーディオ中心の話になる。

いや、、、思った以上に、ストリーミングって、オーディオ的にも面白いね。

今回はPulseaudioを使ってみたという話だ。
実は、Pulseaudioで音楽データを転送するというのは数年前にも考えたことがあって、でもスキル不足で実現していなかった。
今回、何故そんなことをしたのかというのは省略。
運用のノウハウだけ記録しておこうと思う。

参考にしたサイトのアドレスは以下の通り。他にも見たけど忘れた。

https://www.alprovs.com/wordpress/?p=439
https://penkoba.hatenadiary.org/entry/20130809/1376064438
http://bluewidz.blogspot.com/2018/04/oslinux-virualboxdebian-8.html
https://www.it-swarm.dev/ja/pulseaudio/

用意したもの。

1. 普段使いのノートPC、Compaq 6730b。
   OSはFedora。既にPulseaudioはインストールされていて、クライアントとして機能させる。
   FirefoxでAmazon Prime Musicにログインし、音声データをPulseaudioサーバーに送信する。

2. Raspberry Pi2。
   OSはpiCore9.0.3。Pulseaudioサーバーとして動かす。Amazon Prime Musicのデータを受けて、usb dacに送る。

3. usb dacはRATOCのRAL-24192ut1を使う。
   RCA出力をオーディオテクニカのAT-SP150 bkで受ける。

こんなイメージ。

まずサーバーとなるRaspberry pi2をセッティングしていく。
ダウンロードしたpiCore9.0.3をmicroSDカードに書き込む。今回はusb dacしか使わないので「config.txt」を下記のように設定して、dtparam=i2c、spi、i2s、本体のオーディオ出力の使用を止めている。そうすることでalsaが認識するオーディオ出力がusb dacに固定されるメリットもある。

# Enable peripheral buses
dtparam=i2c=off,spi=off,i2s=off

# Enable onboard audio
dtparam=audio=off

カードをRaspberry Pi2に刺して起動。
sshでログインし「filetool.sh -b」を打つ。「sudo fdisk -u /dev/mmcblk0」でパーティションを拡張。リブート。
再ログインして「sudo resize2fs /dev/mmcblk0p2」で拡張したパーティションを固定。
vi /opt/.filetool.lst で「usr/local/etc」を追加。
filetool.sh -bで保存、で準備完了。
このあたり詳細は過去のエントリーで繰り返し書いているので省略。

pulseaudioとalsaをインストール。
最近は「tce」コマンドから項目を選択してインストールすることが増えた。
pulseaudio.tczのインストールとalsa-utils.tczのインストールの操作だけで完成する。実際にはこの2項目の他にも必要なtczが同時に多数インストールされる。

tceコマンドで表示されるpulseaudioの説明から引用。

howto:
alsa needs to be working for whatever sound device you have.
Create dbus entry for booting into X
$ echo 'dbus-launch --sh-syntax --exit-with-session' > ~/.X.d/dbus
$ /usr/local/etc/init.d/dbus status [Check dbus is running]
If not running, start dbus with
$ sudo /usr/local/etc/init.d/dbus start
If dbus was not, initially running, add a command to start it next reboot
$ sudo echo '/usr/local/etc/init.d/dbus start' >> /opt/bootlocal.sh

exit to console
startx
$ pulseaudio -vv [to test]
When it is running correctly
echo "start-pulseaudio-x11" > ~/.X.d/pulseaudio

if a bluetooth sound devices is paired and configured, pulseaudio should find it automatically if the daemon is running

dbusが動いていないとpulseaudioは動かないらしい。
/usr/local/etc/init.d/dbus status で確認したところ、動いていない。

sudo /usr/local/etc/init.d/dbus start で動く。
下記コマンドで、OS起動時にdbusが動くようにbootlocal.shファイルを編集、設定。
sudo echo '/usr/local/etc/init.d/dbus start' >> /opt/bootlocal.sh

今回、~/.X.d/dbusの設定はしていないが、問題ないようだ。

次にpulseaudioの設定。

ホームに.pulseディレクトリを作成。
ここに設定ファイルのdefault.paをコピーする。
この設定ファイルの中の「load-module module-native-protocol-tcp」に、上記のように記述を書き加えることで、ネットワークからのデータを受けることが出来るようになる。
192.168.1.0/24の部分は、各自のネットワーク環境に合わせる。

一応、alsaの状況を確認。「aplay -l」でusb接続しているDACが確認出来たら問題ないだろう。
filetool.sh -bで、dbusとpulseaudioの設定を保存。
これでサーバー完成。
デーモンとしてpulseaudioを起動するときはsshから「pulseaudio -D」、終了には「pulseaudio -k」。

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

これで、このターミナルウィンドウから起動させるプロセスが、赤字のアドレスのpulseaudioサーバーに音声データを伝送するようになる。つまり、赤字の部分はRaspberry Pi2のipアドレスということだ。
同じターミナルウィンドウからコマンドを打ってfirefoxを起動させる。

firefoxが起動したら、amazonにログインし、prime musicの音源を鳴らせばいい。このfirefoxが出力する音声はlanを通じてRaspberry Pi2に転送される。うまくいけばusb dacから音が出る。

注意点としては、ネットワークが遅いと音がぶちぶち途切れる。うちでは6730bの無線lanが遅すぎて音楽にならず、有線100Base-Tでつないだら問題なく鳴るようになった。
ちなみにRaspberry Pi2の出力フォーマットを確認したところs32le 44100で、そこそこのデータ量がある。6730bのネットワーク出力をモニターしてみたら、400KiB/s前後でデータ転送されている。
youtubeの音源だとどうなるか確かめたら、s32le 48000。サイトや音源によって変化するようだ。
DACをRAL-2496ut1に換えると、s16leにフォーマットが変わる。こういう調整はRaspberry Pi2がやってくれているみたい。

あと、クライアントからの信号が止まって暫くしたらサーバーのpulseaudioは自動的にシャットダウンするようで、使う直前にsshでログインして起動しないといけない。
どこかで何か設定できるんだろうけど、確認していない。

さて、2496ut1の光デジタル出力をメインシステムにつないでみたのだけど、問題が。
直接つなぐと音量が大きすぎる。
というか、うちのアンプのボリュームが、普通のデジタル出力からみたら上げ過ぎなのだ。
普段はmpd/libsamplerateで768/32にアップサンプリングしデジタルボリュームで50％前後に絞って出力しているので、逆にアンプのボリュームは上げている。ここに普通のデジタル出力から入力したら、大音量になる。
Firefox上のPrime Musicにもボリュームがあるのだけど、これを下限ギリギリまで下げることになる。モニター画面上、ミリ単位の調節になって使いにくい。

pulseaudioサーバーの音量を下げられるコマンドもあるらしいが、どうもうまくいかない。うちではalsaが動かなくなって音が出なくなった。ここで考えてみたら、s16le 44100のフォーマットで、Raspberry Pi2でデジタルで音量調節というのは、音質に配慮するなら使わないほうがいい手法ではないのか、と思い至る。
そこで、あんまりスマートじゃないけど、メインシステムにつなぐのにはOdeon-Liteを使うことにした。ボリュームがついているので使いやすい音量に設定できる。Odeon-Liteにはusb入力がないので、2496ut1をDDコンバーターとして使う。

突っ込んだ音質評価はしていないが、Prime Musicの音源もそこそこの音質で聞けると思う。

pactl list sinks

pactl set-sink-volume 0 50%

Volume: front-left: 32768 /  50% / -18.06 dB,   front-right: 32768 /  50% / -18.06 dB

pactl set-sink-volume 0 100%
pactl list sinks
Volume: front-left: 65536 / 100% / 0.00 dB,   front-right: 65536 / 100% / 0.00 dB

pactl set-sink-volume 0 95%
Volume: front-left: 62259 /  95% / -1.34 dB,   front-right: 62259 /  95% / -1.34 dB
Volume: front-left: 58982 /  90% / -2.75 dB,   front-right: 58982 /  90% / -2.75 dB
Volume: front-left: 55705 /  85% / -4.24 dB,   front-right: 55705 /  85% / -4.24 dB
Volume: front-left: 52428 /  80% / -5.81 dB,   front-right: 52428 /  80% / -5.81 dB
Volume: front-left: 51773 /  79% / -6.14 dB,   front-right: 51773 /  79% / -6.14 dB
Volume: front-left: 49152 /  75% / -7.50 dB,   front-right: 49152 /  75% / -7.50 dB
Volume: front-left: 45875 /  70% / -9.29 dB,   front-right: 45875 /  70% / -9.29 dB


pactl set-sink-volume 0 65536
pactl list sinks
Volume: front-left: 65536 / 100% / 0.00 dB,   front-right: 65536 / 100% / 0.00 dB

pactl set-sink-volume 0 61440
Volume: front-left: 61440 /  94% / -1.68 dB,   front-right: 61440 /  94% / -1.68 dB
Volume: front-left: 57344 /  88% / -3.48 dB,   front-right: 57344 /  88% / -3.48 dB
Volume: front-left: 53248 /  81% / -5.41 dB,   front-right: 53248 /  81% / -5.41 dB
Volume: front-left: 49152 /  75% / -7.50 dB,   front-right: 49152 /  75% / -7.50 dB
Volume: front-left: 45056 /  69% / -9.76 dB,   front-right: 45056 /  69% / -9.76 dB
Volume: front-left: 40960 /  63% / -12.25 dB,   front-right: 40960 /  63% / -12.25 dB
Volume: front-left: 36864 /  56% / -14.99 dB,   front-right: 36864 /  56% / -14.99 dB
Volume: front-left: 32768 /  50% / -18.06 dB,   front-right: 32768 /  50% / -18.06 dB

pactl set-sink-volume 0 3.0
Volume: front-left: 94519 / 144% / 9.54 dB,   front-right: 94519 / 144% / 9.54 dB

pactl set-sink-volume 0 2.0
front-left: 82570 / 126% / 6.02 dB,   front-right: 82570 / 126% / 6.02 dB

pactl set-sink-volume 0 1.5
Volume: front-left: 75020 / 114% / 3.52 dB,   front-right: 75020 / 114% / 3.52 dB

pactl set-sink-volume 0 1.25
Volume: front-left: 70597 / 108% / 1.94 dB,   front-right: 70597 / 108% / 1.94 dB

pactl set-sink-volume 0 1.0
Volume: front-left: 65536 / 100% / 0.00 dB,   front-right: 65536 / 100% / 0.00 dB

pactl set-sink-volume 0 0.75
Volume: front-left: 59543 /  91% / -2.50 dB,   front-right: 59543 /  91% / -2.50 dB

pactl set-sink-volume 0 0.5
Volume: front-left: 52016 /  79% / -6.02 dB,   front-right: 52016 /  79% / -6.02 dB

pactl set-sink-volume 0 0.33
Volume: front-left: 45288 /  69% / -9.63 dB,   front-right: 45288 /  69% / -9.63 dB

pactl set-sink-volume 0 3.0dB
Volume: front-left: 73533 / 112% / 3.00 dB,   front-right: 73533 / 112% / 3.00 dB

pactl set-sink-volume 0 -3.0dB
Volume: front-left: 65536 / 100% / 0.00 dB,   front-right: 65536 / 100% / 0.00 dB

pactl set-sink-volume 0 -3dB
Volume: front-left: 58409 /  89% / -3.00 dB,   front-right: 58409 /  89% / -3.00 dB

pactl set-sink-volume 0 +3dB
Volume: front-left: 65536 / 100% / 0.00 dB,   front-right: 65536 / 100% / 0.00 dB

pactl set-sink-volume 0 -25%
Volume: front-left: 49152 /  75% / -7.50 dB,   front-right: 49152 /  75% / -7.50 dB
pactl set-sink-volume 0 -25%
Volume: front-left: 32768 /  50% / -18.06 dB,   front-right: 32768 /  50% / -18.06 dB
pactl set-sink-volume 0 +50%
Volume: front-left: 65536 / 100% / 0.00 dB,   front-right: 65536 / 100% / 0.00 dB


pactl set-sink-volume 0 -1024
Volume: front-left: 64512 /  98% / -0.41 dB,   front-right: 64512 /  98% / -0.41 dB
pactl set-sink-volume 0 -1024
Volume: front-left: 63488 /  97% / -0.83 dB,   front-right: 63488 /  97% / -0.83 dB
pactl set-sink-volume 0 -2048
Volume: front-left: 61440 /  94% / -1.68 dB,   front-right: 61440 /  94% / -1.68 dB
pactl set-sink-volume 0 +4096
Volume: front-left: 65536 / 100% / 0.00 dB,   front-right: 65536 / 100% / 0.00 dB


pactl set-sink-volume 0 +1.0
Volume: front-left: 82570 / 126% / 6.02 dB,   front-right: 82570 / 126% / 6.02 dB
pactl set-sink-volume 0 +1.0
Volume: front-left: 104031 / 159% / 12.04 dB,   front-right: 104031 / 159% / 12.04 dB
pactl set-sink-volume 0 -0.5
Volume: front-left: 82570 / 126% / 6.02 dB,   front-right: 82570 / 126% / 6.02 dB
pactl set-sink-volume 0 -0.5
Volume: front-left: 65536 / 100% / 0.00 dB,   front-right: 65536 / 100% / 0.00 dB

まずはちょっとしたメモから。

前回エントリーで出て来たコマンド「cat /proc/asound/card0/stream0」なんだけど。
ふだんpiCore7とi2s DACでusbメモリの音源を鳴らしているシステムで、試しに打ってみた結果が以下。

tc@box:~$ cat /proc/asound/card0/stream0
cat: can't open '/proc/asound/card0/stream0': No such file or directory
tc@box:~$

No such file or directory、、、
usb出力だとusb DACのデータが表示されたけど、i2s出力だとそれがない。考えてみたら、i2sだと出力先デバイスを特定するデータを扱う必要がないのだろう。
出力自体のデータは、下記のように確認できる。.mpdconfの設定は24/96だ。

tc@box:~$ cat /proc/asound/card0/pcm0p/sub0/hw_params
access: RW_INTERLEAVED
format: S24_LE
subformat: STD
channels: 2
rate: 96000 (96000/1)
period_size: 12000
buffer_size: 48000
tc@box:~$

2年前のエントリーで、USB出力は48kHzにリサンプリングされるがi2s出力はされずに設定どおりに出力されるようだ、という記載がある。出力先が何なのかを気にしないのだから、48kHzにリサンプリングする理由がない。
つまり今更だけど、i2s出力とUSB出力はalsaの動き方が違うということだ。

ここで、.mpdconfのaudio_output_format設定を変えて、出力のファイルフォーマットがどうなるかを確認してみた。
「96000:24:2」のとき出力はS24_LE、「44100:16:2」のときS16_LE、「192:32:2」のときS32_LEになった。
audio_output_formatをコメントアウトしたら、出力は44100でS24_LE。あれ？っと思ったけど、よく考えたら、このシステムではmp3を再生していたんだった。CDリッピングのflacデータを再生したら、S16_LEになった。
mp3って、S24_LEになるのかね、、、いろいろ謎がある。

前回エントリーの話では、「-D hw:0,0」を設定したらファイルフォーマットを厳密に設定しないといけないけど、「-D plughw:0,0」は緩いのではないか？ということだった。
今回は、実際のところどうなのか、やってみようということだ。
うちでは珍しくもないけど、長々だらだらとしたエントリーになった。

テスト用環境として、Raspberry Piを2台使って、usb出力のPPAP環境を作る。
Frontに、Ras pi2、mpd 0.19.19、libsamplerateを使用。
Back-endに、Ras piB+。
OSはともにpiCore7。
USB DACはいくつか手持ちがあるけど、何を使うか、、、ちょっと古いが、取り敢えずRATOCのRAL-2496ut1を使うことにした。
これにオーディオテクニカのAT-SP150 bkというデスクトップ用のパワードスピーカーをつないで出力した。
ファイルフォーマットやBack-Endのコマンドを変えながら、音が出るかどうかのデータをとってみる。

Back-endのRas piB+にsshでログインし確認すると以下の通り。

tc@box:~$ cat /proc/asound/card0/stream0
RATOC Systems,Inc. RAL-2496UT1 USB-Transport at usb-20980000.usb-1.4, full spee : USB Audio

Playback:
  Status: Stop
  Interface 1
    Altset 1
    Format: S16_LE
    Channels: 2
    Endpoint: 1 OUT (ASYNC)
    Rates: 44100, 48000, 88200, 96000
  Interface 1
    Altset 2
    Format: S24_3LE
    Channels: 2
    Endpoint: 1 OUT (ASYNC)
    Rates: 44100, 48000, 88200, 96000
tc@box:~$

ほほう、、、面白い。
ADI-2 DACなんかS32_LEしか出ないのに。S16_LEとS24_3LEが表示されている。

Frontの.mpdconfはこんな感じ。

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

audio_output {
type "pipe"
name "ppappipe"
always_on "yes"
command "/usr/local/bin/ncat 192.168.1.18 4444"
}

2496ut1は24/96までのDACなので、192/32はオーバースペックだ。
しかし、ここでBack-endのコマンドを下記のように設定。

/usr/local/bin/ncat -kl 4444 -e "/usr/local/bin/aplay -D plughw:0,0 -M --period-size=512 --buffer-size=4096 -t raw -f S24_LE -r192000 -c2"

音を出してみる。
Back-endの出力はこんな感じに。

tc@box:~$ cat /proc/asound/card*/pcm0p/sub0/hw_params
access: MMAP_INTERLEAVED
format: S24_3LE
subformat: STD
channels: 2
rate: 96000 (96000/1)
period_size: 256
buffer_size: 2048
tc@box:~$

音はちゃんと出ている。
Frontの設定「192/32」が、「24/96」にリサンプリングされている。Back-endの「-f S24_LE -r192000」という設定も、どこにいったのかという感じ。 ちなみにBack-endの構成はこんな感じ。

tc@box:~$ df
Filesystem                Size      Used Available Use% Mounted on
tmpfs                   391.1M      9.4M    381.6M   2% /
tmpfs                   217.3M         0    217.3M   0% /dev/shm
/dev/mmcblk0p2           43.7M     13.1M     28.2M  32% /mnt/mmcblk0p2
/dev/loop0                1.1M      1.1M         0 100% /tmp/tcloop/mc
/dev/loop1                1.9M      1.9M         0 100% /tmp/tcloop/openssh
/dev/loop2                4.9M      4.9M         0 100% /tmp/tcloop/nmap
/dev/loop3              768.0K    768.0K         0 100% /tmp/tcloop/alsa-modules-4.1.13-piCore+
/dev/loop4              256.0K    256.0K         0 100% /tmp/tcloop/alsa
/dev/loop5                1.1M      1.1M         0 100% /tmp/tcloop/glib2
/dev/loop6               68.0K     68.0K         0 100% /tmp/tcloop/libssh2
/dev/loop7              256.0K    256.0K         0 100% /tmp/tcloop/ncurses
/dev/loop8                1.5M      1.5M         0 100% /tmp/tcloop/openssl
/dev/loop9              292.0K    292.0K         0 100% /tmp/tcloop/libnl
/dev/loop10             128.0K    128.0K         0 100% /tmp/tcloop/libpcap
/dev/loop11             128.0K    128.0K         0 100% /tmp/tcloop/lua-lib
/dev/loop12             384.0K    384.0K         0 100% /tmp/tcloop/libasound
/dev/loop13              28.0K     28.0K         0 100% /tmp/tcloop/gamin
/dev/loop14              36.0K     36.0K         0 100% /tmp/tcloop/libelf
/dev/loop15             256.0K    256.0K         0 100% /tmp/tcloop/pcre
/dev/loop16             384.0K    384.0K         0 100% /tmp/tcloop/libgcrypt
/dev/loop17             128.0K    128.0K         0 100% /tmp/tcloop/libusb
/dev/loop18              36.0K     36.0K         0 100% /tmp/tcloop/bzip2-lib
/dev/loop19             128.0K    128.0K         0 100% /tmp/tcloop/libgpg-error
/dev/loop20             128.0K    128.0K         0 100% /tmp/tcloop/libudev
tc@box:~$

alsa.tcz、alsa-modules-4.1.13-piCore+.tcz、libasound.tczだけで、リサンプリングしてるんだろうか？
まあ、ダウンサンプリングに関してはひとつ飛ばしするだけでいいっちゃいいもんなあ、、、
フォーマットはS32_LEだった？のが、S24_3LEに変換されているけど、これってRas piB+的に簡単なのだろうか、、、

設定を変えてみる。
Back-endのコマンドのオプション設定が「-D plughw:0,0」だったのを「-D hw:0,0」に。
さらに「-f S24_3LE -r96000」、つまり2496ut1で使えるはずの設定記載にする。

Back-end :
/usr/local/bin/ncat -kl 4444 -e "/usr/local/bin/aplay -D hw:0,0 -M --period-size=512 --buffer-size=4096 -t raw -f S24_3LE -r96000 -c2"

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

audio_output {
type "pipe"
name "ppappipe"
always_on "yes"
command "/usr/local/bin/ncat 192.168.1.18 4444"
}

音は出た、、、盛大なホワイトノイズが。はっきりしないけど、S24_3LEがいけないのではと思う。
S24_3LEをS24_LEにしたら、「Paused」で音が出ない。
そういうことなんだね。
じゃあ、もうひとつの使えるはずの設定「S16_LE」にしてみる。

Back-end :
/usr/local/bin/ncat -kl 4444 -e "/usr/local/bin/aplay -D hw:0,0 -M --period-size=512 --buffer-size=4096 -t raw -f S16_LE -r96000 -c2"

Front :
samplerate_converter "Fastest Sinc Interpolator"
audio_buffer_size "8192"
buffer_before_play "20%"
audio_output_format "96000:16:2"

audio_output {
type "pipe"
name "ppappipe"
always_on "yes"
command "/usr/local/bin/ncat 192.168.1.18 4444"
}

tc@box:~$ cat /proc/asound/card*/pcm0p/sub0/hw_params
access: MMAP_INTERLEAVED
format: S16_LE
subformat: STD
channels: 2
rate: 96000 (96000/1)
period_size: 512
buffer_size: 4096
tc@box:~$

mpdは動いている。Back-endも信号を受け入れているようだ、、、でも、音が出ない。、、、
じゃあ、、、ここで「-D hw:0,0」だったのを「-D plughw:0,0」に変えてみるか、、、同じ、、、いや、、、出てる？音量が小さい、、、
設定を「-D hw:0,0」に戻す。
ボリュームを上げると、普通に音が出ていたのが分かった。音量が大きく違ったのだ。
S16_LEだと音量が下がるのか？、いや、、、むしろこっちのほうが適正な音量だ。先刻、鳴っていた音量が大き過ぎたのだ。

これは、一筋縄には行かないな、、、

こんな感じでだらだらやってても大変だ。データを取るのに変数は、、、

1) Front : .mpdconf / audio_output_format (44100, 48000, 88200, 96000, 19200 : 16, 24, 32)
2) Back-end : aplay -D (hw:0,0 or plughw:0,0)
3) Back-end : aplay -f (S16_LE, S24_3LE, S24_LE, S32_LE)
4) Back-end : aplay -r (44100, 48000, 88200, 96000, 19200)

変数が4つもある、、、
1)は、44100, 96000, 19200 : 16, 24, 32、ぐらい？
2)aplay -Dオプションは、hwとplughw。
3)はS16_LE、S24_3LE、S24_LE、4)は44100, 96000, 19200ぐらいに絞ろうか、、、
総当たりでやったら、162とおりの組み合わせ。、、、やって出来ないこともないけど、なかなか終わりそうにないな。

さらに絞る。
1)は、44100, 96000 : 16, 24。
2)aplay -Dオプションは、hwとplughw。
3)はS16_LE、S24_LE、4)は44100, 96000。1)の設定に数値を合わせる。
これで、8とおり。
削り過ぎか？、もうちょっと、他の設定もしてみようか、、、以下、結果。

こんなところかなあ、、、、
やはり、aplay -Dオプションで「hw:0,0」を設定すると、ファイルフォーマットをきちんと合わせないと音が出ない。
2496ut1の場合、24bitのフォーマットの扱いが難しい。
Back-endで「S24_3LE」と設定したら、正確な設定のはずなのに、ノイズで音声が聞けなくなる。むしろ「S24_LE」に設定した方が、「plughw」で問題なく音声を鳴らせる分、随分ましだということになる。これは10年ほど前にも問題視されていた事らしくて、alsaはS24_3LEを扱えないという話がネット上に残っているようだ。最近の機械はS32_LEをサポートしている機種がほとんどのようで、こうした問題はなくなったらしい。

入力が176.4kHzや192kHzのフォーマットでも、plughwで設定したら音を出すことができるのには、正直驚いた。
ただ、ダウンサンプリングされてしまうけど。
といっても、dmixがインストールされていないからだと思うけど、48kHzにはならない。
176.4kHzは2分の1の88.2kHzになるのかと思ったら、96kHzにダウンサンプリングされた。そのせいかどうか分からないけど、高音がきつくうるさい感じに聴こえた。同じダウンサンプリングされるのでも、192kHzからのほうが聴きやすく自然な感触に感じた。192/32で音が大きくなるのは、理由がわからない。

本当は、S32_LEをサポートしている新しいDACだとどうなのか、確認したほうがいいんだろうけど、息切れ気味。
このぐらいにしておこうと思う。

最近のシステム構成は下図のような感じ。

アンプが故障したので、代替にBrooklyn Ampを導入している。
SM-SX100と傾向は違うけど、なかなか悪くない音がする。
明確に違うのは中低域だ。ベース楽器が張り出す傾向はSX100と明らかに異なっている。あと、SX100よりもウォームな音がする。
しかしこれなら、SX100が帰って来るまでゆっくり待てるな、、、

と、思っていたら、どうもおかしい。
というか、Brooklyn Ampの音色がSX100にだんだん近付いてきているような気がするのだ。
以前の試聴で使っていたジョニミッチェルやフィッシュマンズの音源でも確かめてみたが、やはり聴こえ方が違ってきている。SX100に近い鳴り方で、情報量が増えてきている。ちょっと前まで、情報量はSX100の7、8割かな、などと思っていたのだけど、段々分からなくなってしまった。
これはエージングというべきなのか、ウォーミングアップがまだ続いているのか、、、
SX100が戻ってきたら比較しないといけない感じだ。

ちなみに、20年前に視聴した記憶の彼方の100万円プリメイン群の情報量は、SX100の2、3割という感覚だ。最近、一時的に使っていたLP-2020A+やTU-870の情報量は数パーセントから1割以下という感じ方。
どういう感じ方なんだろうね。

あと、CDプレーヤー周りでサブシステムを構成した。
ストックしてあった機材の寄せ集めだけど、使えるので結果オーライという感じだ。
ちなみに情報量は1割以下なイメージ。これは仕方ない。
メインシステムとは完全に別系統となっている。こっちも必要に応じて弄っていくと思うけど、テレビ台の下部に押し込んでいるので制約もある中でのことだ。

しばらくはこれで大丈夫、と思っていたら、SM-SX100の修理完了とのメールが来た。
今は帰還を待つのみだ。
さあ、どうなるやらだ。