abk1's scratched blog 3

昨年度末までに、Deezer用にDaphileをUPnPサーバー、Tiny Core/mpdをUPnPレンダラーとして使うことで、ストリーミングサービスの音も768/32にアップサンプリング、PPAPで再生できるようになった。
いやー、いいですよこれは。
音が良いのも勿論だけど、上流2系統を切り替えて使うことが、以前よりもずっと容易になった。
手元のPCで音源再生する操作自体で切り替わる。

以前のDeezer再生システムは、時期によってpulseaudioだったり、piCorePlayerだったり、Daphile自体だったりしたけど、ずっとNAS音源再生のシステムとは音声信号の処理方法が違っていた。だからUSBケーブルを物理的に繋ぎ変えることでしか、上流の接続を切り替える方法がなかった。
USBセレクターの自作まで考えたが、結局できていない。

現在、上流はNAS用とDeezer用、2系統のPPAP Front。
中流以降はADI-2 DAC/SM-SX100系とM500/Brooklyn Amp系、2系統をそれぞれのPPAP Back endが受ける。
それらが両方がPPAP 768/32になった。
PPAP Back endは、常に768/32のデータが来るのを待っている状態なので、そこにデータを流し込む操作さえすれば、その音が出る。
データを流し込むだけでいいのだから、手元のノートPC上で音を出す操作をするだけで切り替えが出来る。具体的には、ウェブブラウザからDaphileを操作するか、ncmpcppからNAS音源再生の操作をすると、操作した方の音が出る。セレクターに類するものは弄らない、というか、ない。
感覚的には切り替え操作自体を意識する必要が殆どなくなる。
ただ、上流両方から出力しないように気をつける必要はありそうだけど。

ストリーミング音源とCDリッピング音源の差異は、殆ど無い。
聴き分けは僕の耳では不可能だ。僅かに違うような気もするんだけど、気のせいレベルだと思う。 Frontのハードの差異か、LANへの繋がり方の違いはあるんじゃないかと思うのだけど、同じ条件でストリーミング音源とCDリッピング音源を比較したら、違いがあるとは言えない感じだ。upmpdcliが動いているかどうかも、差異を生むとは言い難いと思った。

出力先の変更は、もう少し面倒だ。
PPAP Frontの出力先の設定を書き換えることでPPAP Back end-USB DAC-アンプを選択し、mpdを再起動することで、変更する。
DAC、アンプがセットで切り替わるので、スピーカーから音が出るようにアンプセレクターのところまで歩いて行って切り替える必要がある。

今のシステムでは、DACとアンプの接続を切り替えるには両者をつなぐXLRケーブルを抜き差ししないといけないので少し面倒だ。結果、SM-SX100はADI-2 DACと繋ぎっぱなしだし、Brooklyn AmpはM500と繋ぎっぱなしということになる。
市販のセレクターはRCA用だと選択肢が多いけど、XLRケーブル用で上下2系統というのは、なかなか手頃なのが無い。
しかし今後、切り替えが出来るようにしたい。検討中。

それにしても、現在のシステムはこんな感じ。

上流が、ごちゃごちゃしていて分かりにくい。もっとすっきりさせたい。
どうするかこれも検討中。

一応、RatocのDACを残しているのは、youtubeなどの音源をウェブブラウザ-pulseaudioの経路で聴くため。とかいいながら、使う機会がないんだけど。

前回に引き続き、UPnPでデータを飛ばしてレンダラーに組み込んだlibsamplerateでアップサンプリングするプラン。
DebianやFedoraなどではリポジトリから読み込みが出来る様なんだけど（訂正。今のFedoraではソースからのインストールが必要。リポジトリからのインストールが出来たのはv30、31の頃のようだ）、今回は、Tiny Core Pure 64での試み。ソースからのインストールが必要になる。
これが本丸だ。
相当梃子摺るかと思ったが、案外順調にできてしまった。順調と言ってもPulseaudioと比べたら、だけど。
以下、経過を記載しておく。

今回、打ち込んだコマンド等、過程の詳細な記載は省略した。要点だけ書いている。
いつもはこまごまと書くんだけど、長くなりすぎるので。

Daphileの操作画面キャプチャ画像。
右下にTiny Coreのmpdがレンダラーに選択されているのが見える。MPD-90というのはipアドレスだ。
Daphileサーバーはcompaq 6730bに戻している。有線LANに繋がらない2570pは返品、返金となった。

準備

最初からTiny Core Pure 64を組んでいくのは面倒なので、以前にmpdを組み込み、Pulseaudioを組み込みして、昨年10月にバックアップしたイメージを使う。
ストリーミング音源をpulseaudioで転送しアップサンプリング再生する（10月15日、追記）
http://blown-lei.net/endive/blosxom.cgi/audio_diary/20201011a.htm

ハードはapu2c4。
以前はこれで768kHzへのアップサンプリング再生をしていたけど、最近は使っていなかった。
apu2c4で768kHzへのアップサンプリングに取り組む
http://blown-lei.net/endive/blosxom.cgi/audio_diary/20181208a.htm

SDカードにイメージを書き込み、apu2c4に刺して起動。 sshでログイン。

まず、upmpdcliの説明サイトから引用。

Upmpdcli and associated libraries downloads
https://www.lesbonscomptes.com/upmpdcli/upmpdcli-manual.html#UPMPDCLI-PACKAGES

