abk1's scratched blog 3

現在のpiCoreの状況がどうなってるのかと思って、確認したことを記録しておく。

なんで突然、piCoreなのかというと、ハードの違いで音が変わるということを思ううちに、そういえば以前はRaspberry Piで鳴らしていたっけと思い、そこから、今はどうなってるんだろうということになったということだ。
piCoreの最新は13になっている。
http://tinycorelinux.net/13.x/armv6/releases/RPi/

nmap.tczは、piCore9まで用意されていて、10はpiCore自体が欠番。11、12ではnmap.tczがリポジトリに用意されていなかった。
しかし現在、piCore13ではnmap.tczがリポジトリに用意されている。ということは、piCore9以前か13だったら簡単にPPAP Back Endを作れるということだ。
http://tinycorelinux.net/13.x/armv6/tcz/

ちなみに、mpd.tczが用意されているのはpiCore7まで。
libmpdclient.tczはpiCore9までだ。
一方、Tiny Coreはというと、Tiny Core x86（32bit版OS）のリポジトリにはmpd-minimal.tcz、libmpdclient.tczが昔から今までずっと用意されている。つまり、実は手軽にmpdを扱うにはこれが一番簡単だ。nmap.tczもあるが、mpd-minimalでpipeが使えるかは確認していない。
http://tinycorelinux.net/13.x/x86/

64bit OSであるx86_64のリポジトリには、mpdが無い。
ソースをダウンロードしてインストールする必要がある。

一方、alsaはというと、piCore11からversion 1.2.2になって、音源のサンプリング周波数が768kHzまで通るようになっている。
piCore9だと、alsaはversion 1.1.1。音源が198kHzまでで良ければ、piCore9以前のバージョンでよくて、300kHz以上なら11以降が必要ということになる。
参考：
Changelog between 1.1.9 and 1.2.1 releases / Alsa Project News
https://www.alsa-project.org/wiki/Changes_v1.1.9_v1.2.1

現在、うちでは768kHz/32bitでPPAP方式を使っていて、Back Endで使っているのはTiny Core Pure 64 v11.0。ハードはapu2だ。
piCore13ならば、768kHzが使えるPPAP Back Endに出来る筈、、、
しかし問題は、Raspberry PiはUSBとLANが同じチップで処理されているんだったかな。Ras Pi4とか、新しいハードだと改善されたらしい？けど、うちに残っているB+とか2とかだと、大量のデータを送るのは、うまくいかない可能性がある。というか、B+とか2とか非力なハードで、768kHz/32bitなんて重い音声データを扱えるんだろうか。

しかしRaspberry Pi とpiCoreでPPAP Back End、apu2と比較できるならしてみたいかな。

せっかくなので、まずはRaspberry Pi B+で試してみる。
以下、工程と設定のメモ。

download
http://tinycorelinux.net/13.x/armv6/releases/RPi/piCore-13.1.0.zip

cmdline.txt add
host=pC131bp

config.txt rewrite
dtparam=audio=off

login
ssh tc@192.168.1.xxx

sudo fdisk -u /dev/mmcblk0
p
d
2
n
p
2
(write number - /dev/mmcblk0p2 / start)
+100M
w

filetool.sh -b
sudo reboot

login
ssh tc@192.168.1.xxx

sudo resize2fs /dev/mmcblk0p2

tce-load -wi nmap.tcz alsa-modules-5.10.77-piCore.tcz alsa.tcz alsa-utils.tcz

vi /opt/bootlocal.sh
/usr/local/bin/ncat -kl 4400 -e "/usr/local/bin/aplay -D hw:0,0 -M --period-size=4096 --buffer-size=16384 -t raw -f S32_LE -r768000 -c2"

vi /opt/eth0.sh
#!/bin/sh
pkill udhcpc
ifconfig eth0 192.168.10.10 netmask 255.255.255.0 broadcast 192.168.10.255 up
route add default gw 192.168.10.1
# echo nameserver 192.168.10.1 > /etc/resolv.conf

chmod +x /opt/eth0.sh

