abk1's scratched blog 3

最近のシステム構成は下図のような感じ。上流を若干整理した。

Daphileサーバーはオーディオシステムから離した。音質上の配慮ではなく使い易さの事情だ。音質上の変化もないと思う。
当初はDeezerの再生だけ想定していたんだけど、NASマウントの再生でも使用するようになった。流れというか、ついついというか、いちいちncmpcppを開くのが面倒で、Daphile画面からNASのディレクトリ階層構造をたどって鳴らしている。
本当は、ncmpcppから操作する方がずっと速いのだ。Daphileはいちいち表示に時間がかかる。サクサク快適なのはncmpcppのほうがずっと上だけど、、、
NAS音源再生の音は、Daphileからの操作とncmpcppからの再生では、わずかだがncmpcppのほうが勝る。upmpdcliとnfs、後者の方が負担が少ないということなんだろう。しかし、ふだん聴くのに神経質になるほどの差異ではないので、目の前で開いているDaphileのインターフェイスから操作してしまうということだ。朝三暮四というか怠惰である。
Deezerに置いてない音源もざらにあるので、未だにCDを購入することもあるし、リッピングしたファイルは捨てられない。

DaphileではYoutubeも鳴らすことが出来るらしいんだけど、なんだか手順が複雑で分かりにくく感じられて出来ていない。
そういうわけで、アップサンプリングサーバーのPulseaudioサーバーとしての機能も維持している。Youtubeの音声をサーバーに転送し上限384kHzにアップして再生する手法で、所謂空気録音の試聴とかで使うつもりなんだけど、まだ整備できていない。

FX-08miniを１台戻している。電源アダプターが壊れたので、過去にRaspberry Piに使って意外に好印象だったUSB電源を使って動かしている。
音楽信号が700kHz台の領域とそれ以外を100Base-Tで分ける形になっている。一応これは音質上の配慮なんだけど、おまじないレベルで留まっていて、音の変化があるかどうかの確認をしていない。たぶん、しないまんまになるんじゃないかなあ、、、なんとなく良くなってる気がするで済ませている。

アップサンプリングサーバーのディスクイメージをアップして半月だが、どの程度ダウンロードされているのか、分からない。まあ、それはGoogle Driveの仕様みたいなので仕方ないけど。
もう暫くツイッターのトップには掲示ツイートを留めておこうとは思っている。

柄にもなく今回アップしたのは、今回のイメージは比較的使い易くまとまったので、アップしておく意味もあるかな、と思えたというのが大きい。

数年前にイメージをアップしないのかと訊かれたことはあったんだけど、当時はしなかった。
有志の努力で広く公開され提供されているものを、此方でダウンロードして組み合わせただけで、作ろうと思えば誰でも作れるものを、自分で作ったもの？のようにアップする気にはなれなかったというのが大きかった。
加えて、自分が使っているのが一般的にみて使い易いシステムとは思えなかったというのもあった。使いにくいところに、大したフォローもできないということになれば、興味を持ってダウンロードしてくれた筈の人が興味を失うことになり、そういうのは残念なので。

しかし手前味噌だが、今回アップしたイメージのセットは使い易く出来ていて、アップしてもいいだろうと思った。
初心者でも左程困らずに動かせそうだし、多少マニアックな使い方にも耐えそうだ。
ただ組み合わせただけ、という意味では以前と同じだけど、かかる手間暇の軽減という意味も今回のはあるだろうし、まあ、いいか、という気になった。いろいろネットから世話になっているので成果物を置いとくというのもおかしいが、何処かしら、こっちの気が済むというのがある。自己満足に過ぎないといえば、そうなんだろうけど。

当初からの目的は、libsamplerateの音を実際に聴いてみてほしいというのがあった。
環境を整えた上で聴いたことがある人は、実は少ないのではないかと思うので。
充分にPCのスペックを上げて、300、700kHzとサンプリング周波数を上げてこそ、libsamplerateを使う本当のメリットが生まれてくるというのが僕の実感だ。そういう再生をしてもらって、どんなシステムだとどんな風に聴こえるのか、僕自身が知りたかったというのがある。

そんな手法では聴きたくないという人もいるだろうし、当然そういう人には薦めない。
しかし、どうなのかね、、、
この数年間で、音質改善するいろんな手法が技術的に生まれてきているし、ニーズも興味をもたれることも、あんまりないかもしれない。libsamplerateは使っても意味が無いということになっているようで、いろんな事情で廃れる技術というのはあるんで、それならそれで仕方ないということになるのかも知れないが。

先日アップしたイメージをPPAPに転用する方法について記載した日記をPhile webにアップした。

いや、人に説明するというのは難しいものだ。こっちは分かってるから相手もある程度分かってるかのような気になってしまう。とりあえず、理解してもらう説明は後回しで（というか、それって大変すぎ）、動かせるようにということで書いている。それでも何かしら不備がある。

