abk1's scratched blog 3

前回エントリーから1ヶ月。
LMSのサポートが頑張り、Deezerは現在、使えている。

しかしDeezerとLMSが連携しているわけではないので（LMSはDeezerから無視されている。たぶん、良くも悪くも）、いつまたどうなるか、保証は出来ないようだ。そして、こういったことは他のサブスクサービスについても同じ状況、ということだ。
LMSはうちのシステムでストリーミング音源を聴くにあたり、極めて便利で音質上も無くてはならないものなので、多少のリスクはあっても使用継続していく方針。

うちのシステムの現状は、以下のような感じ。

いろいろ追加になって、図も大きくなっている。
以下、変更点を書いていく。

時系列でいきますか。
Daphile（LMS）でDeezerが使えなくなった頃、WiiM Miniを入手している。これの光出力に繋いでMQAを再生するためにS.M.S.L M300SEを入手した（現在はDeezerが使えるようになったので、出番は少なくなっている）。
同時期に、piCorePlayerが不調になり、外してしまった。
このときの経緯は、下記エントリーで書いている。
http://blown-lei.net/endive/blosxom.cgi/audio_diary/20240216a.htm

次に、古くなり不調になったサーバーをあれこれ入れ替え。
Logitech Media Server（現Lyrion Music Server）をMac mini (2010 mid)にインストールした。OSは、あれこれあってFedoraである。
Daphileは、この頃から外している。
経緯は下記エントリーに記載。
http://blown-lei.net/endive/blosxom.cgi/audio_diary/20240310a.htm
http://blown-lei.net/endive/blosxom.cgi/audio_diary/20240324a.htm
http://blown-lei.net/endive/blosxom.cgi/audio_diary/20240405a.htm

なんか、ごちゃごちゃしていて読みにくい。実際、この頃はごちゃごちゃ面倒臭かった。

さて、Roonもあるのだけど、実はうちでは殆ど運用していない。
一番使っているのは、Deezer-LMS-MPDで、次にNAS-MPD。
それでもシステムとして保持しておいた方がいいのかな、と思って、月々のお金を払っているような状況だ。Deezerがどうなるか分からないし、Qobuzが使えるようになったら、というのもある。

これも、なんやかやで、Raspberry Pi 2b が2台、Roon BridgeとPPAP Back-Endが追加になっている。
経緯は下記エントリーに記載。
http://blown-lei.net/endive/blosxom.cgi/audio_diary/20240524a.htm

信号伝送経路が増えたので、コントローラーも増えている。
650 G1からLMS、MPDを操作することが多いんだけど、タブレットからRoon、WiiMを操作することもたまにある。Mac mini M2は、Roonで細かい操作をするのに使うので、図に書き込んでいる。

MPDサーバーにはUSB HDDドライブを音源倉庫として繋いでいるんだけど、結果、使っていない。音が良いのは確かなので、手が空いていったときにデータを入れていきたいと思っている。しかし、何時になるやらだ。

ざっとこんな感じ。
ごちゃごちゃしているのでもう少し整理したいけど、それも面倒で、当面、こんなでいくと思う。

今回は、メモだけだ。

Logitech Media Serverは、Lyrion Music Serverに名称変更した。3月末のことらしい。

Lyrion Music Server
https://lyrion.org/

Lyrion Community
https://forums.slimdevices.com/forum/user-forums/general-discussion/1691649-please-welcome-lyrion-music-server-request-for-artwork-contributions

Wikipediaもいつの間にか書き換えられている。

https://en.wikipedia.org/wiki/Logitech_Media_Server

Lyrion Music Server (formerly Logitech Media Server, SlimServer, SqueezeCenter and Squeezebox Server) is a streaming audio server supported by the LMS community and formerly supported by Logitech, developed in particular to support their Squeezebox range of digital audio receivers.

どうやら、Logitechのサポートから完全にコミュニティによるサポートに移行するにあたり、名称変更したらしい。

そんなLMSなんだけど、4月下旬の時点で、Deezerのサポートが回復している（但し、DeezerはPremium、Duo、Familyと、3つのプランがあるのだけど、Premium以外に対応出来るのかどうかは分からない）。

Daphileも、LMSのアップデートを受ける形で5月上旬にアップデートされて、Deezerが使えるようになったようだ。
同時に、Spotify、TIDAL、Qobuz、YouTubeへの対応も戻った様子。

https://daphile.com/
https://daphile.com/firmware/stable/CHANGES

2024-05-09 version 24.05 (x86_64, x86_64-rt & i486) changes:
- Sorry for the long delay....
- LMS update to 8.5.2 (Git commit 1b0ebb5 on May 9th, 2024)
- Mysqueezebox.com integration removed in LMS 8.5
- Perl upgrade to 5.38 version
- Perl Crypt::Blowfish added to improve Deezer plugin performance
- Streaming plugins tested to work for now:
  - Spotty v4.10.1
  - TIDAL v1.4.6
  - Qobuz v3.5.0
  - Deezer v2.81.4
  - YouTube v0.212