sudo vi /opt/bootsync.sh
/opt/eth0.sh &

filetool.sh -b
sudo reboot

工程終了。
PPAP Middle Endにつないで起動。
Middle Endからsshでログインして、下記コマンドにてUSB DACの認識を確認する。

cat /proc/asound/card0/stream0

音を出してみる。
音は出た。しかし、ノイズだらけで、音楽を聴くというわけにはいかなかった。

Ras Pi2ではどうなのか。

download
http://tinycorelinux.net/13.x/armv7/releases/RPi/piCore-13.1.0.zip

cmdline.txt add
host=pC131b2

tce-load -wi nmap.tcz alsa-modules-5.10.77-piCore-v7.tcz alsa.tcz alsa-utils.tcz

上記以外の工程は同じ。
音は出た。やはりノイズだらけだが、音楽は聞き取れる。音程は正しいのに再生速度が遅い。これでは使えない。

PPAP Front Endでのアップサンプリングを止める。
Back Endの設定も合わせる。

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

これでどうか。
まともな音が出る、けど、、、操作へのレスポンスが遅い。
こんなに遅かったっけ、そういえば遅かったかな、、と思うぐらい遅い。
普段、Daphileとmpdで768kHzにアップして聴いてるのと比べても、なんだか遅い気がする。普段使っているシステムは、再生開始の操作をして音が出るまで数秒かかるけど、ボリューム調整への反応は遅くない。それが、Ras Piだと両方とも遅く感じる。 apu2よりもRas Piのほうが遅いハードだからだろうか。
しかし、DaphileとpiCorePlayerの組み合わせだと、そんなに遅く感じない。
もしかしたらLMSやUPnPは、ユーザーがレスポンスが遅いと感じないように作られているのかもしれない。

あれこれ弄るうちに、Daphileシステムの方も不調になってきた。原因不明、、、全システムをリブート。
システム全体の不調が影響したせいかどうか分からないが、音質も敢えてRas Piで聴きたいと思わせるものがない。

今回はここらで撤退することにした。
残念だが致し方なし。

先日、Google Driveにうちで使っているアップサンプリングサーバーをイメージ化したものをアップした。
Phile Webで記事にしている。

UPnPレンダラー兼アップサンプリングサーバーのディスクイメージをアップしました
https://community.phileweb.com/mypage/entry/5010/20210418/67519/

https://drive.google.com/file/d/1eZ-ijekRj-ond1OIa7aZXgLxjWYbsIPy/view?usp=sharing

うちのシステムそのままだと不便だろうと思ったので、アップする前にいくつか改造を施した。
それらの点についてメモしておく。

１）OSブート時にmpd、upmpdcliが自動的に起動するようにした

うちではmpd、upmpdcliはsshでログインして起動するようにしている。 これを、OS boot時に同時に起動させるようにした。

sudo vi /opt/bootlocal.sh

mpd /home/tc/.mpdconf
adduser upmpdcli -H -D
upmpdcli -D -c /home/tc/.upmpdcliconf


vi .upmpdcliconf

mpdhost = localhost
logfilename = /home/tc/.upmpdcli.log
loglevel = 2
friendlyname = MPD-SRC
mpdport = 6600

これで、mpdはrootで起動する。 upmpdcliはrootでは起動できない仕様なので、ユーザーupmpdcliをboot時に作成し、これを依り代に起動させる。

うちのシステムでは何故こうしていないかというと、mpdがrootで起動していたら「mpd --kill」コマンドが効かないからだ。 mpd.confを書き換え設定変更することが多かったので、たびたびmpdを止める必要があった。いちいちps打ってプロセスidを確認してsudo killとか、面倒でやっていられない。 だから自動起動は不採用になった。

upmpdcliについては、そうした問題はないので採用してもいいんだけど、mpd起動のついでにupmpdcliもコマンド1発で起こせるので、ほったらかしになっているという感じ。この際だから、うちでも使うことにするかもしれない。

２）alsa出力設定を２つにした