アップしたイメージのPPAPへの転用について
https://community.phileweb.com/mypage/entry/5010/20210425/67563/

PPAPでの使い方なので、バックエンドもアップした。
両方のイメージファイルを置いてあるGoogleのアドレスを書いておく。

20210418-TC64-mpd-pa-upnp-AutoStart.img
https://drive.google.com/file/d/1eZ-ijekRj-ond1OIa7aZXgLxjWYbsIPy/view?usp=sharing

tc64-11-1-base1z-2020-04-05-PPAP-BE.img
https://drive.google.com/file/d/1kHhCtR4WCWs3_8i32JrVgGFin-YK9KIZ/view?usp=sharing

先日、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がセットが対応する上限設定ということになる。

下記内容の日記をPhile webにアップした。
https://community.phileweb.com/mypage/entry/5010/20210418/67519/

このたび思う処あり、ディスクイメージをGoogleにアップしました。
どなたでも使っていただいて結構です。

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

イメージについて説明します。

１）セット内容とコンセプト：
linux OS（Tiny Core Pure64 11.1）ベースで作成しています。
有線LAN経由でUPnP/DLNAサーバーから信号受信。mpd、upmpdcli、libsamplerate(SRC)で処理し、alsa経由でUSB-DACに出力することを想定しています。
この際にUSB-DACから処理できるフォーマットを読み取り、アップサンプリングします。例えばUSB-DACが対応しているフォーマットの上限が384/32だった場合、そのフォーマットにアップサンプリングしてDACに送るということです。768/32までのアップサンプリングに対応しています。

つまり、このセットはlibsamplerateによるアップサンプリングの音を聴くためのシステムということです。
libsamplerateは以前はmpdのデフォルトとされていましたが、情報処理の負担が大きい割りにメリットが少ないと考えられたようで、最近はSoXによるアップサンプリングが主流です。
しかし、libsamplerateのほうがより正確な音声情報処理が行われ、44.1/16のデータからでもハイレゾファイルと同等の再生音が得られます。特に300、700kHz台で優位性が得られると考えています。処理の負荷は高いので、PCに要求されるスペックは高くなります。700kHz以上にアップサンプリングする場合、DDR3以上のメモリを積んだPCが必要です。

２）使用方法：
イメージをusbメモリ等のストレージに書き込み起動ディスクとします。
Tiny Core Pure64ベースなので、AMD64、Intel64のPCで使用できます。
有線LANにつないでください。無線は対応できていません。

PC起動に際し、BIOSでPC自体のサウンドボードをオフにしてください。こうすることでUSB-DACがalsaから最優先の出力先に選択され、細かい設定をssh経由で行う必要がなくなる筈です。
セットを書き込んだストレージから起動するようにBIOSを設定してください。
無事に起動したら、UPnP/DLNAのコントローラーから「MPD-SRC」を選択し音声出力できる状態になります。

３）その他の機能：
sshでログインし設定など変更可能です。パスは「tc」です。
pulseaudioサーバー、PPAPフロントとして機能させることができます。

04.20. 追記です。-------------
sshでログインに際して、ユーザーは「tc」です。書き忘れていました。
Tiny Core Pure64ベースのセットで、扱い方はTiny Coreそのものです。
mpd.confは、/home/tc/.mpdconfで設定しています。
追記終わり。-------------

出来れば使っていただいた所感を、この記事のコメントで教えていただければ有難いです。
何分にも、このような試みは私自身初めてでもありlinuxのスキルも限られているため、トラブル等のフォローはできないと思いますので、自己責任でお使いください。質問等には可能な限り返信させていただきますが、出来ない場合もありますのでご容赦ください。

以上、宜しくお願いいたします。

思う処あって、ということなんだけど、実際、迷ったけどアップしてみることにした。
どんな反応があるかは分からないが。

うちではlibsamplerate(SRC)なしではオーディオシステム自体が成り立たないというような重要なコーデックであるにも関わらず、世間では意味が無いとされている。世間と書いたが、少なくともpulseaudio界隈ではそうなっている。なるようになるしかないのかもしれないが、意味が無いということはないということを井の中の蛙のようなうちのサイトで書いてるだけではダメかなと思うことがあり、、、まあ、なるようになるだろうということで、イメージをアップしてみたということだ。

僕自身が井の中の蛙だということがある。
他のオーディオファイル諸氏の音を聴いたことがない。うちの音を聴いてもらったことがない。
コロナ禍でいよいよ困難になった。イメージでもアップして試してもらうしかないじゃないか。

そういうわけで、宜しければ使ってみてください。
レスはphile webか、twitter（ https://twitter.com/flyingnote）で受け付けます。