For building from source, you will need a C++ compiler with full C++11 support, and the development packages for the supporting libraries: libcurl, libmicrohttpd, libmpdclient, and libexpat.
Also the Python modules for streaming service support use the python-requests package, so you may need to install it (it is only needed at run time).
If you are using the source from the git repository, you will also need the autoconf, automake, libtool trio. Use the autogen.sh script to set things up.

この説明サイトは膨大で目が回りそうだけど、今回は要所だけ読んでなんとかした。
ライブラリとして、「libcurl, libmicrohttpd, libmpdclient, and libexpat」が必要と書いている。あと、python-requests、「autoconf, automake, libtool trio（トリオなんだ）」が要るような。

Tiny Coreの状況を確認。
curl expat2 expat2-devは既にインストールされている。
tceで、以下インストール。

# tce
curl-dev.tcz libmicrohttpd.tcz libmicrohttpd-dev.tcz

libmpdclientはリポジトリにtczがないので、ソースからインストール。
最新のはインストールにmeson-ninjaを使う。
敢えて面倒な事はしたくなかったので、以前のバージョンを選択。

wget https://www.musicpd.org/download/libmpdclient/2/libmpdclient-2.11.tar.xz

# tce
doxygen automake

doxygenがないよ、と指摘される。そうだったっけ？
一応、確認したらautomakeもない。既にインストールされてるとばかり思っていた、、、
更に、作業の前には時計を合わせておかないと、エラーになるので合わせる。

sudo ntpclient -s -c 1 -h ntp.nict.jp

./configure、makeの過程で以下警告あり。今回は気にせず進む。

/home/tc/libmpdclient-2.11/include/mpd/connection.h:98: warning: explicit link request to 'MPD_HOST' could not be resolved
/home/tc/libmpdclient-2.11/include/mpd/connection.h:98: warning: explicit link request to 'MPD_PORT' could not be resolved
/home/tc/libmpdclient-2.11/include/mpd/connection.h:99: warning: explicit link request to 'MPD_TIMEOUT' could not be resolved

sudo make DESTDIR=../libmpdclient install

libtool:   error: '../libmpdclient/usr/local/lib' must be an absolute directory name

sudo make DESTDIR=/home/tc/libmpdclient install