mpd.confでalsa出力を設定している。 古いノートPCや、現在のうちのアップサンプリングサーバーでは問題なかったんだけど、新しいノートPC（といっても、10年近く前に発売だけど）でbootしたとき、BIOS設定でPCのサウンドカードをオフにしただけでは音が出ないことがあった。 aplay -lで確認したら、0,0ではなく1,0がUSB-DACに振られている。

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

BIOSでPCのサウンドカードをオンにしたままでPC起動したら、PCのサウンドカードが1,0、USB-DACが2,0になった。 つまり0,0が振られないのだ。

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

なぜこんな仕様になっているのか分からないけど、alsaを設定するのには困る。

対策が見つからなかったので、0,0と1,0、両方にalsa出力するようにmpd.confに記載した。 BIOSでオンボード音声をオフにして、USB-DACひとつだけ繋いだ状態なら、0,0か1,0、どちらかに引っかかって音声出力できるのではないだろうか。 うちにあるいくつかのPCで試した限りでは、問題なく機能した。 こんな感じ。

vi .mpdconf


audio_output {
 type   "alsa"
 name   "My ALSA Device 0"
 device "plughw:0,0"
}
audio_output {
 type   "alsa"
 name   "My ALSA Device 1"
 device "plughw:1,0"
}

３）alsa出力先サウンドカードの設定を変更しフォーマット変更に対応させた

alsaの出力先は、mpd.confで一般的には下記のように記載することが多い。

device "hw:1,0"

以前のエントリーで書いたが「hw:0,0」のような記載だと、mpd.confで指定されたフォーマットに出力が固定される。 うちではそれでいいが、他者が使う想定だと、個々のUSB-DACに設定を合わせないといけない。それには、mpd.confの書き換え、保存という手順が必要で、sshでログインして、viを使わないといけない、なんていうのは扱いにくいだろう。

device "plughw:0,0"

そこで、「plughw:0,0」に設定記載を変更した。 この記載だったら、USB-DACが対応しているフォーマットを、alsaが読み取って調整してくれる。DACが対応している最上限のフォーマットに自動的に合わせるはずだ。 mpd.confに書かれている768/32がセットが対応する上限設定ということになる。

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

前回エントリーで出て来たコマンド「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だとどうなのか、確認したほうがいいんだろうけど、息切れ気味。
このぐらいにしておこうと思う。

7月は岡山も水害があり、仕事の同僚が被災したりして、どうにもブログを書くとかいう気分になれなかった。他にもいろいろあった。
でも、なんとなく最近になってぼちぼちでも再開しようかという気持ちになれたので、書いていこうと思う。

タイトルにあるように、USB電源用のノイズフィルターを自作してみた。
自作と言うのは恥ずかしいぐらいのもので、半田付けしたから自作、みたいな。例によってGNDと+をキャパシタで繋いだだけで、何Hzのノイズを狙ってとか考えもなく、あわよくば高周波を減らせたらいいや、手元にある部品を使って様子を見よう、で作ってしまったようなものである。うちにあるのはそんなのばっかりだ。

オスメスのusb端子はウェブ通販で購入。メス端子のほうに基盤がついていて、オス端子を半田付する。キャパシタは地元の部品屋で購入した0.027μF。
半田付の固定だけでは強度が心許無いので、写真の状態の後、ヒートガンで固めている。
うちのras piに使っているusb電源は、いくつか変遷した後、現在はELECOMのAVA-ACU01という小物になっている。白地に顔が付いたバージョンで、ゆるキャラ系だ。1個500円で売られていたものを複数まとめ買いして携帯の充電に使ったりしていたんだけど、試してみたら意外にいいんじゃないかな、ということでオーディオに使うようになったのだ。
いいといったって、オーディオ用の電源などは試してないので、ほんとうはiPowerとかのほうがいいんだろうなあ、などと思ってるんだけど、3つ買ったら2万円になるし、ちょっと手持ちの部品を試してみてから検討してもいいかな、ということで、やってみた。