(# snip #)

Deezerプラグインの使い方について、メモ。
ごく簡単に。
下記のurlを参照。

lms-deezer/README · GitHub
https://github.com/philippe44/lms-deezer/blob/main/README.md

Installation

To install the lms-deezer plugin:
1 Open your Logitech Media Server (LMS).
2 Go to the server settings.
3 Navigate to the plugins tab.
4 Search for lms-deezer in the available plugins list.
5 Select lms-deezer and follow the on-screen instructions to install it.

Configuration

After installing the lms-deezer plugin, follow these steps to configure it:
1 Open your web browser and log in to Deezer.
2 Once logged in, open your browser's developer tools (usually F12 or Ctrl+Shift+I).
3 Go to the cookies tab and find the cookie named arl for www.deezer.com.
4 Copy the value of this cookie.
5 Go back to the lms-deezer plugin settings in LMS.
6 Paste the arl cookie value into the designated field.

If the ARL code is not entered, you will be able to browse song lists but will not be able to play the audio files.

今回「ARL code」というのを使うのがちょっとハードルだけど、やってみたら簡単だ。

さて先日、Ras Pi 3b+をroon bridgeにしたのだけど、これにmpd、upmpdcliをインストールする前に、まずは、かなり旧式になったRaspberry Pi B+で何かできないかと考えた。B+はいくつか残っていて、使えるものなら使いたい。
そんなことを考えたせいで、あれこれといじることになった。

以下、顛末の記録。
このエントリーは長い。やたら長い。
自分でもどうかと思うが、備忘録だからある程度仕方ない。

というわけで、mpdなど諸々のインストールをどうするか。
mpd
https://www.musicpd.org/download.html

https://www.musicpd.org/news/2023/12/mpd-0-23-15-released/
mesonが要る。
https://www.musicpd.org/news/2018/10/mpd-0-20-23-released/
こっちは要らない。

libmpdclient https://www.musicpd.org/news/2023/12/libmpdclient-2-22-released/
こっちはmesonが要る。
https://www.musicpd.org/news/2021/11/libmpdclient-2-20-released/
こっちは要らない。

それから、 upmpdcli https://www.lesbonscomptes.com/upmpdcli/
https://www.lesbonscomptes.com/upmpdcli/pages/downloads.html
https://www.lesbonscomptes.com/upmpdcli/pages/upmpdcli-manual.html#UPMPDCLI-BUILDING
こちらも最新はmeson。
autotoolsでインストール出来るのは前のバージョンだ。

piCore、Tiny Coreでは、インストールしたソフトウェアをtczファイルという形式に固めて格納する。mesonでインストールすると、それがやりにくいのだ。
2019年にはそうだった。
今はどうなっているだろう。
最新でやってみるか、mesonでやろう。ということで、やってみるということだ。

まず、普段使用のPCにlibmpdclient-2.22をダウンロード。
https://www.musicpd.org/download/libmpdclient/2/libmpdclient-2.22.tar.xz
展開し、README.rstを確認。必要な環境を確認。

You need:
- a C99 compliant compiler (e.g. gcc)
- `Meson 0.56 `__ and `Ninja `__
Run ``meson``:
meson setup output
Compile and install::
ninja -C output
ninja -C output install

次にmpd。
https://www.musicpd.org/download/mpd/0.23/mpd-0.23.15.tar.xz
README.mdを確認。
For basic installation instructions
[read the manual](https://www.musicpd.org/doc/user/install.html).
ネット上の説明を読めということらしいので、読む。

In any case, you need:
a C++17 compiler (e.g. GCC 8 or clang 7)
Meson 0.56.0 and Ninja
Boost 1.58
pkg-config

次、upmpdcli。
https://www.lesbonscomptes.com/upmpdcli/pages/upmpdcli-manual.html#UPMPDCLI-BUILDING

For building from source, you will need a C++ compiler with C++17 support, and the development packages for the supporting libraries: libcurl, libmicrohttpd, libmpdclient, and possibly expat, depending on configuration options.
Also the Python modules for streaming service support use the python3-requests package, so you may need to install it (it is only needed at run time).
Older releases of the packages used the GNU autotools for building. Newer releases (and current git code) use meson and ninja. The change releases were libnpupnp 6.1.2, libupnpp 0.26.3 and upmpdcli 1.8.10.

（グーグル翻訳）
ソースからビルドするには、C++17 をサポートする C++ コンパイラーと、構成オプションに応じてサポート ライブラリ (libcurl、libmicrohttpd、libmpdclient、および場合によっては expat) の開発パッケージが必要です。 また、ストリーミング サービス サポート用の Python モジュールは python3-requests パッケージを使用するため、インストールする必要がある場合があります (実行時のみ必要です)。 パッケージの古いリリースでは、ビルドに GNU オートツールを使用していました。新しいリリース (および現在の git コード) では、meson と ninja が使用されます。変更リリースは、libnpupnp 6.1.2、libupnpp 0.26.3、および upmpdcli 1.8.10 でした。

必要な環境がある程度分かったところで、下記からpiCoreのイメージをダウンロード。Ras Pi b+なので、armv6。
http://tinycorelinux.net/14.x/armv6/releases/RPi/
http://tinycorelinux.net/14.x/armv6/releases/RPi/piCore-14.1.0.zip

リポジトリは下記。
http://tinycorelinux.net/14.x/armv6/tcz/

imgファイルをmicroSDに焼いて、cmdline.txt にhost=pC141bpと追記、config.txtを編集しイヤホンジャックを止めて、ラズパイに刺して電源を入れる。無事、起動した。
sshでログインし、filetool.sh -bでsshの鍵を保存する。
パーティションを拡張。2Gも足しとけばよかろう。

libmpdcliantの要求で、gcc、etcをインストール。
ついでに、どうせ要るであろうsquashfs-toolsもインストール。
tce-load -wi gcc.tcz gcc_libs.tcz gcc_libs-dev.tcz gcc_base-dev.tcz meson.tcz ninja.tcz squashfs-tools.tcz

mpdの要求で以下、インストールだ。
tce-load -wi boost-dev.tcz boost.tcz pkg-config.tcz

upmpdcli,以下、インストール。
tce-load -wi curl.tcz curl-dev.tcz libmicrohttpd.tcz libmicrohttpd-dev.tcz expat2.tcz expat2.tcz expat2-dev.tcz

加えて、PPAPで動かすつもりならnmapをインストールする必要がある。
あと、alsa関連も一応。
tce-load -wi nmap.tcz
tce-load -wi alsa-modules-6.1.68-piCore.tcz alsa.tcz alsa-utils.tcz alsa-utils-doc.tcz alsa-utils-locale.tcz alsa-plugins.tcz alsa-plugins-dev.tcz

以上で、準備完了、かな。

インストールは、libmpdclient、upmpdcli、mpd の順序で行う。

libmpdclient

wget https://www.musicpd.org/download/libmpdclient/2/libmpdclient-2.22.tar.xz
tar Jxfv *tar.xz

tc@pC141bp:~$ ls
libmpdclient-2.22/    	libmpdclient-2.22.tar.xz
tc@pC141bp:~$ ls *22
AUTHORS        	README.rst     	libmpdclient.ld	src/
LICENSES/      	doc/           	meson.build    	test/
NEWS           	include/       	meson_options.txt  test.ld
tc@pC141bp:~$
tc@pC141bp:~$ cd *22
tc@pC141bp:~/libmpdclient-2.22$ mkdir ../libmpdclient
tc@pC141bp:~/libmpdclient-2.22$ meson . ../libmpdclient
The Meson build system
Version: 1.1.0
Source dir: /home/tc/libmpdclient-2.22
Build dir: /home/tc/libmpdclient
Build type: native build
Project name: libmpdclient
Project version: 2.22

meson.build:1:0: ERROR: Unable to detect linker for compiler `cc -Wl,--version`
stdout:
stderr: collect2 version 12.2.0
[cannot find ld] -plugin /tmp/tcloop/gcc/usr/local/bin/../lib/gcc/armv7l-unknown-linux-gnueabihf/12.2.0/liblto_plugin.so   # ( snip ) #
collect2: fatal error: cannot find 'ld'
compilation terminated.

A full log can be found at /home/tc/libmpdclient/meson-logs/meson-log.txt
WARNING: Running the setup command as `meson [options]` instead of `meson setup [options]` is ambiguous and deprecated.
tc@pC141bp:~/libmpdclient-2.22$

エラーを吐いて止まってしまった。何が足りないんだ。
ldってなに。
https://stackoverflow.com/questions/35970824/gcc-collect2-fatal-error-cannot-find-ld
これを参考にする。
tc@pC141bp:~/libmpdclient-2.22$ export PATH=$PATH:/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin
これは効果なし。
gcc入ってるから要らないと思ったけど、clang入れてみるか。

tce-load -wi clang.tcz

これで、意外にたくさんのtczファイルが追加インストールされる。
出来るかな。

tc@pC141bp:~/libmpdclient-2.22$ meson . ../libmpdclient
The Meson build system
Version: 1.1.0
Source dir: /home/tc/libmpdclient-2.22
Build dir: /home/tc/libmpdclient
Build type: native build
Project name: libmpdclient
Project version: 2.22
C compiler for the host machine: cc (gcc 12.2.0 "cc (piCore) 12.2.0")
C linker for the host machine: cc ld.bfd 2.39
Host machine cpu family: arm
Host machine cpu: armv6l
Checking for function "strndup" : YES
Checking for function "getaddrinfo" : YES
Configuring config.h using configuration
Compiler for C supports arguments -Wcast-align: YES
Compiler for C supports arguments -Wcast-qual: YES
Compiler for C supports arguments -Wdouble-promotion: YES
Compiler for C supports arguments -Wfloat-equal: YES
Compiler for C supports arguments -Wmissing-declarations: YES
Compiler for C supports arguments -Wmissing-noreturn: YES
Compiler for C supports arguments -Wmissing-format-attribute: YES
Compiler for C supports arguments -Wmissing-prototypes: YES
Compiler for C supports arguments -Wno-deprecated-declarations: YES
Compiler for C supports arguments -Wpointer-arith: YES
Compiler for C supports arguments -Wredundant-decls: YES
Compiler for C supports arguments -Wshadow: YES
Compiler for C supports arguments -Wstrict-prototypes: YES
Compiler for C supports arguments -Wundef: YES
Compiler for C supports arguments -Wunused: YES
Compiler for C supports arguments -Wwrite-strings: YES
Compiler for C supports arguments -Wunreachable-code-aggressive: NO
Compiler for C supports link arguments -Wl,--version-script=/home/tc/libmpdclient-2.22/test.ld: YES
Configuring version.h using configuration
Build targets in project: 2

Found ninja-1.10.0 at /usr/local/bin/ninja
WARNING: Running the setup command as `meson [options]` instead of `meson setup [options]` is ambiguous and deprecated.
tc@pC141bp:~/libmpdclient-2.22$

警告出てるけどいけたかな。clang、要るんだな。では、ninjaでビルド、インストールだ。

tc@pC141bp:~/libmpdclient-2.22$ ninja -C ../libmpdclient
ninja: Entering directory `../libmpdclient'
[60/60] Linking target example
tc@pC141bp:~/libmpdclient-2.22$

tc@pC141bp:~/libmpdclient-2.22$ sudo ninja -C ../libmpdclient install
ninja: Entering directory `../libmpdclient'
[0/1] Installing files.
Installing libmpdclient.so.2.22 to /usr/local/lib
Installing /home/tc/libmpdclient-2.22/include/mpd/async.h to /usr/local/include/mpd/
Installing /home/tc/libmpdclient-2.22/include/mpd/audio_format.h to /usr/local/include/mpd/
Installing /home/tc/libmpdclient-2.22/include/mpd/client.h to /usr/local/include/mpd/
Installing /home/tc/libmpdclient-2.22/include/mpd/capabilities.h to /usr/local/include/mpd/
Installing /home/tc/libmpdclient-2.22/include/mpd/compiler.h to /usr/local/include/mpd/
Installing /home/tc/libmpdclient-2.22/include/mpd/connection.h to /usr/local/include/mpd/
Installing /home/tc/libmpdclient-2.22/include/mpd/database.h to /usr/local/include/mpd/
Installing /home/tc/libmpdclient-2.22/include/mpd/directory.h to /usr/local/include/mpd/
Installing /home/tc/libmpdclient-2.22/include/mpd/entity.h to /usr/local/include/mpd/
Installing /home/tc/libmpdclient-2.22/include/mpd/error.h to /usr/local/include/mpd/
Installing /home/tc/libmpdclient-2.22/include/mpd/fingerprint.h to /usr/local/include/mpd/
Installing /home/tc/libmpdclient-2.22/include/mpd/idle.h to /usr/local/include/mpd/
Installing /home/tc/libmpdclient-2.22/include/mpd/list.h to /usr/local/include/mpd/
Installing /home/tc/libmpdclient-2.22/include/mpd/mixer.h to /usr/local/include/mpd/
Installing /home/tc/libmpdclient-2.22/include/mpd/mount.h to /usr/local/include/mpd/
Installing /home/tc/libmpdclient-2.22/include/mpd/neighbor.h to /usr/local/include/mpd/
Installing /home/tc/libmpdclient-2.22/include/mpd/parser.h to /usr/local/include/mpd/
Installing /home/tc/libmpdclient-2.22/include/mpd/partition.h to /usr/local/include/mpd/
Installing /home/tc/libmpdclient-2.22/include/mpd/password.h to /usr/local/include/mpd/
Installing /home/tc/libmpdclient-2.22/include/mpd/player.h to /usr/local/include/mpd/
Installing /home/tc/libmpdclient-2.22/include/mpd/playlist.h to /usr/local/include/mpd/
Installing /home/tc/libmpdclient-2.22/include/mpd/position.h to /usr/local/include/mpd/
Installing /home/tc/libmpdclient-2.22/include/mpd/protocol.h to /usr/local/include/mpd/
Installing /home/tc/libmpdclient-2.22/include/mpd/queue.h to /usr/local/include/mpd/
Installing /home/tc/libmpdclient-2.22/include/mpd/recv.h to /usr/local/include/mpd/
Installing /home/tc/libmpdclient-2.22/include/mpd/replay_gain.h to /usr/local/include/mpd/
Installing /home/tc/libmpdclient-2.22/include/mpd/response.h to /usr/local/include/mpd/
Installing /home/tc/libmpdclient-2.22/include/mpd/send.h to /usr/local/include/mpd/
Installing /home/tc/libmpdclient-2.22/include/mpd/status.h to /usr/local/include/mpd/
Installing /home/tc/libmpdclient-2.22/include/mpd/stats.h to /usr/local/include/mpd/
Installing /home/tc/libmpdclient-2.22/include/mpd/tag.h to /usr/local/include/mpd/
Installing /home/tc/libmpdclient-2.22/include/mpd/output.h to /usr/local/include/mpd/
Installing /home/tc/libmpdclient-2.22/include/mpd/pair.h to /usr/local/include/mpd/
Installing /home/tc/libmpdclient-2.22/include/mpd/search.h to /usr/local/include/mpd/
Installing /home/tc/libmpdclient-2.22/include/mpd/socket.h to /usr/local/include/mpd/
Installing /home/tc/libmpdclient-2.22/include/mpd/song.h to /usr/local/include/mpd/
Installing /home/tc/libmpdclient-2.22/include/mpd/sticker.h to /usr/local/include/mpd/
Installing /home/tc/libmpdclient-2.22/include/mpd/settings.h to /usr/local/include/mpd/
Installing /home/tc/libmpdclient-2.22/include/mpd/message.h to /usr/local/include/mpd/
Installing /home/tc/libmpdclient-2.22/include/mpd/binary.h to /usr/local/include/mpd/
Installing /home/tc/libmpdclient-2.22/include/mpd/albumart.h to /usr/local/include/mpd/
Installing /home/tc/libmpdclient-2.22/include/mpd/readpicture.h to /usr/local/include/mpd/
Installing /home/tc/libmpdclient/include/mpd/version.h to /usr/local/include/mpd/
Installing /home/tc/libmpdclient-2.22/AUTHORS to /usr/local/share/doc/libmpdclient
Installing /home/tc/libmpdclient-2.22/LICENSES/BSD-2-Clause.txt to /usr/local/share/doc/libmpdclient
Installing /home/tc/libmpdclient-2.22/LICENSES/BSD-3-Clause.txt to /usr/local/share/doc/libmpdclient
Installing /home/tc/libmpdclient-2.22/NEWS to /usr/local/share/doc/libmpdclient
Installing /home/tc/libmpdclient-2.22/README.rst to /usr/local/share/doc/libmpdclient
Installing /home/tc/libmpdclient/meson-private/libmpdclient.pc to /usr/local/lib/pkgconfig
Installing symlink pointing to libmpdclient.so.2.22 to /usr/local/lib/libmpdclient.so.2
Installing symlink pointing to libmpdclient.so.2 to /usr/local/lib/libmpdclient.so
tc@pC141bp:~/libmpdclient-2.22$

おおおおおお、、、どうすべこれ。
よく見たら、

/usr/local/lib/libmpdclient.so.2.22
/usr/local/include/mpd/
/usr/local/share/doc/libmpdclient/
/usr/local/lib/pkgconfig/libmpdclient.pc
/usr/local/lib/libmpdclient.so.2
/usr/local/lib/libmpdclient.so

以上を、取りまとめたら、いいらしい、のかな。めんどくさいなあ、、、

tc@pC141bp:~$ cd
tc@pC141bp:~$ mkdir libmpdclientx
tc@pC141bp:~$ mkdir libmpdclientx/usr
tc@pC141bp:~$ mkdir libmpdclientx/usr/local
tc@pC141bp:~$ mkdir libmpdclientx/usr/local/lib
tc@pC141bp:~$ mkdir libmpdclientx/usr/local/include
tc@pC141bp:~$ mkdir libmpdclientx/usr/local/share
tc@pC141bp:~$ cp -R /usr/local/lib/libmpdclient.so.2.22 libmpdclientx/usr/local/lib
tc@pC141bp:~$ cp -R /usr/local/include/mpd libmpdclientx/usr/local/include
tc@pC141bp:~$ mkdir libmpdclientx/usr/local/share/doc
tc@pC141bp:~$ cp -R /usr/local/share/doc/libmpdclient libmpdclientx/usr/local/share/doc
tc@pC141bp:~$ cp -R /usr/local/lib/libmpdclient.so.2 libmpdclientx/usr/local/lib
tc@pC141bp:~$ cp -R /usr/local/lib/libmpdclient.so libmpdclientx/usr/local/lib
tc@pC141bp:~$
tc@pC141bp:~$ mksquashfs libmpdclientx libmpdclient-2.22.tcz
Parallel mksquashfs: Using 1 processor
Creating 4.0 filesystem on libmpdclient-2.22.tcz, block size 4096.
[=========================================================-] 187/187 100%

Exportable Squashfs 4.0 filesystem, gzip compressed, data block size 4096
    compressed data, compressed metadata, compressed fragments,
    no xattrs, compressed ids
    duplicates are removed
Filesystem size 203.33 Kbytes (0.20 Mbytes)
    32.18% of uncompressed filesystem size (631.84 Kbytes)
Inode table size 1014 bytes (0.99 Kbytes)
    39.56% of uncompressed inode table size (2563 bytes)
Directory table size 701 bytes (0.68 Kbytes)
    63.10% of uncompressed directory table size (1111 bytes)
Number of duplicate files found 0
Number of inodes 60
Number of files 49
Number of fragments 17
Number of symbolic links 2
Number of device nodes 0
Number of fifo nodes 0
Number of socket nodes 0
Number of directories 9
Number of hard-links 0
Number of ids (unique uids + gids) 2
Number of uids 1
    tc (1001)
Number of gids 1
    staff (50)
tc@pC141bp:~$ md5sum libmpdclient-2.22.tcz > libmpdclient-2.22.tcz.md5.txt
tc@pC141bp:~$ ls
libmpdclient/              	libmpdclient-2.22.tcz
libmpdclient-2.22/         	libmpdclient-2.22.tcz.md5.txt
libmpdclient-2.22.tar.xz   	libmpdclientx/
tc@pC141bp:~$
tc@pC141bp:~$ ls /mnt/*2/tce
mydata.tgz  onboot.lst  ondemand/   optional/
tc@pC141bp:~$ sudo mv *tcz* /mnt/*2/tce/optional
tc@pC141bp:~$ sudo vi /mnt/*2/tce/onboot.lst
(# libmpdclient-2.22.tcz 書き込み)
tc@pC141bp:~$
tc@pC141bp:~$ ls
libmpdclient/         	libmpdclient-2.22.tar.xz
libmpdclient-2.22/    	libmpdclientx/
tc@pC141bp:~$ rm -rf lib*
tc@pC141bp:~$ filetool.sh -b

libmpdclient、インストール終了。手間がかかる。2019年のときとやり方は変わらん。
まあいい、次はupmpdcliだ。

upmpdcli

え、、、え？！、Deezer Plugin、ってなに！
2021年、upmpdcli 1.5.9からDeezerに対応したようだ。
Qobuz、Tidalはもう少し古くて、Upmpdcli 1.2.0からのようだ。2017年より以前のことだ。Spotifyのプラグインはない。
python3-requests パッケージが要るって、これのことか。
どうやって使うのだろう。
https://www.lesbonscomptes.com/upmpdcli/pages/upmpdcli-manual.html#UPMPDCLI-MS-STR
上記の記載によると、昨年秋にDeezerは使えなくなったとのこと。なんとまあ。

まあいい、とりあえず、以下、順次インストールする。

libnpupnp-6.1.2.tar.gz
libupnpp-0.26.4.tar.gz
upmpdcli-1.8.11.tar.gz

まず、libnpupnp

tc@pC141bp:~$ wget https://www.lesbonscomptes.com/upmpdcli/downloads/libnpupnp-6.1.2.tar.gz
Connecting to www.lesbonscomptes.com (62.210.16.61:443)
saving to 'libnpupnp-6.1.2.tar.gz'
libnpupnp-6.1.2.tar. 100% |*********************************************************************|  436k  0:00:00 ETA
'libnpupnp-6.1.2.tar.gz' saved
tc@pC141bp:~$ tar xf lib*
tc@pC141bp:~$ ls
libnpupnp-6.1.2/    	libnpupnp-6.1.2.tar.gz
tc@pC141bp:~$ vi .ash_h*
tc@pC141bp:~$ cd *2
tc@pC141bp:~/libnpupnp-6.1.2$ mkdir ../libnpupnpx
tc@pC141bp:~/libnpupnp-6.1.2$ meson setup . ../libnpupnpx
The Meson build system
Version: 1.1.0
Source dir: /home/tc/libnpupnp-6.1.2
Build dir: /home/tc/libnpupnpx
Build type: native build
Project name: libnpupnp
Project version: 6.1.2
C++ compiler for the host machine: c++ (gcc 12.2.0 "c++ (piCore) 12.2.0")
C++ linker for the host machine: c++ ld.bfd 2.39
Host machine cpu family: arm
Host machine cpu: armv6l
Run-time dependency threads found: YES
Found pkg-config: /usr/local/bin/pkg-config (0.29.2)
Run-time dependency libcurl found: YES 8.0.1
Run-time dependency libmicrohttpd found: YES 0.9.70
Run-time dependency expat found: YES 2.5.0
Compiler for C++ supports arguments -Wno-deprecated-declarations: YES
Compiler for C++ supports arguments /D_CRT_SECURE_NO_WARNINGS: NO
Compiler for C++ supports arguments /wd4251: NO
Configuring upnpconfig.h using configuration
Configuring autoconfig.h using configuration
Build targets in project: 1

Found ninja-1.10.0 at /usr/local/bin/ninja
tc@pC141bp:~/libnpupnp-6.1.2$
tc@pC141bp:~/libnpupnp-6.1.2$ ninja -C ../libnpupnpx
ninja: Entering directory `../libnpupnpx'
#
# ( snip なんかごちゃごちゃいろいろが表示され１時間ぐらいかかる )
#
[28/28] Linking target libnpupnp.so.13
tc@pC141bp:~/libnpupnp-6.1.2$ sudo ninja -C ../libnpupnpx install
ninja: Entering directory `../libnpupnpx'
[0/1] Installing files.
Installing libnpupnp.so.13 to /usr/local/lib
Installing /home/tc/libnpupnp-6.1.2/inc/netif.h to /usr/local/include/npupnp/
Installing /home/tc/libnpupnp-6.1.2/inc/upnpdebug.h to /usr/local/include/npupnp/
Installing /home/tc/libnpupnp-6.1.2/inc/upnpdescription.h to /usr/local/include/npupnp/
Installing /home/tc/libnpupnp-6.1.2/inc/UpnpGlobal.h to /usr/local/include/npupnp/
Installing /home/tc/libnpupnp-6.1.2/inc/upnp.h to /usr/local/include/npupnp/
Installing /home/tc/libnpupnp-6.1.2/inc/upnptools.h to /usr/local/include/npupnp/
Installing /home/tc/libnpupnpx/upnpconfig.h to /usr/local/include/npupnp/
Installing /home/tc/libnpupnpx/meson-private/libnpupnp.pc to /usr/local/lib/pkgconfig
Installing symlink pointing to libnpupnp.so.13 to /usr/local/lib/libnpupnp.so
tc@pC141bp:~/libnpupnp-6.1.2$

さて。

/usr/local/lib/libnpupnp.so.13
/usr/local/include/npupnp/
/usr/local/lib/pkgconfig/libnpupnp.pc
/usr/local/lib/libnpupnp.so

以上、まとめたらいい（しかし、symlinkとか気にせず機械的にやってるけど大丈夫なのかな）。

tc@pC141bp:~$ mkdir libnpupnp
tc@pC141bp:~$ mkdir libnpupnp/usr
tc@pC141bp:~$ mkdir libnpupnp/usr/local
tc@pC141bp:~$ mkdir libnpupnp/usr/local/lib
tc@pC141bp:~$ mkdir libnpupnp/usr/local/lib/pkgconfig
tc@pC141bp:~$ cp -R /usr/local/lib/libnpupnp.so.13 libnpupnp/usr/local/lib
tc@pC141bp:~$ cp -R /usr/local/lib/pkgconfig/libnpupnp.pc libnpupnp/usr/local/lib/pkgconfig
tc@pC141bp:~$ cp -R /usr/local/lib/libnpupnp.so libnpupnp/usr/local/lib
tc@pC141bp:~$ mkdir libnpupnp/usr/local/include
tc@pC141bp:~$ cp -R /usr/local/include/npupnp libnpupnp/usr/local/include
tc@pC141bp:~$
tc@pC141bp:~$ mksquashfs libnpupnp libnpupnp-6.1.2.tcz
Parallel mksquashfs: Using 1 processor
Creating 4.0 filesystem on libnpupnp-6.1.2.tcz, block size 4096.
[===================================================================|] 1718/1718 100%

Exportable Squashfs 4.0 filesystem, gzip compressed, data block size 4096
    compressed data, compressed metadata, compressed fragments,
    no xattrs, compressed ids
    duplicates are removed
Filesystem size 2731.54 Kbytes (2.67 Mbytes)
    39.84% of uncompressed filesystem size (6856.43 Kbytes)
Inode table size 3572 bytes (3.49 Kbytes)
    48.21% of uncompressed inode table size (7409 bytes)
Directory table size 232 bytes (0.23 Kbytes)
    64.09% of uncompressed directory table size (362 bytes)
Number of duplicate files found 0
Number of inodes 17
Number of files 9
Number of fragments 2
Number of symbolic links 1
Number of device nodes 0
Number of fifo nodes 0
Number of socket nodes 0
Number of directories 7
Number of hard-links 0
Number of ids (unique uids + gids) 2
Number of uids 1
    tc (1001)
Number of gids 1
    staff (50)
tc@pC141bp:~$ md5sum libnpupnp-6.1.2.tcz > libnpupnp-6.1.2.tcz.md5.txt
tc@pC141bp:~$ ls
libnpupnp/               	libnpupnp-6.1.2.tcz
libnpupnp-6.1.2/         	libnpupnp-6.1.2.tcz.md5.txt
libnpupnp-6.1.2.tar.gz   	libnpupnpx/
tc@pC141bp:~$ sudo mv *tcz* /mnt/*2/tce/optional
tc@pC141bp:~$ sudo vi /mnt/*2/tce/onboot.lst
(# libnpupnp-6.1.2.tcz 書き込み)
tc@pC141bp:~$ rm -rf lib*
tc@pC141bp:~$ filetool.sh -b
Backing up files to /mnt/mmcblk0p2/tce/mydata.tgz Done.
tc@pC141bp:~$

次、libupnpp。

tc@pC141bp:~$ wget https://www.lesbonscomptes.com/upmpdcli/downloads/libupnpp-0.26.4.tar.gz
Connecting to www.lesbonscomptes.com (62.210.16.61:443)
saving to 'libupnpp-0.26.4.tar.gz'
libupnpp-0.26.4.tar. 100% |************************************************************|  123k  0:00:00 ETA
'libupnpp-0.26.4.tar.gz' saved
tc@pC141bp:~$ tar xf lib*
tc@pC141bp:~$ ls
libupnpp-0.26.4/    	libupnpp-0.26.4.tar.gz
tc@pC141bp:~$ cd *4
tc@pC141bp:~/libupnpp-0.26.4$ mkdir ../libupnpp
tc@pC141bp:~/libupnpp-0.26.4$ meson setup . ../libupnpp
The Meson build system
Version: 1.1.0
Source dir: /home/tc/libupnpp-0.26.4
Build dir: /home/tc/libupnpp
Build type: native build
Project name: libupnpp
Project version: 0.26.4
C++ compiler for the host machine: c++ (gcc 12.2.0 "c++ (piCore) 12.2.0")
C++ linker for the host machine: c++ ld.bfd 2.39
Host machine cpu family: arm
Host machine cpu: armv6l
Run-time dependency threads found: YES
Found pkg-config: /usr/local/bin/pkg-config (0.29.2)
Run-time dependency libnpupnp found: YES 6.1.2
Run-time dependency libcurl found: YES 8.0.1
Run-time dependency expat found: YES 2.5.0
Compiler for C++ supports arguments -Wno-deprecated-declarations: YES
Compiler for C++ supports arguments /D_CRT_SECURE_NO_WARNINGS: NO
Compiler for C++ supports arguments /wd4251: NO
Configuring config.h using configuration
Build targets in project: 2

Found ninja-1.10.0 at /usr/local/bin/ninja
tc@pC141bp:~/libupnpp-0.26.4$

tc@pC141bp:~/libupnpp-0.26.4$ ninja -C ../libupnpp
ninja: Entering directory `../libupnpp'
[32/35] Compiling C++ object libupnpp.so.16.p/libupnpp_smallut.cpp.o
In file included from /tmp/tcloop/gcc/usr/local/include/c++/12.2.0/vector:70,
             	from /tmp/tcloop/gcc/usr/local/include/c++/12.2.0/functional:62,
             	from ../libupnpp-0.26.4/libupnpp/smallut.h:25,
             	from ../libupnpp-0.26.4/libupnpp/smallut.cpp:18:
/tmp/tcloop/gcc/usr/local/include/c++/12.2.0/bits/vector.tcc: In member function 'void std::vector<_Tp, _Alloc>::_M_realloc_insert(iterator, _Args&& ...) [with _Args = {long long int&, long long int&}; _Tp = std::pair; _Alloc = std::allocator >]':
/tmp/tcloop/gcc/usr/local/include/c++/12.2.0/bits/vector.tcc:439:7: note: parameter passing for argument of type 'std::vector >::iterator' changed in GCC 7.1
  439 |   	vector<_Tp, _Alloc>::
  	|   	^~~~~~~~~~~~~~~~~~~
In member function 'std::vector<_Tp, _Alloc>::reference std::vector<_Tp, _Alloc>::emplace_back(_Args&& ...) [with _Args = {long long int&, long long int&}; _Tp = std::pair; _Alloc = std::allocator >]',
	inlined from 'bool MedocUtils::parseHTTPRanges(const std::string&, std::vector >&)' at ../libupnpp-0.26.4/libupnpp/smallut.cpp:1136:29:
/tmp/tcloop/gcc/usr/local/include/c++/12.2.0/bits/vector.tcc:123:28: note: parameter passing for argument of type '__gnu_cxx::__normal_iterator*, std::vector > >' changed in GCC 7.1
  123 |       	_M_realloc_insert(end(), std::forward<_Args>(__args)...);
  	|       	~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
[35/35] Linking target libupnpp.so.16
tc@pC141bp:~/libupnpp-0.26.4$
tc@pC141bp:~/libupnpp-0.26.4$ sudo ninja -C ../libupnpp install
ninja: Entering directory `../libupnpp'
[0/1] Installing files.
Installing libupnpp.so.16 to /usr/local/lib
Installing /home/tc/libupnpp-0.26.4/libupnpp/base64.hxx to /usr/local/include/libupnpp/
Installing /home/tc/libupnpp-0.26.4/libupnpp/log.h to /usr/local/include/libupnpp/
Installing /home/tc/libupnpp-0.26.4/libupnpp/log.hxx to /usr/local/include/libupnpp/
Installing /home/tc/libupnpp-0.26.4/libupnpp/soaphelp.hxx to /usr/local/include/libupnpp/
Installing /home/tc/libupnpp-0.26.4/libupnpp/upnpavutils.hxx to /usr/local/include/libupnpp/
Installing /home/tc/libupnpp-0.26.4/libupnpp/upnperrcodes.hxx to /usr/local/include/libupnpp/
Installing /home/tc/libupnpp-0.26.4/libupnpp/upnppexports.hxx to /usr/local/include/libupnpp/
Installing /home/tc/libupnpp-0.26.4/libupnpp/upnpplib.hxx to /usr/local/include/libupnpp/
Installing /home/tc/libupnpp-0.26.4/libupnpp/upnpputils.hxx to /usr/local/include/libupnpp/
Installing /home/tc/libupnpp-0.26.4/libupnpp/device/device.hxx to /usr/local/include/libupnpp/device/
Installing /home/tc/libupnpp-0.26.4/libupnpp/device/service.hxx to /usr/local/include/libupnpp/device/
Installing /home/tc/libupnpp-0.26.4/libupnpp/device/vdir.hxx to /usr/local/include/libupnpp/device/
Installing /home/tc/libupnpp-0.26.4/libupnpp/control/avtransport.hxx to /usr/local/include/libupnpp/control/
Installing /home/tc/libupnpp-0.26.4/libupnpp/control/cdircontent.hxx to /usr/local/include/libupnpp/control/
Installing /home/tc/libupnpp-0.26.4/libupnpp/control/cdirectory.hxx to /usr/local/include/libupnpp/control/
Installing /home/tc/libupnpp-0.26.4/libupnpp/control/conman.hxx to /usr/local/include/libupnpp/control/
Installing /home/tc/libupnpp-0.26.4/libupnpp/control/description.hxx to /usr/local/include/libupnpp/control/
Installing /home/tc/libupnpp-0.26.4/libupnpp/control/device.hxx to /usr/local/include/libupnpp/control/
Installing /home/tc/libupnpp-0.26.4/libupnpp/control/discovery.hxx to /usr/local/include/libupnpp/control/
Installing /home/tc/libupnpp-0.26.4/libupnpp/control/linnsongcast.hxx to /usr/local/include/libupnpp/control/
Installing /home/tc/libupnpp-0.26.4/libupnpp/control/mediarenderer.hxx to /usr/local/include/libupnpp/control/
Installing /home/tc/libupnpp-0.26.4/libupnpp/control/mediaserver.hxx to /usr/local/include/libupnpp/control/
Installing /home/tc/libupnpp-0.26.4/libupnpp/control/ohinfo.hxx to /usr/local/include/libupnpp/control/
Installing /home/tc/libupnpp-0.26.4/libupnpp/control/ohplaylist.hxx to /usr/local/include/libupnpp/control/
Installing /home/tc/libupnpp-0.26.4/libupnpp/control/ohproduct.hxx to /usr/local/include/libupnpp/control/
Installing /home/tc/libupnpp-0.26.4/libupnpp/control/ohradio.hxx to /usr/local/include/libupnpp/control/
Installing /home/tc/libupnpp-0.26.4/libupnpp/control/ohreceiver.hxx to /usr/local/include/libupnpp/control/
Installing /home/tc/libupnpp-0.26.4/libupnpp/control/ohsender.hxx to /usr/local/include/libupnpp/control/
Installing /home/tc/libupnpp-0.26.4/libupnpp/control/ohtime.hxx to /usr/local/include/libupnpp/control/
Installing /home/tc/libupnpp-0.26.4/libupnpp/control/ohvolume.hxx to /usr/local/include/libupnpp/control/
Installing /home/tc/libupnpp-0.26.4/libupnpp/control/renderingcontrol.hxx to /usr/local/include/libupnpp/control/
Installing /home/tc/libupnpp-0.26.4/libupnpp/control/service.hxx to /usr/local/include/libupnpp/control/
Installing /home/tc/libupnpp-0.26.4/libupnpp/control/typedservice.hxx to /usr/local/include/libupnpp/control/
Installing /home/tc/libupnpp/meson-private/libupnpp.pc to /usr/local/lib/pkgconfig
Installing symlink pointing to libupnpp.so.16 to /usr/local/lib/libupnpp.so
tc@pC141bp:~/libupnpp-0.26.4$

ここでは、色々あるように見えるけど、

/usr/local/lib/libupnpp.so.16
/usr/local/include/libupnpp/
/usr/local/lib/pkgconfig/libupnpp.pc
/usr/local/lib/libupnpp.so

以上をまとめたらいい。

tc@pC141bp:~/libupnpp-0.26.4$ cd
tc@pC141bp:~$ mkdir libupnppx
tc@pC141bp:~$ mkdir libupnppx/usr
tc@pC141bp:~$ mkdir libupnppx/usr/local
tc@pC141bp:~$ mkdir libupnppx/usr/local/lib
tc@pC141bp:~$ mkdir libupnppx/usr/local/include
tc@pC141bp:~$ cp -R /usr/local/lib/libupnpp.so.16 libupnppx/usr/local/lib
tc@pC141bp:~$ cp -R /usr/local/lib/libupnpp.so libupnppx/usr/local/lib
tc@pC141bp:~$ mkdir libupnppx/usr/local/lib/pkgconfig
tc@pC141bp:~$ cp -R /usr/local/lib/pkgconfig/libupnpp.pc libupnppx/usr/local/lib/pkgconfig
tc@pC141bp:~$ cp -R /usr/local/include/libupnpp libupnppx/usr/local/include
tc@pC141bp:~$ mksquashfs libupnppx libupnpp-0.26.4.tcz
Parallel mksquashfs: Using 1 processor
Creating 4.0 filesystem on libupnpp-0.26.4.tcz, block size 4096.
[=================================================================|] 4731/4731 100%

Exportable Squashfs 4.0 filesystem, gzip compressed, data block size 4096
    compressed data, compressed metadata, compressed fragments,
    no xattrs, compressed ids
    duplicates are removed
Filesystem size 8134.72 Kbytes (7.94 Mbytes)
    43.11% of uncompressed filesystem size (18867.71 Kbytes)
Inode table size 9406 bytes (9.19 Kbytes)
    46.36% of uncompressed inode table size (20288 bytes)
Directory table size 549 bytes (0.54 Kbytes)
    55.51% of uncompressed directory table size (989 bytes)
Number of duplicate files found 0
Number of inodes 45
Number of files 35
Number of fragments 16
Number of symbolic links 1
Number of device nodes 0
Number of fifo nodes 0
Number of socket nodes 0
Number of directories 9
Number of hard-links 0
Number of ids (unique uids + gids) 2
Number of uids 1
    tc (1001)
Number of gids 1
    staff (50)
tc@pC141bp:~$ md5sum libupnpp-0.26.4.tcz > libupnpp-0.26.4.tcz.md5.txt
tc@pC141bp:~$
tc@pC141bp:~$ sudo mv *tcz* /mnt/*2/tce/optional
tc@pC141bp:~$ sudo vi /mnt/*2/tce/onboot.lst
(# libupnpp-0.26.4.tcz 書き込み)
tc@pC141bp:~$ rm -rf lib*
tc@pC141bp:~$ filetool.sh -b

次、upmpdcli。

tc@pC141bp:~$ wget https://www.lesbonscomptes.com/upmpdcli/downloads/upmpdcli-1.8.11.tar.gz
Connecting to www.lesbonscomptes.com (62.210.16.61:443)
saving to 'upmpdcli-1.8.11.tar.gz'
upmpdcli-1.8.11.tar. 100% |*******************************************************************|  614k  0:00:00 ETA
'upmpdcli-1.8.11.tar.gz' saved
tc@pC141bp:~$ tar xf upmpdcli*
tc@pC141bp:~$ cd *11
tc@pC141bp:~/upmpdcli-1.8.11$ mkdir ../upmpdcli
tc@pC141bp:~/upmpdcli-1.8.11$ meson setup . ../upmpdcli
The Meson build system
Version: 1.1.0
Source dir: /home/tc/upmpdcli-1.8.11
Build dir: /home/tc/upmpdcli
Build type: native build
Project name: upmpdcli
Project version: 1.8.11
C++ compiler for the host machine: c++ (gcc 12.2.0 "c++ (piCore) 12.2.0")
C++ linker for the host machine: c++ ld.bfd 2.39
Host machine cpu family: arm
Host machine cpu: armv6l
Found pkg-config: /usr/local/bin/pkg-config (0.29.2)
Run-time dependency libupnpp found: YES 0.26.4
Run-time dependency libcurl found: YES 8.0.1
Run-time dependency libmicrohttpd found: YES 0.9.70
Did not find CMake 'cmake'
Found CMake: NO
Run-time dependency jsoncpp found: NO (tried pkgconfig)

meson.build:22:8: ERROR: Dependency "jsoncpp" not found, tried pkgconfig

A full log can be found at /home/tc/upmpdcli/meson-logs/meson-log.txt
tc@pC141bp:~/upmpdcli-1.8.11$

え、cmakeがない、jsoncppがないとな。要るのか。
これでどうか。
tc@pC141bp:~/upmpdcli-1.8.11$ tce-load -wi cmake.tcz json-c.tcz json-c-dev.tcz
エラー。
jsoncppがないと。

json-glib.tcz json-glib-dev.tczもインストール。
tc@pC141bp:/etc/sysconfig/tcedir$ tce-load -wi json-glib-dev.tcz json-glib-dev.tcz
無理でした。
/home/tc/upmpdcli/meson-logs/meson-log.txt というのを読む。

CMake binary for 1 is not cached
CMake binary missing from cross or native file, or env var undefined.
Trying a default CMake fallback at cmake
Found CMake: /usr/local/bin/cmake (3.23.1)
# ( snip ) #
Preliminary CMake check failed. Aborting.
Run-time dependency jsoncpp found: NO (tried pkgconfig and cmake)

meson.build:22:8: ERROR: Dependency "jsoncpp" not found, tried pkgconfig and cmake

いろいろ悪足掻きして追加してみる。
tc@pC141bp:/etc/sysconfig/tcedir$ tce-load -wi json-glib-dev.tcz json-glib-doc.tcz json-glib-gir.tcz json-glib-locale.tcz
これでも無理。エラー、ついには環境依存との表示が出る。

実際、「jsoncpp」はTiny Coreだとリポジトリにtczがあるけど、piCoreには用意されていない。
今、メインシステムで使っているmpdサーバー（Tiny Core OS）にupmpdcliをインストールした時にも、jsoncppが足りなくて、後からインストールしたのだ。
http://blown-lei.net/endive/blosxom.cgi/audio_diary/20210321a.htm
upmpdcliのサイトにはjsoncppについて書いてないように思うが、皆、どうしてるんだろう。

そういうわけで、Ras Pi b+にupmpdcliをインストールする試みは行き詰まった。
jsoncppをソースからインストールとなってくるといよいよハードルが高く、根負けした。

以上で、撤退である。

inter mission

upmpdcliをインストールするには「jsoncpp」というライブラリが必要になる。
aarch64のリポジトリにはtczファイルが用意されているが、armv6、armv7、armv7lには用意されていない。つまり、Ras Pi 3B以下の機種へのインストールは、容易には出来ないということだ。

そういうわけで、とりあえず、b+をPPAP Back Endにしてみた。
しかし、ノイズが入ったり音が切れたりで、快適には使えない。B+ってこうだったっけ。昔はB2で運用してたんだっけか。
http://blown-lei.net/endive/blosxom.cgi/audio_diary/20180301a.htm
昔のエントリーによると、period-sizeとbuffer-sizeを上げたらB+でもBack Endで使えるようだ。

やっぱり、3b+を使わないといけないかな、と思ったら、3b+のpiCore、aarch64のリポジトリにはnmap.tczがない。3b+以上の機種をPPAPで使うとしたら、ソースからインストールする必要がある。
いろいろ制約が多い。
そういれば、そういうこともあって、apu2に移行したような記憶が、、、どうだったかな。

さて、ということは、Roon BridgeとPPAP Back Endを一体にできるのは、うちにあるRas Piだと2bしかない、ということになる。
B+はRoon Bridgをインストールできない。
3b+はUPnP化、Roon Bridge化は出来たとしても、nmapをインストールできない。つまりmpdサーバーの3b+からUSBでDACに出力することになる。それで運用というのもありだけど、作るのが大変な割に、音質は期待できない気がする。

実は今回、Roon (RAAT)とPPAPの音質を比較したいというのが、当初の目的だった。そのためには、Roon Bridgeとncat、両方を動かせる機械を作りたい。同一の機械じゃないと比較ができない。
本当は、Roon ROCKとRoon Ready対応の製品じゃないと、Roonの真価は分からないのかもしれないが、まあ、やってみたいということだ。

Raspberry Pi 2b

そういうわけで、、、Ras Pi 2bに手を入れていく。

http://tinycorelinux.net/14.x/armv7/releases/RPi/
http://tinycorelinux.net/14.x/armv7/releases/RPi/piCore-14.1.0.zip

zipをダウンロードし解凍。
imgファイルをmicroSDに焼いて、cmdline.txt にhost=pC141b2と追記、config.txtを編集しイヤホンジャックを止めて、ラズパイに刺して電源を入れる。

ab@fedora-pb650g1:~$ ssh tc@192.168.1.77
The authenticity of host '192.168.1.77 (192.168.1.77)' can't be established.
ED25519 key fingerprint is SHA256:QNgN5WKnnJhaFEsBAPWo1JOBLBVZtZRl+rVWl0BiduE.
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '192.168.1.77' (ED25519) to the list of known hosts.
tc@192.168.1.77's password:
   ( '>')
  /) TC (\   Core is distributed with ABSOLUTELY NO WARRANTY.
 (/-_--_-\)       	www.tinycorelinux.net

tc@pC141b2:~$
tc@pC141b2:~$ sudo fdisk -u /dev/mmcblk0

The number of cylinders for this disk is set to 120576.
There is nothing wrong with that, but this is larger than 1024,
and could in certain setups cause problems with:
1) software that runs at boot time (e.g., old versions of LILO)
2) booting and partitioning software from other OSs
   (e.g., DOS FDISK, OS/2 FDISK)

Command (m for help): p
Disk /dev/mmcblk0: 3768 MB, 3951034368 bytes, 7716864 sectors
120576 cylinders, 4 heads, 16 sectors/track
Units: sectors of 1 * 512 = 512 bytes

Device   	Boot StartCHS	EndCHS    	StartLBA 	EndLBA	Sectors  Size Id Type
/dev/mmcblk0p1	128,0,1 	1023,3,16     	8192 	139263 	131072 64.0M  c Win95 FAT32 (LBA)
/dev/mmcblk0p2	1023,3,16   1023,3,16   	139264 	172031  	32768 16.0M 83 Linux

Command (m for help): d
Partition number (1-4): 2

Command (m for help): n
Partition type
   p   primary partition (1-4)
   e   extended
p
Partition number (1-4): 2
First sector (16-7716863, default 16): 139264
Last sector or +size{,K,M,G,T} (139264-7716863, default 7716863): +2G

Command (m for help): w
The partition table has been altered.
Calling ioctl() to re-read partition table
fdisk: WARNING: rereading partition table failed, kernel still uses old table: Device or resource busy
tc@pC141b2:~$
tc@pC141b2:~$ filetool.sh -b
Backing up files to /mnt/mmcblk0p2/tce/mydata.tgz Done.
tc@pC141b2:~$ sudo reboot

tc@pC141b2:~$ Connection to 192.168.1.77 closed by remote host.
Connection to 192.168.1.77 closed.
ab@fedora-pb650g1:~$ ssh tc@192.168.1.77
tc@192.168.1.77's password:
   ( '>')
  /) TC (\   Core is distributed with ABSOLUTELY NO WARRANTY.
 (/-_--_-\)       	www.tinycorelinux.net

tc@pC141b2:~$ sudo resize2fs /dev/mmcblk0p2
resize2fs 1.46.5 (30-Dec-2021)
Filesystem at /dev/mmcblk0p2 is mounted on /mnt/mmcblk0p2; on-line resizing required
old_desc_blocks = 1, new_desc_blocks = 1
The filesystem on /dev/mmcblk0p2 is now 524288 (4k) blocks long.

tc@pC141b2:~$

2bのRoon Bridgeは「Roon Bridge (armv7hf)」を使用。
前回エントリーに記載した手順で環境構築、インストールしていく。

tc@pC141b2:~$ tce-load -wi alsa.tcz alsa-utils.tcz alsa-plugins.tcz bash-dev.tcz bash.tcz curl.tcz

tc@pC141b2:~$ aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: Audio [USB HiRes Audio], device 0: USB Audio [USB Audio]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
tc@pC141b2:~$

Pegasus DACを認識出来ている。

tc@pC141b2:~$ wget https://download.roonlabs.net/builds/RoonBridge_linuxarmv7hf.tar.bz2
Connecting to download.roonlabs.net (172.67.14.113:443)
saving to 'RoonBridge_linuxarmv7hf.tar.bz2'
RoonBridge_linuxarmv 100% |*************************************************************| 15.4M  0:00:00 ETA
'RoonBridge_linuxarmv7hf.tar.bz2' saved
tc@pC141b2:~$ tar jxf Roon*
tc@pC141b2:~$ ls
RoonBridge/                  	RoonBridge_linuxarmv7hf.tar.bz2
tc@pC141b2:~$
tc@pC141b2:~$ sudo RoonBridge/check.sh

Checking to see if RoonBridge can run on this machine

	Checking for Binary Compatibility                        	[   OK   ]
	Checking for ALSA Libraries                              	[   OK   ]

STATUS: SUCCESS

tc@pC141b2:~$ rm Roon*bz2
rm: remove 'RoonBridge_linuxarmv7hf.tar.bz2'? y
tc@pC141b2:~$

tc@pC141b2:~$ sudo vi /opt/bootlocal.sh
# ( write : /home/tc/RoonBridge/start.sh start )

tc@pC141b2:~$ filetool.sh -b
Backing up files to /mnt/mmcblk0p2/tce/mydata.tgz Done.
tc@pC141b2:~$ sudo reboot
tc@pC141b2:~$ Connection to 192.168.1.77 closed by remote host.
Connection to 192.168.1.77 closed.
ab@fedora-pb650g1:~$ ssh tc@192.168.1.77
tc@192.168.1.77's password:
   ( '>')
  /) TC (\   Core is distributed with ABSOLUTELY NO WARRANTY.
 (/-_--_-\)       	www.tinycorelinux.net

tc@pC141b2:~$ pstree
init-+-bootlocal.sh---start.sh---mono-sgen-+-2*[mono-sgen]
 	|                                 	`-processreaper
 	|-sh
 	|-sshd---sshd---sshd---sh---pstree
 	|-udevd---2*[udevd]
 	`-udhcpc
tc@pC141b2:~$

Roon Bridge化、成功。タブレット端末のRoonアプリ上で、Roon Bridgeとして認識されている。音も出た。

続いて、PPAP Back-End化。

tc@pC141b2:~$ tce-load -wi nmap.tcz alsa-modules-6.1.68-piCore-v7.tcz alsa.tcz alsa-utils.tcz alsa-utils-locale.tcz
alsa-modules-6.1.68-piCore-v7 is already installed!
alsa is already installed!
alsa-utils is already installed!

# ( snip )

nmap、インストールした。
ここで試しにコマンドを打ってみる。

tc@pC141b2:~$ /usr/local/bin/ncat -kl 4444 -e "/usr/local/bin/aplay -D plughw:0,0 -M --period-size=64 --buffer-size=512 -t raw -f cd"
/usr/local/bin/ncat: error while loading shared libraries:: cannot open shared object file: No such file or directory
tc@pC141b2:~$

libssl.so.1.1がないと言って、蹴られる。
http://tinycorelinux.net/14.x/armv7/tcz/
リポジトリを確認。openssl-1.1.1.tczというのがあるのでインストール。

tc@pC141b2:~$ tce-load -wi openssl-1.1.1.tcz
Downloading: openssl-1.1.1.tcz
Connecting to repo.tinycorelinux.net (128.127.66.77:80)
saving to 'openssl-1.1.1.tcz'
openssl-1.1.1.tcz	100% |***************************************************************| 1172k  0:00:00 ETA
'openssl-1.1.1.tcz' saved
openssl-1.1.1.tcz: OK
tc@pC141b2:~$
tc@pC141b2:~$ /usr/local/bin/ncat -kl 4444 -e "/usr/local/bin/aplay -D plughw:0,0 -M --period-size=64 --buffer-size=512 -t raw -f cd"
^C
tc@pC141b2:~$

tc@pC141b2:~$ vi /opt/bootlocal.sh
( write : /usr/local/bin/ncat -kl 4444 -e "/usr/local/bin/aplay -D plughw:0,0 -M --period-size=256 --buffer-size=512 -t raw -f S32_LE -r44100 -c2" )

tc@pC141b2:~$ filetool.sh -b
Backing up files to /mnt/mmcblk0p2/tce/mydata.tgz Done.
tc@pC141b2:~$
tc@pC141b2:~$ sudo reboot
tc@pC141b2:~$ Connection to 192.168.1.77 closed by remote host.
Connection to 192.168.1.77 closed.
ab@fedora-pb650g1:~$ ssh tc@192.168.1.77
tc@192.168.1.77's password:
   ( '>')
  /) TC (\   Core is distributed with ABSOLUTELY NO WARRANTY.
 (/-_--_-\)       	www.tinycorelinux.net

tc@pC141b2:~$

音は出るだろうか。、、、なんでか、動かない。mpdからの送信を受け付けないようで、ncmpcppで「paused」と表示される。
tc@pC141b2:~$ tce-load -wi openssl-dev.tcz alsa-plugins-dev.tcz
無効。
Roon Bridgeも動かない。
ということは、同一機械での併用は出来ないのか。
PPAPのコマンドを止めたら、Roon Bridgeは動くようになった。alsa出力を奪い合うんだろうか。
その割には、Roonを止めてもPPAPは動かない。
何しろ、うまくいかない。

しかたない。
Raspberry Pi 2bでRoon BridgeとPPAP併用は止めることにする。

Raspberry Pi 3b+

さて、3b+に、mpdとupmpdcliをインストールして、PCトランスポートとして動かしてみることにした。音質への配慮は2の次だ。UPnPPPAPは使わない。基本、アップサンプリングもしない（高度な処理はRas Piには負担が大きいからだ）。

まず、piCoreをダウンロード。3B+を使うことにするので、下記から落とす。バージョンは14.1。
http://tinycorelinux.net/14.x/aarch64/
http://tinycorelinux.net/14.x/aarch64/releases/RPi/piCore64-14.1.0.zip
imgファイルをmicroSDに焼いて、cmdline.txt にhost=pC141b3pと追記、config.txtを編集しイヤホンジャックを止めて、ラズパイに刺して起動。さすがに長いので、環境構築のコマンドは羅列で済ます。

sudo fdisk -u /dev/mmcblk0
filetool.sh -b
sudo resize2fs /dev/mmcblk0p2
tce-load -wi gcc.tcz gcc_libs.tcz gcc_libs-dev.tcz gcc_base-dev.tcz meson.tcz ninja.tcz squashfs-tools.tcz
tce-load -wi boost-dev.tcz boost.tcz pkg-config.tcz clang.tcz curl.tcz curl-dev.tcz libmicrohttpd.tcz expat2.tcz expat2.tcz expat2-dev.tcz
tce-load -wi alsa.tcz alsa-utils.tcz alsa-utils-locale.tcz alsa-plugins.tcz alsa-plugins-dev.tcz
tce-load -wi jsoncpp.tcz jsoncpp-dev.tcz

ここで問題が発覚。upmpdcliのインストールに必要な、libmicrohttpd がリポジトリにない。
ソースからインストールしないといけない。無しではいけないかな。
面倒だなあ、、、止めよう。

Raspberry Pi 2b again

2bを、2台にしよう。

Roon Bridgeは既に作ってある。
だから、ここではPPAP Back-Endを作る。

http://tinycorelinux.net/14.x/armv7/releases/RPi/piCore-14.1.0.zip
zipをダウンロードし解凍。
imgファイルをmicroSDに焼いて、cmdline.txt にhost=pC141b2-ppapBEと追記、config.txtを編集しイヤホンジャックを止めて、ラズパイに刺して電源を入れる。

ab@fedora-pb650g1:~$ ssh tc@192.168.1.77

# ( snip )

tc@192.168.1.77's password:
   ( '>')
  /) TC (\   Core is distributed with ABSOLUTELY NO WARRANTY.
 (/-_--_-\)       	www.tinycorelinux.net

tc@pC141b2-ppapBE:~$ sudo fdisk -u /dev/mmcblk0

# ( snip )

The partition table has been altered.
Calling ioctl() to re-read partition table
fdisk: WARNING: rereading partition table failed, kernel still uses old table: Device or resource busy
tc@pC141b2-ppapBE:~$ filetool.sh -b
Backing up files to /mnt/mmcblk0p2/tce/mydata.tgz Done.
tc@pC141b2-ppapBE:~$ sudo reboot
tc@pC141b2-ppapBE:~$ Connection to 192.168.1.77 closed by remote host.
Connection to 192.168.1.77 closed.

ab@fedora-pb650g1:~$ ssh tc@192.168.1.77
tc@192.168.1.77's password:
   ( '>')
  /) TC (\   Core is distributed with ABSOLUTELY NO WARRANTY.
 (/-_--_-\)       	www.tinycorelinux.net

tc@pC141b2-ppapBE:~$ sudo resize2fs /dev/mmcblk0p2
resize2fs 1.46.5 (30-Dec-2021)
Filesystem at /dev/mmcblk0p2 is mounted on /mnt/mmcblk0p2; on-line resizing required
old_desc_blocks = 1, new_desc_blocks = 1
The filesystem on /dev/mmcblk0p2 is now 51200 (4k) blocks long.

tc@pC141b2-ppapBE:~$ tce-load -wi nmap.tcz alsa.tcz alsa-utils.tcz

# ( snip )

tc@pC141b2-ppapBE:~$ aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: Audio [USB HiRes Audio], device 0: USB Audio [USB Audio]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
tc@pC141b2-ppapBE:~$
tc@pC141b2-ppapBE:~$ vi /opt/bootlocal.sh

# ( write : /usr/local/bin/ncat -kl 4444 -e "/usr/local/bin/aplay -D hw:0,0 -M --period-size=256 --buffer-size=1024 -t raw -f S32_LE -r44100 -c2" )

tc@pC141b2-ppapBE:~$ filetool.sh -b
Backing up files to /mnt/mmcblk0p2/tce/mydata.tgz Done.
tc@pC141b2-ppapBE:~$ sudo reboot

tc@pC141b2-ppapBE:~$ tce-load -wi openssl-1.1.1.tcz
tc@pC141b2-ppapBE:~$ sudo reboot

うっかりしてopenssl-1.1.1.tczを入れ忘れて、後からインストール。そうしたらちゃんと機能した。

結末

そんなわけで、うちではRaspberry Pi 2b が2台、メインシステムに加わった。Roon BridgeとPPAP Back-Endだ。
ちょっと、あれこれ賑やか過ぎる。そのうち、なんとかしよう。

あれこれやる合間に、久しぶりにRas Pi B+ / piCore7でmpdサーバーを作った。サブシステムに使う。
http://blown-lei.net/endive/blosxom.cgi/audio_diary/20180103a.htm
上記の過去エントリーの作り方だと、うまくいかない。
リポジトリからgcc.tczとか諸々多数のライブラリをインストールすることになっているんだけど、今、現在の時点で、gcc.tczはダウンロードできない状態になっている。リポジトリ側の都合らしい。
mpdのインストール、リポジトリからするなら、gccとか余計なライブラリは要らない。
以下、自分用構築メモ備忘録、最小限。

http://tinycorelinux.net/7.x/armv6/releases/RPi/piCore-7.0.zip

dtparam=i2c=off,spi=off,i2s=on,i2c_vc=off
dtoverlay=hifiberry-dac

filetool.sh -b
vi /opt/.filetool.lst

vi /opt/bootlocal.sh

mkdir /mnt/music
mkdir /mnt/music/ariel
mkdir /mnt/music/titan
mkdir /mnt/music/x
touch /mnt/music/x/dummy.cue
chmod -R 777 /mnt/music

tce-load -wi alsa.tcz alsa-config.tcz alsa-doc.tcz alsa-dev.tcz alsaequal.tcz alsa-locale.tcz libcdio-dev.tcz libcdio.tcz curl.tcz curl-dev.tcz libsamplerate.tcz

tce-load -wi flac-dev.tcz flac.tcz libcue.tcz libcue-dev.tcz libmad.tcz mpg123.tcz lame-dev.tcz lame-doc.tcz lame.tcz faad2-dev.tcz faad2-doc.tcz faad2.tcz

tce-load -wi libmpdclient-dev.tcz libmpdclient-doc.tcz libmpdclient.tcz mpd-doc.tcz mpd.tcz

tce-load -wi libnfsidmap.tcz libnfsidmap-dev.tcz

vi .mpdconf

music_directory   "/mnt/music"
playlist_directory   "~/.mpd/playlists"
db_file   "~/.mpd/database"
log_file   "~/.mpd/log"
pid_file   "~/.mpd/pid"
state_file   "~/.mpd/state"
sticker_file   "~/.mpd/sticker.sql"
auto_update   "no"
#auto_update_depth "3"

audio_output {
type   "alsa"
name   "My ALSA Device"
device   "hw:0,0"   # optional
mixer_type   "software"   # optional
## mixer_device    "default"   # optional
## mixer_control   "PCM"   # optional
## mixer_index   "0"   # optional
}
# samplerate_converter   "Fastest Sinc Interpolator"
# audio_buffer_size   "8192"
# buffer_before_play   "20%"
# audio_output_format   "192000:24:2"

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


mkdir .mpd
mkdir .mpd/playlists


vi .ashrc

# alias ariel="sudo mount -t nfs 192.168.1.120:/ariel /mnt/music/ariel"
# alias titan="sudo mount -t nfs 192.168.1.80:/titan /mnt/music/titan"

alias ariel="sudo mount -o addr=192.168.1.120,nolock -t nfs 192.168.1.120:/ariel /mnt/music/ariel"
alias titan="sudo mount -o addr=192.168.1.80,nolock -t nfs 192.168.1.80:/titan /mnt/music/titan"

今年に入って、いつ頃からか正確には分からないのだけど、piCorePlayerが不調になった。
Deezer音源のMQAを、Daphileから変換せずにDAC（SMSL M500）に送って鳴らすために使っていたんだけど、それが出来なくなった。そして、LMSをDaphileからMac miniに移行しても、動かないままだ。
原因ははっきりしない。
代替をどうするか、Volumio 3、Album Player for Linux（これって、Ras Pi用はpiCorePlayerベースなんだね）を試したが、結局うまくいかなかった。

そういうわけで、roon bridge、mpdとupmpdcliを、最新のpiCoreにインストールすることにした。
piCoreは、piCorePlayerのベースになっているOSだ。うちでは昔から汎用していて、今はサブシステムのRas Pi2、Roon Bridgeに使っている。

まず、piCoreをダウンロード。3B+を使うことにするので、下記から落とす。バージョンは14.1。
http://tinycorelinux.net/14.x/aarch64/
http://tinycorelinux.net/14.x/aarch64/releases/RPi/piCore64-14.1.0.zip

imgファイルをmicroSDに焼いて、cmdline.txt にhost=pC141b3pと追記、config.txtを編集しイヤホンジャックを止めて、i2sを一応生かして、ラズパイに刺して電源を入れる。
無事、起動した。
sshでログインし、filetool.sh -bでsshの鍵を保存する。
以下、パーティションを拡張。2Gも足しとけばよかろう。

tc@pC141b3p:~$ sudo fdisk -u /dev/mmcblk0

The number of cylinders for this disk is set to 121008.
There is nothing wrong with that, but this is larger than 1024,
and could in certain setups cause problems with:
1) software that runs at boot time (e.g., old versions of LILO)
2) booting and partitioning software from other OSs
   (e.g., DOS FDISK, OS/2 FDISK)

Command (m for help): p
Disk /dev/mmcblk0: 3781 MB, 3965190144 bytes, 7744512 sectors
121008 cylinders, 4 heads, 16 sectors/track
Units: sectors of 1 * 512 = 512 bytes

Device   	Boot StartCHS	EndCHS    	StartLBA 	EndLBA	Sectors  Size Id Type
/dev/mmcblk0p1	128,0,1 	1023,3,16     	8192 	139263 	131072 64.0M  c Win95 FAT32 (LBA)
/dev/mmcblk0p2	1023,3,16   1023,3,16   	139264 	172031  	32768 16.0M 83 Linux

Command (m for help): d
Partition number (1-4): 2

Command (m for help): n
Partition type
   p   primary partition (1-4)
   e   extended
p
Partition number (1-4): 2
First sector (16-7744511, default 16): 139264
Last sector or +size{,K,M,G,T} (139264-7744511, default 7744511): +2G

Command (m for help): w
The partition table has been altered.
Calling ioctl() to re-read partition table
fdisk: WARNING: rereading partition table failed, kernel still uses old table: Device or resource busy
tc@pC141b3p:~$ sudo reboot

tc@pC141b3p:~$ Connection to 192.168.1.27 closed by remote host.
Connection to 192.168.1.27 closed.
ab@fedora-pb650g1:~$
ab@fedora-pb650g1:~$ ssh tc@192.168.1.27
tc@192.168.1.27's password:
   ( '>')
  /) TC (\   Core is distributed with ABSOLUTELY NO WARRANTY.
 (/-_--_-\)       	www.tinycorelinux.net

tc@pC141b3p:~$ sudo resize2fs /dev/mmcblk0p2
resize2fs 1.46.5 (30-Dec-2021)
Filesystem at /dev/mmcblk0p2 is mounted on /mnt/mmcblk0p2; on-line resizing required
old_desc_blocks = 1, new_desc_blocks = 1
The filesystem on /dev/mmcblk0p2 is now 524288 (4k) blocks long.

tc@pC141b3p:~$

以上で、パーティション拡張終了。

次にntpclient.tczをインストールしようとしたら、リポジトリに置いていない。
http://tinycorelinux.net/14.x/aarch64/tcz/
どういうことかと思ってdateコマンドを打ってみた。

tc@pC141b3p:~$ date
Mon May  6 12:56:11 UTC 2024

どうやらUTCで正確に動いているような。ntpは要らないのかな。

さて、Roon Bridge化する。
https://help.roonlabs.com/portal/en/kb/articles/linux-install

インストーラー使用を推奨ということなんだけどpiCore、Tiny Coreは特殊なのでマニュアルインストールを選択。
libasound2が必要ということだが、説明を読むと、alsaの1.0.27以上が必要と読み替えていいらしい。これはリポジトリにある。
ということでインストール。
関連するソフトも同時に大量にインストールされる。
スクリプトを動かすのにbashが要るので、これもインストールする。ついでになんとなくcurlも入れる。

tc@pC141bp:~$ tce-load -wi alsa.tcz alsa-utils.tcz alsa-plugins.tcz
tc@pC141bp:~$ tce-load -wi bash-dev.tcz bash.tcz curl.tcz

Roonのサイトには、下記３つのRoon Bridgeが用意されている。
Roon Bridge (x64)
Roon Bridge (armv7hf)
Roon Bridge (armv8)

Raspberry Pi 3b+にはarmv8用を使う。piCoreのホームディレクトリにダウンロードし、展開する。

tc@pC141b3p:~$ wget https://download.roonlabs.net/builds/RoonBridge_linuxarmv8.tar.bz2
Connecting to download.roonlabs.net (172.67.14.113:443)
saving to 'RoonBridge_linuxarmv8.tar.bz2'
RoonBridge_linuxarmv 100% |*******************************************************| 17.1M  0:00:00 ETA
'RoonBridge_linuxarmv8.tar.bz2' saved
tc@pC141b3p:~$ tar jxvf RoonBridge_linuxarmv8.tar.bz2
#---- snip

tc@pC141b3p:~$ ls
RoonBridge/                	RoonBridge_linuxarmv8.tar.bz2
tc@pC141b3p:~$ ls RoonBridge
Bridge/   RoonMono/ VERSION   check.sh  start.sh
tc@pC141b3p:~$

チェックスクリプトで使えるかどうか確認する。

tc@pC141b3p:~$ sudo RoonBridge/check.sh

Checking to see if RoonBridge can run on this machine
	Checking for Binary Compatibility                        	[   OK   ]
	Checking for ALSA Libraries                              	[   OK   ]
STATUS: SUCCESS

tc@pC141b3p:~$

使えそうだ。

tc@pC141b3p:~$ rm RoonBridge_linuxarmv8.tar.bz2
rm: remove 'RoonBridge_linuxarmv8.tar.bz2'? y
tc@pC141b3p:~$
tc@pC141b3p:~$ sudo vi /opt/bootlocal.sh

ダウンロードしたtar.bz2ファイルはここで削除する。
piCore起動時にRoonBridgeが起動するように、bootlocal.shを編集。下記、追記。

/home/tc/RoonBridge/start.sh start

tc@pC141b3p:~$ filetool.sh -b
Backing up files to /mnt/mmcblk0p2/tce/mydata.tgz Done.
tc@pC141b3p:~$

filetool.sh -bで、状況を保存。
RoonBridgeが50MBぐらいあるので、数10秒かかる。しかし、他の置き場がないかといっても難しい。というのは、Roonのアップデートがかかる筈なので、filetool.sh -bで保存できない場所に置いたら後で困るから。
結局、ホームディレクトリがいいだろうということになる。

tc@pC141b3p:~$ sudo reboot
tc@pC141b3p:~$ Connection to 192.168.1.27 closed by remote host.
Connection to 192.168.1.27 closed.
ab@fedora-pb650g1:~$
ab@fedora-pb650g1:~$ ssh tc@192.168.1.27
tc@192.168.1.27's password:
   ( '>')
  /) TC (\   Core is distributed with ABSOLUTELY NO WARRANTY.
 (/-_--_-\)       	www.tinycorelinux.net

tc@pC141b3p:~$
tc@pC141b3p:~$ pstree
init-+-bootlocal.sh---start.sh---mono-sgen-+-2*[mono-sgen]
 	|                                 	`-processreaper
 	|-sh
 	|-sshd---sshd---sshd---sh---pstree
 	|-udevd---2*[udevd]
 	`-udhcpc
tc@pC141b3p:~$

pstreeで、mono-sgenと表示されるのがRoonだ。ちゃんと起動している。

しかし、音が出ない。

tc@pC141b3p:~$ aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: AUDIO [SMSL USB AUDIO], device 0: USB Audio [USB Audio]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
tc@pC141b3p:~$

DACは認識しているようだ。

なにがいけないのだろう。alsa-plugins-dev.tcz、alsa-utils-locale.tczもインストールしてみたが、音は出ない。USBケーブルを変えてみたりしたが、関係ない。
サブシステムのRas pi2からは、Roonで音が出ている。3b+との違いは、i2sかUSBか、ということだ。
でも、そんなところが関係するかね、、、

DACを替えてみる。M500からADI-2 DACに。
音、出るじゃん。
M500も、apu2からのUSB出力を受けたら音が出るのだ。なぜか、Ras Pi3b+からだと音が出ない。

pegasusはどうだろう。

tc@pC141b3p:~$ aplay -l
aplay: device_list:277: no soundcards found...
tc@pC141b3p:~$

USB端子を挿しても、認識していない。
スイッチをオン・オフしてみる、、、認識した。音も出る。

tc@pC141b3p:~$ aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: Audio [USB HiRes Audio], device 0: USB Audio [USB Audio]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
tc@pC141b3p:~$

DACの名前が出ていない。まあ、中華DACだもんね。
M500もスイッチをオン・オフしてみる。
piCoreが落ちた。
再起動だ。
音が出た。USBってのはいろいろと微妙だね。

しかし、取り敢えずこれで、3b+をRoon Bridgeにすることに成功した。MQAサンプラーCDからリッピングしたMQAを再生できる。
RoonはDeezerには対応していないので、次は、これにmpdを組み込んで、UPnPレンダラーにする。そうすればLMSサーバーからDeezerのMQAを送信できる。
それが、いつ頃になるかは、分からないが。

あれ、もしかしたらvolumioもスイッチのオン・オフで使えたのかもしれない。まあ、いいや、piCore運用の方向でいこう。

とりあえず、今現在の最終設定をキャプチャ。mpd.confの設定なんて、本気で弄ったの何年ぶりだろう。

上がLMSのUPnPプラグイン、下がmpdだ。
ちなみに、LMSサーバーは、Mac mini 2010 mid、OSはFedora 39。
mpdサーバーは、HP Probook 450 G9 (CPU:i7-1255U)、OSはTiny Core 64 14.0。

問題になったのが、下記の音源。これが、ギャップレス再生しない。音が途切れる。
https://deezer.page.link/JWaU5YtNL56SjPmy7
スリープ　マックス・リヒター
204曲　8時間24分　2015/09/04

うちのシステムでは、ストリーミングの音源によって処理しやすい、しにくいがあるらしく、特定の音源、特定の場所でノイズが乗るとか途切れるとかすることがある。libsamplerateでアップサンプリングするので、サーバーへの負荷が高いのが影響しているかもしれない。

そうした音源でも、このたびLMSサーバーが、HP 2570p（一部壊れかけ）のDaphileからMac miniのFedoraに変更になって、ちゃんと聴けるようになったのがいくつか確認出来ている。だから環境は良くなっているはずなんだけど、上記音源はギャップレス再生すら出来ない。
あろうことか、曲の途中で止まって飛んだりノイズが入ったりもする。
mpdの負荷を減らすためにアップサンプリングを止めるというのも考えられるが、この音源のためだけにそんなことをする気になれない。
試しにmpdの負荷が少なくなるようにアップサンプリングの設定を「best」から「fastest」に変えてみたけど、改善しない。

そんな状況で、うまく再生出来たのは、WiiM miniだった。
つまり、LMSサーバー、mpdサーバーを経由しなければ、支障なく鳴らせる（とはいえ、長時間になったらどうなるか分からないけど。音源8時間全部を鳴らしたわけではない）。

ストリーミングだと音切れ、ノイズが出るけど、ダウンロードした音源だと出ないということがある。そこで、ダウンロードしてみた。
https://www.prestomusic.com/classical/products/8518548--sleep
Max Richter: Sleep
FLAC(CD quality, 44.1 kHz, 16 bit)
204トラックで8時間半。発売は2018年。Deezerのストリーミングに使われているのと同じだと思う。
NASに保存して鳴らしてみたら、ストリーミングよりはずっとましだけど、たまに途切れる。NAS音源でこんなのは初めてだ。

上記よりも早く2015年に、CD、Blu-ray Audioと同時に発売となっているハイレゾ音源もある。ハイレゾを買うとCD同等の音源やmp3などダウンロードできるようだ。
https://www.prestomusic.com/classical/products/8079217--max-richter-sleep-8-hour-version
Max Richter: Sleep (8 hour version)
Hi-Res FLAC (lossless, 96 kHz, 24 bit)
全部で31トラック。これは、204トラックだと音楽が切れるところが繋がっているので、ストリーミング音源と再生時の条件が異なる。

この音源を何とかしようと、UPnPプラグインとmpd.confの設定変更で対応した。

UPnPプラグインのほうは、HTTP mode を「no length」、Cashe を「memory」、Streaming options の Delayを「0」に。
Audio format to UPnP player で、Transcode を「none」。

mpdは、audio_buffer_size を「65536」（KiBなので、64MiBということになる）。
buffer_before_play を「80%」。

このあたりが肝かな。うちで手応えがあるのがこの辺ということだ。
いつからか分からないが、mpdで「buffer_before_play」を100%に設定出来なくなっている。80%が最大値だ。バージョンは0.20.20。
audio_buffer_sizeの最大値は「131071」。128MiB未満ということだ。

audio_buffer_sizeを大きくしたときの問題は、音を出すときに出音に時間がかかることだ。再生ボタンをクリックして音が出るまでの時間が長くなる。
128MiBにしたらストリーミング音源の再生開始に30～40秒。ちなみにNAS音源の再生だと、そこまでの時間はかからないが、20秒ほど。
mpdサーバーでtopを動かしてmpdの状況を見てみると、挙動にかなり余裕があるようだ。なのに、曲の途中で止まる。音が途切れたら、再会するのに10数秒かかったりする。うーん、、、 ということで64MiBにして様子を見ている。

64MiBだと、かなりいける。
しかしそれでも、音切れが皆無にはならない。
他の音源は問題ないんだがなあ、、、他音源の音は、以前より良くなった気がする。

ここまでやってなんだけど、案外、Deezerサーバー側の問題なのかも、と思ったり、LMSサーバーの性能を上げたら解決したりしないかな、などと考えている。
しかし問題になるのはこの音源だけだし、当面、これでいいかなと思っている。

3月28日に僕はDeezer Premiumのユーザーになり、ProBook 430 G5のLMSでDeezerの音源を聞けるようになった。まあ、聞けるようになったといっても簡単だったわけではなくて、Deezerプラグインに「arl」というのを書き込む必要があった。

logitech FORUMS Search Result : deezer
https://forums.slimdevices.com/search?q=deezer&searchJSON=%7B%22keywords%22%3A%22deezer%22%7D

logitech FORUMS ANNOUNCE: Deezer Local plugin
https://forums.slimdevices.com/forum/user-forums/3rd-party-software/1686739-announce-deezer-local-plugin

How to Get Your Deezer ARL?
https://www.dumpmedia.com/deezplus/deezer-arl.html

これらを参考に、Firefoxから長い文字列をコピーし「ARL token」の小さな窓に書き込んで、めでたく音が出た。それが28日だったか29日だったか、はっきり覚えていない。どっちでもいい話だ。

さて、この時点ではまだ、サーバーをどれにするかは決まっていない。
Mac mini (2010 mid) の処遇が、定まらないのだ。

Mac mini (Mid 2010)
https://support.apple.com/ja-jp/112588

まず、手持ちの古いノートPCたちは何処かしら故障があるのが多いが、Mac miniは無傷だ。スペックもさほど見劣りしない。それにHDDを抜くのが簡単ではない。僕は中古屋にPCを売るときは内蔵ストレージは抜いて持っていくのだけど、かなり深いところまで掘らないといけない。つまりMac miniは中古屋に売りにくい。前向きに処分する気になれないのだ。
そうした理由に加えて、昔のMac miniは音がいいという話を読んだことがある。できれば確かめたい。

Mac miniには古いデータや使わなくなったソフトが沢山残っていて、そのまま使う気にもなれない。この際なので、デュアルブートにしてみよう。厳密じゃないが、OSによる音質差を比較できる。

rEFIt ~ 複数のOSの中から起動するOSを選択する(Intel Mac 用) | Basic Werk
http://basicwerk.com/blog/archives/817
MacMini に Ubuntu をインストール: rEFIt のインストール
http://ubuntu-on-macmini.blogspot.com/2011/01/refit.html

rEFIt - An EFI Boot Menu and Toolkit
https://refit.sourceforge.net/

macOS をダウンロードしてインストールする方法 - Apple サポート (日本)
https://support.apple.com/ja-jp/102662

まずは、Yosemite 10.10をダウンロードしてクリーンインストールしようとしたら、大きすぎてDVD１枚に焼けない。Lionもぎりぎり焼けない。片面2層に書き込みできるDVD-ROMが要るらしい。うちにはない。
Mac mini購入時に付属していたSnow LeopardのインストーラーDVDをあちこち探して引っ張りだし、HDDを４つのパーティションに切って、インストール。
雪豹の起動画面、派手だなー。

続いて、rEFItをインストールする。
ふつうにSafariでrEFItのサイトにいってダウンロードしようとしたら、セキュリティの関係でアクセスできない、といわれる。どういうつもりだ、Safari、雪豹。
しかたがないので他のPCのFirefoxでダウンロードして、それをUSBメモリにコピーして、それをMacに挿してインストールした。

続いてFedoraをインストール。順調にデュアルブートになるかな、と思ったら、雪豹で起動できなくなった。というか、OSの選択が出来ない。電源を入れたら、rEFItの画面が出ず、そのままFedoraでブートする。
なんでこうなったか、よく分からない。

全部入れ直し？、えええ。。。

そういうわけで、Mac miniはFedoraで動くようになった。sshによるログイン、リブートも出来る。
結果として、むしろオーディオサーバーの用途に適う動き方になった。とはいえ、デュアルブートできなくなったのは残念だ。

これにLMSをインストールした。やり方は前回エントリーと同じである。
なんだか音がいい様な気がする。もしかしたら、文鎮のように重いアルミ筐体が効いているのかもしれない。

これでLMSが2台になった。
音質の比較ができるかと思ったが、2台だと音が出ないとか不具合が出てきた（Daphileで問題なかったのは幸運だったのかね）。
しかし、ほんとうにLMSが増えたのが原因なんだろうか。
Deeaerのサービス利用・販売約款（なんでかDeezer HiFi用のままだけど）を読み返してみる。

https://www.deezer.com/legal/cgu

「Deezer HiFiサービスの音楽カタログ及び本件サイトのプレイリストにある楽曲をオフライン時にも聴くことができるようにするため、許可された3台の機器（ポータブル又は非ポータブル機器）に一時的にダウンロードすることを目的とした無制限アクセス」と、ある。

3台というのが、ひっかかっている可能性はないか。
僕はスマホにもDeezerをインストールしている。PCのWebプレーヤーを開いていることもある。考えてみたら、WiiMでも使うことがある。
これらにLMSが加わったら3台を超える。

いや、3台というのが、同時に3台、という意味とは限らない。Deezerには、アカウントがリンクしているデバイスを確認できる場所がWebプレーヤー上にあるのだ。リンクって何なのかは、よく分からないのだけど、「最大3台のデバイスとリンクできます」と表示があるので、約款に書いてあることなのだろう。
今現在使っているデバイスが表示される、というものではないらしい。過去に使ったデバイスが、全て表示されるというものでもないようだ。

Spotifyには、このようなものはない。機器の数の制限は、探したが見つからなかった。
だったら、Spotifyで、2台のLMSを運用できるかどうか、確認してみてもいいのではないか。

2つのLMSサーバーで、Spotifyを交互に操作してみた。
音は普通に鳴る。、、と思っていたら、挙動が少しおかしい。停止ボタンが効かない。ああ、そういえば、Daphileを2台で使ってるときにこれってよくあったっけ（忘れていた、、）。
どうも、通信状態が良くないと起きるような気がする。
やっぱり、１台で使うのがいいんだろうな。

しかし音の比較はしておきたい。

まず、Mac mini WiFiと、430 G5 LAN。これだとMac miniのほうが、音の厚み、重なり、透明度、深みがあって、あらが見えやすい。
次、Mac mini LAN。若干、430 G5 LANに近付いた。
430 G5 LANを聴き直す。ある意味、穏やかで聴き易いんだけど、ハイファイからは離れる気がする。
結果、Mac mini WiFiを選択することにした。

さて、Mac miniにroonもインストールしよう。

mkdir Roon
cd Roon
wget https://download.roonlabs.net/builds/RoonServer_linuxx64.tar.bz2
tar jxvf RoonServer_linuxx64.tar.bz2
sudo ./RoonServer/check.sh

Checking to see if RoonServer can run on this machine

	Checking for Binary Compatibility                        	[   OK   ]
	Checking for ALSA Libraries                              	[   OK   ]
	Checking for ffmpeg or avconv                           	which: no ffmpeg in (/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/var/lib/snapd/snap/bin)
which: no avconv in (/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/var/lib/snapd/snap/bin)
 [ FAILED ]
	Checking for the mount.cifs command                      	[   OK   ]
	Checking for libicu                                     	which: no icuinfo in (/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/var/lib/snapd/snap/bin)
 [   OK   ]
	Testing ulimit -n 8192                                   	[   OK   ]

STATUS: FAILED

ffmpeg or avconv が、必要だ。インストールする。

[ab@fedora Roon]$ sudo dnf install ffmpeg
メタデータの期限切れの最終確認: 3:39:36 前の 2024年04月02日 04時35分28秒 に実施しました。

引数に一致する結果がありません: ffmpeg
エラー: 一致するものが見つかりません: ffmpeg
[ab@fedora Roon]$ sudo dnf install avconv
メタデータの期限切れの最終確認: 3:39:09 前の 2024年04月02日 04時35分28秒 に実施しました。

引数に一致する結果がありません: avconv
エラー: 一致するものが見つかりません: avconv

そうだった。Fedoraってそんなだった。前はどうやってインストールしたんだっけ、、、
まあ、いいか、、動かしてみよう。

[ab@fedora Roon]$ sudo ./RoonServer/start.sh &

00:00:00.001 Info:  get lock file path: /tmp/.rnsgem0-
00:00:00.023 Info:  GetLockFile, fd: 36
00:00:00.023 Info:  GetLockFile, res: 0
00:00:00.023 Trace: Nope, we are the only one running
Initializing
Started
Running

まじか。ffmpegやavconvがなくても動くようだ。使えるんだろうか。

タブレットからアクセスしたら、roonサーバーがないよ、と出る。
やはり無理かと思ったら、よく見たら他のサーバーを探すか？、と表示されているのでクリックしたらアクセス出来た。
つまり、前のサーバーが止まったら、新しいサーバーに切り替える手続きが必要らしい。
roonへのログインから、あれこれ手続き、サインイン。

でも、そこからが大変で、roonって、やっぱりなんだかすごく分かりにくい。
設定のあちこちにトラップが仕掛けられているように感じる。まあ、慣れた人には分かるんだろうけど、セッティングなんて一度やったらずっとしないので、以前に何をどうやったかなんて忘れている。
なんというか、感覚的に使ってほしいんだろうけど、僕の感覚から外れている。

NAS音源は、Roonのcifsではなく、Fedoraにnfsでマウントしたのをローカル音源扱いして設定した。これがいいのかどうかは、分からない。
このNAS音源の読み込み、ライブラリの構築が、これがとてつもなく時間がかかるんだね、忘れていた。負荷が大きいからだろうか、Roonサーバーに加えて、LMSサーバー、NAS共々、使えなくなった。音が途切れるのだ。使える音源は、WiiM経由のDeezer、Spotifyのみとなった。
しばらくは辛抱、と思ったが、、、

結局、Mac miniのRoonは使用に至らなかった。
なぜか分からないが途中で落ちて、以降、起動しなくなった。
ffmpegやavconvがないからかな、わからない。Roon、アンインストール。

RoonサーバーはProBook 430 G5に戻った。こちらでは既にライブラリは構築されているので、直ぐに戻せた。

そういうわけで、WiFiで、両者の使用を再開した。LANケーブルはごちゃごちゃしていて邪魔気だし。

だけど、どうも繋がりにくいみたいで、LMSは次の曲に移るところでちょくちょく途切れる。
Roonのほうは曲が途中で途切れて、ネットワークのスペックが低いという警告が出た（英語で数秒で消えたので、細かいところは分からないけど、そういう内容だ）。
早々に共々、有線LANに戻すことになった。

戻してみたら、Mac mini LMSの音は、Daphileで鳴らしていた時よりも良くなった気がする。
Daphileでいつも特定の場所で音飛びしていたDeezer音源が、ちゃんと再生されるようになった。

Daphileのサーバーに使っていた機体は2台とも故障、不調があって、これを機に中古屋に引退である（部品取り用ジャンクとして引き取ってくれた）。ああ、こういうとこが原因だったのか、と思ったが、考えてみたらウェブの通信にmysqueezebox.comが噛んでいたことも関係していた可能性はある。確かめようがないことだが。
ともあれ、今回の機種変更で、以前より安定したということだろう。

一方、Roonの430 G5はサーバーとして使いやすいというわけではない。

一番目の問題は、ディスプレイを閉じたままだとOSが起動しないことだ。つまり、OSを再起動するたびに棚の底から引き出して、開けないといけない。Roonサーバーは基本、動かしっぱなしで、滅多なことでは再起動しないので影響は少ないんだけど、不便は不便だ。
実は、こういうノートPCは初めてな気がする。仕様なのか故障してるのか他の原因なのか、分からない。

そして、RoonがFedora OS起動時に起動しない。
Roonの説明ではOS起動に併せてRoonも起動する筈だと、今回、気付いた。それとは異なる挙動だ。Roonはrootで起動するのが関係しているかもしれない。

あと、ターミナルからのRoonの起動が簡単ではないことが分かった。以前は簡単だと思っていたんだけど、何故、簡単に出来ると思ったのか、今となっては分からない。sshでサーバーにログインして起動するんだけど、以前は出来たと思ったことが出来ないことに気付いた。
現在は、ちょっと裏技っぽいというか、邪道な気がする手法で起動している。洗練とかけ離れた、猿が思い付いたような手法で、ここに書くのは憚られるようなものなので書かないでおこうと思ったが、書いておく。

[ab@fedora2 ~]$ sudo /opt/RoonServer/start.sh
[sudo] ab のパスワード:
00:00:00.033 Info:  get lock file path: /tmp/.rnsgem0-
00:00:00.177 Info:  GetLockFile, fd: 36
00:00:00.177 Info:  GetLockFile, res: 0
00:00:00.178 Trace: Nope, we are the only one running
Initializing
Started
Not responding
has mp3float: 1, aac_fixed: 0
Running
^C
[ab@fedora2 ~]$

まず、ここまで。
コントロール+Cキーでコマンドから離脱したら、Roonも止まる。
これは、コマンドによるRoonの起動にパスワードが必要な動作で、パスワードを打ったab（私）が離脱したら、コマンドによる動作（Roon）も止まるという感じ。

ここで、さらにコマンドを打つ。
今度はコマンドの末尾に「&」を付けて、abが離脱出来るようにする。

[ab@fedora2 ~]$ sudo /opt/RoonServer/start.sh &
[1] 2290
[ab@fedora2 ~]$ 00:00:00.001 Info:  get lock file path: /tmp/.rnsgem0-
00:00:00.024 Info:  GetLockFile, fd: 36
00:00:00.024 Info:  GetLockFile, res: 0
00:00:00.025 Trace: Nope, we are the only one running
Initializing
Started
has mp3float: 1, aac_fixed: 0
Running
^C
[ab@fedora2 ~]$ top

sudoのパスワードを１回打つと、15分間は打たなくてもsudoが通るようになる。
ここでRoonを動かすコマンドを打つと、abによるパスワード打ち込み無しにRoonが動く。ここで、abがコントロール+Cキーで離脱しても、Roonはrootが引き継いだままで動きつづける。
そんな感じ。

こんなんでいいとは、あんまり思えない。今後の検討課題だ。でもなんか、Roonはこのままになるかもしれない。そんなに困らないし。

とりあえず、ごちゃごちゃしてるが、経過の記録。

前回、3月10日のエントリーで、2月になるとDeezerの再生が出来なくなると1月末からDaphileで告知されているが、まだ使えていると書いた。
3月17日、Daphileの表示が変わっているのに気付いた。下のスキャン画像にみられるように、日程の記述が現れている。

3月19日から使えなくなる、ということだ。
実際、19日の日中、うちのDaphileはDeezerを認識しなくなった。

いつになれば再び認識できるようになるのかは、分からない。
3月28日、Deezerの契約がPremiumに切り替わったら、Mac miniのLMSでDeezerの音源を取得できるようになるはず。こちらには新しいDeezerプラグインをインストールしてある。それまで待つしかない。

DapjileがアップデートされてDeezerが使えるようになる様子は、まだない。
暫くはWiiMのDeezer、SPDIFと、LMSによるSpotify、MPDアップサンプリング、USBで、ストリーミングは凌ぐしかない。

そうなってみて、どうなったかというと、両者で充分に満足しているということが、ない。
NAS音源への訴求が増えた。以前、高音質が得られることを確認したUSB-HDD音源の利用を本気で考えようか、などと横道に逸れたことを考えたりする。
落ち着いてない。

それでもWiiMからDeezerのMQA (2Lレーベル) を再生すると多少落ち着く。
MQA (352.8kHz)の再生は、M300SEはM500に及ばない気がする。DACの格が違うので、やむを得ないだろう。MPDでアップサンプリングしADI-2 DACに送り込むDeezerの音にも、残念ながら及ばないかな。M300SEは安いなりに健闘していると思う。
それにしても、ある程度の水準以上の音質は必要らしい。
どうも、コロナ禍で缶詰めになったときよりも我慢が効かないようだ。気分の問題だが、しかたがない。

その一方で、LMSの運用について分かったこと。ひとつのネットワーク環境で複数のLMSが動作するのは、やはり望ましくないようだ。

うちでは以前から2台のDaphileを運用していて、この時点では大きな弊害はなかった。時々、２つだと良くないのかな、と思わせる些細なおかしな挙動があるにはあった。具体的には例えば、選択していたプレーヤーへの紐付けが知らぬ間に切れて、他のプレーヤーが選択されているとか。しかし繋ぎ直せば済むことで、運用上、大きな問題にはならなかった。

それが、Mac miniのLMSサーバーを追加したところ、挙動がいよいよおかしくなった。他のサーバーを触ったら音を出しているサーバーの音が止まるとか、Daphileでアートワークが表示されなくなるとか、2台のDaphileのうち1台でSpotifyが使えなくなるとか。
LMSのログを確認したら、赤字でエラーが大量に記録されている。Unable to get players、とか、failed: Unable to send UDP reply packet、とか。

一般的に、2台のDaphileを使って音質アップを図る場合は、片方のLMSは止めることになっている。
ひとつのLMSで複数のプレーヤーを利用する話は多いが（これが出来るのはLMSの長所らしい）、複数のLMSをひとつのネットワーク内で併用するということについては、あんまり説明が無い。
検索したら、いくつか出てくる。

Multiple LMS Servers? Possible? - HomeSeer Message Board
https://forums.homeseer.com/forum/media-plug-ins/media-discussion/squeezebox-pcp/100918-multiple-lms-servers-possible
Multiple instances of LMS on same network? - Squeezebox : Community : Forums
https://forums.slimdevices.com/forum/user-forums/logitech-media-server/101345-multiple-instances-of-lms-on-same-network

複数のLMSサーバーを運用できるとは、書いていない。
バージョン7.9以前では出来ないと書かれている（8以上ではどうなんだろうね、、）。

実際のところ、うちでは複数のLMSを運用する必要性はない。興味本位で運用しているに過ぎず、1台で済ませるほうが合理的だ。
そして、LMSサーバーはDaphileでなければいけない理由もない。
Daphileは良く出来ている多用途音楽用ディストリビューションだと思うけど、うちではLMSサーバーとしての役割しか負っていない。Daphile以外のOSにLMSをインストールして、音を比較してどうかというのはあるけど、Spotifyのmp3 320kbpsで比較する限りにおいては、特筆すべき差異はないように思う。
それに現状、Deezerが聴けない。聴けるようになれば選択肢になるのだけど。

そういうわけで、今後はLMSサーバーは1台に絞り込むことにする。どのPC、OSを選ぶかは、状況を確認しながら検討が必要だ。

使えそうなPCは以下。
いや、いくつか、古くなったPCはこの機に処分することにした。若干、挙動がおかしいのもある。

HP ProBook 430 G5 - Intel Core i5 7200U RAM DDR4-2400 8GB fedora roon core
HP EliteBook 2570p - Intel Core i5 3360M RAM DDR3-1600 8GB daphile
HP ProBook 450 G3 - celeron 3855U RAM DDR3L-1600 12GB
Mac mini (Mid 2010) - 2.4GHz Intel Core 2 Duo RAM 8GB macos lms
Compaq 6730b - daphile

430 G5を選択するのが順当だろうけど、どうなるだろうか。
roonサーバーへのアクセスは、専用アプリで行う。
LMSにはウェブブラウザから行う。
使用するタイミングも競合しないので、１つのPCで共存できる、と考えた。

さて、やってみよう。
Logitech Media Server Downloads
https://lms-community.github.io/lms-server-repository/
上記、LMSのサイトに430 G5からアクセス。OSはFedoraなので、rpmファイルをダウンロード。
下記コマンドでインストール。

sudo yum install '/home/ab/Downloads/logitechmediaserver-8.5.0-1.noarch.rpm'

しかし、yumが簡単に見えて、実は、rpmのほうが親切。
インストール終了に合わせて、下記アドバイスがある。

ab@fedora:~$ sudo rpm -iv '/home/ab/Downloads/logitechmediaserver-8.5.0-1.noarch.rpm'
パッケージを検証中...
パッケージの準備中...
logitechmediaserver-8.5.0-1.noarch
Point your web browser to http://fedora:9000/ to configure Logitech Media Server.

インストールが済んだら、自動的に起動してウェブブラウザでアクセスしろということらしい。正直、yumでインストールしたら「完了しました！」というだけなので、どうしたらいいか分からなかったかもしれない（どこかに書いてあるのかも知れんが）。

LMSサーバーは普通に動くが、UPnP/DLNA Bridgeプラグインの設定で嵌る。
インストールはしたが、プレーヤー（UPnPレンダラー）を認識しない。

まず、Configuration fileがないので「Generate」というボタンを押して作れ、というんだけど、クリックしても変化なく埒があかない。
/var/lib/squeezeboxserver/prefs というディレクトリに、upnpbridge.xmlという、本来は自動的に作られる筈のファイルが作られない状態になっているらしい。ディレクトリのパーミッションをchmodで変更。それでも動かない。

ログを確認したら、Cannot load SSL libraries、ということで、Squeeze2upnpというのが起動できないままリスタートを繰り返している。
https://forums.slimdevices.com/forum/user-forums/logitech-media-server/1683394-airplay-and-chromecast-bridges-fail-to-load-ssl-libraries
上記url、フォーラムで同様の状況あり。
Select Binaryの設定で、staticを選択する必要があった。

これで漸く起動してUPnPレンダラーを認識した。ログも赤字が消えてきれいになった。
こういう苦労を、Daphileだったらしなくていいのだろう。
動き出したら、upnpbridge.xmlが出来ていた。パーミッション変更が必要だったのかどうかは分からないままだ。

音は、悪くは無いかな。

以上、状況の記録。

前回のエントリーで、2月になるとDaphileでDeezerの再生が出来なくなるので、方策を探っていると書いた。
まだ使えている。
しかし画面にこんなQRコードが出る。これは1月末からずっと出ている。

そうこうするうちに、2月末、mysqueezebox.comなしでも動くDeezerプラグインがアップされた。本当にありがたいことで、足を向けて眠れない。彼らはLMSのUPnPプラグインや、TidalやYoutubeのプラグインも作っている。
以下、いろいろ参考urlと引用（一部、誤記は修正した）。

Logitech is closing mysqueezebox servers | Deezer Community, bringing music lovers together
https://en.deezercommunity.com/features-feedback-44/logitech-is-closing-mysqueezebox-servers-78309?sort=dateline.desc#comments

Cedzerosept
Lover
21 replies
3 days ago

I can also confirm that a solution has been found and works, thanks to Philippe44 and Michael Herger. It allows squeezebox and squeezelite users to access Deezer without the need of mysqueezebox.com servers. They developed a new Deezer Plugin for LMS, all this running without the mysqueezebox.com servers.

Please note that a Deezer paid account is required.

For the moment it seems that the easiest way to install the new LMS plugin is as follow:

1. Install / Upgrade to LMS 8.5.0
2. Use the standard LMS web interface; go to the ‘Plugins’ section / tab (“Plugins” / “Manage Plugins”)
3. At the very end of the plugin list, you will find an “Additional Repositories” section → add the following repository URL: https://raw.githubusercontent.com/philippe44/lms-deezer/main/repo/repo.xml
4. Click on the “Save Settings” button located in the bottom left
5. Refresh the page and you should see the new Deezer plugin listed at the very end of the plugin list
6. Tick the box and Click on the “Save Settings” button located in the bottom left
7. The new Deezer Plugin will then appear in the “Active Plugins” section at the very beginning of the Plugin list
8. Click on the “Settings” link following the Deezer plugin description & Author column
9. On the “Deezer Plugin” configuration page, add your Deezer Account and ARL token and click on “Save Settings”
10. I don’t remember if it’s necessary to restart LMS, but normally, now all should be Ok!

If necessary you can follow the dedicated thread on the slimdevices forum: https://forums.slimdevices.com/forum/user-forums/general-discussion/1668568-tidal-deezer-pandora

Enjoy!

LMS Coｍmunity
https://lms-community.github.io/
Logitech Media Server Downloads
https://lms-community.github.io/lms-server-repository/

Logitech Media Server
https://wiki.slimdevices.com/index.php/Logitech_Media_Server.html
Logitech Media Server repositories
https://wiki.slimdevices.com/index.php/Squeezebox_Server_repositories

GitHub - philippe44/lms-deezer
https://github.com/philippe44/lms-deezer/

さて、新しいDeezerプラグインを使うためには、Logitech Media Server (以下LMS)のバージョンが「8.5.0」でないといけないらしい。
DaphileのLMSは8.3.1なので、使えない。
どこかに、8.5.0をインストールして、そこにDeezerプラグインをインストールする必要がある。

LMSは、ラズパイなどでも動く。
今回は使わなくなっていたMac mini (Mid 2010)にインストールすることにした。roonをインストールしようとして出来なかった奴だ。OSは10.13.6。
インストール経過のスクリーンショットは撮り忘れた。

Mac miniを起動し、上記「Logitech Media Server Downloads」にウェブブラウザでアクセスする。
8.5.0 - Development Build から「LogitechMediaServer-8.5.0-1709149164.pkg」をダウンロード。
pkgを開きインストーラーを起動。
手順を踏んでいくと「システム環境設定」にインストールされ、起動した状態になる。

上部に設定項目のタグが並んでいる。
Statusから、LMSのstop、startを指示する。Mac mini起動時にLMSを起動するかどうかも設定できる。
Libraryで、LMSの「名前」を設定しておく。今回は「miniLMS」にした。
Accountは、今回は設定せず。

Advancedからは「Web Renote Control」と「Advanced Settings」というボタンをクリックして、Mac miniのウェブブラウザで操作、設定画面を開くことができる。
しかしLAN上にある他のPCのウェブブラウザからLMSサーバーにアクセスして、これらの操作画面を開くこともできる。
informationは状況表示のタグで、ここからIPアドレス等、確認できる。

LAN上の、普段使いのノートPCのウェブブラウザに、LMSサーバーのアドレスを打ち込む。今回のうちのMac miniの設定だと「192.168.1.50:9000」。
これでLMSにアクセス出来る。

右下のボタン「Settings」から設定画面に。

上に設定のタグが並んでいる。細かい説明は省略。Daphileに慣れていたらそんなに困らない気がする。
「Manege Plugins」のタグから、プラグインをインストールできる。

一番下にスクロール。
上で引用したdeezercommunity.comでの記述にあったリポジトリを書き込む。
右下「Apply」をクリック、じきにリポジトリが認識され「Deezer local」表記でプラグインが現れる。

チェックボックスをチェックし、Apply、以降、手順を踏んでいくとインストールされ、「Active plugins」のリストに表示される。
プラグインの右側に「Settings」のボタンがあるので、クリック。ここから、Deezerアカウントを設定する。

音質はCD(FLAC)。「Add Account」ボタンをクリック。

ログイン画面が表示される。
自分のDeezerアカウントとパスワードを入力しログイン。

ところが、うまくいかない。
動かなかったり、いつまで待っても何も表示されないのっぺらぼうな画面になったまま、切り替わらない。
気が付いたら、プラグインのセッティング画面はこんな感じになっていた。

Authorization failed, or no Premium account.と。
Premium account、って、何だ。

ここで、思い出した。
Deezer HiFiって、今となっては古い契約形態なのだ。
いつ頃から変わったのか分からないんだけど、昨年の11月に気付いて、当時は内容の詳細がはっきりしなかったので切り替えないまま忘れて、そのままになっていた。

Deezer Premiumに変更したら使えるのか。
改めて確認したら、Deezer HiFiよりも安い。音質の低下も無いようだ。1年契約にしたら月に千円しない。いいのかな、そんな安くて。

切り替えようとしたら、こんなん出た。

3月28日に有効って、、、 じゃあ、それまではDeezer HiFiで、ってことなのか。
ちなみに、月々支払いへの変更でも切り替わるのは3月28日だった。9月29日から入会して支払日が28日になっているので、そういうことになるのだろうか。

変更手続きをしたが、変更になるのは月末だ。
プラグインを使えるかどうか確かめるのも月末になる。それまでは、おあずけだ。

時間が経ったらこんなことになっていた。

そうですか、そうですか。

さて、Deezerが聴けなくても、Spotifyなら聴けるんじゃないか、と思ってプラグインをインストールしてみたんだけど、聴けない。
英語で何か表示が出ているのを確認したら、プレーヤーがない状況では使えないということらしい。

プレーヤーとはなんであるかというと、要するにLMSの出力先だ。
うちの普段のDaphileの使用状況では下記のような信号の流れで、この場合、MPD serverが、プレーヤーとして選択されている。
Web Streaming ＞ Daphile (LMS server, UPnP server) ＞ MPD Server (UPnP renderer, PPAP Front)

今回、最初は下記のような信号伝達を想定していた。
Web Streaming ＞ Mac mini (LMS server) ＞ Daphile (UPnP server) ＞ MPD Server (UPnP renderer, PPAP Front)

Daphileは、他のサーバーのLMSを使用するように設定で指定できる。
しかし、Mac miniのLMS serverを使いながら、DaphileをUPnP serverにすることは出来ないらしい。考えてみたら、動いているLMSはMac miniのもので、そこにはUPnPプラグインがないのだから、出来ないのが道理である。

つまり、Mac miniのLMSにもUPnPプラグインをインストールして、そこからUPnPレンダラーをプレーヤーにする必要がある。そうなると、Daphileは必要ないことになる。
Web Streaming ＞ Mac mini (LMS server, UPnP server) ＞ MPD Server (UPnP renderer, PPAP Front)

Mac miniのLMSにUPnPプラグインをインストールすると、家庭内LAN上にあるUPnPレンダラーがいくつか（MPDサーバー２つとWiiM Mini、あとDaphileサーバー２つ）、出力先のプレーヤー候補として認識される。
MPDサーバー1台をプレーヤーに設定。

これで、LMSがSpotifyからのデータを読み込むようになり、音が出た。
Mac miniでSpotifyを鳴らしたときの音をDaphileを使ったときと比較したけど、殆ど差異は聴き取れなかった。

近日中にmysqueezebox.com.が閉鎖されるのは確かなのだろう。
Daphileも、mysqueezebox.com.への依存を排除したLMS 8.5.0に移行するだろう。それがいつになるのか、ということだと思う。Daphileのアップデートを暫くは確認しながら、運用を考えていくことになると思う。Deezerだけではなく、たぶんTidalも使えるようになるだろう。

Daphileのアップデートがないなら、LMSサーバーをMac miniで運用していくことになる。
まあ、でもたぶん、アップデートがないということは、ないだろう。うちのDeezer HiFiがPremiumになるのと、どっちが先だろうか。

前回エントリーの追記に、2月になるとDaphileでDeezerの再生ができなくなると書いたが、まだ使えている。いつまで使えるんだろうね、、、
再度、引用。

https://forums.slimdevices.com/forum/user-forums/general-discussion/1668327-uesmartradio-com-and-mysqueezebox-com-servers#post1668327
logitech FORUMS
UESmartRadio.com and MySqueezebox.com Servers

After a more than ten year journey, as of February 2024, we will discontinue our UESmartRadio.com and MySqueezebox.com servers.
/—snip—/
Most notably this will impact users of TIDAL, Pandora, and Deezer.
/—snip—/

使えているからといって安穏とはしていられない。Daphileが使えないとなったら、PCのウェブプレーヤーかスマホやタブレットのDeezerアプリからの出力を、何とかしてオーディオシステムに送る方法を見つけないといけない。
とりあえず、BubbleUPnPを試したが、使えない。過去にDaphileを使い始める前にも試みたことがあって、うまくいかなかったんだけど、やはり今回も難しかった。

DeezerのストリーミングデータをDLNA/UPnPで出力できる装置が欲しいけど、見つからない。Daphile + MySqueezebox.comは、極めて貴重だった。
見つからない以上、諦めるしかない。

そういうわけで、WiiM Miniを入手した。

ストリーミングレシーバーとか、いうのかな、いろんなストリーミングサービスを受信して、イヤホン端子や光デジタルから出力する。WiiM MiniはDeezerを受けることができる。

WiiM Proという選択もあったんだけど、入力に有線LANがあるなど機能が多い分、Proのほうがノイズが多いかもしれない。
デジタル出力はUSBがないのは同じで、SPDIF出力のみだ。
こちらの要求は、当面そこそこの音でDeezerをギャップレス再生できればいいので、割り切ってMiniにした。
あと、もうひとつ、以下は製品サイトのサポートの表記から引用。

Features we're thinking about in future updates:
/—snip—/
Cast to Sonos and other 3rd DLNA devices
/—snip—/

将来的には、DLNAでデータを飛ばすアップデートを考えているらしい。もしもこれでうちのPPAPサーバーにデータを送れるようになるなら、非常にありがたい。
いつになるかは、分からないが。

音質は、とりあえず光出力をPegasus R2Rに入れて、Deezer HiFiの44.1/16として、普通にいい音で鳴る。
1万円以下でこの働きなら、現状、なにも言うことはない。PPAPサーバーを通した音と比較したら劣るけど（微細な表現とか芳醇さで差が出る）、十分に許容できる水準だ。
なんとなくだけど、44.1/16の音は、昔より良くなっている気がする。あれこれと電源やノイズの対策を重ねてきているのが効いている可能性はある。

ついでに書いておくと、なんとなく全般的に感じることなんだけど、最近の機械は光入力の音が昔（20世紀頃を想定）に比べて良くなっている気がする。これは入力信号の処理方法がどこかで技術的に改善されたんだろうか。よく知らないので分からないけど、そういうことがあってもおかしくないと思う。

むしろ困るのは操作性の方。手元のタブレットにWiiM Homeというアプリをインストールして、そこから操作するのだけど、いかんせん、パソコンで操作するDaphileのほうが操作性はいい。

これは、もう、仕方ないかもしれない。
パソコン画面で使うDaphileは、一つの画面に表示される情報量が多いのが僕にとって良いので、タブレットアプリでは端から勝負にならない。Wiim HomeはWindows、Macのアプリもあるんだけど、うちの環境はLinuxなので、やや敷居が高い。

タブレットでは、Deezer、Spotify、Squeezer、Roonなどアプリを触っているが、WiiM Homeはそれらと比べて劣ることはなく、一般的な使いやすさの水準は十分にクリアしている、と思う。
ただ、My Libraryの中を検索できないのはつらい。ひたすら狭い画面を指で、求める音源を探してスクロールするしかない。自分のライブラリなんか持つなとでもいうようだ。
もはや、辛抱して使うしかない。

もうひとつの問題は、Deezerにタブレットやスマホからアクセスするので、気が付いたらこれらの電池が0%近くになっていること。日常的に使うものなので、ときに慌てることがあるので、注意が必要。音を流しっぱなしにしている時は、WiiM Homeは止めておいた方がいい。

WiiM以外に使える機種はないのかというと、BluesoundもDeezerに対応している。USB2.0で出力できる。
Bluesound NODEは8万円、WiiM MIniよりも高価な分、上質な音が狙える可能性がある、かな。しかし、今回は様子見。WiiM Miniを買ったばかりだし。

日本のコンポ、ネットワークプレーヤーもいくつかチェックした。Deezerに対応している機種はそこそこあるけど、DLNA/UPnPで出力してくれるようでないと選択しようという気にならない。そういう機種はまだ見つけられていない。

さて、更に何ができるか考える。

Deezerで配信されるMQAを鳴らす手段がなくなるので、対処したい。MQAはこの先どうなるか分からないので、聴けるなら聴けるうちに聴いておくほうがいいかな。

S.M.S.L M500がUSB入力でMQAに対応しているけど、DeezerからDaphileへの経路が使えなくなったら、M500には伝送できない。
WiiM Miniの光出力によるMQAを受信できるDACが必要になる。
調べたら、S.M.S.L M300SEというDACが、SPDIFでもMQAに対応しているとのことで、しかも2万円を切る。というわけで、ゲットした。こんなふうにして散財していくものなのかも。

M300SEは、光入力でMQAを受けることが出来るという。そこで、WiiM Miniからの出力を入れてみたが、認識しない。
PCMとして再生する。なんでだ、、、

原因は、WiiM Homeでの設定ミスだった。
タブレットの画面で「デバイス」から、WiiM Miniの設定に入れるんだけど、その中に「オーディオ設定」という項目があって、その中に「MQAベータ版」という項目がある。
そこを「オン」にしてはいけなかった。
これは、WiiM MiniでMQAを処理するためのもので、DACでMQAを受けることが出来る場合は、触ってはいけないのだろう。ここをオフにして、普通にDeezerのデータがロスレスでM300SEに送られるようにしたら、ちゃんとMQA (352.8kHz) を認識、352.8kHzで再生できた。

ちなみに、2Lの音源が全て352.8kHzなわけではない。中には44.1kHzのMQAもある。44.1kHzのMQAともなれば、PCMと比べて良いのかどうかよく分からない。聴き比べまではしていないから評価できないのだ。案外、環境によっては違いが出るのかもしれない。

M300SEの音はいい。
若干、低音が細い気がするけど、そこまで求めるのは多くを望みすぎだろう。M300SEは完成度が高いという評がネット上にあって、僕もそのとおりだと思う。

ちなみに、WiiM MiniはUPnPレンダラーでもあるので、現時点ではDaphileからMQA音源のデータを送ることが出来る。
しかしそれも、2月末までには終了するだろう。

さて、DaphileからWiiM Miniに送るMQAと、WiiM Homeからの指示でWiiM Mini自身が受信するMQA、どちらの音がいいか。
後者の方が、伸びやかに聞こえる。同じデジタルデータでWiiM Miniから光出力するMQAなのに。これには、MQAもデジタルオーディオの呪縛から逃れられないんだなあ、という思いを強くした。

TidalがMQAから撤退する中、MQAのストリーミング配信は、Deezerの2L音源に殆ど限定される状況になった、ということだ。
ある意味、貴重かもしれない。

個人的には、MQA (特に352.8kHz) は手軽にかなり良い音が得られるので、フォーマットとして残ってほしいと思う。音源制作過程がPCMと違って密室だというので受け入れられないという意見もあるようだが、録音機器や再生機器の特性を反映させた上でのMQA音源の再生なので、それを公開したらそれら個々の機器のジッターの内実を晒すことになる、と思う。
そんなことになるのは、機器のメーカーは何処も受け入れないと思うので、結果、MQAは密室のままでやっていかざるを得ないだろうと思うので、まあ、仕方ない。

個人的には、何をやっているのか、公開してもいいのではないか、と思う。
幾多のレコーディング機器やオーディオ機器のメーカーが慌てることになるだろうけど、ほとぼりが冷めたらデジタルオーディオとジッターを取り巻く状況は1歩も2歩も前進すると思うので。ただ問題は、そうした騒動があったとして、その後にMQAを受け入れるメーカーが、どのくらいいるだろうかということだ。高音質音源はPCMかDSDのハイレゾに特化するというメーカーばかりになるかもしれない。
まあ、そうなったらなったで、現状と大して変わらないという見方もできるが。

最近、Grimmというオーディオメーカーが、標本化定理に沿ったDA変換が出来るようになったと謳っているとネット上で見た。
製品は数年前に売り出されていて、MU1という。
最近のデジタルオーディオの論調は「理想どおりのDA変換はDACチップの技術的限界で不可能」というものだったので、どうやって実現しているんだろう、とか思う。問題は、量子化誤差（量子化ノイズ）とか、折り返し歪みといったものになるんだろうけど、ここらあたり、ジッターの悪影響で括ってしまってもいいのではないかと（乱暴だな）、、、

ネット上で触れられる情報によると、MU1は殆どコンピューターであり、コンピューターで扱える特別なフィルターで技術的限界越えを実現した、ということで、僕なりに考えたのは、おそらく、そうだとしたら、MU1が行っていることは、MQAが行っていることと実は似ているのではないか、ということ。
つまり、機器のジッター特性を排除するフィルターを機器に実装したら、出てくる音はジッターの影響を最小限にした音、つまり、標本化定理に沿った理想的なDA変換に極めて近似した音になる。
そうした手法ならば、やっていることはMQA再生に似ているのではないか、と。
空想だけど。

GrimmとMQAの違いは、Grimmはハイエンド機器で、MQAはM300SEでも実装できるということと、Grimmは普通のPCM音源の再生でも恩恵が得られるが、MQAは特別に仕立てたMQA音源の再生に限られるということ。
そして前者はビットパーフェクトなPCMの再生で、後者はロスレスではないブラックボックスだ。

どっちがいいかとか、どっちがダメとか、そういう議論には、僕は結論を出したくない。
むしろ、両方ある方がいいんじゃないかと思う。PCMやDSDは基本技術として重要だけど、それだけでは閉塞的だ。

M500とM300SEで、MQAの音を比較しようと思っていたら、M500にUSB出力するpiCorePlayerが使えなくなった。
Squeezeliteが動かなくなったのだ。まだMySqueezebox.comのサーバーは動いていて、使えなくなった理由は不明。
試しにpCPにLMSをインストールしてみたけど、やはり動かない。よく調べて何か設定に手を入れたら動くのかもしれないけど、よく分からない。pCPを新規インストールしたら一瞬、動いたが、じきに不調となって音が出ない。

現状、Ras Piからの出力は、UPnPでDeezerからの信号を受けてUSB出力してくれさえしたらいい。
Volumioに入れ替えてみた。
音は出て、DeezerのMQAも再生できる。しかし、なぜか安定しない。すぐに音が出なくなる。こっちも結局、原因は不明だ。継続使用は断念。

別に、PPAPを通してapu2からMQAデータを送ることは、出来ないわけではない。問題はmpdなど複数のサーバーの設定を変えないといけないことだ。そして、普段の使い方に戻すときにはまた設定を戻してやる必要がある。
面倒だ。
DAC間のMQA再生音の比較なんか、しなくてもいいかな。

そうこうするうちに、うちにあった一番古いNASが、ついに壊れた。
さいきん、いろいろ壊れる。
2007年のIODATAの製品で、一番最初に入手したNASだった。2台目は同型機だが、これも暫く前、昨年だったかに壊れた。3台目はオーディオ用のつもりで2010年代に入手したのだけど、早々に不調になり、今も使っている4台目のHS-210に代替わりした。その後、HS-251、TS-212p、HS-264、と入手している。

今、残っているのは、HS-210、TS-212p、HS-264ということになる。
考えたら、ずいぶん壊れたものだ。HDDが壊れたものもあれば、そうでないのもある。
古いデータは500GBの半分しかなかったので、必要なデータは新しいNASに救出した。移動しきれなかったデータもあるけど、長年触ることもなかったもので、なくしてもダメージは少ないものだ。

思えば世の中も、最近はいろんなものが壊れていく。
日本でも世界でも、壊れなくてもいいものが次々と壊れているので、うちなんか何でもない方だ。
もうじき、花粉症の季節が来る。
去年はゴーグルとマスクなしには外を歩けなかった。
今年は、症状が軽ければいいんだけど。

世の中いろいろあるが、がんばっていこう。
うちのシステムの現状は、以下のような感じ。

うちにはメイン系とテスト系、2系統のデジタル再生経路があって、気分によって適宜使い分けている。
先日から、テスト系のmpdサーバーに銅メッシュを組み込んで様子を見ていた。
音質は良くなったと思うのだけど、外したらどう変わるかを確認してみた。銅メッシュを使用する前は、柔らかさに欠けるがすっきりしていてそれなりの持ち味がある音だと思っていたんだけど、なんだか以前は感じていた魅力を感じられなくて、けっこう早々に銅メッシュを戻した。戻してみての音は悪くない。

サーバーによって差異がある。メイン系のmpdサーバーは、銅メッシュは不具合が出て上手くいかなかった。
オーディオ用サーバー6台のうち、銅メッシュで改善したと思ったのは3台。2台はよくなった気がする感じで、1台は不具合で不採用になった。良くなる確率は高かった。
銅メッシュを組み込んで改善するサーバーが多いということは、他にも工夫の余地があるということだ。

ノートPCをオーディオ用で運用するというのは良し悪しだ。というか、音のことを考えたら、良いことは基本的には無い。使い勝手や取り回しがいいだろうとか、そういう理由で使っている。

しかし当面、これでいく。
理由は、変更した方がいいかな、と思うサーバーが意外と少ないからだ。
PPAP関係のサーバーでは、Back-End、Middle-Endはapu2で、画像出力も冷却ファンもないボードPCで理想に近い。Frontには相応のスペックが必要になるので選択肢が限られ、置き場に困るようなものは使えないので、ノートPCとなる。
結局、残るのはDaphileサーバー2台ということになる。替えたら音が良くなるだろうか。ストリーミング音源の入り口だが。
そういうわけで、最優先課題ではない。
ノートPCでどこまでやれるかやってみるというのも、個人の勝手でやる分にはありだろう。

次に、DACのUSB接続。
ケーブルの抜き差しでDACを替えるので、一般的なUSB中継コネクタで丈夫そうな奴を介して接続していた。
そんなやり方でも意外に音は悪くならないけど、どうなんだこれ。

オーディオ用のUSBケーブルという話しに行くのが順当なのかもしれないが行かない。

2018年頃まで使っていたUSB-029H2-RPを復帰させて、USB中継コネクタから置き換えてみた。
昔はACアダプターにつないで電源をとっていたが、今回は、それは使わないことにした。PCとDAC間のGNDを切断する設定ができるんだけど、それもしていない。切ったらPCトランスポートとDACがうまく接続しない場合があるからだ。

これは、直ぐにできることなのでやってみた。
あまり期待してなかったが、これが効いた。
音色の色彩感が増している。768kHz/32bitの信号も問題なく伝送している。

これでいこう、と思っていたのだけど、ある日、GNDを切ってみた。
音の変化は、感じられない。
しばらくは問題なかったんだけど、大晦日に急に伝送が不安定になり音が出なくなった。
USB-029H2-RPを外してつないだら、DACがUSB信号を認識し音が戻った。
音質は変わらないかな、、、こうなると、GNDをつなぐ設定でUSB-029H2-RPを戻しても、DACとつながらない。理由は何でか分からないが。

しばらくUSB-029H2-RPなしで使った後、USB-029H2-RPを再使用すると、、、つながった。
こうなると、音が良くなったように感じられる。
たぶん、GND周りで何か問題が蓄積してつながらなくなり、使い方を変えることで時間経過とともに改善したのだろう。
暫く試験運用したが、GNDがつながっていたら問題はないようだ。

次、UPS（OMRON BY50S）のバッテリーを替える。
前に替えてから3年近く経っている。
これは最近、警告ブザーが鳴ったので、交換した方がいいのだ。最近といっても、数週間以上たっている。新しいバッテリーを取り寄せて交換した。
交換しての音の変化は、音に張りが出たような、気がする。情報量も、増えたのかな、音が重層的に、かつ分離が良く聴こえるようになった、気がする。前は聴こえてなかった音が拾えてる気がする。明瞭で透明感が高い。
とっかえひっかえいろんな音源を聴いてみるが、なんだか思った以上に良くなってる気がする。

これってもしかして、「回復した」ってことなのかな。
どのぐらい前だったか、はっきりしないけど、以前は、こんな感じに聴こえていたような気がする。
古いバッテリーは箱詰めして宅急便でメーカーの回収に出したので、もう新しいのと入れ替えての比較はできない。いや、回収に出してなくても、そんな面倒なことは、しないかな、、、どうだろう。

もしかしたら、こういう電池は、早めに替えた方がいいのかもしれない。
暫く前に、DACへの給電元をUPSから電源タップに変えている。UPSより電源タップのほうが音が良いと思ったのだ。しかしUPSのバッテリーの状態が評価に影響していた可能性がある。

考えてみたら、これって、サーバーの電源環境だ。
やはり電源周りは重要なんだろう。

SM-SX100とDACをつなぐXLRケーブルを替えている。
今回の変更は音質を気にしてのものではなく、ADI-2 DACをスタンバイ状態にして暫くしたら、ハウリングが起きることに気付いたのがきっかけだ。Brooklyn Ampではなぜかハウリングは起きない。Pegasus R2Rでも起きない。
ハウリングの原因は、結局のところ、はっきりしない。
ケーブルがノイズを拾っているのかな、と思ったので、替えてみた。結局、替えても状況は変わらない。
ADI-2 DACのスタンバイ状態を解除して、音を出せる状態にしたらハウリングは消える。気持ちいいものではないけど、暫く様子をみることにした。

そういう経緯の結果、ケーブルも固定せずに音色の様子をみることにした。
長らく使っていたオヤイデのTUNAMI TERZO XX V2/0.7を、ortofonのReference 8NXに変更。8NXは20年ほど前に使っていたもので、ずっと死蔵していた。響きは8NXのほうがいいような気がする。TUNAMIよりもあたりが柔らかい。柔らかすぎかどうか、暫く試してみるつもり。
SAECのXR1000も試した。これも死蔵していたもの。こっちは実直なケーブルという印象。TUNAMIと8NXの中間だけど、響きの成分が少なく感じるせいか、印象としての硬さはTUNAMIよりも上。
しばらく、音質を比較し検討してみる。

ハウリングについては、様子を見ながら考える。

前述の諸々の処置の末、Brooklyn AmpとPegasus R2Rの組み合わせが、以前よりも良くなっている。温度感、湿度感を維持しながらハイファイで、以前は出来なかった両者のいいとこ取りが出来ている気がする。
これは望ましい向上だ。

Pegasus R2Rの音が良くなっているのは、デジタル入力信号のジッターが減っているのだろう。
ADI-2 DACはもともとジッターの影響を受けにくい設計が売りだと思うので、比較したらPegasusの方がジッター減少の恩恵が大きいかもしれない。NOSで使っているし。

さて、Brooklyn AmpのXLR入力に使っている固定式アッテネーターのインシュレーター、これまでゴム板の積層で支えていたんだけど、ましなやり方がないかと考えていた。
最近、たまたまYoutubeで、さざれ水晶を袋に詰めてインシュレーターにしたら良いという話を見た。水晶はリプラスのインシュレーターを昔、VRDS-25xsに使っていたことがあって印象がいいので、これで置き換えてみるか、ということにした。

Youtubeによると、さざれ水晶を麻袋に入れて使うということだったんだけど、麻は昔、これもVRDS-25xsで使って、音がカサつくという印象があるのでやめて、コットンの袋にした。ところが、ネットで買ったら、これが体育館のマットのような臭いがする。ちょっと残念感がある。

袋を洗ってみたけど臭いは残る。しかしそれでもゴム板から水晶袋に置き換えたら音は良くなったような。
硬質ゴムの音から、水晶と綿の音に変わった。耳当たりがやさしくなった気がする。同時に見通しが良くなって音場が広がった気がするかな。

図の上では、以前に削除したサブシステムの表示を戻している。これは、Roonを試す機材にしたからだ。Qobuzが日本でも使えるようになれば、うちでもRoonの真価が分かるはずだ（いつになるんだろうね）。

ほんとうはメインシステムに組み込んで比較したいところだけど、面倒くさがりな気持ちが勝って出来ていない。そのうち試すかもしれない。
余っていたノートPCを1台、Roon Serverに使っている。
またノートかよ、って感じだ。

ブログのトップに旗を貼った。
日本国内もひどいが、世界もひどい。
何ができるかと言っても、個人にできることは少ない。
でも、本当は、連帯すべきなのだ。
個人主義の時代というけど、イコール他人の不幸は気にしないという意味ではない。
痛みは連鎖する。
そして、皆を不幸にする。
他人の不幸に、自分のことのように怒るのは、むしろ当たり前で、自然なことなのだ。
当たり前のことが、当たり前な世界になればいい。

みなさま、よい新年を。

NHKがドキュメントを放送した。

宮﨑駿『君たちはどう生きるか』は高畑勲からの解放だった　『プロフェッショナル』を観て
https://realsound.jp/movie/2023/12/post-1523016.html

まあ、なんというか、驚いた。
あそこまで高畑への思いが強いとは。
たぶん、駿にとって父親のような存在だったのだろう。

ネット上には、そんな駿の姿を受け入れにくくて、恣意的な編集があるのではないかという見方も上がっているが、僕みたいなのが言うのもなんだが、写ってる画面自体の説得力がはんぱなくて、そんな見方は捻じ伏せられていると思う。 恣意的な編集は、そんなことをする余地がある場合にできることではないだろうか。

そして、あの映画が、どういう経過で作られたかが分かった。
いろいろと、腑に落ちた。
どう腑に落ちたのかといわれると、説明しにくいが。

おそらく最初は、失われたものたちの本と君たちはどう生きるかをミックスしたような話だったのだろう。そこに幼いころの駿をモデルにして主人公に据えるような。
高畑をモデルに描きたいというのは、最初からあったのだろうか。
少なくとも、高畑に見せたいというのはあっただろう。それは、多かれ少なかれ昔から、駿の作品にはあっただろう。

それが、高畑が亡くなり、別の話になった。高畑をモデルにしたキャラクターがいたとしても、生きているときに見せたいものと、亡くなった高畑に向けてのものでは、まったく違うものになるだろう。
あの、木に竹を継いだようにも見える構造の不可解さは、駿のモチベーションのベクトルが大きく変わったことによるのだと思う。あの映画は高畑への追悼であり、同時に駿自身の内面、長年にわたってアニメーションを作ってきた過去に向けての追悼でもあるのだ。

あの映画には、生きていく若い駿が描かれている。
消えていく大伯父は老いて力を失っていく高畑であり、駿でもある。

どのキャラクターのモデルが誰で、というのは鈴木プロデューサーからかな？、公開当初からわずかながら出されていたと思う。
しかし、深い内実は今回の番組まで晒されてなかった。この映画、内実を晒してしまったら、その内実だけで作品が語られてしまうリスクが大きいような気がする。

下手な宣伝は打てない。
とってつけたような表面的で売れ線な宣伝を打ったら、作品に込められた監督の内面を傷付ける。泥を塗ることになる。追悼を売るのかということになる。
宣伝を打てなかったのは、あまりにもプライベートが反映された映画だったからだろう。
鈴木氏は、見る人が見たらわかると言っていたような記憶がある。
たぶん、実際、そういう映画なのだろう。

今回、あの番組で、あそこまで制作側の、駿の内実が晒されて、作品そのものへの評価や観客の理解はどうなるのか、とは思う。
プライベートな映画は、アングラ（僕の言い方だけど）だったらやりやすいのだ。
大規模な商業映画ではやりにくいはずだ。
まあ、やっちゃったわけだけど。ふつうじゃないわな。

真人に向かって自分の時に戻れと叫ぶ大伯父のシーンを繰り返しアフレコする場面で、ドキュメントは締め括られる。
なるほど、これはそういう映画なんだな、と。
あれが大伯父の本音ということだ。

プロフェッショナル　仕事の流儀　ジブリと宮崎駿の２３９９日
https://www.nhk-ondemand.jp/goods/G2023132680SA000/index.html

とても面白く、興味深いドキュメントだった。
再放送しないそうだ。
見たければ現状、オンデマンドで見るしかない。
しかし金払ってみてもいいのではないかと思った。

駿は新しい作品を作るだろうか。個人的には、未来の話を見たい。
彼の作品は、昔の話が多い印象がある。
コナンは未来の話に感じられる。あれ以降は描いていない。
ナウシカは未来といえないこともないが、あまりに遠くかけ離れていて実感がない。On Your Markというのがあるようだけど、どういうつもりなのかよくわからない。実際、実験なのだろう。

未来は描きたくないんだろうか。というか、暗い未来しか描いていない気がする。
明るい気持ちになれる未来ものを、また見たいなあと勝手に思う。

あと、今回のドキュメントを見て気付いたことがある。
高畑はコナンに関わっている。調べてみたら、ラオ博士を演出している。
だから、たぶん、やはり、大伯父にはラオ博士が入っている。これは、だからどうなんだって話だけど。

今回は、大した内容はない。
デジタル音源を扱うストレージは悩ましいという話。

若い頃にデジタルだから音は同じと聞かされ続けたせいか、理屈や体験で理解はできても、未だに「同じ01なのに音が変わる」ことについて、違和感がある。同じデータなら同じ音で鳴ってほしいと思ってしまう。
NAS音源とストリーミングで音が違うのを、同等にしたいと思う。
まあ、その一方で、USB HDDによって音が違うのは、なるほどなあって感じで受け入れているのだけど。

とあるオーディオ評論家が、苦言を呈しておられる。
ジッターの影響を減らすように配慮した音源をイベントで用意しても、オーディオ業者は理解していないので無意味になるということらしい。音質が良くないUSBメモリに音源を入れてくる、配慮した音源を業務用のパソコンに保存される、など。
せっかく配慮した音源を用意しても、周囲の無理解で音源の優位性が失われる。
お気持ちはお察しする。

しかし、僕はむしろ、デジタルコピーしても音質劣化しないようにするにはどうしたらいいのか、を知りたい。

アナログなら評価が定まった良質音源を探すことが出来る。
デジタルではそうもいかない。
形が変わらないアナログと違って、デジタルはコピー、転送、ユーザーの手元で品質がコロコロ変わる。
変わっても元のデータは同じ。

アナログディスクは割れたらおしまい。
デジタルデータはバックアップがあればストレージが壊れても残る。
データは同じだが、アナログの良質音源とは違って「ジッターを帯びた不完全な音源」となる。いや、デジタル音源はすべて、そういうレッテルを、ユーザーが自身によって張り付けざるを得ない。
あるいは、「01だから同じ」と割り切るのかな、、、

ストレージ、USBメモリやHDD、リッピングやコピーの方法、何がいいのか分からない。音源やコンポと違って、批評や評価がないからだ。特定の商品でそういった配慮をしたものはあるけど少数で、技術的なアドバンテージが明確な根拠をもって語られることが、あんまりない気がする。説明があっても、素人にしたら煙に巻かれる様だ。

一方、どのような環境、状況で使うかによって音質は変わるので、素人による製品や手法の評価はままならない。
以前はどんなドライブがいいとかあったが、最近はあんまり見なくなった。いいのがないという話もみたことがあったが、それすら最近はない。

結果、入手した製品を手探りで可能な限り上手く使うしかないのではないか、と言わざるを得なくなる。
その一方で、ストレージのジッターに配慮しない者が多数な世間では、良質な媒体や製品を提供しようとする者への、黙殺ならいいほうで、中傷や批判が主流派として罷り通る。

デジタルコピーしても音質劣化しないようにする、あるいは悪影響を最小限にする方法を、知ることができない。
それは、そういう方法が求められていないから、ということでもある。
もしかしたら、今までの経緯、数十年のデジタルオーディオの変遷の中で、諦められたからかもしれない。

技術的に一般化することが困難なのであれば、ユーザーが戸惑い立ち止まっても、仕方がない面がある。
それは、まじないとかオカルトと言われても反論できないということだ。でも、そうなのかね？

現実にHDDが違えば音が違うが、そうはいっても、実装の仕方でも環境要因でも評価は変わるだろう。簡単にどの製品がいいとも、言いにくいんじゃないかと思う。
そういう意味で、個別の製品は、批評や評価の対象になりにくいと想像する。

だったら、ユーザーが入手できる雑多な製品をユーザーなりに可能な限り上手く使えるようにする、そういう手法やノウハウを、どこかで誰かが提示すべきじゃないだろうか。それも、技術的な根拠を十分に添えて。
できないのかな。それに、誰がするのよ。

でも、そういう状況が生まれてきたら、たぶん、ストレージ使用の悩ましさとか、デジタルオーディオのよく分からなさも、薄れるんじゃないかと思うのだ。
配慮された高価な製品がある一方で、コンシューマー向きで安価な製品を使いこなすノウハウもある。
そういう状況はアナログオーディオでは一般的だ。
デジタルオーディオは、オカルティックな空気の中で、技術とユーザーが分断されている（そうした状況が、いかがわしいYoutuberが再生回数を稼いだりする温床になっている気がする）。

あんまり良くないと思うのだ。
いかがなものだろう。
今に始まったことではないし、難しいんだろうがなあ。

話は変わるけど、そんな面倒なノウハウを考える必要が少ないフォーマットとして、MQAが生まれたと僕は思う。
そういう意味で、技術を潰すのは惜しいと思っている。

最近、オーディオサーバーのノイズ対策に、筐体内に銅メッシュを仕込むというのを試みている。

まずPPAP Back-End、Middle-Endときて、Daphileサーバー2台に仕込んだ。
次に、mpdサーバーに仕込む。
mpdサーバーはPPAP Frontであり、UPnPレンダラーでもある。うちではそういう構成で運用している。

まず、テスト用mpdサーバー。
機種は、Hp Elitebook 820 G2。中古のノートPCだ。OSはTiny Core 64 11.1。
仕込み中の写真は撮り忘れた。
銅メッシュはキーボードの裏側に置ければ良かったんだけど、分解の手間が多い。本体の底面側を開けるのは簡単なので、そこに絶縁用の藁半紙と一緒に設置した。GNDはファンの縁の地金に銅メッシュを押し付けて取ることに。
気になるのは、銅メッシュの設置位置が筐体の空気吸入孔に重なるので、冷却機能に影響しないかということ。あまり温度が上がるようなら、設置場所を再検討しないといけない。

前回エントリーと同様の方法で、温度を確認した。
3秒ごとの数値を5分間計測しtxtファイルに打ち出し、それを集計し電卓等を使って平均値を出す。

tc@box:~$ watch -t -n 3 cat /sys/class/thermal/thermal_zone0/temp > temp.txt
[ab@fedora1 Documents]$ awk '{sum+=$1}END{print sum}' temp.txt

44438 (min:44000 max:45000)

音を出していないときの温度は、若干、上がった。風通しが悪いからか、、、

次に、音楽を鳴らしてどうなるか確認した。
ちなみに前エントリー以降、温度計測に際して音源に使っているのは下記CD box、1枚目CDのリッピングflacファイル。NAS音源だ。
Quator Danel - Shostakovich - The Complete String Quartets
https://www.discogs.com/release/8599892

Fastest、192kHz
47926 (min:47000 max:50000)

Fastest、768kHz
51383 (min:48000 max:58000)

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

Best、192kHz
56093 (min:53000 max:62000)

銅メッシュをつける前と比べたら、若干温度は下がっているのかな。どうだろう。

音質はどうなのか。
Medium、768kHzで鳴らす。
ぐっと、良くなった、気がする。何より色合いが濃くなって力強くなった。以前のテスト系 Medium 768kHzは、メイン系のBest 384kHzと比べたら、良く言えばスマートでモニター的だが線が細い印象だったんだけど、厚みが出てきた。

NAS音源でメイン系と比較してみる。libsamplerateの設定が違うので、音は違う。しかし差異はかなり小さくなった気がする。ブラインドでの聞き分けは、僕には出来ないだろう。

ストリーミング音源はどうだろうか。上述した音源は、Deezerにもある。
以前より、ずっと良くなっていると感じる。
NAS音源との比較では、差はある。比較したらNASの方がキレが良くて生命力が強いのだ。若干、情報量も多いような気がする。しかし、以前よりも差は減った。ブラインドで当てるのは、かなり聞き慣れた音源でないと難しそうだ。

テスト系とメイン系で、ストリーミング音源再生を比較してみる。
設定が違うので音も若干違うが、NAS音源のときと同様、音色の濃さがほぼ同等になった。
テスト系の音は、以前はクールで淡白な感触だった。それが銅メッシュを組み込んでからは、熱を帯びて鳴るようになっている。音色がメイン系に近付いて、色合いが濃くなったような感じだ。同時に、余音のような、音と音の間を埋めるような音が、より明瞭にリアルになった感触がある。
なんというか、これだけ聴いていたら、ストリーミングだけで何が不満なのか、という感じに鳴っている。

ここでテスト系とメイン系、mpdの設定を同じにして比較してみる。
メイン系をテスト系に合わせて、Medium 768kHzに。これはテスト系サーバーにとっては相当重く、メイン系サーバーにとっては比較的軽い操作だ。
音源はストリーミング。
温度だけ見たら、テスト系は20℃近く、メイン系は15℃弱ぐらい上がるようだ。
音は、メイン系の方に余裕があるようで僅かに反応が早い。ブラインドでは分からないんじゃないかな。
以前は、ここまで僅差ではなかった。それでも、この微妙な差は、もしかしたら重要な感じで、響きの美しさはメイン系の方が僅かに良いのかな。

ストリーミング音源使用時の温度。
前述のCDリッピング音源と同じ作品の、Deezer音源を使用した。下記が結果。

Fastest、192kHz
49952 (min:49000 max:51000)
Fastest、768kHz
53644 (min:51000 max:61000)
Medium、768kHz
60738 (min:53000 max:68000)
Best、192kHz
57295 (min:52000 max:63000)

やはり、温度は上がっている。UPnPの負担が増えているので当然か。
そういえば、銅メッシュなしのとき、ストリーミングでどうだったか、記録してないな、、、
銅メッシュを外して、ストリーミングで鳴らしてみた。結果は下記。

Fastest、192kHz
47786 (min:47000 max:49000)
Fastest、768kHz
53748 (min:51000 max:62000)
Medium、768kHz
60738 (min:53000 max:69000)
Best、192kHz
58291 (min:54000 max:64000)

温度はメッシュを付けているときよりも低いときがある。前回エントリーで挙げた、NAS音源を鳴らしていたときよりも低いときもある。銅メッシュで温度が下がるというのが、怪しくなってきた。筐体の蓋を開閉した直後に測ったせいかもしれないが、関係ないかもしれない。本当はもっと繰り返しデータを取るべきなんだろうが、そこまで取り組む根気はない。

銅メッシュを外すと、音は良くも悪くもクールになる。奥行、深みは少ないが、これはこれで、そんなに悪くはない。すっきりしていて涼しくて淡麗だ。しかし比較し評価するなら、メッシュがあるほうがいい。
温度を表にしておく。

	無音	Fastest、192kHz	Fastest、768kHz	Medium、768kHz	Best、192kHz
NAS	44000	47267	53019	59670	58452
Deezer		47786	53748	60738	58291
NAS (Cu+)	44438	47926	51383	57876	56093
Deezer (Cu+)		49952	53644	60738	57295

さて、次はメイン系mpdサーバーの処理だ。

他のサーバーに比べたら新しい。
機種は、Hp Probook 450 G9。OSはTiny Core 64 14.0。
作業に入る前に、銅メッシュなしの状態で温度のデータを取る。
mpdの設定は、Best、384kHzで固定。そのかわり、音を出してるときのデータは、4回取る。

音を出していないとき
47000 (min:47000 max:47000)

NAS音源
70896 (min:69000 max:73000)
71262 (min:64000 max:75000)
71705 (min:65000 max:75000)
71514 (min:70000 max:74000)

ストリーミング音源
71442 (min:66000 max:75000)
71252 (min:68000 max:74000)
71292 (min:69000 max:74000)
71609 (min:68000 max:74000)

以上、時系列。
NAS音源を鳴らし始めて3分後からデータをとり始めたけど、ちょっと早いのかもしれない。10分ぐらい待った方がよさそうだ（テスト系のときは数10分後から測り始めている）。

意外だったのは、テスト系ではストリーミング音源で温度が上がる傾向があったのに、メイン系では上がらないことだ。NASとストリーミングの音質の差と温度の差に相関関係がありそうだと思っていたのだけど。

いや、考えてみたら上流のデジタルデータを受け付けているmpdサーバーで、データが同じなのに（まあ、調べたわけじゃないけど、同じだと思うんだよね、、）、上流のサーバーが違ったら発熱量が違うほうが、本当はいけないのだ。
でもそこは、ジッターの差によって、負荷が違うのだろうと想像していた。
メイン系は新しい機種で性能も上で、処理能力が大きいので温度差が出ないのだろうか。

テスト系の音を聴き直してみる。設定は、Medium、384kHz。
たしかにNASとストリーミングでは音質に差があり、聴き比べたら、テスト系よりもメイン系の方が音質差は少ない。しかし少ないながらも、音質の差はあるのだ。CPUの温度には現れないレベルということなのだろうか。
そして、驚いたこと。
テスト系より、メイン系の方が、音が乾いて聴こえるのだ。テスト系の方が生々しい気がする。

テスト系を768kHzで鳴らしてみる。音の雰囲気が変わり、こうなると、メイン系との比較が出来なくなった。

メイン系に銅メッシュを仕込む。
筐体の底板を開けるのは比較的簡単。銅メッシュを仕込む隙間もある。
しかし、簡単にGNDがとれない。丸形端子をネジ止めできたらいいんだけど、意外に適当な使えるネジがない。銅メッシュにケーブルを半田付けし、その先の丸形端子を筐体の地金にテープで貼ることにした。
こんな感じ。

電源を入れ、しばし放置して温度を測る。

音を出していないとき
46000 (min:46000 max:46000)

NAS音源
70991 (min:69000 max:74000)
71154 (min:64000 max:74000)
72029 (min:70000 max:75000)
71775 (min:64000 max:74000)

ストリーミング音源
71775 (min:62000 max:75000)
70706 (min:56000 max:74000)
72010 (min:64000 max:75000)
72282 (min:71000 max:74000)

銅メッシュを設置する前より、温度はむしろ、上がっているかな。
音質はどうなのかというと、あんまりぱっとしない。良い方に変化した感じはしない。しかし、それより問題があって、なんだかサーバー自体が安定しない感じがするということだ。Daphileからのコントロールが不安定な感じ。
なにしろ、上手く行っていない。

温度が上がるのは良くない。
銅メッシュのサイズが大きすぎて冷却が上手くいっていないのかもしれないと考えて、メッシュの量を半分にして、やや小ぶりに、薄くした。細い針金を編んでいるので、切れ端から銅線がこぼれないように注意が必要だ（コンピューターに入れるので、切れ端が変なところに紛れ込んではまずいと思う）。

音はむしろ、そのほうが良いようだ。
硬い感じがとれて色彩感も出てきた。

温度を再計測。

音を出していないとき
47000 (min:47000 max:47000)

NAS音源
72375 (min:70000 max:75000)
71825 (min:67000 max:75000)
71571 (min:70000 max:74000)
71867 (min:64000 max:75000)

ストリーミング音源
71896 (min:69000 max:76000)
71328 (min:64000 max:74000)
72049 (min:69000 max:75000)
71961 (min:66000 max:75000)

温度は、あんまり、変わらない。
音はというと、それでも、どうにもすぐれない。
いくつか音源を聴くうちに、濁りがあるように感じられてきた。ベールのように霞みが掛かっている。そのせいか、見え方が違ってくる。遠くまでとどかないのだ。
副作用の方が強い。
銅メッシュを外す。
見通しの良い、以前の音が戻ってきた。

しかし、こうなってくると、テスト系の音も慎重に評価しないといけない。
何らかの歪みが、逆に心地良く聴こえているのかもしれない。GNDにものをつなぐときには注意が必要だ。しばしば反応は鋭敏でいいことばかりではない。
それにしても、2台の違いはどこから生じているのだろう。

ともあれ、しばらく、様子を見ていく。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

うまくいかない。
音が出るまで時間が掛かり、音が出始めた後のコントロール、音量の調整や再生停止などの操作にすごく時間がかかる。数十秒もかかる。768kHzのデータの方が重そうなのに何でなのか、考えるうちに、もしかしたら、バッファーの設定が影響しているのではと思い付いた。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

44000

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

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

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

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

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

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

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