Jun 28, 2022
earfluff and eyecandy によるJitterの解説 その３
前回、前々回に引き続き、earfluff and eyecandy によるJitterの解説について読んでいる。
今回が最後だ。
Jitter – earfluff and eyecandy
http://www.tonmeister.ca/wordpress/category/jitter/
今回はPart 6から。
Jitter: Part 6 – What is Affected?
Jitter: Part 6 – What is Affected?
http://www.tonmeister.ca/wordpress/2018/08/10/jitter-part-6-what-is-affected/So far, we’ve looked at what jitter is, and two ways of classifying it (The first way was by looking at whether it’s phase or amplitude jitter. The second way was to find out whether it is random or deterministic.) In this posting, we’ll talk about a different way of classifying jitter and wander – by the system that it’s affecting. Knowing this helps us in diagnosing where the jitter occurs in a system, since different systems exhibit different behaviours as a result of jitter.
これまで、ジッターとは何か、およびそれを分類する2つの方法を見てきました（最初の方法は、位相ジッターか振幅ジッターかを調べることでした。2番目の方法は、ランダムか決定論かを調べることでした）。この投稿では、影響を受けているシステムによって、ジッターとワンダーを分類する別の方法について説明します。これを知ることは、システムのどこでジッターが発生するかを診断するのに役立ちます。これは、システムが異なれば、ジッターの結果として異なる動作を示すためです。
We can put two major headings on the systems affected by jitter in your system:
data jitter
sampling jitterIf you have data jitter, then the timing errors in the carrier signal caused by the modulator cause the receiver device to make errors when it detects whether the carrier is a “high” or a “low” voltage.
If you have sampling jitter, then you’re measuring or playing the audio signal’s instantaneous level at the wrong time.
These two types of jitter will have different effects if they occur – so let’s look at them in the next two separate postings to keep things neat and tidy.システム内のジッターの影響を受けているシステムには、次の2つの主な見出しを付けることができます。
データジッター
サンプリングジッターデータジッターがある場合、変調の原因によって引き起こされるキャリア信号のタイミングエラーにより、キャリア信号が「高」または「低」のどちらの電圧であるかを受信デバイスで検出したときに、エラーが発生します。
サンプリングジッターがある場合は、瞬間的なオーディオ信号レベルを、間違った時間のタイミングで測定したり再生している状態になります。
これらの2つのタイプのジッターは、発生した場合に異なる影響を及ぼします。したがって、次の2つの別々の投稿でそれらを見て、物事をきちんと整理してください。
Part 6は短いので、全文引用した。
しかし、googleまかせではちょっと問題かと思ったので、僕が手を入れることにした。どうだろうね。
Jitter: Part 7 – Data Jitter
Jitter: Part 7 – Data Jitter
http://www.tonmeister.ca/wordpress/2018/08/10/jitter-part-7-data-jitter/
ここは、正直良く分からない、、、
Part 6で書いてあったことは、『データジッターがある場合、変調の原因によって引き起こされるキャリア信号のタイミングエラーにより、キャリア信号が「高」または「低」のどちらの電圧であるかを受信デバイスで検出したときに、エラーが発生します。』とのこと。
要はキャリア信号自体に乗っかる形で影響するジッターという理解でいいのだろうか。
Part 7では「Peak-to-Peak error」、「RMS error」という言葉が出てくる。
これらの用語は、デジタルオーディオの本などでクロックジッター、周期ジッター（Period Jitter）というジッターの説明に出てくるようなんだけど（前に書いたけど、Periodic Jitterとperiod Jitterは、別の概念のような？）、それが、ここに出てきている。
データジッターという言葉は、そもそもグーグル検索で殆んど引っかかって来ない。data jitterなら多少はあるのだけど。なんだか、いろいろ謎である。
説明で「ランダムジッター」を想定している。
説明内容にあるような、ランダムジッターが多すぎたら読み取りエラーを生じるようになるのは、理解できる。
しかしデータジッターは、ランダムジッターだけなんだろうか。
ちょっと、そこの辺りがよく分からない。
もっといろんな作用が起こってると考えないと説明しにくいことがあるような気がする。
あと、ジッターでデータエラーを生じるような悪劣な環境でオーディオをやっているという想定は、かなり限定された状況のような気がする。
データエラーまで生じなくても、データジッターは音に影響するはずなのだ。
そこに触れてないようなのが、よく分からないところ。
技術的に説明しにくいのだろうか。まあ、僕が見当違いを言ってる可能性もある。
Jitter: Part 8.1 – Sampling Jitter - Jitter in the Analogue to Digital conversion
Jitter: Part 8.1 – Sampling Jitter
http://www.tonmeister.ca/wordpress/2018/08/28/jitter-part-8-1-sampling-jitter/
ここでは、AD変換について説明している。
個人的には過去に見たことがあるような内容が多いし、あんまり注意して読まなくてもいいかなと思ったら、そうでもないような。
エントリーの下の方に、ジッタの量が一定に保たれている場合に、振幅エラーの量は信号の傾きに応じて変調する、というのを「図6」に示している。「赤い曲線は、サンプルごとの誤差（ジッター信号から元の信号を差し引いたもの）を拡大してプロットしたもの」との、説明がある。
Secondly, if the amount of jitter is kept constant, then the amount of amplitude error will modulate (or vary) with the slope of the signal. This is illustrated in Figure 6, below.
Fig 6. The blue curve is a sine wave to which I have applied excessive amounts of jitter with a Gaussian distribution. The red curve is the sample-by-sample error (the original signal subtracted from the jittered signal) plotted on a magnified scale. As can be seen, the level of the instantaneous error is proportional to the slope of the signal. So, the end result is that the noise generated by the jitter is modulated by the signal. (If you look carefully at the blue curve, you can see the result of the jitter – it’s vertically narrower when the slope is low – at the tops and bottoms of the curve.)
AD変換で、これがデジタル音楽データに乗ったらおおごとだと思うんだけど。
これと同等のことが、DA変換でも起こり得ることじゃないのかと思う。
つまり「図6」の赤い線（線というより塗りつぶされてるが）は、ジッターがアナログ再生音を濁らせる、その様子が可視化されているのではないかと。
ADで起きることなら、DAで起きても不思議はないと思うのだけど、見当違いかもしれないが。
Jitter – Part 8.2 – Sampling Jitter - Jitter in the Digital to Analogue conversion
Jitter – Part 8.2 – Sampling Jitter
http://www.tonmeister.ca/wordpress/2018/08/30/jitter-part-8-2-sampling-jitter/
part 8.2では、DA変換について説明している。
オーディオ再生だったらこっちがメインだと思ったら、たぶん8.1で説明した内容と多くが被るのだろう、ごく簡単にすませている。
まあ、ジッターの説明でよく見る絵が描いてある。
文末に「I’ve completely omitted the effects of the anti-aliasing filter and the reconstruction filter – just to keep things simple.（単純化するために、アンチエイリアシングフィルターと再構成フィルターの効果を完全に省略しました。）」とある。
Jitter – Part 8.3 – Sampling Rate Conversion
Jitter – Part 8.3 – Sampling Rate Conversion
http://www.tonmeister.ca/wordpress/2018/08/30/jitter-part-8-3-sampling-rate-conversion/
ここではサンプリングレート変換について書いてある。
しかし、そんなに多くは書かれていない。
Synchronous Sampling Rate Conversion（同期サンプリングレート変換）とAsynchronous Sampling Rate Conversion（非同期サンプリングレート変換）についての説明がある。
うちで行っているのは、非同期のほうだ。
The good news is that, if the clock that is used for ASRC’s output sampling rate is very accurate and stable, and if the filtering that is applied to the incoming signal is well-done, then an ASRC can behave very, very well – and there are lots of examples of this. (Sadly, there are many more examples where an ASRC is implemented poorly. This is why many people think that sampling rate converters are bad – because most sampling rate converters are bad.) in fact, a correctly-made sampling rate converter can be used to reduce jitter in a system (so you would even want to use it in cases where the incoming sampling rate and outgoing sampling rates are the same). This is why some DAC’s include an ASRC at the input – to reduce jitter originating at the signal source.
(trranlated by google)
幸いなことに、ASRCの出力サンプリングレートに使用されるクロックが非常に正確で安定していて、着信信号に適用されるフィルタリングが適切に行われている場合、ASRCは非常に適切に動作できます。この例はたくさんあります。（残念ながら、ASRCの実装が不十分な例は他にもたくさんあります。これが、多くの人がサンプリングレートコンバーターが悪いと考える理由です。ほとんどのサンプリングレートコンバーターが悪いためです。）実際、正しく作成されたサンプリングレートコンバーターを使用できます。システムのジッターを減らすため（したがって、着信サンプリングレートと発信サンプリングレートが同じ場合にも使用する必要があります）。これが、一部のDACの入力にASRCが含まれている理由です。これは、信号ソースで発生するジッターを低減するためです。
サンプリングレート変換でジッターを減らせると、なんと、ここでお墨付きがもらえた！
うまく実装したらという条件付きだけど。
Jitter – Part 9 – When do I care?
Jitter – Part 9 – When do I care?
http://www.tonmeister.ca/wordpress/2018/08/30/jitter-part-9-when-do-i-care/In order to talk about WHEN we care about jitter, we have to separate jitter into the categories of Data Jitter and Sampling Jitter
ジッタを気にする場合について話すには、ジッタをデータジッタとサンプリングジッタのカテゴリに分類する必要があります。
このPart 9で最後だ。
データジッターに関しては、機械と接続ケーブルをちゃんと使えと書いてある（うーむ、、、）。
サンプリングジッターのほうのまとめも、大したことは書いてないかな。
Can you hear jitter?
The simple answer to this these days is “probably not”. The reason I say this is that, in modern equipment, jitter is very unlikely to be the weakest link in the chain. Heading this list of likely suspects (roughly in the order that I worry about them) are things like
- aliasing artefacts caused by low-quality sampling rate conversion in the signal flow (note that this has nothing to do with jitter)
- amateurish errors coming out the recording studio (like clipped signals, grossly excessive over-compression, and autotuners) (and don’t get me wrong – any of these things can be used intentionally and artistically… I’m talking about artefacts caused by unintentional errors.)
- playback room acoustics, loudspeaker configuration and listener position
- artefacts caused by the use of psychoacoustic CODEC’s used to squeeze too much information through too small a pipe (although bitrates are coming up in some cases…)
- Dynamic range compression used in the playback software or hardware, trying to make everything sound the same (loudness)
- low-quality loudspeakers or headphones (I’m thinking mostly about distortion and temporal response here
- noise – noise from the gear, background noise in your listening room… you name it.
So, if none of these cause you any concern whatsoever, then you can start worrying about jitter.
最近は、昔ながらの「デジタルっぽい」音源は、ほとんど全く無くなった。
それどころか、昔のCDでも最近の機械で鳴らすと、デジタルっぽくない音がすることも多い。
録音も再生機器も良くなったということだろう。
しかし明瞭に聞こえなくても、ジッターが再生音に影響しているのは確かだと思う。
今でもちょっとしたことで、デジタル音源の音が変わるのだから。
今回、ジッターというのはいろんな切り口があるのだというのを改めて確認した。
それにしても、複雑で意味不明で分かりにくい。その一方で疑問が解けたこともあったので、読んでよかったと思う。引き続き、マイペースではあるけど、勉強していこう。
しかし、疲れた、、、今回はここまで。
Jun 12, 2022
TAS Super LP List と TAS Super Download List
今回は音源の話。
というか、高音質音源リストについて。
海外に「the absolute sound」というオーディオサイトがある。
そこにオーディオファイル向けの高音質音源がリストされている。
The HP Super LP List
by Harry Pearson Nov 17th, 2014
https://www.theabsolutesound.com/articles/the-hp-super-lp-list2019 TAS Super LP List
BLOG by TAS Staff Jul 10th, 2019
https://www.theabsolutesound.com/articles/2019-tas-super-lp-list
Harry Pearsonという人がまとめた古い音源中心のアナログディスクのリストがあって、TASスタッフが引き継いだということらしいんだけど、2019年を最後に更新されなくなった。コロナの関係とかもあったのかもしれないが。
2020年以降は、こんな感じ。
2020 Top Ten Lists
BLOG by Jeff Wilson Dec 14th, 2020
https://www.theabsolutesound.com/articles/2020-top-ten-lists2021 TAS Tapeography
BLOG by Jonathan Valin Jan 17th, 2022
https://www.theabsolutesound.com/articles/2021-tas-tapeography
テープのリストって、すごいわね、、、
そして2022年は、こんな感じ。
TAS Super Download List : Classical
MUSIC by TAS Staff Mar 31st, 2022
https://www.theabsolutesound.com/articles/tas-super-download-list-classicalTAS Super Download List : Jazz
MUSIC by TAS Staff Apr 01st, 2022
https://www.theabsolutesound.com/articles/tas-super-download-list-jazzTAS Super Download List : Pop, Rock, and Folk
MUSIC by TAS Staff Apr 01st, 2022
https://www.theabsolutesound.com/articles/tas-super-download-list-pop-rock-and-folkThough HP once attempted to compile a list of recommended digital recordings (then only available on CDs and SACDs), he was unable to make consistent progress and eventually abandoned the effort.
Over the next few years, I will attempt to pick up where Harry left off.
For various reasons, I’m going to begin with media available via the Internet, starting with high-resolution downloads from HDtracks. In time, I will add streamed versions of these same titles (assuming they are recommendable, of course).（翻訳 by Google）
HPはかつて推奨されるデジタル録音のリストを編集しようとしましたが（当時はCDとSACDでのみ利用可能でした）、一貫した進歩を遂げることができず、最終的にその努力を断念しました。
今後数年間で、ハリーが中断したところから再開しようと思います。
さまざまな理由から、HDtracksからの高解像度のダウンロードから始めて、インターネット経由で利用できるメディアから始めます。そのうちに、これらの同じタイトルのストリーミングバージョンを追加します（もちろん、それらが推奨されると仮定します）。
ダウンロードやストリーミングのリストを作っていく計画とのこと。
最初は20個しかないが、TASのWebサイトで毎月1〜2回、新しいタイトルを追加していく意向らしい。
LPのリストは、どうやら2019年が最新版ということで、しばらくは更新されないかもしれない。実際のところ、難しそうな感じだし、割り切って別のリストを構築するというのは、いい考えではないかと思う。
それにしても、オーディオファイル向けの高音質音源のリストというのは難しい。
リストから漏れている音源がどうしても出てくるし、音が良くても楽しめない内容だったらちょっと辛い。
個人的に思うのは、音が「良くない」ソフトというのは少ない。
割合がどのくらいなのかといわれると困るけど、まあ、3分の2以上は、いいオーディオで鳴らしたほうが音が良くなるし、聴き応えもあるように思う。、、まあ、当たり前か。
何について言ってるのかが問題だね、、、クラシックが特にそんな感じかな、、、
JPopは、あんまり音が良くないのが多いとは思う。特にボーカル。お風呂で歌ってるように聞こえるのが多い印象がある。カラオケマイクを通したように聞こえるのだ。まあ、日本はカラオケの国だから仕方ないのかな。それがポップだということもあるし。それでも、ちゃんと録音してると思う音源も探せばそこそこあるような気がするのだけど。そういうわけで、僕にとってJPopで音質がいいというのは、ボーカルの音がいいというのとほぼ同義だったりする。その程度の聴き方しか出来てないということかもしれないが。
話が逸れた。
話が漠然としすぎていてまとまらない。
たいていの音源は、いい装置で鳴らせばいい音で鳴る。
そんな中で、特別に音質がいい音源を選りすぐってセレクトしないといけない。
当然だけど、再生装置、環境によって、音は変わる。
Harry Pearsonの再生環境で最高の音が鳴るディスクが、他の環境で素晴らしく鳴るとは限らない。
The HP Super LP Listの選から漏れた音源が、他の環境で、Harry Pearsonの装置で鳴らすThe HP Super LP Listの最高の音源以上の音で鳴ることが、絶対に無いとは言い切れない。そういう危うさが、高音質音源のリストには付き纏う。
完全に理想的とは言えないオーディオ機材、人の聴覚と感受性以上のセンサーが存在しない、そんな状況で最善を尽くす以外ないのだろう。
それでも「定番」としてのリストはニーズがあり、現実的に必要だと思う。
新しいリストが有用で充実したものになることを願う。
Ras Pi B+とpiCore13.1でPPAP Back Endを作ってみたけど
現在のpiCoreの状況がどうなってるのかと思って、確認したことを記録しておく。
なんで突然、piCoreなのかというと、ハードの違いで音が変わるということを思ううちに、そういえば以前はRaspberry Piで鳴らしていたっけと思い、そこから、今はどうなってるんだろうということになったということだ。
piCoreの最新は13になっている。
http://tinycorelinux.net/13.x/armv6/releases/RPi/
nmap.tczは、piCore9まで用意されていて、10はpiCore自体が欠番。11、12ではnmap.tczがリポジトリに用意されていなかった。
しかし現在、piCore13ではnmap.tczがリポジトリに用意されている。ということは、piCore9以前か13だったら簡単にPPAP Back Endを作れるということだ。
http://tinycorelinux.net/13.x/armv6/tcz/
ちなみに、mpd.tczが用意されているのはpiCore7まで。
libmpdclient.tczはpiCore9までだ。
一方、Tiny Coreはというと、Tiny Core x86（32bit版OS）のリポジトリにはmpd-minimal.tcz、libmpdclient.tczが昔から今までずっと用意されている。つまり、実は手軽にmpdを扱うにはこれが一番簡単だ。nmap.tczもあるが、mpd-minimalでpipeが使えるかは確認していない。
http://tinycorelinux.net/13.x/x86/
64bit OSであるx86_64のリポジトリには、mpdが無い。
ソースをダウンロードしてインストールする必要がある。
一方、alsaはというと、piCore11からversion 1.2.2になって、音源のサンプリング周波数が768kHzまで通るようになっている。
piCore9だと、alsaはversion 1.1.1。音源が198kHzまでで良ければ、piCore9以前のバージョンでよくて、300kHz以上なら11以降が必要ということになる。
参考：
Changelog between 1.1.9 and 1.2.1 releases / Alsa Project News
https://www.alsa-project.org/wiki/Changes_v1.1.9_v1.2.1
現在、うちでは768kHz/32bitでPPAP方式を使っていて、Back Endで使っているのはTiny Core Pure 64 v11.0。ハードはapu2だ。
piCore13ならば、768kHzが使えるPPAP Back Endに出来る筈、、、
しかし問題は、Raspberry PiはUSBとLANが同じチップで処理されているんだったかな。Ras Pi4とか、新しいハードだと改善されたらしい？けど、うちに残っているB+とか2とかだと、大量のデータを送るのは、うまくいかない可能性がある。というか、B+とか2とか非力なハードで、768kHz/32bitなんて重い音声データを扱えるんだろうか。
しかしRaspberry Pi とpiCoreでPPAP Back End、apu2と比較できるならしてみたいかな。
せっかくなので、まずはRaspberry Pi B+で試してみる。
以下、工程と設定のメモ。
download http://tinycorelinux.net/13.x/armv6/releases/RPi/piCore-13.1.0.zip cmdline.txt add host=pC131bp config.txt rewrite dtparam=audio=off login ssh tc@192.168.1.xxx sudo fdisk -u /dev/mmcblk0 p d 2 n p 2 (write number - /dev/mmcblk0p2 / start) +100M w filetool.sh -b sudo reboot login ssh tc@192.168.1.xxx sudo resize2fs /dev/mmcblk0p2 tce-load -wi nmap.tcz alsa-modules-5.10.77-piCore.tcz alsa.tcz alsa-utils.tcz vi /opt/bootlocal.sh /usr/local/bin/ncat -kl 4400 -e "/usr/local/bin/aplay -D hw:0,0 -M --period-size=4096 --buffer-size=16384 -t raw -f S32_LE -r768000 -c2" vi /opt/eth0.sh #!/bin/sh pkill udhcpc ifconfig eth0 192.168.10.10 netmask 255.255.255.0 broadcast 192.168.10.255 up route add default gw 192.168.10.1 # echo nameserver 192.168.10.1 > /etc/resolv.conf chmod +x /opt/eth0.sh sudo vi /opt/bootsync.sh /opt/eth0.sh & filetool.sh -b sudo reboot
工程終了。
PPAP Middle Endにつないで起動。
Middle Endからsshでログインして、下記コマンドにてUSB DACの認識を確認する。
cat /proc/asound/card0/stream0
音を出してみる。
音は出た。しかし、ノイズだらけで、音楽を聴くというわけにはいかなかった。
Ras Pi2ではどうなのか。
download http://tinycorelinux.net/13.x/armv7/releases/RPi/piCore-13.1.0.zip cmdline.txt add host=pC131b2 tce-load -wi nmap.tcz alsa-modules-5.10.77-piCore-v7.tcz alsa.tcz alsa-utils.tcz
上記以外の工程は同じ。
音は出た。やはりノイズだらけだが、音楽は聞き取れる。音程は正しいのに再生速度が遅い。これでは使えない。
PPAP Front Endでのアップサンプリングを止める。
Back Endの設定も合わせる。
/usr/local/bin/ncat -kl 4400 -e "/usr/local/bin/aplay -D hw:0,0 -M --period-size=64 --buffer-size=512 -t raw -f cd"
これでどうか。
まともな音が出る、けど、、、操作へのレスポンスが遅い。
こんなに遅かったっけ、そういえば遅かったかな、、と思うぐらい遅い。
普段、Daphileとmpdで768kHzにアップして聴いてるのと比べても、なんだか遅い気がする。普段使っているシステムは、再生開始の操作をして音が出るまで数秒かかるけど、ボリューム調整への反応は遅くない。それが、Ras Piだと両方とも遅く感じる。
apu2よりもRas Piのほうが遅いハードだからだろうか。
しかし、DaphileとpiCorePlayerの組み合わせだと、そんなに遅く感じない。
もしかしたらLMSやUPnPは、ユーザーがレスポンスが遅いと感じないように作られているのかもしれない。
あれこれ弄るうちに、Daphileシステムの方も不調になってきた。原因不明、、、全システムをリブート。
システム全体の不調が影響したせいかどうか分からないが、音質も敢えてRas Piで聴きたいと思わせるものがない。
今回はここらで撤退することにした。
残念だが致し方なし。
May 28, 2022
オーディオ状況報告（2022.05.28.）
半年前と比べて、若干システム上流を中心に変更がある。
聴こえ方も多少変わった。
最近のシステム構成は下図のような感じ。
前よりすっきりしてるかな。
一番大きな変更は、PPAPのMiddle EndとBack Endを直結したこと。
これは実は長年の懸案であり、今更感はあったのだけど、やってみたら改善効果は大きかった。
何故もっと早くしなかったのかというと、たぶん5、6年以上は前のことだが、最初に直結方式の説明をネット上で読んだときに、わけが分からない、手に負えそうにない、と思ったのが大きいかもしれない。
当時の僕はmpdを触り始めて間がなくて、Linuxにも今程には慣れていなかったので、後回しにした。
後回しになって、そのままになったのだ。
他の手法で音質改善は得られていたし、他にやることもあったので。
ネット上で直結による向上が大きいという話をたまたま読んで、そういえば、という感じで手を付けたということだ。
多少の苦手意識があっても、手を付けたらいいこともあるようだ。
上流の配置が変わり音が変わり、結果、ハブが減った。
NETGEARのGS105Eが1つ外れて1個になった。少ない方が良さそう。Planex FXG-05RPも外せるかなと思ったけど、こっちは外さない方が良かった。
そんなこんなで音質向上したということだけど、よりHi-Fiになったという意味合いだ。
これに伴って、2台のDACの聴こえ方に以前よりも差が出てきた。
ADI-2 DACのほうがよりHi-Fiでモニター的、Pegasus R2R DACのほうが絵画的。それが、より明瞭になってきた。
同時に、情報量の差が明瞭になってきた。ADI-2の方が僅かに情報量が多い。
アンプの方も差が出てきて、SM-SX100のほうがHi-Fi。
Brooklyn Ampのほうが情報量は僅かに少なく絵画的。
こうした両者の差が大きくなってきたので、Brooklyn Ampに可変抵抗アッテネーターが使えなくなった。
固定抵抗アッテネーターなら情報量や鮮度の低下が少ないので、まだ使える。使えるというのは、Brooklyn Ampの絵画的な音の美点を、アッテネーターがスポイルしないというような意味合いだ。
DAC2台とアンプ2台で4通りの組み合わせになる。
ADI-2とSX100が最もHi-Fiで情報量が多く、うちのリファレンスということになる。
Pegasusは高音域に美点があり、Brooklyn Ampはボーカル帯域に美点がある。
PegasusとSX100だとPegasusの美点が、ADI-2とBrooklyn AmpだとBrooklyn Ampの美点が表現された音になるようだ。
ところが、じゃあPegasusとBrooklyn Ampだと両者の美点が表現されるのかというと、さにあらず、なんだか曇ったような冴えない音になってしまう。両取りとはいかないようだ。この組み合わせで良く聴こえる音源も探せばある可能性がと思うのだけど、どうなのかな。
M500が此処まで蚊帳の外だ。最近は使うことが少なくなった。
しかし将来的にMQAストリーミングの再生に使えないかと思っている。
Daphileサーバーが２つに増えているが、片方、6730bのほうをテスト運用とYoutube音声などの再生などに使っている。ここからpiCorePlayerに出力しM500に繋いでいる。
piCorePlayerを使った再生は、うちのシステムで唯一、mpdを使わない再生ということになる。
そんなこんなで、この1か月でけっこう変わった。もう手を入れるところは無いかな、、、どうだろう。
コロナだ戦争だとうっとうしい世の中だ。
夏バテしないように気を付けよう。
May 22, 2022
Behringer MONITOR1の性能を確認する（5月24日、追記）
Brooklyn Ampに使っている「MONITOR1」の実力がどうなのか、ずっとどこかで気になっていた。
MONITOR1 ベリンガー公式
https://www.electori-br.jp/products/625.html
使い始めた当初は、これで充分だと判断した。5000円と安価な製品で、アンプの能力をスポイルしている可能性は否定できない。当時、それも込みで必要十分と判断したのだ。
しかし2年近く経って状況も変わった。
ひとつは、Brooklyn Ampのアップグレードサービスが日本でも受けられるようになったこと。
https://www.mytekdigital.jp/contact/brooklyn-amp-upgrade/
もうひとつは、上流の改善に伴って、相対的にスポイルの度合いが大きくなっているのではないか？という心配。
アッテネーターなので信号劣化が無いということはありえない。
実際にどの程度の影響があるのか、今まではそんなに気にせずに使ってきたけど、今後のためにも確認しておく必要がある。
アップグレードによる音の変化については、stereophileに分かりやすいレビューがある。
ちょっと引用する。
Mytek HiFi Brooklyn AMP+ power amplifier
https://www.stereophile.com/content/mytek-hifi-brooklyn-amp-power-amplifier"Sometimes, when people listen to the AMP+ version," Jurewicz continued, "they say that the older Brooklyn AMP had this nice midrange, which is essentially a grunge produced by distortions, but it seems to be acceptable in the older model.
The new model is cleaner, with a bigger soundstage and more detail.The AMP+ is more precise.
I would look to achieve that midrange sweetness of the earlier AMP through other means, using other components that are in that direction.（訳）
「時々、AMP+バージョンを聞いた人の中に、」Jurewicz氏は続けます。「古いBrooklyn AMPのミッドレンジが良かったと言う人がいて、これは本質的に歪みによって生成された汚れですが、古いモデルでは受け入れられるようなのです。
新しいモデルはよりクリーンで、サウンドステージがより大きく、より詳細になっています。AMP+はより正確です。
私なら、そうした傾向がある他のコンポーネントを使用するなど、他の方法で以前のAMPのミッドレンジの心地よさを実現したいと思います。」
なるほど、、、
うちで使っていて、ああ、そういう感じか、、と納得がいく話だ。
要するに、バージョンアップしたら良くも悪くもSM-SX100の音に近付くということらしい。
そしてそうなると、バージョンアップはどうしよう、ということになる。
もともと、Brooklyn AmpはSX100が壊れた時の代替と考えて購入した。
そういう意味では、音が同じでも問題はない。
しかし、なんというんだろうな、、おんなじ傾向のアンプが２台あってもなあ、、という気持ちがあって、バージョンアップに踏みきれないでいる。
まあ、2年前と違ってSX100が修理不能になったときはなったときだという気持ちになっているし（どうやら代替アンプは簡単に見つかりそうなご時世だから）、極端な話、そのときBrooklyn Amp+を買ったっていいのだ。そのときバージョンアップできるならしても良い。ひょっとしたらSX100を越えるかもしれない。
そうなったときに、MONITOR1のクオリティが問題になる。
今は、気が向いたときになんとなく使う感じなので、ゆるい音質で構わない。メインで使うとなったら、ボトルネックになるようでは困る。まあ、そのとき考えればいいっちゃいいんだけど、気になる。
上流の改善は、PPAP Back Endの構成が変わったことによるものだ。Middle、Backへの分割、更に直結化（こっちのほうが大きいかな）によって、どのくらいかな、、アンプをグレードアップするぐらいの改善があった。
直結化したとき、そんなに変わらないな、、と最初は思った。しばらく聴いていて、どうも腑に落ちないと思ううちに、アンプがBrooklyn Ampであることに気が付く。なんとなくSX100で聴いてるような気になっていたのだ。
アンプを切り替えて、改めて改善していることを確認した。
つまり直結化による上流改善の度合いは、Brooklyn AmpからSX100に替えるのと同等だろう、ということだ。
そして、SX100の音の改善が、Brooklyn Ampの改善よりも、かなり大きい感じなのだ。
以前は、Brooklyn Ampは感覚的にSM-SX100の97～99%ぐらいと書いていた。これはブラインドで区別がつくかどうかぐらいで、その後もそれは変わらなかったのだけど、現在は、、90～95%ぐらい？、、多少幅があるけど。
たぶんブラインドで分かる。
そこまで差が付くのは、Brooklyn Ampにはアッテネーターを咬ませていることも影響しているのではないか。
そういうわけで、以下、試聴結果。
其々のアンプについて、MONITOR1使用の有無で音を比べる。
MONITOR1のボリュームは50で固定。普段使っている位置だ。聴感での音量を合わせるためmpd、SM-SX100のボリュームを調整した。
試聴に使った音源は下記。Deezer HiFiのストリーミングを使用した。
Whispering Forest : Walter Tilgner
まず、SM-SX100。
ボリューム : mpd:75/100 SM-SX100:50/128
以前よりも音場、音像の見通しが良くなっている。
隙間が見通せるというのか重なり具合が分かり易くなった。以前の様相をバウムクーヘンとしたら、現在はミルフィーユという感じだ。間に挟まっているのが何なのか見える感じ。それらの質感も違う。より微細なニュアンスが表現されている。
こんなこというとあれなんだが、何か次元が違う感じに良くなった気がする。
ボリューム : mpd:75/100 SM-SX100:90/128 MONITOR1:50/100
MONITOR1をDACとSX100の間に入れてみる。
音量を合わせるためSX100のボリュームを90に上げる。
音は、少しだけ霞んでいる。見通せるという感じが薄れている。
ブラインドでは聴き分けられない、かもしれない、かな？ 分かっていて比べたら明らかに違うんだけど。聴き慣れてたら、ブラインドでも分かる違いだと思う。
続いて、Brooklyn Amp。
ボリューム : mpd:85/100 Brooklyn Amp:x MONITOR1:50/100
MONITOR1のボリュームは50で固定。
Brooklyn Ampはボリュームがないのでmpdで音量を調整する必要がある。聴感で音量を合わせると、若干mpdのボリュームが上がった。
これだけ聴いていたら、悪くない。
しかしSX100と比べたら、良く言えばまったりしていて、見通しが良くない。マットすぎる感じ。
Brooklyn Ampの音も以前よりは改善している筈なのだけど、比較してしまうとそんな気がしなくなる。
ボリューム : mpd:50/100 Brooklyn Amp:x
MONITOR1を外すと音量が上がるので、mpdのボリュームを絞る。
音の曇りがなくなった。見通しが良い。
かなりSX100に近付く。しかしSX100で感じられるレベルの音場、定位の明瞭さには届かない。バウムクーヘンからミルフィーユへの途上という感じかな。
それでも直結化以前のSX100よりいいかもしれない。これは記憶との照合でかなり微妙なところだ。直結以前の設定に戻して比べるといいんだろうけど、そこまでするのは色々と面倒だ。
MONITOR1併用のSM-SX100と、同等ぐらいか、いや上回っている？ ケーブル抜き差ししながらの試聴で、これも微妙だ。
今回、試聴してみたら、Brooklyn AmpにMONITOR1を併用することで、SM-SX100との音質の差が開いてきている気がする。
いや、書き方がまずくて誤解を招きそうなので訂正。以前はMONITOR1併用で気にせず聴けたけど、上流の改善に伴ってSX100の音が大きく改善したので、ギャップが気になり始めたということだ。
今のところ運用上の問題になっていないので、当面は様子を見ながら使うつもりだ。
今更だけど、やはりアッテネーターは使わずに済むなら使わないに越したことはないと思った。
問題は、使わないとmpdのボリュームだけで音量調整することになるので、音源によってはmpdのボリュームを10まで下げるとか、そういうレベルの調整が必要になること。
さすがにそうなるとデジタル信号レベルでの劣化が心配、、、
音質を維持するには、より良質なアッテネーターかプリアンプが必要ということになるだろうか。しかしXLRでつなぐ必要があるので、製品から探すとしたら機種選択が厳しい。
なかなかどうにも悩ましいので、気長に考えようかと思う。
気長にとか言いながら24日、追記。
過去に固定抵抗のXLRアッテネーターを使っていたことを思い出した。
最近、こういうのが多いような気がする。
バランス接続に業務用アッテネーターを試す
http://blown-lei.net/endive/blosxom.cgi/audio_diary/20200718a.htm
過去エントリーではclassic proのアッテネーターを使っているが、その後、TOMOCA AT12を購入して使っていた。
https://www.soundhouse.co.jp/products/detail/item/79925/
TOMOCA ( トモカ ) AT12 | サウンドハウス
MONITOR1と違いがあるかどうか使って見た。
今回はDACではなく、Brooklyn AmpのXLR入力端子にアッテネーターを刺す。
アッテネーターにはゴムシートを巻いて、ゴム板の積層で作ったインシュレーターで下から支えて、振動対策を施す。
音は固定抵抗の方がいい。というか、この音質なら以前のように気兼ねなくBrooklyn Ampを使える。
しかし改めて聴くと、困ったことにMONITOR1を通した音もそんなに言うほど悪くないよなあ、という感じなのだ。そりゃあそうで、そういう感じだから以前はそこそこ使ってこれたのである。若干ベールが被るけど、何らかの対策をしたら案外音質向上するんじゃないのか？とか考え始めた、、、
まあ、でも、そこまで手を広げる余裕はないので、ひまが出来たらということになるだろう。
May 12, 2022
いわゆる直結を試みる
LANの直結を今まで試みていなかったのは、利便性が低下することと、色々やりかたを調べるのが面倒だったからだ、、、
しかし、やり残していることなのでやることにした。
さて、、、先立っての試験運用を何を使ってやるか。
LAN端子を2つ以上持っている機械は、うちにはapu2以外にない。メインシステムで試すしかないということだ。
トラブルがあっては面倒なので、apu2のSDカードをバックアップしておく必要があるかな、、、
普段からバックアップを取ってないのかといわれたら、どれがバックアップなのか分からなくなっているのだ。何をやってるのかまったく分からない。
そんなことを考えていたら、そういえば暫く前にBack EndのイメージをGoogleにアップしてたっけ、と思い出した。
あれを落としてきて試せばいいんじゃないの。
tc64-11-1-base1z-2020-04-05-PPAP-BE.img
https://drive.google.com/file/d/1kHhCtR4WCWs3_8i32JrVgGFin-YK9KIZ/view?usp=sharing
そういうわけで、ダウンロード。
カードに焼く。
物理的に遠くに離してあったMIddle EndをBack Endの近くに戻す。
まず状況。
( '>')
/) TC (\ Core is distributed with ABSOLUTELY NO WARRANTY.
(/-_--_-\) www.tinycorelinux.net
tc@box:~$ ifconfig
eth0 Link encap:Ethernet HWaddr 00:0D:B9:47:8A:40
inet addr:192.168.1.33 Bcast:192.168.1.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:42922414 errors:0 dropped:2894 overruns:0 frame:0
TX packets:43024988 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:62288871488 (58.0 GiB) TX bytes:62314222899 (58.0 GiB)
Memory:fe600000-fe61ffff
eth1 Link encap:Ethernet HWaddr 00:0D:B9:47:8A:41
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
Memory:fe700000-fe71ffff
eth2 Link encap:Ethernet HWaddr 00:0D:B9:47:8A:42
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
Memory:fe800000-fe81ffff
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
tc@box:~$
現在、IP固定の設定はしていない。DHCPサーバーからeth0にアドレスを取得している。
今回はeth1のIPを固定してみる。
ところで、どれが0でどれが2だったかいつも分からなくなるので写真を貼っておく。
シリアルケーブル端子に近い方が0である。
IP固定は昔、piCoreを使っていた頃はよく設定していた。
だけど、最近はしていないのですっかり忘れている。というか、Tiny CoreでのIP固定はしたことがない。
複数のイーサネットポートを扱うのも初めてだ。
どうなんだろ、piCoreみたく/optにeth1.shを作って置いといたらいいのかな、、、
Middle End の電源を落として、ケースの蓋を開ける。
SDカードを入れ替えて、起動する。
以下、sshでログインしてからの経過。
vi /opt/eth1.sh #!/bin/sh pkill udhcpc ifconfig eth1 192.168.10.2 netmask 255.255.255.0 broadcast 192.168.10.255 up route add default gw 192.168.10.1 # echo nameserver 192.168.10.1 > /etc/resolv.conf chmod +x /opt/eth1.sh sudo vi /opt/bootsync.sh #!/bin/sh # put other system startup commands here, the boot process will wait until they complete. # Use bootlocal.sh for system startup commands that can run in the background # and therefore not slow down the boot process. /usr/bin/sethostname box /opt/bootlocal.sh & /opt/eth1.sh & filetool.sh -b sudo reboot
viでeth1の設定ファイル「eth1.sh」を作成。IPを192.168.10.2で固定する。nameserverの記述は要らないのではないかと思ったのでコメント化した。
chmodで実行権限を与える。
bootsync.shファイルに「/opt/eth1.sh &」を書き加える。
filetool.sh -bで保存し、リブート。
リブート後、sshでログイン。
tc@box:~$ ifconfig
eth0 Link encap:Ethernet HWaddr 00:0D:B9:47:8A:40
inet addr:192.168.1.33 Bcast:192.168.1.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:562 errors:0 dropped:28 overruns:0 frame:0
TX packets:246 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:52631 (51.3 KiB) TX bytes:35785 (34.9 KiB)
Memory:fe600000-fe61ffff
eth1 Link encap:Ethernet HWaddr 00:0D:B9:47:8A:41
inet addr:192.168.10.2 Bcast:192.168.10.255 Mask:255.255.255.0
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
Memory:fe700000-fe71ffff
eth2 Link encap:Ethernet HWaddr 00:0D:B9:47:8A:42
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
Memory:fe800000-fe81ffff
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
tc@box:~$
eth1に「192.168.10.2」が振られている。
次はこれをMiddle Endにしていく。
過去エントリーを参考。
http://blown-lei.net/endive/blosxom.cgi/audio_diary/20210824a.htm
PPAP Back-Endをタンデム化
sudo vi /opt/bootlocal.sh /usr/local/bin/ncat -kl 4400 -e "/usr/local/bin/ncat 192.168.10.10 4400" filetool.sh -b sudo reboot
bootlocal.shファイルに上記のようにコマンド記載。Back EndのIPを「192.168.10.10」とする。
これで動くのかな、、、
合わせて、Back Endのほうも設定し直していくということになる。
Back Endのほうは、イメージを焼くのは飛ばしてsshにログインして設定した。
Middle Endでの試行でIP固定の設定ぐらいまでは出来そうな目星は付いたので。
（6月8日、下記の書き間違いを修正した）
vi /opt/eth1.sh #!/bin/sh pkill udhcpc ifconfig eth1 192.168.10.10 netmask 255.255.255.0 broadcast 192.168.10.255 up route add default gw 192.168.10.1 # echo nameserver 192.168.10.1 > /etc/resolv.conf chmod +x /opt/eth1.sh sudo vi /opt/bootsync.sh #!/bin/sh # put other system startup commands here, the boot process will wait until they complete. # Use bootlocal.sh for system startup commands that can run in the background # and therefore not slow down the boot process. /usr/bin/sethostname box /opt/bootlocal.sh & /opt/eth1.sh & filetool.sh -b sudo reboot
Middle Endと同じ手法で、eth1の設定を行っていく。
filetool.sh -bで保存し、リブート。
リブート後、sshでログイン。
tc@box:~$ ifconfig
eth0 Link encap:Ethernet HWaddr 00:0D:B9:50:86:58
inet addr:192.168.1.89 Bcast:192.168.1.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:44 errors:0 dropped:0 overruns:0 frame:0
TX packets:35 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:6283 (6.1 KiB) TX bytes:5919 (5.7 KiB)
Memory:fe600000-fe61ffff
eth1 Link encap:Ethernet HWaddr 00:0D:B9:50:86:59
inet addr:192.168.10.10 Bcast:192.168.10.255 Mask:255.255.255.0
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
Memory:fe700000-fe71ffff
eth2 Link encap:Ethernet HWaddr 00:0D:B9:50:86:5A
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
Memory:fe800000-fe81ffff
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
tc@box:~$
eth1に「192.168.10.10」が振られている。
さて、直結で機能するかどうか。
Back Endのeth0からLANケーブルを抜く。
MiddleとBackのeth1端子をLANケーブルでつなぎ、Midlle EndからsshでBack Endにログインしてみる。
tc@box:~$ ssh tc@192.168.10.10 The authenticity of host '192.168.10.10 (192.168.10.10)' can't be established. ECDSA key fingerprint is SHA256:eICMkwr/u6JIomP1WNI9YocJTnDxmI8M7ICHoj/oeEY. Are you sure you want to continue connecting (yes/no/[fingerprint])? yes Warning: Permanently added '192.168.10.10' (ECDSA) to the list of known hosts. tc@192.168.10.10's password: ( '>') /) TC (\ Core is distributed with ABSOLUTELY NO WARRANTY. (/-_--_-\) www.tinycorelinux.net tc@box:~$
いけました、、、
次、ncmpcppからFrontのmpdに音楽再生の指示を出してみる、、、音は出ました！
はあ、、やってみたら簡単なものである。
もとのつなぎ方と直結、両者の違いを図にしてみた。
音質はどうか。
例えばベールが1枚はがれたようなとか、、薄皮1枚のベール？、、
前とあんまり変わらないような。
正直、違いが分からない、、、どうなんだろう。
まあ、耳が悪いということなのかもしれない、、、
まあ、でも、せっかく設定したのだし、暫くはこれで使っていこうと思う。
暫く使った後で戻したら、こんなに違うんだっけ！ということもあるかもしれないし。
早々だけど追記。
Back Endのeth0とeth2は止めた方がいいという話があって、今回は合わせて止めることにした。
参考にさせていただいたのはこちら。
不要なネットワークデバイスを黙らせる PCオーディオ実験室
http://flac.aki.gs/bony/?p=3681
/opt/bootlocal.shに下記追記した。
pkill udhcpc sudo ifconfig eth0 down pkill udhcpc sudo ifconfig eth2 down
これでeth1以外は寝付く。
更に早々に追記。
音は良くなっていると思う。
簡単に切り替えて比べるということは出来ないので記憶が頼りだけど。
音色の性格が、明瞭になったというか。音場の中で重層化されている様相が見えやすくなったというか、なにしろよい方向。前には戻れないと思う。
May 10, 2022
DVDドライブで聴くCDの音が良いような
うちではCDを聴くのにノートPCにUSB接続したDVDドライブを使っている。
ノートPCといってもTiny Core 64 / mpdをインストールしたPPAPフロントエンドだ。つまり音の出口はうちのメインシステム。
普段、CDはリッピングしてflacにしてNASに置いて鳴らしているんだけど、リッピングができていないときにDVDドライブを使って直接にCDから聴いている。
しかし使い始めた当初から、なんだかこれが音が良いような気がすると思っていた。
ブラインドで分かるとは思えないし、プラセボだろうと思っていたんだけど、その割には何時の間にかリッピング前にCDで聴いてみるということが増えてきた。単にリッピングが面倒だからという説明で納得していていいのか、、、そんなことを考えるようになった。
そういうわけで、ちょっと踏み込んで考えてみようという気持ちになったということだ。
差異があるのはPPAP Frontサーバーだ。
様相を表にしてみる。
mpdがどのように動いているのか、比較する。
| strage plugin | input plugin | decorder plugin | output plugin | |
|---|---|---|---|---|
| Daphile / UPnP | curl | curl | pcm | pipe |
| NAS / TCP IP | local | file | flac | pipe |
| CD Drive / USB | udisks | cdio_paranoia | pcm | pipe |
mpdの前段の処理が三者三様で異なっていることが分かる。
plugin以外の要素も加えて図にする。
UPnPを使うときはupmpdcliが同時に動いている。topでみたらVSZ %VSZが大きくて、仮想メモリを1.5GBぐらい確保しているようだ。何に使っているのか分からないけど。
DaphileにUPnPのサーバーとコントロールポイントを宛てているのは、Daphileのコントローラーであるウェブブラウザがコントロールポイントというのはどうもしっくりこなかったからだ。ウェブブラウザとDaphileがUPnPでつながっているわけではないと思うので。
スマホアプリのSqueezerとか使ってコントロールする場合はどうなのかな、あれもUPnPとは違うのではなかったかと思うのだけど。
NASから鳴らす場合はnfsが働いているんだけど、昔の経験ではNASのマウントはけっこう重い。甘っちょろいNASはマウントの負担で動かなくなることがある。
UPnPを使う場合よりは図面がすっきりしている。
USB DVD/CDドライブを使う場合は、cdio、dbusあたりが働くのではないかと思うんだけど、よく分からない。しかし何が動いてるにせよ、アドレスの処理とかの負担が少ない分、たぶんLANを通すより軽いのではないだろうか。
mpcは軽いクライアントで殆ど無視できると思うので、LANはPPAP Middle Endへの出力にほぼ専念できるのではないか。
これだけ違ったら、音の良し悪しの判断はともかく、音が違っていたとしてもおかしくないということかな。、、、
いや、音が違っておかしくないということはない。
なぜ違うんだろうというのは疑問として残る。
同じデジタル音源で同じ再生機器であっても、OSで音が違う、再生ソフトで音が違うというのは、しばしば聞く話だ。
しかしデジタル信号としては同じものだ。
（うちはmpdでアップサンプリングするので厳密にいつも同じなのかと問われたら同じ計算してるとしたら同じ結果になるんじゃないかなとしか答えられないんだけど、ビットパーフェクトで鳴らす場合にも実際にそういうことであるわけで）
同じ信号でも音が違うというのは、アナログレコードだったら当たり前のことだと思ってしまう。
しかし、アナログ的に厳密に同じ環境にして鳴らした場合、音の聴き分けは難しいのではないだろうか。
デジタルのCDは、最初は同じCDは同じ音がすると言われた。
アナログはちょっとしたことで変わるけどデジタル信号は01で変わらないからと。
現実、そうは聞こえないと言ったら、機械が悪いとか聞く者の耳が悪いとか言われたものだ。
実際のところ、撲なんかは今でも、同じデジタル信号で同じ音がしないことに、どこか納得できない気分を抱えている。これは何なのか。若い頃に、デジタルは同じ音がしないはずが無いということを叩き込まれたせいなのか？
なんというかな、、、
あれだけ「同じ音だ」と言っていた人達は、今は何処で何をしているのか。
理屈は分からないけど同じ音がするはずがないんだよ、だってデジタル信号といったって電気っていうのはアナログな存在だからね、などと言っても、僕は何だかそれでは気が済まない。
そう、実際にすっかり同じ音が出るようにした上で、「ほら、ここまでのことをしないとデジタルで同じ音は出ないんだよ。あなたたちが言ってたことってすごく底が浅くていい加減で視野狭窄で考えも研究も足りなかったってことが分かったかい？」というふうに言ってやりたいのだと思う。
まあ、無理なんだけど。
デジタルだから同じなんて言ってたけど、今思えば底が浅くていい加減で視野狭窄で考えも研究も足りなかったと思う、と言ってるオーディオ関係者を見たことが無いので、そんな気分になるのかな。
今の状況は「コンポが良くないから音が同じにならないのだ」で済んでしまう。
ソフトで音が変わるなんて、どこかおかしい機械をお使いなんですね、とか。
それって昔と同じじゃんね？
いったいなにをうだうだいってるのか。
要するに、アプリだプラグインだを通すうちに音が変わるのは現実としてあっても理屈が伴っていなくて気持ちが悪いと言いたいのだろう。
ジッターが違うんだろうだけではいまいち足りない気がする。
アプリの違いによって、どのようなジッターが生まれ、どのようにして音に影響するのか、それが説明されないと分からない。
ここらはアナログ的な何かだろう。
というかデジタルな問題ではない。
ソフトウェアが動くことでコンピューターの中でアナログ的な何かが生じているはずだ。瞬間的にではなく、音に影響するぐらい持続的に生じていて、それがソフトウェアによって異なり、デジタル音声データに乗っかって転送され、DA変換の何処かに影響する。
そう考えないと、現実に起きていることの説明がつかない。
だってデジタル信号としては同じなのだから。
僕が思い付くのは、プラグインの動作に周期的に継続して現れる01の並びがあって、これに伴う周期的な電圧変動がクロックを揺らし周期的なジッターとなる、これがデジタル信号に乗って伝送される、周期的な変動だから音に乗る、とか。
まあ、僕なんかが出来るのはこんなふうに取り留めなく妄想じみた思考をすることばかりで、現実には研究できる人にしっかりやってもらうしかないわけだけど。
なんか、今回は要するに愚痴みたいな感じになった。どうなってんだろう。おかしいなあ、、、
May 08, 2022
DaphileでMQAデータをpiCorePlayerに転送再生する
今回はちょっとした小ネタというか。
DaphileでMQAを再生できるかという話、なんだけど、Daphileサーバー本体からの出力（USBとか）は試していない。
LAN経由でpiCorePlayerに送ったらできましたよという話だ。
システムの構成図。
うちではDaphileにNASをマウントして使っている。NASにMQA CDからリッピングしたMQAファイルを置いている。
下図が再生時のDaphileの画面。
というか、ウェブブラウザでの操作画面のスクリーンショットだ。
左上に、マウントされたNASの共有音楽フォルダが、階層化されている状況を含めて表示されている。
その下にフォルダに含まれているflac-mqaのファイル表示。
右のプレイリストに登録された曲が表示されている、、、のだけど、曲名はリッピング時にタグを入れるときに僕がサボったので、ちゃんとしていない。ちゃんと入れたらちゃんとした表示になる。
piCorePlayerのUSB出力からM500に音声データが伝送されて、表示された様子。
MQA 352.8kHzと表示されている。MQAの音がする。
たぶんだけど、Daphileサーバー本体からUSB出力してもMQAを鳴らせるのではないかな。試してないから明言はできないけど。
Feb 08, 2022
Daphile 設定関係の覚え書き
Daphile – Digital Music Convenience for Audiophiles
https://daphile.com/
Daphileというのは非常によくできたディストリビューションだと思うのだけど、困るのは使い方が難しいことだ。
一見、感覚的に使えるように見えるのだけど、気付かないと使い方が分からないことが、ままある。Volumioより難しい。そして使い方のマニュアルがない。
https://daphile.com/download/FAQ.txt
FAQを読んでいて得心した。
Q5.
Hardware. Is Daphile compatible with ... DAC, wifi adapter, motherboard or any device?A5.
In general I can't answer these questions.
I have also decided that I will not collect and maintain any hardware compatibility information.
I don't want to take responsibility for possibly providing wrong information for anyone's purchase decisions.
割り切ったものである。
あれこれ説明がないのは、自己責任でも喰い付いてくるユーザーだけが使ってくれりゃあいい、ということなのだろう。
このFAQ.txtに書かれている内容は、興味深いと思うところもあるけど、実際の使用に関してはあんまり助けにならない。Daphileの使い方については、あちこちのサイトで書かれているので、ここで繰り返して書いても意味があまりないかも。だけど説明が面倒なことも多くて、書かれていないことも多いように思う。
そして、自分で過去にやったことを再インストールの際には忘れている、、、そういうわけで、覚え書きを作ることにした。
まず設定についてのメモ書きである。
思い付いたら適宜追記、修正していくつもり。なかなか読み易いものにできないから、気付いたときに直していく。
小さい修正の場合は、いちいち断りを入れないか、入れても時間が経ったら断り書きを消そうと思う。そのほうが読みやすいだろうからというのが単純な理由。
インストールに際しての注意
Daphileは、ダウンロードしたインストール用Daphileを使って、起動に使うメディア（HDD、USBメモリなど）にインストールして使う。
インストールについての基本的な手順は、下記アドレスのpdfに書いてある。
Daphile Installation
https://daphile.com/download/DaphileInstallation.pdf
動きさえすればどんなメディアにインストールしても構わないと思うけど（上記マニュアルによると最低2GB）、小さすぎるメディアは避けた方が良い。
というのは、使っていくうちにライブラリ（登録してある音源とか、お気に入りとか、プレイリストとか）が大きくなって来ると、運用上、メディアの容量が足りなくなるようなのだ。
そうなるとDaphileの挙動自体が危なっかしくなってくる。プラグインのアップデートや変更などの操作を受付けなくなる。そういう時には、再生音が途切れるようになったり、不具合も出てくるような印象がある。
うちでは2GBのUSBメモリにインストールして使おうとしたのだけど、あれこれやるうちにデータ収納スペースが足りないと表示され（スクショは撮り忘れた）動かなくなった。そこで4GBのを使っていたんだけど、再び挙動がおかしいので、32GBのに変更して様子をみていた。
ちなみに、うちではNAS音源をマウントして使っていたのだけど、うちのNASには8000枚以上のCDリッピングファイル音源が入っており、其々にcue sheetがある。音源データを読み込むとそこそこ結構なデータ量になる。
Daphileよりもmpdのほうがデータベースを作る速さはずっと速いのだけど、mpdはcue sheetの中に書かれたデータまでは、データベースに読み込まない。
しかしDaphileは、それも読み込んでいる。そのぶん、データベースとしてはずっと大きくなる。ハードのスペックにもよるだろうけど、数10分かかっていた。さらにストリーミングサービスのデータもこれに加わることになる。
しかしそれでも実際のところ、使っているUSBメモリの使用量は2GBより小さい。
だから、どうして容量が足りないと表示されたり不具合が出るのか、分からなかったのだけど。
最近はNASをマウントするのは止めてしまった。
というのは、やはり不具合が起きる心配と（実際に不調が多かったかというとそうでもないんだけど、気分の問題が大きいかな）、Daphileにマウントして鳴らすより、mpdサーバーにマウントしたのをmpdクライアントで操作して鳴らす方が、音が良いような、気がしたから。
うちではDaphileからmpdサーバーにデータを送って鳴らしているので、それよりはNASから直接にmpdサーバーに送る方が全体のデータ処理の負担が少ないのだろうと思う。ブラインドでは気付かないと思う。
次に気になるのは、マイクロSDカードとかで運用するのはリスクが高いかもしれないということだ。
基本的にシャットダウンする時はメディアへのデータ書き込みが行われるようで、使う音源の数が多いほど扱うライブラリのデータ量も増えて、シャットダウンに時間がかかっている。
うちでは基本、起動しっ放しなので大きな問題にはなりにくいけど、プラグインのアップデータの際には再起動が必要になり、ライブラリの再読み込みも行ったりしているようだ。
そういうわけで、書き込みの繰り返しに強いメディアを選ぶ方がいいだろうと思う。
使ってないときは電源を切るということなら尚のことだ。
インストール後の設定について
ウェブブラウザからDaphileにアクセスすると、操作画面が表示される。
左にボタンが並んでいて、上から4番目「Settings」をクリックしたら、設定画面が表示される。
うちで「Settings」で設定している項目について、ここでメモしていく。
操作画面で上から並んでいる順番に記載する。
ここに記載がない項目は、デフォルトのままで使っているか、記載する根気が無い項目ということだ。
前述した Daphile Installation のpdfファイルに、General、Audio Device、Storage の項目に付いては、基本的なことについての記載がある。
General
うちで設定しているのは「System name」と「Time zone」。
System nameはネットワーク上で使われる名前なので、好きに付けてやればいい。複数のDaphileを使う場合は違う名前にしておけば区別が付く。
Time zoneは「Japan」。
他はデフォルトのまま。
Audio Device
うちではBIOSで音声出力を止めてUPnPサーバーとして使っているので「No compatible audio devices」と表示されている。
USB DACなどつないだ場合は、ここに表示される筈。
Key Bindings、CD Ripping
うちでは触っていない。
リッピングマシンとして使うと便利という話を聞いたことがある。
Networking
うちではデフォルトのまま、Automatic (DHCP)にしている。DHCPサーバーからipアドレスが自動で割り振られる。
Power
ここではCPUやクロックの設定が出来る。CPU frequencyを若干高めに設定している（うちの機種の場合、2.2Ghz前後）。処理能力優先だ。
よく解らないというのもあって他はデフォルトのまま。
Storage
ここではストレージ音源の設定を行う。うちでは「Local drives」は無し。「Network drives」でNASの共有ディレクトリをマウントする。
NASのマウント方法については以下エントリーを参照。
http://blown-lei.net/endive/blosxom.cgi/audio_diary/20210413a.htm
DaphileにNASをマウントしてみる（cue sheetが使える！）
Backup
ここは触っていない。
Backupは、Daphileのローカルに音源を保存する場合にバックアップできるみたい？
設定のバックアップも出来るようだ
しかし、使ったことがないので、よくわからない。
System Firmware
Daphileのアップデートがあると、ここに表示される。
接続したメディアにDaphileの新規インストールができたりもするようだ。
Advanced Media Server Settings
ちょうど上の画像を見てもらったらいいけど、「Settings」の表示画面、最下部左側に、暗灰色に白抜き文字のボタンが２つある。
「Save & Restart」と「Advanced Media Server Settings」だ。
後者のボタンをクリックすると、更なる設定用画面が表示される。
横に並んだタブについて、左から順番に記載していく。
Player
DACなど音声出力先のボタンと、設定のボタン（Basic Settings）が表示される。
上の画像では、テスト用システムで運用しているpiCorePlayerが表示されているのだけど、複数の出力先があるようなら、左上のプレーヤー名が表示されているプルダウンボタンから選択して、他のプレーヤーの設定もできるようになっている。
Basic Settingと表示されているボタンからプルダウンで、更に細かな設定を選べるのだけど、設定項目は非常に多い。
とても手が回ってないのだけど、「Alarm Clock」をOFFに。
他はデフォルトのままで使っている。
My Music
ここはデフォルトのままで弄っていない。
mysqueezebox.com
Daphileには多くのプラグインが用意されているのだけど、それらの3分の1がLogitechから提供されている。
うちではDeezerを聴くためにDaphileを導入したのだけど、DeezerプラグインもLogitechから提供されていて、使うには下記アドレスのサイト「Logitech Squeezebox」でアカウントを作る必要がある。
https://www.mysqueezebox.com/index/Home
Logitech Squeezeboxにアクセスして、簡単にユーザー登録、アカウントを作ることができる。
そのアカウント情報（メールアドレスとパスワード）を、ここで入力、保存する。
詳細については後述。
Deezerプラグインの使い方についての項に記載する。
Interface
ここではDaphileの表示を設定。「Show Artist with Albums」「Show Year with Albums」を「Enabled」にしている。
アルバム一覧を表示したときにアーティスト名などが表示されるということだが、ストレージで設定された音源（つまり自宅ローカルの音源）では機能するけど、ストリーミング音源の表示には適用されない。
その他、一度に表示される音源数とか、サムネイルサイズとか、設定できる。
Plugins
さて、Daphileでは多数のプラグインが動作している。
ここではリストが表示され、上から「Active plugins」、「Inactive plugins」、「3rd party plagins」と、ずらりとプラグインが並んでいる。
デフォルトで要らないものは外したいし、追加したいプラグインもある。
「Active plugins」にリストされているのが、有効化されているプラグインだ。
うちでデフォルトから外したのは、ネットラジオ関係をいくつか。プレイリストの曲が終わったら何か他の曲を鳴らしてくれるプラグインとか、アマゾンのCDストアにつながるプラグインとか、TIDALのプラグインなどだ。「Active plugins」のリストから外したいプラグインを選んでチェックボックスのチェックを外して、表示右下の「Apply」、「close」。
プラグインによっては、DaphileのOS再起動が必要になる。必要ないものもあるようだ。使いながら個別で確認していくしかないかと思う。
追加したプラグインはUPnP関係、Spotifyなど。
未使用のプラグインリスト（「Inactive plugins」と「3rd party plagins」）で該当するプラグインのチェックボックスにチェックを入れ、「Apply」「close」「Save & Restart」で、Daphileを再起動したら使用可能になるけど、ちょっと複雑。
以下、表にする。
| UPnP |
UPnP関係では、「UPnP/DLNA Media interface」と「UPnP/DLNA bridge」を有効化する。
まず「inactive plagins」のリストにある「UPnP/DLNA Media interface」を、他のプラグイン同様の手順で有効化。
そうして待つと、UPnP/DLNA bridgeプラグインの最新版がプラグインリストの最上部に表示される。 この時点でプラグインが有効化され「Active plugins」に表示される（「Audio Player」の画面表示にすると、右下の灰色のボタンにUPnPレンダラーが表示されていて、Daphileからレンダラーに音声データを送ることが可能になっていることが分かる）。
リスト表示されたUPnP/DLNA bridgeプラグインの右端「settings」から細かい設定が出来るようになっている。 |
| Spotify |
Spotifyは「3rd party plagins」の「Spotify for Squeezebox, Still Spotty」を有効化（Spotifyについては複数のプラグインがあるのだけど、どういうときにどれを使うのか詳細はよく分からない）。
有効になると「Spotty」にプラグイン名の表示が変わる。
SpotifyはWebプレーヤーではギャップレス再生ができない。 
|
| Deezer |
2024.04.22.追記。 新しいプラグインが導入されたので、下記の記述はやはり今現在には役に立たない。新しいプラグインの使い方は、そのうち余裕が出来たら記載するつもり。
2024.06.11.追記。 こまごまとここで説明しなくても、書いてあるとおりにしたら、そんなに難しくないと思う。
2024.01.29.追記。
https://forums.slimdevices.com/forum/user-forums/general-discussion/1668327-uesmartradio-com-and-mysqueezebox-com-servers#post1668327
要は、MySqueezebox.comのサーバー保守が終了になるのが原因、ということだ。
Deezer以外にも、Tidal、Pandoraが使えなくなる。
DeezerプラグインはLogitechから提供されていて、デフォルトで有効に登録されているが、そのままでは使えない。
https://www.mysqueezebox.com/index/Home 
Logitech Squeezeboxのサイトに行き、ユーザー登録しアカウントを作る。 
リストの中に「Deezer」が表示されている。これをクリックし選択したら、説明の記載と「Install App」のボタンが表示されるので、ボタンををクリック。 
DaphileはLMSで動いているので、これでDeezerプラグインを使えるようになる。
DaphileでDeezerを使うメリットは、何よりギャップレス再生が出来るようになることだ。
下の画像はDeezerの使用画面をキャプチャしたもの。 
|
| Youtube |
Youtubeの音をDaphileで鳴らすことができる。
しかしこの時点では使えない。Youtubeの管理をしているGoogleで「API Key」というのをもらってこないといけない。 
訳してみた。
正直、これを読んだだけではなんのことかさっぱりわからない。 無事にキーを取得し、プラグインに書き込めたら、DaphileでYoutube動画の音を聞くことが出きるようになる。最近は48kHz/16bitとかCDと同等以上の音質のものもあるようで、思っていた以上に楽しめる。 
|
Advanced
Advancedは弄っていない。
Information
各種情報が見れる。
Logitech Media Server Status、Library Status、などなどの項目がある。
うちではDeezer、Spotifyといった項目もあって、プレイリストに登録された音源データの数などをリストしている。
Cache FolderとかPlugin Folderとかパスの情報も表示されている。だから何ができるというわけではないのだけど。
Theme
右下、「Theme」という記載の後に２つ、グレーのボタンがある。これでブラウザ画面の表示を変更できる。
左側は「Default」の黒、「Light」の白を選択。
右側は「Wallpaper Toggle」と書いてあって、壁紙の使用、不使用を切り替える。
今のところ、設定についてはこんな感じか。
かなり読み辛いけど、読み易くする余裕はないので、仕方ないかな。
Jan 20, 2022
オーディオ状況報告（2022.01.20.）
気が付いたら新年だ。今年は特に年越しの実感がなくて、お餅を食べても正月だという気がしなかった。
もうすぐ北京オリンピックだそうだ。
どうにもこうにも実感がないのは新型コロナの所為かもしれないけど、まあ、それでも新年だ。おめでとう。今年もがんばろう。
ブログ更新はちょっと滞っていたが、それというのもアップする話がなかったからだ。
以前にエントリーでアップしたRaspberry Piのアクセスポイント化については、能力が無く中断、寝かすことにした。僕のようなにわかlinux使いには難しい。
Pegasus DACに1.5MHzにアップサンプリングして入力出来ないかもやってはみていたが、alsa、aplayの対応上限が768kHzらしいということで、将来的な対応を待つほうが良さそうだと判明。
最近は、Daphileが不調になりサーバー機種を替えたけど、１つのエントリーにするほどの話でもなし。
システム構成説明のアップデートでもしとこうか、ということだ。
最近のシステム構成は下図のような感じ。
ほとんど変化がない。
まず、有線LANのハブがひとつ減った。
FX-08miniをもしかして外した方がいいかもしれない？と思って外している。取り敢えず、外して害は無いようだ。ここらは電源やGNDの状況で変わるかもしれない。
あと、さっき書いたけど、Daphileサーバーが変わった。
以前はCompaq 6730bという骨董品？といっていいか、そんなノートPCを使っていたんだけど、1月に入ってぶちぶち音が飛ぶようになった。
NAS音源やSpotifyだと問題ない。Deezerでおかしくなる。
DeezerをWebブラウザで聴いたら問題ないので、やっぱりDaphileとDeezerプラグインが不調なのだ。
原因として思い当たったのは、ひとつはRadio Paradiseを鳴らそうとしたこと。
MQAを鳴らすことが出来るかどうか試してみようと思ったんだけど、なんだかおかしなことになって、ついでにクライアントとして使っているノートPCのWebブラウザまでおかしくなり、DaphileからはRadio Paradiseのプラグインを削除、ノートPCのWebブラウザを再インストールということに。
その頃から、Deezerも不調になった。
Daphileを動かすサーバーを替えてみる。
OSが入ったUSBメモリを、HP Elitebook 2570pに刺して起動。スペックは上がった筈だが、状況は変わらず。OSが壊れている？
仕方ないので、Compaq 6730bでDaphile新規インストールし動かしてみるが、何故か変わらず。
そこで、新規インストールしたUSBメモリを2570pに刺して動かしたら、どうやら問題なく動いている。現在、そういう状況だ。古いOSとサーバーと、両方に問題があったのだろうか。
ネット上の掲示板でDaphileについて書かれたのを読むと、apu2だと重いという記述がある。6730bのスペックはapu2よりも下なので、そこそこ重い状態で使っていたということかも。Deezerを使うに当たって、ライブラリ構築するためにプレイリストやお気に入りを多用しているんだけど、登録数が増えてくるのに従い重くなってきたのかもしれない。
新しいDaphileサーバーにしたElitebook 2570pは、以前はmpdアップサンプリングサーバーとして使っていた機械だ。820 G2と2570p、どちらも其々の趣きがあったんだけど、820 G2のほうがモニター的でHi-Fiに鳴る。2570pは揺らぎが出る。Daphileサーバーの不調があって、2570pを転用することにした。
そんなこんなで、今はあれこれ弄らずオーディオを聴いている。ある意味、平和だが退屈でもある。
また何かあったら手を入れていくつもり。
あ、Brooklyn Ampをどうするかが残ってるな、、、
Oct 31, 2021
カーステレオにRas Pi2+piCore7+MPD+i2s DAC （追記 10月31日、11月03日）
早々に追記。
このエントリーに書かれていることは、再現性がない。
何がどうなっているのやら、、、
もはや自分でもどうやって作ったのかわからないので、バックアップをGoogleに上げておく。
うちのHDDが飛んだりしたら紛失してしまうことになるので。
どうなってるのか見たいという人がおられたら、好きなようにしてくださればいいと思う。
https://drive.google.com/file/d/13eVisGZTRs3syI9z7cQ-2pC7SebC2f0Z/view?usp=sharing
うちのカーステレオ用音楽プレーヤーとして使っているBlackberry Bold 9000が最近あやうい。
というのは、内蔵電池が膨れてきている。
そのせいで本体の蓋が閉まらない。それでも使えて音も出るけど、じきに使えなくなるだろう。
交換用の電池は一応ネット上で売っているけど、何時売られなくなるか分からないし、過去には使ったら本体を壊した電池もあった。別の意味で危ういのだ。博打である。
当時、本体が壊れたので、普通の音楽プレーヤーで代替になれる製品を探したんだけど、試聴できた範囲ではいいのがなかった。音が良くないのと、操作性が良くないのと。
音が良いのになると高価になる。Bold 9000の中古が8千円で手に入るのに、数万以上で使いにくいプレーヤーを買う選択枝はなかった。
9000は物理キーから触覚で操作できるので、カーステレオ用として非常に使い易い。
必要となれば、ボタン１つで鳴っている音楽の曲名なども液晶画面に表示出来る。曲のランダム再生も、本体の電源を入れて諸々の操作で5秒以内で音楽が流れ出す。物理キーとトラックボール、いちいち目で見て確認しなくても出来てしまう。
しかし今や、9000は中古も売ってない。
あと、入手してもOSのバージョンアップが出来ないかもしれない。昔はなんとかしてやっつけたが、やり方を正確には覚えていないのだ（うちのサイトに備忘録があるんだけど、殆ど役に立たなかったんだよね、、）。
使い易くするにはバージョンアップしないといけないんだけど、これが出来ないかもしれないとなれば、、、
そういうわけで、代替機を作ることにした。
引き出しの奥で眠っているRaspberry Pi 2と、i2s DAC、piCore7 + MPD 0.19.9、追加投資はバッテリーぐらいで、なんとかしようというのだ。
少々梃子摺って、問題もないではないが、なんとかなった。
11月3日、書き忘れていたのに気付いたので追記。Raspberry Pi 2には無線機能がないので、USB HiFi アダプターにバッファローのWLI-UC-GNMを使っている。10年前の機材だ。
https://kakaku.com/item/K0000115107/
コンセプトはこんな感じで。
１．車のRCA入力端子につなぐ
２．電源オン・オフはコード（USBケーブル）の接続で行う
３．操作はWiFiでスマートフォンから行う（piCoreをAPモードで動かす）
４．USBメモリに収めた音源をランダム再生する
うちの車は、運転席左後ろの収納ボックス内にカーステレオのRCA入力端子が付いている。
9000は、専用のケーブルを自作して、イヤホン端子からRCA端子につないでいた。
ふつうのケーブルだと太すぎて、9000本体を収納ボックスから出せないのだ。出せなかったら操作できない。収納ボックスの蓋を開きっぱなしにしていたら運転の邪魔になる。そんなわけで、極細のRCA-イヤホン端子のケーブルが必要になったということだ。
Ras Piはスマホから操作するので、収納ボックス内に置いてかまわない。i2s DACと普通のRCAケーブルでつなげばいいということになる。
piCoreは電源コード抜去で電源を落としても大丈夫なOSなので、今回はなんとしてでも使うことにした。
車から降りるときにプレーヤーをシャットダウンする必要があるんだけど、raspbianベースのOS（例えばVolumioなど）だと、OSにログインしてシャットダウンの操作をしなければならない。手順を踏んでシャットダウンしないとOSが壊れるからだ。
その場で電源を落とせるほうが使い易い。piCoreはこういった用途に適している。
音声再生の操作はスマホからWiFiでアクセスして行う。
piCoreを所謂APモードで起動するのだが、過去に何回か手を付けたけど、分からなくて途中で投げてばかりだった。ネット上にはpiCoreでやってるケースは見つけられなかった。Raspbianベースで同様のことをやってる作例はあるのだけど、それでも随分参考になった。
操作性は、9000と比べたら低下している。
WiFiでRas Piとつなげて（これはスマホに自動設定できるけど）、MPDクライアントを起動し、音楽フォルダを選択してプレイリストに登録して再生、ランダム設定、、、
画面を見ながらじゃないとできないことがあれこれとある。たぶん操作に慣れても30秒はかかるのではないか。
あとアートワークを表示しない。これはMPD 0.19の仕様上、仕方がないのだけど。
うだうだ書いてきたけど、実際に行った建付けは右往左往だったけど、出来た結果を整頓して分かりやすく備忘録にしておこう。
参考にさせていただいたサイトは下記。多謝。他にも参考にしたけど忘れた。
https://itmedia.co.jp/news/articles/2008/14/news042.html
https://qiita.com/JhonnyBravo/items/5df2d9b2fcb142b6a67c
https://katona.hatenadiary.org/entry/20071101/p2
http://flac.aki.gs/bony/?page_id=1085
https://wiki.archlinux.jp/index.php/Music_Player_Daemon
http://kitatokyo2013.blogspot.com/2014/02/picoreplayerip.html
http://soramimi.jp/raspberrypi/mpd/
https://qiita.com/hoto17296/items/2e638fa28597b18505cd
https://gadget-live.net/raspberry-pi-self-made-router/
https://raspida.com/wifi4raspbian
https://herb.h.kobe-u.ac.jp/raspiinfo/raspiAP.html
https://armadillo.atmark-techno.com/blog/615/1830
piCore7はここからダウンロードした。
http://tinycorelinux.net/7.x/armv7/releases/RPi2/
piCore7を使う理由は、MPDのインストールが楽だから。
うちで余っているRas PiはB+と初期型の2なので、B+だったらarmv6、初期型2だったらarmv7となる。
3B+も1台予備があるんだけど、piCore7は対応していない。新しいバージョンのpiCoreだとMPDをソースからインストールしないといけないので、けっこうな手間なのだ。
ダウンロードしたイメージをマイクロSDカードに焼いて、i2s DACの設定を書き込み、Ras Piに刺して家庭内有線LANにつないで起動。パーティションを拡張。
ここら詳細は過去のエントリーを参照のこと。
http://blown-lei.net/endive/blosxom.cgi/audio_diary/20180103a.html
piCore7にmpdをインストールする方法
今回、完成後のonboot.lstは下記。
mc.tcz openssh.tcz wifi.tcz firmware-rtlwifi.tcz firmware-ralinkwifi.tcz usbutils.tcz net-usb-4.1.13-piCore_v7+.tcz net-usb-4.1.20-piCore_v7+.tcz hostapd.tcz dnsmasq-doc.tcz dnsmasq.tcz rfkill.tcz libmpdclient.tcz libmpdclient-dev.tcz mpd.tcz alsa.tcz alsa-config.tcz alsa-dev.tcz
このリストにあるtczを、tceでインストールしていけば、関連のライブラリ等も含めて同等のものが出来る筈だ。
mc.tczとopenssh.tczは最初からインストールされている。それ以降のtczをインストールしていけばいい。
MPDをインストールしたらalsa関連も一緒にされるものと思い込んでいたら、されなかったので最後に追加でインストールしている。実際にi2s出力で必要かどうかは分からないが、一応入れている。
APモード関連
まずAPモードの設定から。
起動時にAPとなるRas PiのIPアドレスを固定するには、/opt/bootsync.shに「wlan0.sh」の設定をしておく必要がある。
下記、記載。
/home/tc/wlan0.sh &
/home/tc/wlan0.sh に、wlan0の設定を記述する。
下記の記載で、RasPi-APが「192.168.2.1」になる。
pkill udhcpc ifconfig wlan0 192.168.2.1 netmask 255.255.255.0 broadcast 192.168.2.255 up route add default gw 192.168.2.1 echo nameserver 192.168.2.1 > /home/tc/resolv.conf
/home/tc/resolv.conf に下記記載。
（このファイルを削除したら、有線LANにつながらなくなる。どういう挙動なのかよく分からないが、、、）
nameserver 192.168.2.1
USB無線LANアダプターを刺して、認識しているかどうかを確認。
tc@box:~$ lsusb Bus 001 Device 004: ID 0411:01a2 BUFFALO INC. (formerly MelCo., Inc.) WLI-UC-GNM Wireless LAN Adapter [Ralink RT8070] Bus 001 Device 005: ID 0bda:0109 Realtek Semiconductor Corp. Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp. SMSC9512/9514 Fast Ethernet Adapter Bus 001 Device 002: ID 0424:9514 Standard Microsystems Corp. SMC9514 Hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub tc@box:~$
ハードの認識はしている。しかし設定をしていない段階では認識していても動いていない。
/opt/bootlocal.sh にiwconfigでスイッチを入れるように設定。
iwconfig wlan0 power on
bootlocal.sh には、hostapd起動の設定も記載。
今回は、tcディレクトリに置いた設定ファイルをhostapdで読み込むようにする。
hostapd /home/tc/hostapd.conf -B
tcディレクトリに置いた設定ファイル、/home/tc/hostapd.confには、下記を記載。
interface=wlan0 ssid=RasPi-AP hw_mode=g channel=7 wmm_enabled=0 macaddr_acl=0 auth_algs=1 ignore_broadcast_ssid=0 wpa=2 wpa_passphrase=abcdefghijkl wpa_key_mgmt=WPA-PSK wpa_pairwise=TKIP rsn_pairwise=CCMP
細々したことはよく分からないんだけど、無線LAN(wlan0)を「ssid=RasPi-AP」で動かす設定。
wpa_passphraseは、スマートフォンからRasPi-APネットワークにログインするためのパスワードだ。
dnsmasqでDHCPの設定。
/home/tc/dnsmasq.conf に下記記載している。
interface=wlan0 dhcp-range=192.168.2.2,192.168.2.99,255.255.255.0,24h
udhcpcのdefault.scriptが何処にあるのか探したら、/usr/share/udhcpc/default.scriptが見つかった。中をみたら「RESOLV_CONF="/etc/resolv.conf"」と。
今回はtcディレクトリにresolv.confを置いているので、それを設定してやらないといけないのかな。
/home/tc/udhcpc.script を設定。「RESOLV_CONF="/etc/resolv.conf"」の記述を「RESOLV_CONF="/home/tc/resolv.conf"」に書き換えて設置、、、
実はこの辺り、、、なんでこんなことしたのか記憶がない。何を参考にしたのかもよく分からない。
しかし、/home/tc/udhcpc.scriptを外したらうまく動かなくなる。無線は動いてログインできるんだけど、有線LANがつながらなくなる（まあ、有線LANはカーステレオ使用には無用なんだけど、使える方がメンテしやすい）。なので、何かしているんだとは思うんだけど、、、
よく分からないところもあるが、これでRas PiのAPモードが動く。
APモードなんだけど、同時に有線LANの方も稼働しているので、LANケーブルをつなげばそっちからの設定変更やMPDクライアントでのアクセスも可能だ。
しかし、dnsmasq、udhcpc周りには問題があって（設定がおかしいからだと思うが、、、）、APからクライアントにアドレスが配布されない。クライアント側のスマートフォンで固定IPにすれば運用上の支障はないので、当面このままで使うつもり。
MPDの設定
MPDは、Ras Pi起動と同時に自動起動させる。
これがなぜか、今までのうちでのやり方で上手くいかなかった。ネット上にはrootでは起動しないと書いてあったり（そうなの？！、、、）。
なので、/home/tc/.profile の末尾にコマンドを記載することで起動させるようにした。
/usr/local/bin/mpd /home/tc/.mpdconf
mpd.confは/home/tc/.mpdconfで設定。下記の通り。
music_directory "/mnt/music"
# playlist_directory "/mnt/music/mp/mpd/playlists"
playlist_directory "/home/tc/.mpd/playlists"
log_file "/home/tc/.mpd/log"
pid_file "/home/tc/.mpd/pid"
state_file "/home/tc/.mpd/state"
sticker_file "/home/tc/.mpd/sticker.sql"
db_file "/usr/local/share/mpd/database"
auto_update "yes"
#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"
カーオーディオの使用でライブラリを保存する操作は基本的にはしないので、MPD起動と同時にライブラリのアップデートを行うように設定。
auto_update "yes"
データベースファイルをMPD起動と同時に作るので、filetool.sh -bに記載されていない場所に設定した（これは工程作業の都合で使用上には関係ないけど）。
db_file "/usr/local/share/mpd/database"
/opt/bootlocal.sh に下記記載し、OS起動時に/mnt/musicやデータベースファイルを置くディレクトリなどを作る。
音源となるUSBメモリ／マイクロSD＋USBアダプターをOS起動時に認識、マウントポイント「mp」にマウントさせる。
mkdir /usr/local/share/mpd chmod -R 777 /usr/local/share/mpd mkdir /mnt/music mkdir /mnt/music/mp mkdir /mnt/music/ram touch /mnt/music/ram/dummy.cue chmod -R 777 /mnt/music mount -w /dev/sda1 /mnt/music/mp
以上で、MPD関連の設定は完了。
スマートフォンの設定
インストールと設定を終えたRas Piは、電源を入れて起動したらAPモードで動いている。MPDも自動的に起動し音源データを読み込みライブラリを形成し、クライアントからの指示があれば音声再生が可能な状態になっている。
MPDクライアントを動かすスマートフォン（当方はAndroid 11）を設定する。
WiFiからアクセスポイントRasPi-APを選択。
前述したとおり、Ras Piの方から自動的にIPアドレスを振ってくれない。
Ras PiのDHCPサーバーが問題なく動いていればスマートフォンに自動的にアドレスを振ってくれるはずなんだけど、これが機能していないのだ。
できないものは仕方がないので、スマートフォンのほうでIPアドレスを設定。IPアドレス固定で設定する。
APモードのRas Piが「192.168.2.1」でネットマスクはnetmask 255.255.255.0 なので「192.168.2.xxx（xxxは2から254の間の任意の数でいける筈）」でスマートフォンを設定。
インターネットに繋がりませんと警告？が出るけど、繋げなくてもいいということで設定する。
これで接続、MPDクライアントから操作ができるようになる。
うちではM.A.L.P.を使っているけど、クライアントソフトによって設定や使い方は違うと思うので、これ以降は省略。
そんなこんなで、取り敢えずRaspberry Piベースでカーオーディオ用のポータブルMPDプレーヤーが出来上がった。
音の方は、試しに車のシガーソケットからUSB電源をとって試聴したところ充分過ぎる音が出たので（シガーソケットでこの音か？と驚いた）、問題があるとか何とかは置いといて速やかに日常使用に移行させようという感じ。
接続が問題かな、RCAケーブルとか電源ケーブルをどうするかとか。
当初はバッテリー駆動するつもりだったが、シガーソケットから電源をとれるようにすることも検討している。
DHCPの問題は、今後あせらずに対処していこうと思う。
Sep 05, 2021
オーディオ状況報告（2021.09.05.）
パラリンピックが終わりますね。世の中いろいろだなあ、、、
最近のシステム構成は下図のような感じ。
6月のときと比べると上流が幾分変わっている。
うちではメインのオーディオシステムをPPAP方式で鳴らしているが、以前はFront-EndとBack-End、2台タンデムで運用していた（といっても、Back-Endが2台だったので3台なんだけど）。
これを3台タンデムで運用するようにした。
前回エントリーの説明ではFront、Back-End 1、2としていたけど、分かりにくいのでFront-End、Middle-End、Back-Endと呼ぶことにした。ソフトウェアやPCのタンデムシステムでそういう呼び方をすることがあるようなので、それに合わせた。
以前にはBack-Endとして使っていた2台のapu2を、Middle-EndとBack-Endに振り分けたことになる。
結果、USB DACへの出力は1系統になった。
2台のUSB DACへの出力切り替えは、ケーブルの接続自体を切り替えて行うようにした。音質上の不都合は特に感じられない、と思う。
追々、余裕がある時にちゃんと確かめて見ようとは思うけど、現状に不満がないので何時になるか分からない。
音質の変化について少し。
2台だとDeezer/DaphileからUPnP経由でmpdにつなぐ音が、NASマウント音源から直接にmpdにつなぐ音に及ばなかったんだけど、3台だと同等の音質で鳴るようになった。
同等になったといっても、どちらの鳴らし方も2台の時より向上しているようで、SM-SX100は以前より更に音源の音質にピーキーになった。優秀録音だと思っていた音源の中に、ここに来て振り落されるのがあるのだ。粗が見えてくる。
そういうときには、Brooklyn Ampがいい塩梅に鳴らしてくれるので助かる。
書き忘れていたけど、Front-Endの2570pと820G2、僅かだが音が違うようだ。2570pのほうがややアメージングな方向に音色が振れている。なんだかわからないが。
各サーバーの配置も変更した。
以前はオーディオシステム周囲に複数のサーバーが集まっていたんだけど、現在は極力、PPAP Back-End以外はオーディオシステムから離すようにしている。
Daphile、PPAP Front-End、Middle-Endは、オーディオシステムとは別系統の電源から給電している。NASも移動させた方がいいのかもしれないが以前と変わらない場所にある。これはスペースの都合で移動できていないからだ。
現状のオーディオLANネットワークの状況は下図の通り。
PPAP Back-Endの前段に4台のハブがカスケードになっている。これは何れかを外してみたら音が劣化するの繰り返しで、結局、何れも外さないままということになった。
様子を見ながら、減らせるようなら減らしたいけど、このままになるかも。
PegasusとADI-2の比較は、44.1/16音源をlibsamplerate(SRC)で768kHzにアップサンプリングした音源での比較しか出来ていない。それも大雑把なものだ。
以前はADI-2の方が良いのか？と思っていたが、電源の条件を合わせないと比較できない。
アンプの電源タップ（BP500-2）につないでいたPegasusを、ADI-2をつないでいるBY50Sにつなぎかえてみたら、すっかり同等になった。
Pegasusは本来AC110-240V対応なので、100Vで使うなら安定している電源が必要なのかも。
Pegasusのほうが鮮やかで絵画的、ADI-2のほうがクールでモニター的に鳴る。
当面、気分によって切り替えながら使うつもりだ。
Aug 24, 2021
PPAP Back-Endをタンデム化
まず、前のエントリーから引用する。
- 1）NAS音源 > 2570p > apu2
- 2）NAS音源 > Daphile > 2570p > apu2
- 3）Deezer > Daphile > 2570p > apu2
- 4）NAS音源 > 820G2 > apu2
- 5）NAS音源 > Daphile > 820G2 > apu2
- 6）Deezer > Daphile > 820G2 > apu2
3）＜ 2）≦ 1、5、6）＜ 4）、こんな感じ。
引用内容から導かれる仮設。
- 2570pよりも、820G2のほうが音が良い
- mpd/upnpサーバーを、LANの経路上、PPAP Back-Endから離した方が音が良い
- upnp(upmpdcli)を使うより、使わないデータ伝送の方が音が良い
さて、その後どうだったか。
まず、Back-Endの近くにあった2570pを、820Gの傍に移動して音を比較。
結果、両機種の音に僅かな差異はあるような気がするものの、音質は同等と結論した。
こうした過程で、移動した2570pの音が改善したことが分かった。
一つ目の仮説は否定され、二つ目の仮説は正しいと思われることが分かった。
さて三つ目の仮説は、一つ目の仮説が反証され二つ目の仮説が実証される過程で再検証された、といっていいのかな？
どうもやはり、upnp/upmpdcliを経由するよりも、NASやCDから直接（と言っていいのか？）、mpdの入力プラグインに音声データを入力する方が音が良い。
PPAPでは、mpdサーバーから、DACに信号を送る機能を分離している。
DACに信号を送る機能はPPAP Back-Endが受け持っているが、Front以前の状況によって音が変るということは、遠く家庭内LAN経由で複数のハブを介して離れていても、Frontの負担がBack-Endに影響しているということだ。
僕としては、upnp経由の音（Deezer hifi / Daphileの音源）を、mpd単体の音と同等にしたい。
upmpdcliといえば、過去にはpolipoを組み合わせて高音質化する手法を見たことがあった。
polipoは「キャッシュウェブプロキシ」というもので、キャッシュや負荷を制御することでmpdの負担を減らす、ということだった？と思う。
当時、よく分からず、今もよく分かっていない。
簡単にできたというネット上の書き込みもあるのだけど、よく分からないのでこの手法は使いにくい。
そこで思い付いたのは、PPAP Back-Endを2連直列、タンデム化するというアイデアだ。もともとPPAP自体がタンデムシステムなので、Back-Endがタンデムということは三人乗りになるわけだけど。
前回、ノイズ源を減らすとか言いながら、また増やしている。
下図のような感じに。
出来るだろうか。
最初は、Back-End化したraspberry pi B+ / piCore7で試した。
設定ファイル「bootlocal.sh」には、「/usr/local/bin/ncat -kl 4400 -e "/usr/local/bin/aplay -D hw:0,0 -M --period-size=1024 --buffer-size=16384 -t raw -f S32_LE -r768000 -c2"」というようなコマンドが書き込まれていて、OS起動時に読み込み実行され、PPAP Back-Endとして機能する。
これを下記のように書き換える。
sudo vi /opt/bootlocal.sh /usr/local/bin/ncat -kl 4400 -e "/usr/local/bin/ncat 192.168.1.89 4400" filetool.sh -b sudo reboot
こんな感じに、中継機として設定してみる。
コマンドの記述は思い付きである。
ちょっと思い付きというのは乱暴なので書き直し。Frontのmpd.confのpipe出力に記載している内容を参考に、というか、そのまま引用して書き加えている。
要は、ncatで受けてaplayに送ってDACに出力していたのを、ncatで受けて再度ncatから送り出すようにした。上の例だと、ipアドレス「192.168.1.89」のPPAP Back-End、つまり2台目のBack-Endにデータを送るということだ。
PPAP Frontのほうも、中継機のipアドレスにデータを送るようにmpd.confを書き換え、mpdを再起動。
これで動かしてみたら、、、普通に音が出た。我ながらびっくりした。
さて、44.1/16のデータ転送では音が出たが、Ras pi B+ではスペックが足りない。192kHzでは使えなかった。音が途切れるしクライアントの操作から出音が５～６秒以上遅れる。
そこで、前回エントリー時にシステムから外して余っていたapu2c4を復帰させた。もともとBack-Endとして動かしていた機体なので、再設定も簡単。
ハードのスペックが上がったら、前述のような問題は全くなくなった。768kHzでもストレス無く使える。
音はどうか。
結論から言えば、目論見どおり、upnp経由のDeezer hifi / Daphileの音を改善できた。
S/N、階調が深まり、弦楽器の倍音、余韻が細やかに減衰する。パーカッションの基音が聴き取りやすい。環境音の鳥の声や、録音時に紛れ込んだノイズのリアリティがアップする。一皮剥けて見通しが良くなった。
mpd単体の音と比較して差異が全くなくなったとは言えない感じだけど、かなり差が縮まった。ブラインドで区別する自信はない。
mpd単体再生で、Back-Endが１台のときと2台のとき、変化はどうなのかということになると、かなり難しい。差異を聴き取れない。
しかし、こんなところに改善を目指せる余地が残っていたということに驚いた。
やってみるものである。
あとは、追加したBack-Endを何処に設置するのがいいかの検討が残っている。追々やる。
今日からパラリンピックが始まる。まったく世界はカオスだ。感染回避を心掛けるのみならず、可能な限り身辺安全を確保し、病院のお世話になるような怪我や体調悪化を、ひたすら回避する。命に関るようなことがあっても、現状、病院が守ってくれる余力は限られているのだから。
諸兄も頑張ってください。ご自愛を。
Jul 31, 2021
ネットワーク上のサーバー運用を再考する
世の中はオリンピックで盛り上がっている。
何よりも大過なく終わっていただくこと（中止含む）を祈るばかりだが、非常に危うい。
パラリンピックはやるんだろうか。
コロナ禍は各自で身を守るしかないのだろう。医療崩壊のリスクが高い今、感染回避を心掛けるのみならず、可能な限り身辺安全を確保し病院のお世話になるような怪我や体調悪化を回避する必要がある。頑張ろう。
以前に「mpdでCD再生に対応する」というエントリーを挙げたことがある。
テスト用システムのhp Elitebook 820G2で設定したままになっていて、時々、CDを鳴らすのに使っていた。
820G2につないだUSB-DVDドライブでCDのデータを読み込み、768kHzにアップサンプリングする。PPAPフロント機能でLAN経由でメインシステムのPPAPバックエンドにデータを送る。これで、メインシステムでCDを聴くことが出来る。
そうこうするうちに、気付いたことがある。
昔、オーディオ用のLANネットワークを100Base-Tで組んでいた頃、700kHz台にアップサンプリングしたデータと768kHzのハイレゾファイルのデータを転送出来なかった経験がある。
当時はFX-08miniを使っていた。FX-08miniは音がいいスマートハブだけど通信速度は100Base-Tだ。768/32では音が途切れて使えなくなったので、ハブを替えて、768/32のデータが通る回線は1000Base-Tでつないで、以降は問題なく音声再生できるようになった。
そうした経験から、768kHzのPCMデータを100Base-Tで転送することは出来ないと思っていた。
しかし現在、テスト系の820G2とPPAPバックエンド（apu2）の間には一部、FX-08miniを使っていて100Base-Tの区感がある。それにも関わらずデータの転送が出来ている。
現在のPCオーディオのLANネットワークを図にしてみた。
以前のアップした図にテストシステムの820G2も描き加えて整理している。820G2はメインシステムからはかなり離れたところ、Daphileサーバーとして運用しているCompaq 6730bの隣に置いてある。
さて、どういうことだろう、、、
バックエンド直前のハブが1000Base-Tである必要があるのか？と思って、試しにADI-2 DAC直前のFXG-05RPTを外してFX-08miniに替えてみたところ、問題なく音が出る。これは違う、、、
他に考えられることといえば、以前と変わっているのは普段使いのノートPCのスペックが上がっていること。Compaq 6730bから、Probook 450G3に替えている。オーディオシステムから遠く離れた場所につないだPCでも、負荷が大きくなると音に悪影響がある。しかし、それが原因で768/32が100Base-Tで通るようになるというのは、考え難いかな、どうだろう、、、
以前から感じていたんだけど、テストシステムで再生するCDの音が意外に良い気がする。DVDドライブでガンガンCDが回っているからノイズだらけなはずなのに、音は悪くない気がするのだ。
音がいいと感じるのは、テストシステムのアップサンプリングサーバー（820G2）がPPAPバックエンドから離れているからではないのか。加えてテストシステム、Daphileサーバーの電源と、PPAPバックエンドを含むメインシステムの電源は、分電盤上で分離されている。820G2のノイズはメインシステムに伝わりにくいかもしれない。
Daphileで聴いているときはどうなのか。
このときはDaphileから44.1/16のデータを、PPAPバックエンドのすぐ傍にあるPPAPフロント兼アップサンプリングサーバー（2570p）に送ってアップサンプリングしている。つまり、バックエンドにノイズの影響が及びやすい場所でアップサンプリングしていることになる。
テスト系とメインシステム系、どちらサーバーのほうが音がいいのか。そもそもサーバーに使っている機種が違うので単純に比較できない面もあるけど、比べてみた。
ブラインドでは、まず分からないと思う。
しかし繰り返し切り替えて比較したら、テスト系の方が僅かに音がいいのが分かる。雑味が少ないのだ。
これは僅差でも戻れない差異か、と思いながらテスト系を継続して使っていたら、普段の日常的用途に使っているノート（450G3）を操作したときに音が途切れることが時々あった。
テスト系と450G3は電源タップを共有している。
アップサンプリングサーバーをノイズが多い環境に置くのは望ましくないということか。
こういう場合、経験的には暫く使ううちに不具合が増えて上手くいかなくなっていくことが多いように思う。
そこで、メイン系アップサンプリングサーバー（2570p）をつなぐハブを変えてみた。
FX-08miniでつないでいる場所よりPPAPバックエンド側のGS105Eにつないでいたのを、手前のLSW4-GT-8NSのところに持ってきた。
これまでバックエンド側に置いていたのは768/32の信号は100Base-Tを越えられないと思っていたからで、伝送できて越えられると分かったからにはバックエンドの近くににつなぐ必然性はない、という判断だ。
音の違いは、テスト系を使った時より少ない。しかし極めて僅差だが、良いような気がする。
普段使いの450G3であれこれしていても、音は途切れない、かな？
と思っていたら、再生音が途切れるようになってきた。
Daphileを再起動したら一旦は落ち着いた。しかし以前には無かったことであり、結局は768/32で100Base-Tを通すのは難しいということになるのだろうか。100Base-Tで768/32を通すのは、送信側にも負担になるのだろうか。Daphileは44.1/16を送信しているだけなのだけど、受信側が上手く動いてなかったら送信側にも負担は生じるかもしれない。
それとも、他に原因が？、、、
取り敢えず、2570pをつなぐハブを変更前のGS105Eに戻して様子を見る、、また音が途切れる。
Deezer、休日は人気がある曲はつながりにくいのか？、、、
Daphileサーバーの6730bの温度を確認したら80℃以上と。
熱すぎる（Daphileはウェブブラウザインターフェイスからサーバー温度を確認できるのだ）。
一旦シャットダウン、本棚の下から引っ張り出す。
使っていない内蔵HDDが熱くなっている。これが原因ではないとは思うが取り敢えず外す。ついでにメモリも4x2GBだったのを1枚に減らす。風通しが良くなったら違うかもしれない。DVDドライブは使ってないのでbiosで止める。
置き方も変えてみる。底板が熱くなりやすいので上下を逆さまにセッティングしてみた。多少は冷えやすくなるんじゃないだろうか。
本来、加熱するから冷やすじゃなくて加熱しないように使うべきだと思うが、仕方ない。
家庭内LANの状況とか、Deezer側の状況？とか、なんだかいろんな要素が複合的に作用しているようだ。
その後、サーバーの温度が安定したので、再び2570pをLSW4につないで様子をみているけど、、、どうだろうな、、、
そんな感じであれこれやっていく中で、音の比較もしてきている。
うちではCDリッピング音源をNASに置いているんだけど、Deezerにも同等の音源がある場合、6通りの再生方法が考えられる。
以下の通り。
- 1）NAS音源 > 2570p > apu2
- 2）NAS音源 > Daphile > 2570p > apu2
- 3）Deezer > Daphile > 2570p > apu2
- 4）NAS音源 > 820G2 > apu2
- 5）NAS音源 > Daphile > 820G2 > apu2
- 6）Deezer > Daphile > 820G2 > apu2
比較したところ、3）は他と比べたら良くない。
1）5）6）は若干の音色の違いはあるようだが、ほぼ同等だと思う。
難しいのは2）で、差があるようで無いようで、明確に言いにくい。
一番いいのは、4）だ。
3）＜ 2）≦ 1、5、6）＜ 4）、こんな感じ。
テスト系で鳴らしたCDの音が良いと感じたのは、順当だったということらしい。
サーバーを何処に置くかよりも、サーバーに使っているハードの違いのほうが影響が大きい可能性もある。
今後、確認していきたい。
もう一点気になってきたことが。
以前は、PPAPバックエンドが2台あって、USB DACへの出力切り替えは使用するバックエンドをssh経由で切り替えることで変更するようになっていた。しかし、それが面倒な時には物理的にUSBケーブルの抜き差しで切り替えることがあった。それどころか、いつの間にか切り替えに便利なようにUSBケーブルに中継アダプターが入っている。
こんなことをして音質に影響があるかと思ったら、特に問題を感じない。
だったら、ケーブル抜き差しの切り替えでいいんじゃないか、と。
どうせ上流を切り替えたら下流もXLRケーブルやアンプセレクターなど切り替える必要があるので、手間としては大して変わらない。
そうなると、apu2を1台に出来る。ノイズ源を１つ減らすことが出来る。
現在、ADI-2 DACにつながっているapu2d4の前にはFXG-05RPTを入れている。過去の経験からは、ここに音の良いハブ1台をかませたほうがいい。所謂ハブのカスケード接続だ。
Pegasusにつながるapu2c4のほうは、これが入っていない。
前述の100Base-T伝送の関連で一時、FXG-05RPTをFX-08miniに戻してみたんだけど、ウォーミングアップが足りないせいかLANターミネーターを刺してなかったせいか理由は分からないが、音質が低下した。以前には散々聴き比べてFXG-05RPTにしたけど、今回は差が大きいと感じたのだ。
2台のapu2の条件を合わせようとするならFXG-05RPTをもう1台購入する必要がある。しかし今購入するなら以前の倍の価格で売っている。というか、前に買った時が安売りだったのだ。
apu2を1台にするなら追加購入を考える必要はなくなる。
そういうわけで、apu2を1台にした。
余ったapu2でDaphileを運用するというのも考えられるかと思う。
現状、そんな感じで細々したところを弄っているけど、取り組みは気まぐれな感じなので、セッティングが確定して落ち着くにはもうしばらく時間がかかりそうだ。
Jul 06, 2021
pulseaudioでMQAデータを転送再生する
以前のエントリーで、pulseaudio経由の音声信号伝達について書いていた。
現在は、ras pi2とM500（USB-DAC）をつないでシステム化している。piCore7にalsaとpulseaudioだけ組み込んだ簡素なサーバーだ。
Youtubeなどの再生に使うんだけど、実はもうひとつ他に目的があって、MQA再生環境が必要な時にM500を使おうと考えていた。
今回、普段使いのノートPCでmpdを動かして、MQAデータをpulseaudio出力しpulseaudioサーバーに転送、M500で再生したところ、MQAを認識し再生した。
MQAはpulseaudio経由で転送することも可能なことが分かった。
大したことはしていない。
ノートPC（OSはFedora）の.mpdconfに下記のようにpulseaudio出力を設定、サーバーのipアドレスを設定し、mpdでMQAファイルを再生しただけだ。
audio_output {
type "pulse"
name "My Pulse Output"
## server "remote_server" # optional
server "192.168.1.77"
## sink "remote_server_sink" # optional
}
MQAの音は、綺麗だと思う。
うちではメインの音源は主にCD相当のデータをlibsamplerateでアップサンプリングして鳴らしていて、これはこれで高音質なんだけど、なんというか、MQAの音には無理がない軽やかさがある。スムーズで余裕があり歌心がある鳴り方をする。
MQA対応のハードというのは「オーダーメイドの服」みたいな理解を僕はしていて、つまり、MQA音源とハードウェアがあつらえた服のように合っている、というイメージだ。
従来のPCM再生はハードウェアがPCM音源に合わせないといけないが、限界があるというイメージ。
MQAはハードウェアの合わせ方が予め決まっていて、ハード側がそれに沿って合わせるように作られているので、PCMの限界を越えるというイメージ。
うちでやっているPCM768kHzへのアップサンプリングは音源をハードに合わせる努力であって、だから良質な仕立て（libsamplerate）が必要なんだけど、確かに音質改善があって楽音の情報量としても多いけど、何処かしら頑張ってる音という感触がある。これはハードのスペック向上によって改善するのかもしれないけど。
MQAの音は、そういう野暮ったさがない。スマートな音がする。
今回はpulseaudioで転送したけど、一般的なUPnPでも転送は可能だと思う。そもそも、UPnPで転送してMQAだと読めなくなるようなら、使いものになってない筈だ。
うちではUPnPで転送するなら、転送先にmpd、upmpdcliをインストールしないといけない。他にUPnPレンダラーの作り方を知らないからだ。
そうそうMQAは使わないし、当面は現在のシステムでいいと思っているけど。