結果は、意外にいいような。
音が滑らかになり奥行が出て、微かにまとわりついていたギラつきが消えて音色がより分かりやすくなった。
まだ改善の余地があったと比べて気付いた。
以前からときどき試聴に使っているエネスクのルーマニア狂詩曲2番とか、1年前よりもずっと聴きやすく美しく鳴るようになってきているんだけど、さらに気持ちよく鳴るようになった。

ロック音源の関係で驚いたことは、THe Whoの「Live at Leeds」を聴けるようになったということ。
聴けるってどういうことかというと、僕はこのCD音源を学生のころに購入して、あんまりにも音が悪いと思って聴き通せず中古屋に売った（他の物を買う元手にしないといけないので）という経緯があるのだ。ノイズっぽいし籠っていて精彩を欠くという再生音。ただ、当時のオーディオシステムはトータル数万円のシスコンで、スピーカーは16cm？フルレンジ？にプラスチック製で直径1cmのドームツイーターが付いていて、ツイーターの傍に耳を近づけても音が聞こえなかった。マイルスのトランペットとコルトレーンのサックスを聴き分けられないという代物だった。
しかしその後、これを持っていないというのはロックファンとしていかがなものかという気持ちに負けて、再購入したのである。その後、システムが変わっても良い音だと思ったことは全くなかったし、そもそもパッケージにノイズなんかは気にするなという旨のコメントが予め書かれているのである。最後まで聴き通した記憶が無い。

その音源が、あろうことかTAS Super LP Listに載っているのである。
http://www.theabsolutesound.com/articles/2018-tas-super-lp-list/

まあ、リマスターで再発のアナログ盤なので、初期CDとは別物だろうけど。
しかし、どこにか優秀録音の片鱗があるのかもしれない、聴いてみないといけないと思って聴いてみたら、なんと、意外に聴けるのだ。パチパチノイズが入っている（8794年のCDでリマスター前のものだ。リマスター後は消えている）けど、ロック演奏の生々しさは、確かに音源に記録されていて、最初から最後まで感動を持って聴き通せたのである。
リマスターCDはどうなのよと思って入手したらノイズが消えていて、初期CDより聴きやすくなっている。音が明るいというのかな。ただ何というのか、、、Live at Leedsってなんだか、ヘビーな初期CDのほうが自分には馴染む気がする。好みだろう。
しかしなるほど、名盤とされるだけのことはあるんだこれはと、ロック聴きだして35年でようやく理解するに至った。

TAS Super LP Listはアナログ音源なんだけど、CDでもいいかと思って最近は参考にしている。
ポピュラー系にはLive at Leedsのように意外な音源もアップされていて、どう料理するか考えろというリストなのかなこれは、と思うようになった。

そんなこんなで、電源アダプターのDCラインというのは対策しやすいのかな？と思って、fireface UCXのDC入力プラグに、上記のフィルターと似たような構造のアダプターを作って噛ませてみた。どうだったかというと、こっちは全く駄目で、再生音がこもり覇気がなくなってしまった。
ひとつ覚えではやはり無理みたいだ。
こっちのほうこそiPowerを使ったほうがいいのかな、、、

UCXの電源といえば、1年も前になるかもしれないけど、楽器店で電源アダプターを注文しようとしたことがある。楽器用のものを流用して音質アップを図ろうとしたのだ。受付でにこやかにどういったご要件でしょうか、と尋ねてくるお姉さんに、これこれの代替品の電源アダプターが欲しいんですがと切り出したところ、たちまちお姉さんの表情がかき曇った。そして、何を言われたかは全く覚えていないのだけど、対応できない理由について、なんでそんな顔して話す必要があるのかというような、苦虫をかみ潰したような、親の仇を見るかのような表情で話すのである。こちらは平静を装いながら、いや、難しいんならよろしいんです、、、と精一杯の応答を絞り出したのだった。
いったい、何があったんだろう。

オーディオで気になることは他にもいろいろとあるんだけど、まず、alsaがバージョンアップしてaplayで扱えるサンプリング周波数が上がったこと。

http://www.alsa-project.org/main/index.php/Detailed_changes_v1.1.5_v1.1.6