make installから、tczファイルを作って、/mnt/*/tce/optionalに保存する。
ここらへんで、python-requestsをインストールしとく（インストールし忘れていた）。

# tce
python3.6-requests.tcz

upmpdcliをインストール

下記のソースコード配布ページからソースをダウンロード。

Upmpdcli and associated libraries downloads
https://www.lesbonscomptes.com/upmpdcli/pages/downloads.html

Current version (tar files):

libnpupnp-4.1.1.tar.gz
libupnpp-0.21.0.tar.gz
upmpdcli-1.5.11.tar.gz
sc2mpd-1.1.8.tar.gz

順次、インストールしていく。
sc2mpdはOpenHome関連で、うちの環境とは関係ないのでインストールしていない（後でインストールしとけば良かったかなと思ったけど、動く環境作る方が優先なので）。
これらのソース、あちこちファイル読んでもインストールの手法が見つからない。
./configure、make、make--install、tcz保存、通常の流れでインストールできる。

wget https://www.lesbonscomptes.com/upmpdcli/downloads/libnpupnp-4.1.1.tar.gz
./configure
make

checking whether build environment is sane... configure: error: newly created file is older than distributed files!

時計を合わせるのを忘れたらこんな警告が出る。

sudo ntpclient -s -c 1 -h ntp.nict.jp

順次、インストール。

wget https://www.lesbonscomptes.com/upmpdcli/downloads/libupnpp-0.21.0.tar.gz

wget https://www.lesbonscomptes.com/upmpdcli/downloads/upmpdcli-1.5.11.tar.gz

途中で足りないライブラリがあると指摘され下記インストールしている。

# tce
jsoncpp-dev.tcz

mpdを再インストール

さて、これで動くかというと動かない。下記、mpdの状況を確認。

tc@box:~$ mpd -V
Music Player Daemon 0.20.20

Database plugins:
 simple


pi@volumio:~$ mpd -V
Music Player Daemon 0.19.1

Database plugins:
 simple proxy upnp

Storage plugins:
 local smbclient nfs

Neighbor plugins:
 smbclient upnp

Tiny CoreとVolumio 1.55のmpdの状況を比較。
使えるプラグインの表示が違う。Tiny Coreのほうはupnpの表示がない。
再インストールだ。

sudo ntpclient -s -c 1 -h ntp.nict.jp

wget https://www.musicpd.org/download/mpd/0.20/mpd-0.20.20.tar.xz

./configure --enable-pipe-output

mpdインストールのいつもの工程で再インストールしたが、それだけでは動かなかった。
./configureのオプション指定を変える。

./configure --enable-pipe-output --enable-upnp

configure: error: UPnP client support: libupnp not found

# tce
libupnp.tcz libupnp-dev.tcz

なんと、、ここでlibupnpがないと指摘された。
実は、tczリポジトリにはupnp関係のtczは沢山あって、でも何が要るやら分からなかったのでインストールしてなかったのだ。
tceでインストール。
その後は順調に進んで、インストールできた。

tc@box:~$ mpd -V
Music Player Daemon 0.20.20

Database plugins:
 simple proxy upnp

Storage plugins:
 local curl

Neighbor plugins:
 upnp

インストール終了時点　概要

インストール終了時点でのonboot.lstは下記の通り。

sudo vi /mnt/*1/tce/onboot.lst

openssh.tcz
i2c-5.4.3-tinycore64.tcz
alsa-modules-5.4.3-tinycore64.tcz
alsa.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
nfs-utils.tcz
nmap.tcz
libcap-dev.tcz
alsa-plugins-dev.tcz
alsa-config.tcz
alsa-dev.tcz
gudev-lib.tcz
dbus-dev.tcz
pulseaudio-13.0.tcz
libmicrohttpd.tcz
libmicrohttpd-dev.tcz
curl-dev.tcz
doxygen.tcz
automake.tcz
libmpdclient-2.11.tcz
python3.6-requests.tcz
libnpupnp-4.1.1.tcz
libupnpp-0.21.0.tcz
jsoncpp-dev.tcz
upmpdcli-1.5.11.tcz
libupnp.tcz
libupnp-dev.tcz
mpd-0.20.20.tcz

upmpdcliを動かす

mpdを起動（うちではssh経由で起動するのがデフォルト）。
DaphileにUpNPレンダラーとして認識されたら、ウェブブラウザ操作画面のプレーヤー表示部に出てくるはずなんだけど、出て来ない。
upmpdcliがインストールしただけでは動いてないので、起動しないといけない。

Upmpdcli
https://www.lesbonscomptes.com/upmpdcli/upmpdcli-manual.html

In most situations, upmpdcli will be run as follows:

upmpdcli -D -c /etc/upmpdcli.conf

The -D option tells upmpdcli to fork and run in background. The -c option specifies a configuration file. See the upmpdcli(1) manual page for more information about the command line.

マニュアル、膨大なんだけど。
わけが分からないと言いながらあれこれ、、、

tc@box:~$ upmpdcli --help
upmpdcli: usage:
-c configfile 	 configuration file to use
-h host    	 specify host MPD is running on
-p port     	 specify MPD port
-d logfilename	 debug messages to
-l loglevel	  log level (0-6)
-D    	 run as a daemon
-f friendlyname	 define device displayed name
-q 0|1	 if set, we own the mpd queue, else avoid clearing it whenever we feel like it
-i iface    	 specify network interface name to be used for UPnP
-P upport    	 specify port number to be used for UPnP
-O 0|1	 decide if we run and export the OpenHome services
-v      	print version info
-m <0|1|2|3|4> media server mode (default, multidev|only renderer|only media|embedded|multidev)

Upmpdcli 1.5.11 libupnpp 0.21.0
tc@box:~$ 

試行錯誤するうちに、こんなんが表示された（実は --help 以外でも、例えば --x とかでも表示される）。
ここから起動コマンドを考える。

upmpdcli -D -m 1 -f MPD-90 -d /home/tc/.upmpdcli.log -l 2 -O 0

sshから上記コマンドでupmpdcliを起動。
出来ました！
Daphileにupnpレンダラーとして認識された。これで、音が出る筈。
本当は、upmpdcli.confで設定して運用するほうがスマートなんだけど、当面はこれで動かすことにする。

upmpdcli.confの原本は下記に保存されている。コピーして使えばいいのだろうか。
まだ使い方が分からない。
/usr/local/share/upmpdcli/upmpdcli.conf-dist

PPAPで音を出す

実はこのTiny Core Pure 64、もともとのイメージファイルがPPAP Frontとして機能するように作られている。
768kHzにアップサンプリングして、PPAP Back-Endに送る設定がこの時点で既に出来ている。

USB DACを繋いでmpd.conf再設定とか面倒だったので、いきなりそれで使ってみることにした。
PPAP環境は常日頃から使っていて出来ているので、Daphileから音を出す操作をしたら、そのままPPAPシステムに繋がる筈ということだ。
こんなイメージ。

音は出ました。

Frontの状況。

CPU0: 45.8% usr  3.5% sys  0.0% nic 50.0% idle  0.0% io  0.0% irq  0.5% sirq
CPU1: 10.7% usr  3.3% sys  0.0% nic 85.9% idle  0.0% io  0.0% irq  0.0% sirq
CPU2:  9.9% usr  2.5% sys  0.0% nic 87.5% idle  0.0% io  0.0% irq  0.0% sirq
CPU3: 43.7% usr  0.3% sys  0.0% nic 55.2% idle  0.0% io  0.0% irq  0.5% sirq
Load average: 1.09 0.97 0.56 3/386 3852
  PID  PPID USER     STAT   VSZ %VSZ CPU %CPU COMMAND
 6776     1 tc       S     507m 12.8   0 26.5 mpd
 2841  6776 tc       S    16480  0.4   2  1.4 /usr/local/bin/ncat 192.168.1.89 4400
 3637  6742 tc       R     4016  0.1   1  0.2 top
15901     1 tc       S    1743m 44.2   3  0.1 upmpdcli -D -m 3 -f MPD-90 -d /home/tc/.upmpdcli.log -l 2 -O 0

Back-Endの状況。

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

Mem: 103904K used, 3925992K free, 18384K shrd, 5676K buff, 34188K cached
CPU:  0.2% usr  2.1% sys  0.0% nic 97.1% idle  0.0% io  0.0% irq  0.5% sirq
Load average: 0.06 0.04 0.00 3/113 17254
  PID  PPID USER     STAT   VSZ %VSZ CPU %CPU COMMAND
17204  1213 root     S    15484  0.3   3  1.0 /usr/local/bin/ncat -kl 4400 -e /usr/local/bin/aplay -D hw:0,0 -M --period-size=4096 --buffer-size=32768 -t raw -f S32_LE -r768000 -c2
17205 17204 root     S     4608  0.1   1  0.5 /usr/local/bin/aplay -D hw:0,0 -M --period-size=4096 --buffer-size=32768 -t raw -f S32_LE -r768000 -c2
   30     2 root     IW       0  0.0   1  0.1 [kworker/1:1-eve]
17254 17226 tc       R     4016  0.1   2  0.0 top
 1213  1094 root     S    15484  0.3   1  0.0 /usr/local/bin/ncat -kl 4400 -e /usr/local/bin/aplay -D hw:0,0 -M --period-size=4096 --buffer-size=32768 -t raw -f S32_LE -r768000 -c2
17222  1211 root     S     5872  0.1   0  0.0 sshd: tc [priv]

音の方は、NASの音に比べてDaphileからのほうが固いような気がする。NASが絹のような感触だとしたら、Daphileからのほうはガラスのような感触というか。
そもそもアップサンプリングサーバーがHP Elitebookとapu2c4で違う機械だとか状況が違うので、音も違うのが当たり前だと思う。

もう少しだけソフトだったらいいかなと思うけど、768kHzじゃないと出ない音が出ている。
運用しながら調整していきたい。

UPnPでデータを飛ばしてレンダラーに組み込んだlibsamplerateでアップサンプリングするプランだけど、いくらか試みた中で、めぼしいところを書いておこうと思う。
途中経過報告だ。

実は、Daphileでアップサンプリングが出来る（いきなり逆走してるが、時系列上仕方ない）。
アップサンプリングして、Daphileがオーディオデバイスとして認識しているUSB DACに出力することは可能だ。
設定項目の表記からの推定だけど、使われるライブラリはSoXらしい。
piCorePlayerに送るLMSからの出力は、アップサンプリングできない。

この際なので、Daphileのアップサンプリングも試してみようと思ってやってみた。だけど、どうも思わしくない。
44.1/16を整数倍していって、88.2kHzから352.8kHzまで試してみた。しかし音が滲んだ感じになり、締りがなくなりぼんやりしている。アップサンプリングなどしない方がいい。
加えてアップサンプリングさせたらギャップレス再生が出来なくなった。こちらも大きな問題で、Daphileを使う意味がなくなる。

Daphileを動かしているのはCompaq 6730bでハードとして古いので強化したらどうだろうかとか、64-bit x86か、32-bit x86を使ったらどうだろうとか、思うところもあるんだけど、取り敢えず直ぐに使えるハードがないし、想像以上に上手くいかなかったので最早あんまり期待していない、、、
しかし手持ちの古いハードで遣り繰りしていくのにも、そろそろ限界を感じている。上を目指す気があるなら、新しいハードがもう少しあった方が余裕があるよね、、、ということでアップサンプリングサーバーとして使っているHP EliteBook 2570pを、もう1台、入手することにした。

それにしても、新しくすると言っても2012年頃の製品だ。6730bは2008年頃の製品だから、4年ぐらい新しくなる。
4年新しくするって、意味ないかな、、、
そんなこと思いながらも、安いのがあったので注文してしまった。

さて、次の作戦はUPnP、Volumioだ。Volumioといっても、懐かしのv1.55を使う。構造がシンプルで扱いやすいし、UPnPクライアントとしての機能も内蔵している。
しかもリサンプラーはデフォルトでlibsamplerate派生と思われるlibresampleだ。
考えてみたら、これは使ってみない手はない。

下記サイトからSourceForgeのダウンロードへのリンクが貼ってある。
Volumio 1.55 for Raspberry Pi & Raspberry Pi 2
https://community.volumio.org/t/volumio-1-55-for-raspberry-pi-raspberry-pi-2/2393

ディスクイメージを焼いて、Raspberry pi2に刺して起動、ipアドレスを確認しウェブブラウザからアクセスすると操作画面が表示される。
右上の「MENU」から「Playback」、MPD Configuration の「Audio Output」からDACへの出力を設定する。
どうも、繋ぐDACによって表示がまちまちな様子なので、適宜その時の状況で合わせる。

UPnPレンダラーの設定は4年前にしたことがある。
http://blown-lei.net/endive/blosxom.cgi/audio_diary/20170102a.htm

右上の「MENU」から「System」に入る。
Services managementの「UPNP Control」と「UPNP\DLNA Indexing」をON。「APPLY」。
再起動が必要だけど、volumio 1.55はブラウザからの操作で上手く再起動しないことがよくあるので、シャットダウンして電源を入れ直した方が確実だと思う。

Daphileのほうは、下記サイトに操作画面のキャプチャ付きで詳しい説明がある。多謝。
PCで音楽: Daphileのメディアサーバー化
http://asoyaji.blogspot.com/2019/07/daphile.html

Settings、Advanced Media Server Settings から「plugins」の中の「UPnP/DLNA bridge」「UPnP/DLNA Media Interface」を有効にする。
「3rd party Plugins」のプラグインリストから選んでチェックボックスにチェックを入れ、右下のapplyをクリック、再起動。選択したプラグインが「Active Plugins」のリストに移動する。
「UPnP/DLNA bridge」の「settings」をクリックし、「Start the Bridge」にチェックを入れ、「Restart」をクリック。
こんな感じで「Audio Player」の画面に戻ると、UPnPレンダラーがプレーヤーとして表示されるようになる。
うちでの「Audio Player」画面のキャプチャ。
この画面から操作したら音が出る。

そんな感じで、DaphileとVolimioを繋いでみた。
まず、アップサンプリングなし。問題なく音楽が再生できる。
アップサンプリングを設定。
まずDACの状況を確認する。
sshでVolumio 1.55にログイン、ユーザーはpi、パスワードはraspberry。
コマンド「cat /proc/asound/card0/stream0」でUSB DACの入力対応を確認。s32leなので32bitで周波数を上げていくことにする。

以下、ウェブブラウザの画面から設定。
右上の「MENU」から「Playback」、MPD Configurationの項目。
Audio buffer sizeはアップサンプリングするなら増量していく必要がある。
Audio output formatで、サンプリング周波数とビット深度を設定。
Sample rate converterは「Fastest Sinc Interpolator」で固定。Best、Mediumの設定も出来るが、Raspberry Pi2には負担が大きすぎて、まともに再生できないこともあるので使わない。Fastestがもともとmpdではデフォルトだし、それで十分にアップサンプリングによる音質向上効果が得られる。

話が逸れるが、個人的にはlibsamplerateのFastestの方が、SoXのVery Highよりも正確な処理をしているのではないかと思う。
正確というのは、もとのデジタル信号から理想的なDA変換をして得られるアナログ波形から、異なるサンプリング周波数とビット深度で理想的なAD変換を行ったときに得られるデジタルデータに、より近いデータに変換される、という意味だ。ややこしいけど。

過去に、ハイレゾ音源の音と、その音源から作られたCD相当の音源をlibsamplerateでアップサンプリングした音を、聴き比べたことがあるのだけど、殆ど差異がないという印象だった。
http://blown-lei.net/endive/blosxom.cgi/audio_diary/20170625a.htm
以前のエントリーの文面としては「結果はというと、44.1のアップサンプリングよりハイレゾ音源の方が繊細で耳あたりがいい鳴り方をする。アンプのボリュームが上がっていきやすい。ある意味、順当な結果になって良かった、という感じ。」と書いているが、、、
実は、差を「盛って」書いている。
今更こんなこと言うのはあれだけど「ここまで差が無いなら、アップサンプリングでいいじゃん」と思ったのが本音だった、、、
しかし当時は、それを弩ストレートに書く気になれなかったので、5mmを5cmぐらいに読み取る感じで書いた（ちょっと追記。普段、聴いているときよりもアンプのボリュームを上げたときに若干だが聴きやすいのはハイレゾ音源の方だった。通常の音量では聴き分けは難しいと思ったので、音量を上げて聴いたという経緯だ）。
その後のうちのオーディオのやり方は、やっぱりハイレゾ音源の方がいい、ではなく、CD音源でlibsamplerateによるアップサンプリング一辺倒で768kHzに至っている。結局、そういうことしか、うちではしていない。多分、4年前に聴いた300kHz台ハイレゾ音源の音は、700kHz台へのアップサンプリングになった時点で越えている。聴き比べしたわけじゃないので、多分だけど。

あと、SoXとlibsamplerateの音の違いを確認したこともあった。
http://blown-lei.net/endive/blosxom.cgi/audio_diary/20180318a.htm
SoXはソースのサンプリング周波数の整数倍へのリサンプリングと、非整数倍へのリサンプリングで、再生音の定位が違う。libsamplerateは大きくは違わない。多分、libsamplerateの方が正確なのだ。正確さは音質にも影響している。
僕が700kHz台までやってみようと思えたのは、音質が確実に良くなったからだ。SoXしか弄ってなかったら、そんなことはしていないだろう。

話を戻す。
192kHzまでは安定して再生。
しかし300kHz台では途切れて音楽にならない。
これは、想定内、、、過去の経験からも、300kHz台以上はRaspberry Pi2にはきつい。それでapu2に移行した経緯がある。

ここで、EliteBook 2570pが届いた。
USBメモリでDaphileを動かしているCompaq 6730bをシャットダウンし、2570pに刺し替えて起動。
トラブル発生。一応、ipアドレスが振られている？のにDaphileの起動画面にアクセスできない。
そしてpingすら通らない。
あれこれと試した末、有線LAN端子の接点がひとつ折れているのを発見する。
なるほど、有線は使えないってことね、、、1万4千円だからな、、、返品は面倒だな、、、

Compaq 6730bで起動し直し、Wifi接続に設定し直して、再度、2570pで起動。
今度は、LANにつながった、、、
無線でも速度は確保出来ているようだ。
これだったら384kHzはいけるだろうか。6730bに比べたらましな感じだが、、、
結果からいえば無理だった。クロックアップしてみたり、sshでVolumioにログインして/etc/mpd.confを書き換えて352.8kHzを設定もしてみたけど、どうしても音が途切れ不安定になる。

192kHzで使用継続する意味があるかどうか。
web player、pulseaudio、libsamplerateで384kHzにアップサンプリングするほうが音はいい。実在感といえばいいか、音色の深み、輝きに差が出る。どうしても192kHzでは見劣りしてしまう。 しかしそれでも、Volumioを使って192kHzに上げた方が、Daphileに直接、USB DACを繋ぐよりはいいようだ。
当面、使ってみることにした。
使用上の問題で、何故かVolumioの音量が勝手に変わるということがある。音が出ないな、と思ったらボリュームが０とかになっている。何か理由があるんだろうけど確認できていない。

今回いくつか、普段使わないディストリビューションを使ったけど、うちでは何だか不具合が出て上手くいかなかった。
そういうわけで、いずれはTiny Coreベースでなんとかしたい。Tiny Coreはうちでは比較的安定している。少々荒っぽいことをしても動くタフなディストリビューションだという印象がある。
直ぐには出来ないだろうが、当面はWeb Player-Pulseaudio-384kHz、Daphile-Volumio 1.55-192kHzで凌ぐつもり。

最近は、web player、pulseaudio、libsamplerateを使って、Deezerなど音楽ストリーミングサービス音源をアップサンプリングして聴いている。しかし、もう少しスマートにやれないかな、という気持ちはあった。

そんな気持ちでいた時に、Daphile（https://www.daphile.com/）が今年1月のアップデートでDeezer hifiに対応したのを知って、取り敢えず使ってみた。
以下、その経過をメモ。

まずハードを用意。
処分しようと思いながら置いてあったノートPC、Compaq 6730bを使う。HDDは外してある。
Daphileをインストールするusbメモリスティック。
普段使いのPCに、Daphileのサイトからイメージファイルをダウンロード。64-bit x86、32-bit x86、64-bit x86 with realtime kernel、3種類用意されている。今回はrealtime kernelを使用した。

usbメモリにイメージを書き込み。
6730bにそれを刺し、有線LANケーブルを接続、usb DACを繋ぐ。biosでusbメモリから起動するように設定し起動する。
Daphileのipアドレスを確認しLan経由でウェブブラウザからアクセス。

起動画面のキャプチャとかあれば気が利いてていいんだけど、撮っていない。
画面左側に並んだボタンの中から「settings」をクリック。
設定画面の一番下に「Advanced Media Server Settings」というボタンがあるので、クリック。
上に並んだタグの中から「plugins」をクリック。
ズラッと並んだプラグイン一覧から「Deezer(v1.0)」を探しチェックボックスにチェックして有効化。再起動の操作が必要だったかな。

これだけではまだ使えなくて、一覧表のDeezer(v1.0)表示の右の方、「Logitech」という表記のリンクをクリックし「Logitech Squeezebox」のサイトに飛んで、ユーザー登録する必要がある。手順は忘れたが、登録したらSqueezeboxサイトの「My Apps」にDeezerが登録される。
これで、DaphileでDeezerを使えるようになる。
Deezerの会員じゃないのに登録を試みたらどうなるかは試していない。そんなことする人はいないだろうとはと思うけど。

Daphileの画面に戻って、操作画面左上のボタン「Audio Player」をクリック。
Player操作画面の「My Apps」の中にDeezerのアイコンが表示されるので、そこをクリックしたらDeezerの操作画面に入れる。
このアイコンは直ぐに表示されないことがある。暫く待つうちに表示されるようだ。

大雑把だけどこんな感じ。

Compaq 6730b、Daphileで、Deezerのストリーミング音声データをusb出力からDACに出力。
音質は、44.1/16レベルのちゃんとした音質、そこそこ良好な印象だ。
しかし、web player + pulseaudio + libsamplerateで384kHzにアップサンプリングした音には及ばない。比較したら情報量が少なくて粗っぽい。

しかしギャップレス再生してくれる。
これは大きい。
web player-384kHzは音はいいんだけど、楽曲によってはトラック間で途切れるのは音楽的じゃないし、改善する目途も立っていない。
Daphileの音質を改善して使いたいと思うには十分な理由だ。

libsamplerateでアップサンプリングできるだろうか。
しかしDaphileはそれ自体で完結した音楽用ディストリビューションで、sshによる外部からのアクセス等は出来ないようになっている。つまり、ウェブブラウザからの操作しか基本的に受け付けないので、libsampleratのインストール操作自体が出来ない。
ベータ版ならsshでログイン出来るらしいが、それで弄って使うというのは気乗りしない。Daphileのアップデートに際して困るだろうし、sshでログインできたとして簡単にlibsamplerateが使えるようになるとは限らない。

ならば、LMSレンダラーでやるか。
DaphileはLMS（Logitech Media Server）として機能している。
piCorePlayer（https://www.picoreplayer.org/）をレンダラーにして音声データを送ることができる。
つまり、piCorePlayerにlibsamplerateをインストールするという案。

そんなわけで、まずpiCorePlayerをLMSレンダラーにしてみた。
まず、Raspberry Piを用意。今回使用したのは3B+。
現在、piCorePlayerのバージョンは7.0.0。せっかくなので64Bit Kernel版をダウンロードしmicroSDカードに焼いて3B+に刺す。
LANとusb DACを繋いでusb電源で起動。
この段階では、まだ音は出せない。DACの設定をする必要がある。

ウェブブラウザからpiCorePlayerのipアドレスにアクセス。
操作画面上に表示されたタグ「squeezelite settings」をクリック、Choose audio outputの項目で「USB audio」を選択し「Save」をクリック。続いてpiCorePlayerを再起動。これで音声出力の設定が変更、保存される。
他にイヤホン端子出力を止める設定とかあった気がするが今回は省略。

ここからはDaphileを操作。
操作画面右下で、プレーヤーにpiCorePlayerを選択。
音楽再生の操作をしたらpiCorePlayerに繋いだusb DACから音が出る。

というわけでCompaq 6730b、DahileでLMSを介してDeezerの音声データをpiCprePlayerからusb出力。
音質は悪くない。
しかし、Daphileのusb出力から音出しした時と比べて、意外に大きな向上はないかな、、、
せっかくRaspberry Piを使っているんだから、i2s DACを使うほうが賢いのかもしれない。
そうこうしながらpiCorePlayerにsshでログインして中を見てみたんだけど、libsamplerateをインストールして、というような細工は、僕にはちょっと出来そうにない。

これはお蔵入りか、とも思ったが、試しに電源やusb端子に簡単なノイズ対策をしてみたら、なんだか結構、良くなってきた感じ。
情報量は少ないままだけど音色はいい。粗さが気にならなくなってスムーズになった。
これなら、web player-384kHzと併用しても良さそうだ。なにしろギャップレス再生ができるんだから。

しかし、こうなると残る選択枝は、libsamplerateをインストールしたupnpレンダラーをDaphileに繋ぐ案だ。
Daphileをupnpサーバーとして運用する。
出来るかな、upnpは随分昔に弄ったことはあるけど、、、
まだ手が付いていない。後日、もしも出来たらエントリーにする。

ちょっと余談だけど、Daphileで表示されるDeezerは、web playerのDeezerの表示とは若干違っている。
お気に入り登録の扱いとか、Daphileで再生した曲は、web playerの「最近再生した曲」には表示されないけどアカウントから入る「再生履歴」には表示されるとか、なんだか色々分かっていないことがある。
使ううちに分かっていくだろうと思うが、今の段階では使い勝手はweb playerのほうが良い感じだ。

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はもう少し扱いやすかったらいいと思う。

Deezer Web Playerを使うことがめっきり増えた。主に聴いたことのない音源を追いかける役割を担っている。
これはつまり、最近は一つの音源を繰り返しじっくりという聴き方をすることが減ったということを意味する。
これは実は昔の聴き方に近い。
CD音源を買うことは殆ど無くなった。
今やDeezerはうちのメイン音源になっていて、768kHz-PPAPを鳴らすことが減ってしまっている。

それでもストリーミングだけに一本化はしたくない。
理由の一つは音質。
たまにNAS音源の768kHz-PPAPをSM-SX100で鳴らすとやっぱり良いので、外すわけにいかない。
普段はDeezer-384kHzはM500、Brooklyn Ampに継いでいるが、ときに入れ替えてADI-2 DAC、SM-SX100で鳴らしてみることがある。音質は若干良くなるけど、768kHz-PPAP音源のほうが更に良さそうな感じ。
将来的にpulseaudioで768kHzまでアップサンプリングできるようになったら、どうなるか分からないけど。

もう一つの理由は、音源の保証だ。
ストリーミングサーバーに置かれた音源が、何かの拍子に無くなったら聴けなくなる。
僕は音源提供元への信用が薄いとでもいうのか、いつ何時どんな理由によってか知らないが、特定の音源が消えないとも限らないと思っている。そもそもストリーミング元に音源を置くように契約している著作権保持者がいるはずだ。どういう契約なのか知らないけど、著作権者の都合でストリーミングを止めるとなれば、それまで聴けていた音源が無くなってしまうことになる。

そんな理由で、Deezerで聴けても気に入った音源はCDかダウンロードかで買おうと思っている。
音質の向上と音源確保の保証、両方が理由だ。

そういう運用をしているDeezerだけど、1回聴いた音源をまた聴きたいと思うことも多々ある。
僕の場合、あれって何だったかな、となるのが困る。
音源のイメージだけはあるけど固有名詞が出てこない。こうなると再発見するのが難しい。

Web Playserやアプリの機能を使って「お気に入り」にしておくという手もあるが。登録数が100件ぐらいならなんとかなるけど、今後、数100件以上とかになったらアートワークを見て探すというのは困難になってくると予想する。スクロールも大変だし、検索機能も探せるデータが限られているので、便利とは言い難い。

まず試したのは、うちで借りているレンタルサーバーでサービス提供されているデータベースを使うというアイデア。
phpMyAdminというソフトが使える。
データの登録をDeezer Web Playerが動いているウェブブラウザからできる。

手始めに、長岡鉄男のA級外盤のデータベースを作ってみた。
参考にしたのは、共同通信社から出版されている本2冊と、まとめサイト、Discogs、といったところ。
紹介されているディスク200枚のうち、Deezerには4割強の音源がアップされていることが分かった。長岡A級外盤はレアな音源も多いけど、意外なものがDeezer上にあったりする。

データベースを作りながら同時平行で使って、という感じだったんだけど、使いながら、どうもこれは違うなという感じになってきた。
しっかりした業務用にも使えそうなデータベースで（多分、本来はそういう用途で使うものなのだろう）、見た目は固い感じで、使い方もきちんとしないと上手く使えない。慣れてないのもあるんだろうけど、帯に短し襷に長しという感じなのだ。
もっと気軽、手軽に使いたい。

そこで、うちのブログに使っているblosxomでなんとかならないかと思い付いた。
blosxomというのは手軽で柔軟なのが持ち味だ。

１から構築するのは無理なので「blosxom starter kit」を使う。
https://github.com/blosxom-fanatics/starter-kit/wiki

細かいことは、オーディオとは関係ないし、ここでは省略（後日、気が向いたら別エントリーにでもしようと思う）。
あちこち設定に手を入れて、データベースらしい体裁に整える。
こんな感じ。
http://blown-lei.net/raisin/blosxom.cgi

かなり大雑把でデータの記載もいい加減にしているが、僕が個人的に使うには十分な感じ。
もともとブログキットなので、データ登録をウェブブラウザ上からできる。
検索はデータベース上のデータ全体を広範にカバーするので、細かい指示指定が必要なphpMyAdminの検索よりも手軽に使える。
加えて今回、タグがどのくらい使えるかを試してみようと思っている。ブログではいまいち上手く運用できないと感じたけど、データベースだとどうだろうか。ちなみに、phpMyAdminにはタグはない。

本当は、Roonあたり導入したらこういう悩みは少ないのかもしれないけど、うちのようなイレギュラーな運用の中でどういう納まり方が出来るのか見当も付かない。そもそも使えないかも知れないし。2週間の無料試用期間があるというが、うちで試すには期間が短すぎると感じるのもあって、手を出しにくい（個人的には最低2ヶ月欲しい。甘い？）。

そのうち飽きるか投げ出すか、しばらく運用してみようと思う。

今回も定額ストリーミングサービスの謎について。
忙しいので多くは書かない。

ケニー・ドーハムというジャズアーティストの音源がDeezer上でストリーミングされている。
彼のアルバムのディスコグラフィは、2020.12.22.現在、こんな感じ。

https://www.deezer.com/ja/album/62001562
Kenny Dorham「Inta Somethin'」 | 1962 | CM BLUE NOTE (A92)

上記はオリジナルアルバムのストリーミングアドレス。
Discogsのデータは下記アドレス。
https://www.discogs.com/master/239468

ケニー・ドーハムの他のアルバムについてアドレスをいくつか貼ってみる。

• https://www.deezer.com/ja/album/145612572
  Live Through This | 2020 | LTT brothers music
• https://www.deezer.com/ja/album/166529442
  Salon | 2020 | More Wings in Hell
• https://www.deezer.com/ja/album/149134452
  Out Of Mind | 2020 | OOM 1-20
• https://www.deezer.com/ja/album/136594252
  Time To Relaxe | 2020 | fsp analog 2be
• https://www.deezer.com/ja/album/151288632
  Cheaper Tricks | 2020 | tricki masters mind
• https://www.deezer.com/ja/album/146346482
  Back In The Game | 2020 | the music game companys
• https://www.deezer.com/ja/album/131128892
  A Happy Easter | 2020 | Archive & Catapulte
• https://www.deezer.com/ja/album/116419792
  Xmas Angel | 2019 | xmas angels 11

これら８つのアルバムは「Inta Somethin'」の曲順を変えただけだ。
つまり、オリジナルの1枚のアルバムの曲順を変えた8枚の新譜？が作られて、確認しないと分からないような形で登録されているのである。

タイトルを見たら、なるほど、クリスマスとかイースターとかリラックスとか、そういうニーズで検索して引っかかりそうな名前が付けられている。以前のGigazineの記事にあったような話だ。
ケニー・ドーハムのアルバムには、これってオリジナルじゃないだろ、というようなのが他にもある。
上の画像に載っているアルバムのほとんどがそうなっている。

登録しているレーベルというのか著作権保持者というのか、BLUE NOTEじゃないけど、関連会社なのだろうか。

Live Through This | 2020 | LTT brothers music、ということなんだけど、LTT brothers musicってなに、ってことでグーグル検索。
結果、見つかったアドレスが以下。世界中のamazonだ。

• https://www.amazon.co.jp/dp/B087Z36XCH
  Live Through This - ケニー・ドーハム
• https://www.amazon.co.jp/dp/B087YPDWNX
  Live Through This - ケニー・バレル
• https://www.amazon.it/dp/B087ZCX5QD
  Live Through This - Hugo Montenegro & His Orchestra
• https://www.amazon.es/dp/B087Z7JMTF
  Live Through This - Toots Thielemans
• https://www.amazon.de/dp/B087YKYQQC
  Live Through This - The Dave Brubeck Quartet
• https://www.amazon.fr/dp/B087YTC9YL
  Live Through This - Dizzy Gillespie

ご丁寧に、アルバム名だけではなくアートワークも同じである。
いろんなアーティストがいる。
ここでLTT brothersのLTTというのはLive Through Thisをリリースするということかと気が付く。なんだかなあ、、、

Qobuzでは、こんな感じになっている。
https://www.qobuz.com/fr-fr/label/ltt-brothers-music/download-streaming-albums/1080879

他のレーベル？も、おそらくは似たような感じなのだろう。こういうお金儲けって何なんだろうか。
流れていくお金の透明性って確保されてるんだろうかとか、心配になる。

それとユーザーから見たら、こういう偽造再生リスト紛いがオリジナルと同列で表示されてるのは、紛らわしいこと、この上ないんだけど。
Discogsなどで何がオリジナルなのか調べながら聴かないといけない。

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

思えば、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/