aplay: Adjust sample rate limits to support newer hardware
There are number of devices that support up to 384 kHz sampling rate and some devices up to 768 kHz sampling rate. This patch increases sanity check limit to 768k in order to support testing of such hardware.

しかし、まだpiCoreには移植されてないんだよね。自分でコンパイルも試みたけど難しい、、、
まあ、使えるようになるまで待とうかと。

これが使えるようになれば、384kHzとか768kHzにアップサンプリングしたPCM音源をPPAPで鳴らすことが出来るかもしれない。
768kHzが使えるDACがCHORDとかRMEから発売されている。
こういうのに入力したらどんな音が出るだろうと思うんだけど、、、
これらのDACは、MQAに対応していない。RMEとかサイトでMQAを推してるのに対応してない。
フィルターとかクロックとかで高度な技術を使っている分だけ、対応に時間がかかるというのはあるんだろうか。
どうしようかなと。

MQAは、誰も言わないみたいだけど、僕が勝手に考えてるのは、見当違いかもしれないけど、PCMよりもジッターの影響を受け難いのではないか、ということ。
つまりノイズ管理やクロック精度の重要性が低くなり、デジタルオーディオの一番厄介な部分の労力が減ることになり、かなり気楽に構えていても安定して良い音が得られるようになる、のではないかと、思ってるのだけど。
あちこちの説明を読むと、PCMには出来ないところに踏み込んだ技術のようだ。
過去のCD導入の時は音がいいと言われながら違ったし、ハイレゾも音がいいと言われながらそうなの？という感じだし、今回は、確かに音がいいと言われながら普及するといいなあと思っている。
でも僕自身、試聴機会がないので、なんとかならないかな、と思っている。

どこから書いたものか。
数ヶ月前、nano iDSD LEが壊れた。
PPAP(piped pcm audio play)のバックエンドをつないで音を出そうとしていたら、音が出なくなってしまったのだ。
うちのDACはfireface UCXのCCモードとi2s DACということになった。
LEは音源のサンプリング周波数をLEDの色で表示する機能があった。
CCモードのUCXは入力信号のサンプリング周波数を表示しない。
iPadをつないでいたら、TotalMix FXの画面から見えるんだろうけど、うちにはiPadはない。
そういうわけで、、、
バックエンドのUSB出力が48kHzにリサンプリングされているのについ最近まで気付かなかった。不覚だった、、、

もしもこれを読んで驚いている人がいたら、すみません。おわびします。

下記のエントリーには加筆訂正を入れました。
piCore7でppap (piped pcm audio play)を試みる
http://blown-lei.net/endive/blosxom.cgi/audio_diary/20180301a.htm

それでも、やはりPPAPの音はいい。
サンプリングの良し悪しなんかより、バックエンドで負担軽減のほうがずっと音質改善につながるってことなのかな、、、
感心したり凹んだりしていてもしょうがないので、ちょっとなんとかしようということになる。

なんで気付いたのか書いておかないといけない。

実はずいぶん前にTEAC UD-501を入手していた。
半額以下で売られていて、もともと興味があった機種だったので、迷った末に入手して、したはいいけど、なかなか出番がなくて死蔵していた。
LEから音が出なくなって、使ってみようかとも思ったけど、体調不良もあって伸び伸びに。
体調が回復して、数日前に思い出してつないでみた。
UCXに出力してるのと同じ96kHzで送ったら、UD-501のインジケーターに48kHzと表示されて、あれー？？？、ということに。

バックエンドにsshでログインして「cat /proc/asound/card*/pcm0p/sub0/hw_params」と打ってみたら「48000」と表示が。
フロントではどうかというと、フロントではalsaは働いていないので「No such file or directory」と表示される。
そうなんだよね、、、だから確認する手段が全くなかったわけではないのだ。
今から思えばだけど、抜けていて気付いてない。

最初は何で48kHzに変換されるのか分からず戸惑ったけど、48kHzといえば、、、というので思い出した。
alsaはデフォルトで48kHzに変換することがある。

過去にあげたエントリー↓5年前だけど、もっと遥か昔のような気がする、、、

http://blown-lei.net/endive/blosxom.cgi/audio_diary/20130302a.htm

mpdを終了し、mpd.confを編集する。

##	device		"hw:0,0"	# optional

文頭の##を削除して保存。
mpdを再起動する。

ALSAはデフォルトでdmixを有効にしている。
5年前はmpd.confのalsaの設定で修正した。
PPAPのバックエンドで同じ手は使えない。どこで設定したらいいのか、、、
alsaのサイトで手がかりがないか探す。

https://www.alsa-project.org/main/index.php/Asoundrc
Asoundrc - AlsaProject

Some notes:

The dmix PCM name is already defined in the global configuration file /usr/share/alsa/alsa.conf.

- The default sample rate for this device is 48000Hz. If you would like to change it use:

aplay -D"plug:'dmix:RATE=44100'" test.wav

- An example command for dmix plugin to use 44100Hz sample-rate and hw:1,0 output device:

aplay -Dplug:\'dmix:SLAVE=\"hw:1,0\",RATE=44100\' test.wav

わからん。 /usr/share/alsa/alsa.confは、piCoreにはない。
それに-D"plug:'dmix:RATE=44100'"って結局dmix使ってるんじゃ？

そういえば、lightMPDはどうしてるんだろう、、、
ということで、今一度、rpi2-smpdplayer-usb-20180103の中を探ってみる、、、
以前、うちのシステムにつなごうとしたことがあったんだけど、結局はよく分からず上手くいかなかった。
何か参考にできないか、、、

smpdplayer.confの中にこんな記載を見つける。

APLAY_ARGS="-D hw:0,0 --test-nowait -q -M --period-size=384 --buffer-size=21888 -t raw -f cd"

これってaplayコマンドのオプションそのものだよね、、、
これを参考に「-D hw:0,0」をうちのシステムに書き込んでみたけど、、、残念、動かない。

hw:がキーワードかな、、、あれこれネット上を探して次に参考にしたのがこちら。

http://takuya-1st.hatenablog.jp/entry/2016/04/18/011246
Raspberry Pi のオーディオ・デバイスを指定して音を再生する。 - それマグで！

aplay -D plughw:1,0 /usr/share/sounds/alsa/Front_Left.wav

こんな書き方があるのか、、、
これを参考に、うちのPPAP バックエンドの/opt/bootlocal.shを以下のように書き換える。

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

これで、ビンゴ！
UD-501のインジケーターに96kHzが表示されるようになりました！

そんなこんなで、fireface UCXにCCモード上限の96kHzで入力できるようになった。
バックエンドで「cat /proc/asound/card*/pcm0p/sub0/hw_params」を打つと「96000」と表示される。

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

UD-501はどうかといえば、192kHzまではPPAPで使える。384kHzは音が途切れ途切れで使えない。
NASマウントmpdからのUSB出力で、NAS音源の384kHzハイレゾを鳴らせないなら、PPAPで384kHzを鳴らせないのもRasberry pi2のLAN/USB周りの限界ということになるかと思う。
やってみたら、問題なく鳴る。
ということは、うちのPPAPの何処かに348kHzを送れない原因があるということだ。

この辺は今後の課題だ。

それにしても、UCXで気付かずに聴いていた48kHzの音はなんだか良かった。
このサイトの５年前のエントリーにも、48kHzのときのほうがゆったりして暖かい音が出ていた印象があるとか書いている。
今回の顛末で感じている印象も５年前と同じなのだ。-D plughw:0,0を書き込んだバックエンドから出る音は以前よりもクールで、それは48kHzにしても同様だ。

これはもしかしたら、dmixの音なのかもしれないと思い至った。
前々回のエントリーで書いた、mpdの設定で「mixer_type "software"」を記述する場所によって音色が違う気がする、というのも、alsaの項目内に書けばdmixが働き、そうでないなら働かないとしたら、なんとなく音色が違うのも辻褄が合う。
どんなものだろうか。