abk1's scratched blog 3

さて、世の中はいろいろ面倒だが、うちのオーディオは泰平を貪るがごとく鳴っている。
LMS周りの懸案はあるが、それを除けばこれ以上何をしようか、という雰囲気だ。まあ、課題を探せば見つかるんだろうけど、取り立ててしたいことがない、というか。
そういうわけで、こういうときに、改めて音色の検証をしておくのもありかな、と思った。

検証にあたって使用するコンポの状況は以下。下流から上流へ。

スピーカー
JBL / 4425mk2
現行品4429の源流。発売当時のネット上の評価は低かったが、そんなのはあてにならない。
FOSTEX / T900A
スーパーツイーター。アッテネーターを排除したチャージカップルドネットワークで繋いでいる。情報の減衰が少ない。
https://www.fostex.jp/products/t900a/

スピーカーケーブル
協和電線 / 5.5sq Cabtyre
キャブタイヤは昔から使っている。昔々に他のケーブルも聴いたこともあったと思うけど、長々これを使っている。

アンプセレクター
ORB / SC-S0 NOVA
他の同等品の機械と比較したことはないけど、いいんじゃないかと思う。
https://www.orb.co.jp/audio/products/mcs0nova.html

コネクターケーブル
HS&T / VVF 1.6mm LFV 2芯
セレクターとアンプを繋ぐのにVVFを使っている。径1.6mmの単線。ごつい針金で固い。

アンプ
Mytek / Brooklyn AMP
メイン使用のSM-SX100の代打だが、ちょくちょく気が向いたときに使う。パワーアンプでボリュームが付いていないので、音量調整は上流のMPDで行う。 HiFi度はSX100に僅かに劣るが、今回はこれ。
現行品は、Brooklyn AMP+。幾つか読んだレビューによるとSX100の音に近付いている様子。
https://www.mytekdigital.jp/products/brooklyn-amp-plus/

固定抵抗アッテネーター
TOMOCA / AT12
業務用のXLRアッテネーター、12dB減衰。これなしではMPDのデジタルボリュームを大きく絞らないといけなくなるので。アンプの端子に差しっ放しでは気分的に心許ないので、さざれ水晶を綿袋に詰めたインシュレーターで支えている。
https://www.tomoca.co.jp/brand/tomoca/tom_att/at-12/

インターコネクトケーブル XLR
wireworld / OASIS 6 使いやすいので使っている、かな。実はあんまり他と比較してというのはしていない。

コネクターパネル
TOMOCA / P-112N
業務用のコネクターパネル。ラックにネジ止めしている。
これにXLRコネクターを取り付けて、ケーブルの抜き差しでDACとアンプの接続切り替えに使っている。ケーブルをラックに固定する形になることが振動対策になるようで、接点が増えるにもかかわらず音質劣化を感じない（ちなみにパネルを使わずに２本のケーブルを繋いだら明瞭に音質は劣化する）。
https://www.tomoca.co.jp/brand/tomoca/tom_bncpatch/p-112n/

コネクターケーブル XLR
HS&T / VVF 1.6mm LFV 3芯（脱シースなど加工）
コネクターパネルとDACを繋ぐのにVVFを加工して使っている。径1.6mmの単線、ごつい針金で固いので加工は結構大変だった。
作成した当時、エントリーにしている。
http://blown-lei.net/endive/blosxom.cgi/audio_diary/20210623a.htm

DAC
Musician / Pegasus R2R DAC
位置付けとしてはADI-2 DACのサブだけど、これもぼちぼち使う。
新型が出ていて、現行品はPegasus II R2R DAC。
http://www.musician-audio.com/en/col.jsp?id=122

USBケーブル
Zonotone / 6N・USB-Grandio 2.0
これは昔の別冊ステレオサウンドの企画で付いていた4本のUSBケーブルのうちの1本。
ちなみにAIM電子 SHIELDIO UACをS.M.S.L M500に、SUPRA USB 2.0をADI-2 DACに、WIRE WORLD ULTRAVIOLET 7 USB AUDIOをヘッドフォンシステム用に使っている。
https://www.fujisan.co.jp/product/1281691479/b/1017003/

USBアイソレーター
HuMANDATA / USB-029H2-RP
アイソレーター兼コネクターとして使っている。つまりPCトランスポートとDACをケーブルの抜き差しで切り替える。
https://www.fa.hdl.co.jp/jp/isolator/musb-highspeed/musb-029h2-rp.html

USBケーブル
PCトランスポートとUSBアイソレーター間は、市販の一般的なものを使っている。高価なオーディオ用を使う気は今のところない。

PCトランスポート
Raspberry Pi / 2B / piCore 14.1 PPAP Back-End
非力なワンボードPC。正直、これといった電源への配慮やノイズ対策はしていない、素のままだ。6年前にpiCore 9でPPAPを試みた時にはノイズが乗るなどして上手くいかなかったが、今回、使用を復活してみて、全く問題なく384kHz/32bitの信号を伝送できている。当時、何が悪かったのかは、正直、よく分からない。

LAN
ここは、オーディオ的な対策はほとんどしていない。一般的なスイッチングハブで比較的ましなのかな？というのを使っている、というぐらいのものだ。

MPDサーバー兼UPnPレンダラー
hp / EliteBook 820G2 / Tiny Core 64 11.1 PPAP Front
ストリーミングやNAS音源からの44.1/16の信号を、libsamplerate + MPDでアップサンプリングしPCトランスポートに送る。
デジタルボリュームで音量調整を担う場所でもある（Max 100で、クラシックやジャズの音源は殆どが50以上、多くが70前後になる。ポップ系だと、ときに30以下になることがある）。
今回、ここのMPDのアップサンプリングの設定を変えて、音質の変化を聴いてみようということ。

ざっと、こんな感じ。
思ったよりも、前振りの文面が長い。実は今回、前振りのほうがずっと長い。

さて、まず、アップサンプリングを止める。
/home/~/.mpdconfの設定は、「audio_output_format "44100:32:2"」にする。
なんで44.1/16なのに、44100:16:2じゃないのかというと、なぜかそれだと音が出ないからだ。44100:32:2だと音が出る。これはDACを繋いだ時に、Back-EndのRas Pi 2Bにsshから cat /proc/asound/card0/stream0 を打った時に表示される「S32_LE」に合わせたもので、そういう意味では、理屈は合っている。

この状態で、44.1/16の信号がビットパーフェクトで送信されているのかどうか。
出力信号のチェックとして、44.1/16のMQAデータを44100:32:2の設定でSMSL M500に送ってみると、MQAと認識し再生する。ということは、音声のデジタル信号はビットパーフェクトで送信されていると考えていい。

さて、そういうわけで、NASやDeezerストリーミングから、44.1/16のPCMデータを前述のシステムで鳴らしてみる。
アップサンプリングなしのビットパーフェクトデータということだ。
正直、普段聴いているより音色の肌理が粗い。ざらっとしていて、やや耳障りだ。これしか聴いてなかったら多分、これでいいと感じそうではあるのだけど。

「audio_output_format "88200:32:2"」に。
だいぶ良くなる。肌理が細かく、抜けが良くなる。情報量が増えて埋もれていた音が聞こえてくる。音声のニュアンス、リアリティが向上する。
libsamplerateによる改善は、そういう感じだ。

「audio_output_format "192000:32:2"」に。
更に良くなる。
ここで一応、断っておくが、libsamplerateによるアップサンプリングに際しては、もとの周波数の整数倍かどうかは、気にしなくても良い。リサンプラーの種類によっては、整数倍じゃないと音が良くなかったり、悪くなる場合があるが、libsamplerateは指定した周波数どおりに音質が上がっていく。そういう仕組みなのだ。

「audio_output_format "384000:32:2"」に。
かなり良くなる。普段、聴いている音にかなり近い、というか、機材をSM-SX100とADI-2 DACにしたら、もう少しHiFi度が上がる。Brooklyn AMPとPegasusは、ややざっくばらんな感触だ。

想定内というか、やっぱりそうだよな、という結果だった。
以前に比べたら、ノイズ対策も増やしているので、もしかしたらアップサンプリング無しと有りとで、音質の差が縮まっていたりしないかな、と思ったんだけど、そんなことはなかった。

今後、アップサンプリングをしないとして、
１．更なるノイズ対策や電源の強化を行えば、今の機材でも44.1/16の音をハイレゾのように鳴らせる
２．更なるノイズ対策や電源の強化を行っても、今の機材では44.1/16の音をハイレゾのように鳴らせない

３．機材を良くしたら、それだけで、44.1/16の音をハイレゾのように鳴らせる
４．機材を良くして、更なるノイズ対策や電源の強化を行えば、44.1/16の音をハイレゾのように鳴らせる
５．機材を良くして、更なるノイズ対策や電源の強化を行っても、44.1/16の音をハイレゾのようには鳴らせない

さて、どれだろう。
どれでもいいっちゃ、いいんだけど。うちでは当面は今の機材でアップサンプリングして鳴らすだろうから。

前回のエントリーでは、TC64-11.1 mpdサーバーをHP Probook 450 G9で動かした。
どこまでやれるか試しているのだが、ここで問題がある。

カタログ上、450 G9のCPUは最高4.9GHzで動く筈だが、3.7GHzまででしか動いてくれない。
インテルのCPUにはターボ・ブースト・テクノロジーというのがあって、負荷がかかると自動的にクロック周波数を上げるのだけど、それが充分に機能してない？ようなのだ。
原因が分からない。

ネット上で調べたところ、原因として考えられるのは、熱の問題、電力の問題、BIOSのバグ、これらは該当しないだろう。
あと、AVX2、AVX-512のような遅いSIMDがクロックを下げるとか。
これはよく分からない。アクティブなコアが増加するとクロック周波数の上昇率が下がるということらしいが、mpdサーバーで動いているプロセスは少ない。
ほとんどのコアは仕事をしてないようにすら見えるので、これも違う気がする。

うちのmpdサーバー EliteBook 820 G2の状況をメモ。

tc@box:~$ grep MHz /proc/cpuinfo
cpu MHz		: 2886.755
cpu MHz		: 2831.833
cpu MHz		: 2697.611
cpu MHz		: 2694.282

tc@box:~$ cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor
powersave
powersave
powersave
powersave

tc@box:~$ grep 'model name' /proc/cpuinfo
model name	: Intel(R) Core(TM) i5-5300U CPU @ 2.30GHz
model name	: Intel(R) Core(TM) i5-5300U CPU @ 2.30GHz
model name	: Intel(R) Core(TM) i5-5300U CPU @ 2.30GHz
model name	: Intel(R) Core(TM) i5-5300U CPU @ 2.30GHz
tc@box:~$ 

powersaveで動いている。
CPUは2.30GHzだが、動くときには2.8GHz以上で動いている。i5-5300Uのターボ・ブースト利用時の最大周波数は2.90 GHzであり、ブーストが機能している。
（powersaveでもブーストは効くんだね）

そういうわけで、Probook 450 G9のi7-1255Uでターボ・ブーストが機能しない？のが残念な状況だ。
正直、買って試してみないと分からないな、というのはあったので想定内といえばそうなんだけど、820 G2で動いてるんだから多分いけるだろう、と甘い判断をしたわけだ。、、

Probook 450 G9をmpdサーバーとして動かしてみたときの状況。

tc@box:~$ grep MHz /proc/cpuinfo
cpu MHz		: 2608.375
cpu MHz		: 2643.276
cpu MHz		: 3700.000
cpu MHz		: 3700.000
cpu MHz		: 820.543
cpu MHz		: 1357.115
cpu MHz		: 2889.705
cpu MHz		: 1141.198
cpu MHz		: 2205.000
cpu MHz		: 2569.790
cpu MHz		: 1859.254
cpu MHz		: 888.040

tc@box:~$ cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor
powersave
*snip*

tc@box:~$ grep 'model name' /proc/cpuinfo
model name	: 12th Gen Intel(R) Core(TM) i7-1255U
*snip*

tc@box:~$ 

こんな感じで3.7GHzが上限になっている様だ。なんでかねえ、、、

https://www.intel.co.jp/content/www/jp/ja/products/sku/226259/intel-core-i71255u-processor-12m-cache-up-to-4-70-ghz/specifications.html
インテル® Core™ i7-1255U プロセッサー

上記のインテルのサイトによると、
Performance-coresの数　2、Efficient-coresの数　8
Performance-core最大ターボ・フリークエンシー　4.70 GHz
Efficient-core のターボ・ブースト利用時の最大フリークエンシー　3.50 GHz
とある。

https://xtech.nikkei.com/atcl/nxt/column/18/02268/111800001/
最新のインテルCPU、第12世代Coreシリーズは何が違うのか
日経クロステック 2022.12.12

上記記事によると第12世代のインテルCPU、つまりi7-1255Uは、PコアとEコア、2種類のコアを積んでいると。
高い性能が必要な処理はPコア、負荷は低いが常時実行するような処理はEコアが向いているそうだ。
性能を重視した従来のCPUコアがPコアであり、性能よりも電力効率を重視したのがEコアで物理的サイズはPコアの4分の1と。
そんな構造なので、スレッドごとの処理を適切なコアに割り振る「スレッド・ディレクター」というのがCPUに組み込まれていて、負荷が高い処理はPコアに振り分けされるらしい。

実際、topでの挙動を見ると、mpdの処理は専ら「CPU0」と「CPU2」、２つのスレッドが代りばんこに受け持っているようだ。CPU0～3がPコアのスレッドなのかな。
これは、４つのスレッド全てでリレーする、820 G2のi5-5300Uの挙動とは異なる。
しかしそれなら、4GHz以上で動いてもいいと思うのだが、、、

ネット上を調べていたら、CPUの動作クロックを設定する「cpufreq」というツールがあり、Tiny Core 11では「cpupower.tcz」という形でリポジトリ上にあるらしいということが分かった。
インストール。

tc@box:~$ cpupower
Usage:	cpupower [-c|--cpu cpulist ]  []
Supported commands are:
	frequency-info
	frequency-set
	idle-info
	idle-set
	set
	info
	monitor
	help

Not all commands can make use of the -c cpulist option.

Use 'cpupower help ' for getting help for above commands.

tc@box:~$ cpupower frequency-info
analyzing CPU 0:
  driver: intel_pstate
  CPUs which run at the same hardware frequency: 0
  CPUs which need to have their frequency coordinated by software: 0
  maximum transition latency:  Cannot determine or is not supported.
  hardware limits: 400 MHz - 4.70 GHz
  available cpufreq governors: performance powersave
  current policy: frequency should be within 400 MHz and 4.70 GHz.
                  The governor "powersave" may decide which speed to use
                  within this range.
  current CPU frequency: Unable to call hardware
  current CPU frequency: 405 MHz (asserted by call to kernel)
  boost state support:
    Supported: yes
    Active: yes
tc@box:~$ 

tc@box:~$ sudo cpupower frequency-set -g performance
Setting cpu: 0
Setting cpu: 1
Setting cpu: 2
Setting cpu: 3
Setting cpu: 4
Setting cpu: 5
Setting cpu: 6
Setting cpu: 7
Setting cpu: 8
Setting cpu: 9
Setting cpu: 10
Setting cpu: 11

tc@box:~$ cpupower frequency-info
analyzing CPU 0:
  driver: intel_pstate
  CPUs which run at the same hardware frequency: 0
  CPUs which need to have their frequency coordinated by software: 0
  maximum transition latency:  Cannot determine or is not supported.
  hardware limits: 400 MHz - 4.70 GHz
  available cpufreq governors: performance powersave
  current policy: frequency should be within 400 MHz and 4.70 GHz.
                  The governor "performance" may decide which speed to use
                  within this range.
  current CPU frequency: Unable to call hardware
  current CPU frequency: 657 MHz (asserted by call to kernel)
  boost state support:
    Supported: yes
    Active: yes
tc@box:~$ 

tc@box:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
performance

「powersave」を「performance」に変更。
これで、CPUがパフォーマンス優先にセットされた。

これでどうかというと、やはり、3.7GHzまで。
どうしたものかな、と思いながら使っていたら、ときに3.7GHzより少し上が出る。コンスタントには出ない。しかし、どうやら出せないわけじゃないんだろうなと。

そこで、BIOS関係で節電に関する設定を調整してみることにした。

ネット上に公開されているHPのマニュアルから引用。
HP PC Commercial BIOS (UEFI) Setup
Administration Guide
For Commercial Platforms using HP BIOSphere Gen 7-9 2020 -2022

しかし設定できる項目が少ない。こんなもんなのかなあ。
ネット上の日本語マニュアルは古いので英語の方を読む。日本語版には書いてないようなことが書いてある。

とりあえず、下記のように設定してみた。

設定変えたら、ほとんど動いていなかったEコアたちが一斉に動きだし、音が途切れるように。
Pコアに重要な仕事を降るということをしなくなったようだ。
変更した設定を戻していく。
Power Controlを「on」に。

Pコアに仕事を降るようになった？ようだが、それでも音が途切れる。

tc@box:~$ cpupower frequency-info
analyzing CPU 0:
  no or unknown cpufreq driver is active on this CPU
  CPUs which run at the same hardware frequency: Not Available
  CPUs which need to have their frequency coordinated by software: Not Available
  maximum transition latency:  Cannot determine or is not supported.
Not Available
  available cpufreq governors: Not Available
  Unable to determine current policy
  current CPU frequency: Unable to call hardware
  current CPU frequency:  Unable to call to kernel
  boost state support:
    Supported: no
    Active: no
tc@box:~$ 

tc@box:~$ grep MHz /proc/cpuinfo
cpu MHz		: 841.518
cpu MHz		: 1462.869
cpu MHz		: 1700.000
cpu MHz		: 1703.346
cpu MHz		: 634.992
cpu MHz		: 1034.485
cpu MHz		: 1013.223
cpu MHz		: 1197.852
cpu MHz		: 1119.194
cpu MHz		: 977.032
cpu MHz		: 1196.461
cpu MHz		: 1198.542
tc@box:~$ 

なんか、すごく上手くいってないっぽい。IntelのCPUだという認識が出来ていない。
クロック周波数も上がっていない。

Runtime Power Managementを「on」に戻す。
Power Controlを「off」に。
これで、まともに音が出るようになった。

tc@box:~$ cpupower frequency-info
analyzing CPU 0:
  driver: intel_pstate
  CPUs which run at the same hardware frequency: 0
  CPUs which need to have their frequency coordinated by software: 0
  maximum transition latency:  Cannot determine or is not supported.
  hardware limits: 400 MHz - 4.70 GHz
  available cpufreq governors: performance powersave
  current policy: frequency should be within 400 MHz and 4.70 GHz.
                  The governor "powersave" may decide which speed to use
                  within this range.
  current CPU frequency: Unable to call hardware
  current CPU frequency: 966 MHz (asserted by call to kernel)
  boost state support:
    Supported: yes
    Active: yes

tc@box:~$ sudo cpupower frequency-set -g performance
Setting cpu: 0
Setting cpu: 1
*snip*

tc@box:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
performance
tc@box:~$ 

これで700kHz台を出そうとしたが、やはり10秒ほどでぶちぶち途切れる。
300kHz台だと問題なく音が出る。
音が出ているときのCPUのクロック周波数の上限は3.7GHz付近で変わらない。
まともに音が出ていないときは、クロック周波数も上がっていない、ということがある。ここの辺り挙動が謎だ。

ちょっと気になったのが、BIOSの説明書に出てきた「IPM+」というもの。
電源管理を行うソフトらしい。
Windowsで起動したら設定できるらしいので、セキュリティブートを有効にしてWindowsを起動し確認してみたら、インストールされていないようだったので、ほっとくことにする。

結局、BIOSの電源関係はあまり関係ないように思われた。

もしかして、Tiny Core OSの問題？とも思ったりもするが、調べてもはっきりしないし、確信もない。

この件は、当面、保留である。

そういうわけで、HP Probook 450 G9 mpdサーバーは、libsamplerateの設定を「Best Sinc Interpolator」、アップサンプリング設定を384kHzで動かしている。

そこそこ余裕を持って動いているように見える。
というのは、topで見るとmpdを担当するCPU0、CPU2、2つのスレッドがともに休んでいる時間がそこそこ見えるからだ。
比較したら、820 G2でMedium、768kHzで動かす方がもっと余裕がある挙動で動く。
Bestの設定は、やはり相当、重いのだと思う。

音はそれに見合うものがあると思うのだけど、音質の確認は流し聴きだけで、十分にはしていない。
音源によってはリアリティがMedium、768kHzより高いと思う。
Medium、768kHzと、Best、192kHzだと、どっちがいいかは好みにもよるかも、みたいな感じだった。これらも真剣に比較しないまま今に至ってるんだけど、Best、384kHzは、それらの水準を超えると思う。

今後、余裕がある時に確認していこうと思う。
課題はいろいろ残っているけど、無理せず、焦らず、という感じ。

前回、libsamplerateの「Best」の設定で音を出すことが出来たというエントリーをアップした。
その後で、ふと我に返る。
192kHzって、ふつーにハイレゾだよなあ、、、

うちのシステムは、CDクラスの音源を768kHzという、いうなればスーパーハイレゾに変換して鳴らすというのが目玉である。
今迄、そうすることでCD音源の音をより良い音で聴くことが出来ると考えていた。CD音源そのままの44.1/16から本来の音を引き出すのは結構大変だという認識で、アップサンプリングする方が引き出し易いだろうという考えでやってきている。
しかし、普通のハイレゾレベルへのアップサンプリングなら、普通にハイレゾ購入してそのまま鳴らすほうが、たぶん良いのではないか。

まあ、CD音源しかないんだよという音源もあるし、Deezer HiFiにハイレゾレベルの配信を期待するわけにもいかないので、意味はあるっちゃあるんだけど。
そんなことを考えながら、Best Sinc Interpolator:192kHz で聴いている。

情報量の比較は出来ていない。
しかし微弱な音とか、倍音成分が聴こえ方にデリケートに影響する音源は、明らかに良いような気がする。
アタックの立ち上がりとか余韻が綺麗。
Medium:768kHzよりも、繊細かつ芯が通った音色という印象。
比べたら、Best:192kHzのほうが、しなやかで柔らかく精密なのだ。

前回のエントリーをアップしたときと、評価がずいぶん変わってしまった（あのときは、短時間の印象だけだったから、、、評価は軽々しくするものではないな、、、）。
しかし、これは、まいったな、、、

libsamplerateで700kHz台にアップするより、普通にハイレゾ鳴らす方が良いということになる。
以前、300kHz台のハイレゾと、CDと同クラスの音源をアップサンプリングしたのとを比較したことがある。当時は、殆ど差がないと判断した。僅差でブラインドでは全く分からないと感じた。
http://blown-lei.net/endive/blosxom.cgi/audio_diary/20170625a.htm
libsamplerateの設定も「Fastest」、それでも充分な性能と判断したのだ。
でも、5年も前のことになるのね、、、
当時、44.1＜96＜192＜384だった。その後、384＜768で、今に至る。

それが、今回、ひっくり返った。
Medium:768kHzのアップサンプリングよりも、Best:192kHzのアップサンプリングのほうが良いということなら、それよりも192kHzのハイレゾファイルの方が良いだろう。それが順当だ。
5年前と今と、何が違うんだろう。

5年前のシステムは、Raspberry Pi2、moode audio3.1 + i2sDACでアップサンプリングしていた。NAS音源も使っていたが、高音質を目指すときはRAMメモリ再生という方式。
ハードもソフトも現在とはずいぶん違う。
ということは、当時してみたことを、今のシステムでもう一度やってみるべきかな。
そして、出力形態の違いでどのように音が変わるのか、確認する必要がある。

高域が正確に再生されるかどうかは、音声再生全体に影響する。
libsamplerateの設定で、Best、Medium、Fastestの違いによって、リサンプリングに際しての高域減衰に差が生じる。
以下、引用。

http://www.mega-nerd.com/SRC/api_misc.html#Converters

SRC_SINC_BEST_QUALITY - This is a bandlimited interpolator derived from the mathematical sinc function and this is the highest quality sinc based converter, providing a worst case Signal-to-Noise Ratio (SNR) of 97 decibels (dB) at a bandwidth of 97%.
All three SRC_SINC_* converters are based on the techniques of Julius O. Smith although this code was developed independantly.

SRC_SINC_MEDIUM_QUALITY - This is another bandlimited interpolator much like the previous one.
It has an SNR of 97dB and a bandwidth of 90%.
The speed of the conversion is much faster than the previous one.

SRC_SINC_FASTEST - This is the fastest bandlimited interpolator and has an SNR of 97dB and a bandwidth of 80%.

Bestの設定はリサンプリングに伴う高域の減衰が小さい（大雑把な言い方だが）。
以前はFastestの設定で使っていて、高域の減衰は大きい。その状況でハイレゾファイルと比較して、再生音に差はほぼ無いと思えた。つまり、そのときは高域の差異に伴う音の違いは、殆ど聴き取れなかったのだ。
恐らく、実際に音が違っているのに聴き取れなかったのではない。両者の再生音の高域に差が無かった可能性の方が高い。

どうして差が生じなかったのか。
ハイレゾファイルの再生が、適切に出来ていなかったのかもしれない。
考えられる原因は、ジッターだ。
再生環境のジッターが影響し、ハイレゾファイル再生の高域が劣化した。
アップサンプリングの方は劣化しないのかというと、既に高域が減衰しているので、受ける影響が少なかったのではないか。
結果的に両者の差が僅差となったのではないか。つまり、再生された音声が劣化していたために区別がつかなくなっていた可能性がある。

そして、再生音が劣化したハイレゾ音源よりも700kHz台にアップサンプリングした音の方が良くなった。
サンプリング周波数が上がっていくのと平行して、ノイズ対策や電源、GNDへの手入れが行われ、PPAPの構成も進化し、恐らくは、ジッターへの耐性も5年前よりも向上した。
そうした変化によって、以前はジッターの影響で劣化していた高域特性が改善してきた。
以前よりも、音源の素性が再生音に反映されるようになっているのではないか。

以上、仮説だ。

専門家は、ジッターはおそらく聴き取れないだろうと言う。
https://www.tonmeister.ca/wordpress/2018/08/30/jitter-part-9-when-do-i-care/
たしかに明確にこの音がジッターだと特定するのは難しい。

しかし、ジッターによる音質劣化はかなりのもので、聴き取れる場合も多いと思う。
例えば、80年代のCDプレーヤーで再生した時は冴えない音しかしなかったCD音源が、今の再生環境ではそれなりの音で鳴ることが珍しくない。ジッターへの対処が30年で進歩しているのだ。あの冴えなさ具合を考えたら、ジッターの影響でハイレゾファイルの再生音が僅かに劣化することなど、十分に有り得ると思う。
プレーヤーが安物だったからだろうって？
確かにその可能性は、否定できないのだが。

主旨は違うけど、サンプリング周波数をあれこれ変えて視聴するという試みを2年前にしている。
http://blown-lei.net/endive/blosxom.cgi/audio_diary/20200524a.htm
CD音源アップサンプリングなしの音質について、仮想アースを使う方が相当良いみたいなことを書いている。
当時は気付かなかったが、たぶん、この時点でも以前とは違っていたのだろう。

あれこれ試聴したとしても、たぶん今更、裏付けは取れない。
でも現在の状況確認は必要だ。

しかしだ、、、これって、体力いるんだよね、、、ゆっくりやるつもりだ。

うちのオーディオの音に、現状、全く不満はない。
しかし不満がないからといって、問題がないわけではない。

明らかな弱点はある。
例えば低音、JBL 4425mk2はバスレフ形式で若干緩い感触があるが35Hz〜20kHz(-6dB)と、体躯の割に低い音域まで出る。8畳の部屋で鳴らしていた時は30Hzが出ていた。しかし部屋が広くなってそこまでは出なくなり、Waltz for Debbyの地下鉄が聞こえなくなった。
部屋の作りのせいで室内音響は左右差があって、だから音像定位は合格点は出せない。
こうした欠点も、僕の要求水準が低いから放置で済んでいる。

要求水準が低いと言ったが、容易に手を出すことができない、というのもある。
現状以上の低音が欲しかったら、もっと大きいスピーカーが必要だし、部屋のレイアウトは変えられない。

うちのサイトがPCオーディオ関係のエントリーばっかりなのは、容易に出来る音質改善策だったからというのが大きいと思う。
経済的にも大きなことにならない。といいながら、PCトランスポートを構成するのにうちではPCが5台動いている。apu2が2台と中古ノートPCが3台、トータルで10万以上はかかっている。それに気付いたら、そんなに安価というわけじゃないのか、とも思ったけど、それでこの音なのだから十分に安いとも思う。

これ以上、することはないか、、、
そういう視点でうちのシステムを見ていて、ふと気付いたのが、エントリーのタイトルにしたようなことだった。
これはmpdのアップサンプリング設定だ。
つまり「libsamplerate」で「PCへの負荷が最高となる設定」だったら、どんな音質を引き出せるのかという、これは考えてみたら、Secret Rabbit Code (a.k.a. libsamplerate) を6年前に使い始めてから、ずっと手を付けないままにしていた宿題なのだ。

今まで手を付けなかったのは理由もある。
というのは「Best Sinc Interpolator」で設定して、mpd + libsamplerateを動かすと、まともに音が出ない。

libsamplerateの設定は、Best、Medium、Fastest、ZOH、Linearの5段階。
これらのうち、音質の優位性が得られる設定はBest、Medium、Fastest の３つである。
参考url
Music Player Daemon documentation » Plugin reference
https://mpd.readthedocs.io/en/stable/plugins.html#libsamplerate
Secret Rabbit Code (aka libsamplerate) - Miscellaneous API Documentation
http://www.mega-nerd.com/SRC/api_misc.html#Converters

Best、Medium、Fastestの設定でmpdを動かすには、負担に耐えられるスペックがPCに要求される。

ZOH、Linearの設定は、かなり低スペックなPCでも動く。
しかしあんまり使う意味はない。
現在のうちの環境では、音質悪化する（以前にアップしたジッターの説明サイトでも、実装が悪いASRCでは往々にしてそういうことが起きると書いてある）。
こうした設定で音質が改善するとしたら、デジタル信号伝送の環境が悪いということがあるので、よくよく見直した方がいい。昔のことだが、うちではNASが壊れかけていたときに、こうした低品質な設定で音が良くなったことがあった。

6年前、うちで使っていたPCトランスポートはRaspberry Pi2だった。
mpdのlibsamplerateのデフォルト設定は「Fastest」で、比較的、負担が少ない設定となっている。それでもRas Pi B+にとっては負担が大きくて無理で、Ras Pi2でようやく可能になった。当時はBestどころかMediumの設定も、PCへの負担が大きくて使えなかったのだ。

それが、アップサンプリングのサンプリング周波数を上げるにはPCトランスポートのスペックを上げざるを得なかった。
Raspberry Piからapu2、ノートPCへとスペックを上げて、768kHzへのアップサンプリングが可能となって、気が付いたら、Mediumの設定が使えるようになっていた。
使えるようになって比較したら、FastestよりMediumのほうが音色が濃厚で厚みがある。以降、うちでの設定は変更になった。Phile webに日記をアップしてレスをもらったのが切っ掛けで気付いたので、ほぼ1年前のことになる。

実は最近、気付いたことがある。
CDをうちのシステム（USB-DVDドライブからmpdに読み込む）で鳴らしていると、特定のCDで音が途切れることがある。Mediumの設定をFastestに変えたら途切れなくなる。
つまり、Mediumの設定でCDを鳴らそうと思ったら、スペックが僅かに足りていないのだ。
mpdサーバーのスペックを上げるに越したことはない。

現在、mpdサーバーを担当しているのは、HP EliteBook 820 G2。
過去の経験からは、最も重要なのはメモリのスピードという認識。
820 G2のメモリは、DDR3L-1600。
メモリクロック:200MHz、バスクロック:800MHz、転送速度:12.800GB/s、データ転送速度:1,600MHz、ということらしい。
参考：
https://ja.wikipedia.org/wiki/DDR3_SDRAM
https://ja.wikipedia.org/wiki/DDR4_SDRAM
見れば全部わかるDDR4メモリ完全ガイド、規格からレイテンシ、本当の速さまで再確認
https://akiba-pc.watch.impress.co.jp/docs/sp/1231939.html

CPUは「less /proc/cpuinfo」で確認した。
Intel(R) Core(TM) i5-5300U CPU @ 2.30GHz、2コアだけどスレッドは4（topから見たらCPUが4個と認識される）。
しかし正直、CPUにどの程度のスペックが必要なのかは、よく分からない。

sshからmpdサーバーにログインしてtopで状況を確認していく。libsamplerateの設定はMedium。
mpdのCPU使用率は、0%から25%を変動する。平均は12～16%ぐらい。
1キーで、CPUのスレッドを表示。
音声信号処理の負担がかかっているスレッドが、数秒で切り替わっているようだ。基本的に演算処理は1つのスレッドが担当し、同時並列で複数のスレッドが演算を分担することはないようだ。一度に動くスレッドが４つのうち１つなので、CPU使用率が最大25%ぐらいまでということかな（つまり、そのスレッドとしては100%使い切っているということだ）。
mpdサーバーは、mpdを動かしてるだけではなく、daphileサーバーやPPAPサーバーとも連携しないといけない。スレッド4つは最低欲しい（2つだとなんだか危なっかしい気がする）。
メモリはというと、使用量はそんなに多くない。8GB積んでいるけど使っているのは500MB程度だ。

libsamplerateの設定を「Best」にしてみる。
音を出すと、音が出るのに10秒近くかかる。数秒間だけ音が出た後、途切れ途切れになってしまう。
topでみたら、mpdのCPU使用率が25%に貼り付いている。つまり、最大限使っている。そして、スレッドが切り替わらない。切り替わるのに数10秒かかる。たぶん演算処理が追いついていないのだ。
メモリの状況は、Mediumのときと変わらない。

しかし、数秒間の音は、悪くはなかった。
ちゃんと鳴らすにはもっと速いPCが必要。

どんな機種にするか、、、
今までのようにノートPCの中古にするか、いっそのことミニPCにするか。
ミニPCのほうが安価だ。しかしミニPCの場合、メモリのスペックがなかなか調べても分かりにくいということがある。DDR4までは分かっても、クロックや速度が分からないままで売られていることが多い。あと、BIOSを触ろうと思ったらモニターとキーボードを用意する必要がある。まあ、すりゃあいいじゃんと言われたらその通りなのだけど、、、面倒だ。そこについてはノートPCのほうが扱いやすい。ましである。

とりあえず扱い易さを優先して、中古ノートPCにした。
機種は、HP ProBook 430 G5。
CPUはCore i5 7200U。定格クロックが2.50GHz、第7世代なのかな。
メモリーは8GB。DDR4 PC4-2400が標準だけど、第7世代CPU以前だと2133で稼働するらしい。どうなんだろこれは。
参考：
インテル® Core™ i5-7200U プロセッサー
https://www.intel.co.jp/content/www/jp/ja/products/sku/95443/intel-core-i57200u-processor-3m-cache-up-to-3-10-ghz/specifications.html

結果。
820 G2より僅かにマシだけど、やはり同様に音が途切れて使えない。
topを打つと、CPUの使用率は4スレッドのCPUで25%。使いきっている。「less /proc/cpuinfo」を打つと「cpu MHz : 3100.001」と表示。Core i5 7200Uは最大クロックで動いているようだが、足りていない。

途中で音が切れるのは、メモリよりもCPUの速度が足りないのかもしれない。3GHzでも遅い。
速いCPUを調べてみたが、ノートPC用だと定格クロックは3GHz台が殆んど。最大クロックだと4GHz台以上に届くのがあるけど、どうなんだろうか、そういうのって。
PassMarkという数値が高いCPUはたくさんあるけど、そういうのはコア数やスレッド数が多い。mpd+libsamplerateは1スレッドを占有し音声信号処理に充てる。つまりスレッド数を増やして性能を上げているCPUは、たぶんあんまり意味がない。1スレッドで、どれだけのパフォーマンスを出せるかが重要な筈。

そんな中で気になったCPUをいくつかメモ。
Intel Core i3-12300、i7-10610U、i3-1115G4、、、まだまだある。最大クロック4GHz台で動くCPUだ。
そして、そういうのが載ってるノートPCは高い。中古も高い。じゃあ、mini PCでどうかとなると機種がない（探すのが下手なのかもしれない）。あっても売り切れてるし、今まで買ってきたのと比べたら高い。

あと、今回の試行で、一点、Tiny Coreのほうに問題が見付かった。
現在運用しているmpdサーバーで動いているシステムは、ProBook 430 G5では起動しない。
EFIというのが入ってないためだ。
仕方ないので、TC64 11.1から移植して何とか起動。しかしf9キーから入ってブートローダーを選択しないといけないし「Wrong EFI」と表示が出る。
TinyCorePure64-13.1そのものからだと、そんな面倒しなくてもUSB起動優先の設定さえしておけば、起動ボタンを押すだけでそのまま起動するので、ブートローダー周りの問題なのだろう。
普通に使えるのを作らないと、再起動が簡単にできないので、システムに組み込みにくい。

ハードルが高い、、、

ここでふと、768kHzだから出来ないんじゃね？と思い至る。
430 G5で、設定を192kHzにしてみたら、比較的スムーズに音が出た、、、、、

topコマンドで状況を確認。
mpdのCPU使用率は、0から25%を変動し、平均はだいたい10%台。メインシステムでMediumの設定で使っているときと同じような挙動だ。そこそこ余裕がある。
スレッドも切り替わる。というか、4つのスレッド全てが0%という瞬間がそこそこあって、スレッドの切り替わりはあるけど、ゆっくりと切り替わる。かなり余裕を持って動いている、、、
これなら安定して使えそうだ。

なんだ、、、Best Sinc Interpolator、できたじゃん！

音は、いい。
ある意味、良いのは当たり前だ。PPAPで直結してるんだから。
Medium:768kHzと比べて、どうなのかというのが問題、、、なんだろうか。

ここまでやってなんだけど、どっちでもいいやん、という気分で、本気の聴き比べは、出来ていない。
ちなみに、384kHzだとぎりぎりで、ノイズが入り、数10秒鳴った後で音が途切れ始めた。もう少しスペックを上げたら384kHzで鳴らせそうだ。
そんなギリギリ状態の384kHzの音よりも、安定している192kHzのほうが良かった。
しばらく鳴らした感じでは、Best:192kHzよりも、Medium:768kHzのほうが良さそうだとは思ったけど、、、ちゃんと比較して、各々の傾向が見えてきたら、意外に面白いことがあるかもしれない、という印象だ。しかし、僕の駄耳でははっきりしたことは分からないかもしれない。
音の表面の感触が違う気がする。
Medium:768kHzのほうが明らかに細かい音が聞こえるんだけど、Best:192kHzのほうが、甘い、気がする。

まあ、今は深く追求はしない。
Bestの尻尾を掴むことができたところで良しとしようと思う。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ストリーミング音源利用に際して懸案だった、CDレベル音源のlibsamplerateによるアップサンプリングが、一応出来たので、備忘録にしておく。

そこそこ梃子摺ったけど、出来てみればそんなに複雑でもない。
ただ、作業行程で何が足りないのか推測し繰り返し試みないといけなかったので時間がかかった。まあ、僕の手際が悪いんだけど。
なにしろ、ログを読んでも何が足りないとかいけないとか、簡単に分からない。基本的なlinuxの知識が少ないので、初歩的なことを書いているのに気付かず、躓いたまま苦心惨憺の後に気付いたり、ということが多々ある。気付くまでログのあっち読んだりこっち読んだり、あれやったりこれやったりになるのだ。はっきりエラーと明言されていない記述も注意する必要があって、気付いたらそんなことだったのかなんだけど。
そういうときは、もしかして、この記述が怪しいのかな、ポイントなのかな？という、感が頼りになってくる。例えばログの中に「capability」という言葉があって、capability？、、cap?、、libcapというのが要るのかな？、、という感じで追い込む。
コンピューターをいじってるのにそんなんでいいのかという感じだ。

最初はpiCore 9で試みたが上手くいかず、tiny core 64 11.1で作っている。
そもそも、本気でアップサンプリングするならraspberry pi2とかだと限界がある。
ともあれ、以下、手順の要約。

tiny core pure 64 11.1のインストール行程を最初からなぞるのは面倒だったので、PPAP Frontを作る際のベースに使って、バックアップを保存していたディスクイメージを使うことにした。これをSDカードに書込み、Compaq 6730bに刺して起動、sshでログインしbulseaudioサーバーの環境を作っていく。

まず、tceコマンドで足りないライブラリ等をインストール。
alsa関連を足りないことがないように拡充、libcap関連、dbus関連を追加。
あと、以下に経過を記録。

wget http://freedesktop.org/software/pulseaudio/releases/pulseaudio-13.0.tar.xz
tar -xf pulse*xz
cd pulseaudio-13.0

./configure --disable-x11 --enable-alsa --enable-samplerate
make
mkdir ../pulseaudio
sudo make DESTDIR=/home/tc/pulseaudio install

cd

mksquashfs pulseaudio pulseaudio-13.0.tcz
md5sum pulseaudio-13.0.tcz > pulseaudio-13.0.tcz.md5.txt

sudo cp *tcz* /mnt/*2/tce/optional
sudo vi /mnt/*2/tce/onboot.lst
(pulseaudio-13.0.tcz)

wgetでpulseaudio-13.0をダウンロード。
展開しディレクトリに入る。alsaとsamplerate（libsamplerate）は使えるように、x11は使わない設定で、インストール。
tczファイルなど作成し、optionalディレクトリにコピー、onboot.lstにOS起動時読み込みの設定を書き込み。

これで、pulseaudio-13.0をインストール終了。
この時点でのインストール済みのtcz一覧は、下記アドレスのファイルに記載。ずいぶん沢山入っている。本来なら要らないものも多く入っていると思う。
http://blown-lei.net/blog/pulseaudio-optional-tcz.txt
onboot.lstは下記のとおり。

less /mnt/*2/tce/onboot.lst

openssh.tcz
i2c-5.4.3-tinycore64.tcz
nfs-utils.tcz
alsa-modules-5.4.3-tinycore64.tcz
alsa.tcz
nmap.tcz
gcc.tcz
boost-1.65-dev.tcz
pkg-config.tcz
bison.tcz
autoconf.tcz
libtool-dev.tcz
bc.tcz
cmake.tcz
compiletc.tcz
squashfs-tools.tcz
ntpclient.tcz
libsamplerate.tcz
libsamplerate-dev.tcz
lame.tcz
lame-dev.tcz
libmad.tcz
libmad-dev.tcz
alsa-plugins-dev.tcz
alsa-config.tcz
alsa-dev.tcz
libcap.tcz
libcap-dev.tcz
dbus-dev.tcz
pulseaudio-13.0.tcz

こんな環境に出来上がった。
pulseaudioサーバーを設定していく。

mkdir .pulse
cp pulseaudio/usr/local/etc/pulse/default.pa .pulse
cp pulseaudio/usr/local/etc/pulse/daemon.conf .pulse

rm -rf pulseaudio*

ホームtcディレクトリに「.pulse」ディレクトリを作成。
設定ファイル「default.pa」と「daemon.conf」をソースからコピー複製し「.pulse」に設置。
インストールに使った残骸は「rm -rf」で削除。
設定ファイルの内容を、使用環境などに合わせて下記の通り変更。

vi .pulse/default.pa

#load-module module-native-protocol-tcp
load-module module-native-protocol-tcp auth-ip-acl=127.0.0.1;192.168.1.0/24

vi .pulse/daemon.conf

; resample-method = speex-float-1
resample-method = src-sinc-fastest

; default-sample-rate = 44100
; alternate-sample-rate = 48000
default-sample-rate = 192000
alternate-sample-rate = 192000

; default-sample-format = s16le
default-sample-format = s32le

以前のエントリーに書いたけど、module-native-protocol-tcpを設定することで、クライアントからの信号を受ける事ができるようになる。 src-sinc-fastestはlibsamplerateの設定。USB-DACの状況に合わせて記載。

filetool.sh -b
sudo reboot

設定を保存。リブート。

再度、sshでログインし、試用を開始。使えるリサンプラーを確認する。

tc@box:~$ pulseaudio --dump-resample-methods
src-sinc-best-quality
src-sinc-medium-quality
src-sinc-fastest
src-zero-order-hold
src-linear
trivial
speex-float-0
speex-float-1
speex-float-2
speex-float-3
speex-float-4
speex-float-5
speex-float-6
speex-float-7
speex-float-8
speex-float-9
speex-float-10
speex-fixed-0
speex-fixed-1
speex-fixed-2
speex-fixed-3
speex-fixed-4
speex-fixed-5
speex-fixed-6
speex-fixed-7
speex-fixed-8
speex-fixed-9
speex-fixed-10
ffmpeg
auto
copy
peaks
tc@box:~$ 

src-sinc-best-quality、src-sinc-medium-quality、src-sinc-fastest、と表示がある。
libsamplerateは使えるはずだ。

さて、鳴らしてみましょうか、、、「pulseaudio -D」で起動し、クライアントのfirefoxから音声信号を伝送する。
さっそく、音がでない。「top」を打つと、pulseaudioは仕事をしている様子。
状況は？

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

tc@box:~$ pactl list sinks
Sink #0
    State: RUNNING
    Name: auto_null
    Description: Dummy Output
    Driver: module-null-sink.c
    Sample Specification: s32le 2ch 192000Hz
    Channel Map: front-left,front-right
    Owner Module: 13
    Mute: no
    Volume: front-left: 65536 / 100% / 0.00 dB,   front-right: 65536 / 100% / 0.00 dB
            balance 0.00
    Base Volume: 65536 / 100% / 0.00 dB
    Monitor Source: auto_null.monitor
    Latency: 206 usec, configured 500 usec
    Flags: DECIBEL_VOLUME LATENCY
    Properties:
        device.description = "Dummy Output"
        device.class = "abstract"
        device.icon_name = "audio-card"
    Formats:
        pcm
tc@box:~$

Name: auto_null、Description: Dummy Output、って、何？。
alsaはdacを認識しているが、pulseaudioは認識していない。
というか、クライアントから送られてきた信号が何処かに消えていくように設定されてるらしい。

原因は不明。多分何処かでミスってるのだろう。普通は自動的に読み込まれるのでハードの設定はpulseaudioではしなくていいものらしい。
しかしそんなことは言ってられないので、下記のように設定する。

vi .pulse/default.pa

#load-module module-alsa-sink
load-module module-alsa-sink device=hw:0,0

aplay -lで、「card 0: IncRAL2496UT1 [//], device 0: USB Audio」なので、hw:0,0だ。
これでどうか。

tc@box:~$ pactl list sinks
Sink #0
	State: RUNNING
	Name: alsa_output.hw_0_0
	Description: RATOC Systems, Inc.RAL-2496UT1_
	Driver: module-alsa-sink.c
（... 以下略 ）

一応、認識した、、、
pulseaudioを再起動して、信号伝送すると、、、音が出た。
ようやく一息、これで、なんとかなるのかな？

取り敢えず現状、音質は後回しで、ちゃんと運用できる事が優先なんだけど、いくつか問題が。

まず、192kHzだとブツブツ途切れるようなノイズが入って使えなかった。96kHzだと問題ないんだけど。
DACを変えたら、、、問題なくなったのかな？、、、
一応、384kHzで音は出るが700kHz台だと「Invalid sample rate '768000'.」とかエラー表示される。どうも微妙だ。
しかし、300kHz台が使える。
音は、、、
さすがに768kHzの深淵には及ばないけど、そこそこ良いんじゃないかな。
月にCD1枚程度の金額で、この音で聴けるなら、、、相当安いんじゃないかな。いや、、、使えますよこれ。

次に、ギャップレス再生ができない問題。これは、、、どうなんだろうね。
自宅NASの音源をmpdで聴いてきた限りでは、この問題は全く気にしなくても良かった。まあ、、、仕方がないのかな、、、

もうひとつは、クライアントPCにキャッシュが積み重なるようで、どんどんメモリが消費されていく。つまり、鳴らし始めのうちはいいけど数時間鳴らすとクライアントPCが不安定になるのだ。不可逆圧縮音源を使っていた時には、消費される容量が少なかったので、気付かなかったのだろうか。
しかし、8GB積んでるんだよ？
それが気付けば100%近く使用になりswapまで消費し始める。何にそんなに使ってるんだろう、、、firefoxを閉じると忽ち使用メモリ量は低下する。
一方、、、pulseaudioサーバー側は、ほとんどメモリを使っていない。

tc@box:~$ free
              total        used        free      shared  buff/cache   available
Mem:        3946904      239024     3592700       20636      115180     3440612
Swap:        959968           0      959968
tc@box:~$ 

何がどうなっているのやら。
素直にNode2iあたり導入するほうが楽なのかもしれない、、、（でもあれ、Linux用の操作アプリはないんじゃないかな、、、）
まあ、もうちょっと弄ってみましょうか、、、

弄れるかな、、、
弄れるかどうかはともかくとして、メインソースとして充分に使えそうなのが非常にありがたい。CD購入も減らせそうだ。

vi .pulse/default.pa

#load-module module-alsa-sink
load-module module-alsa-sink device=hw:0,0


### Automatically load driver modules depending on the hardware available
.ifexists module-udev-detect.so
# load-module module-udev-detect
load-module module-udev-detect tsched=0
.else
### Use the static hardware detection module (for systems that lack udev support)
# load-module module-detect
load-module module-detect tsched=0
.endif

#load-module module-native-protocol-tcp
load-module module-native-protocol-tcp auth-ip-acl=127.0.0.1;192.168.1.0/24

vi .pulse/daemon.conf

; shm-size-bytes = 0 # setting this 0 will use the system-default, usually 64 MiB
# shm-size-bytes = 131072
# shm-size-bytes = 65536
shm-size-bytes = 32768

; resample-method = speex-float-1
resample-method = src-sinc-fastest

default-sample-format = s32le
default-sample-rate = 352800
alternate-sample-rate = 352800


; default-fragments = 4
; default-fragment-size-msec = 25

default-fragments = 2
# default-fragment-size-msec = 500
default-fragment-size-msec = 200
# default-fragment-size-msec = 100
# default-fragment-size-msec = 25

先日、リサプラーによって再生音の定位に違いを生じるかどうか、libsamplerate使用、SoX使用、アップサンプリングなしの音を比較試聴し、違いがあることを確認した。
DACは、nano iDSD LE。

このとき、libsamplerate、44.1/16へのリサンプリング有る無しで聴き比べたが、違いがあった。
libsamplerateを通した音はlibsamplerateの音になる。
同じ44.1/16でも、リサンプラーを通すとリサンプラーの音になるのだ。

SoXと比較して、libsamplerateのほうが音への影響が良くも悪くも大きいと思う。libsamplerateはDA-AD変換をシミュレートするので、言ってみれば元から全てデジタル信号を再構築するわけだから、音が違って当たり前と、言おうと思えば言える。
しかし、デジタル信号自体が違うから音が違う、でいいのか？

前回の記録から試聴結果を引用してみる。順序は変えている。

44.1/16、リサンプリングなし。(NAS original音源)
チェロは右、SoXの時ほどじゃないけど、目の高さより若干高いことに気付いた。
ボーカルは中央、正面やや上に上がった。1分20秒すぎのボーカル、高音の響きが上～左向きに。２分台後半、やや右、後方に揺れる。
バス、ほぼ中央。

44.1/16 (NAS resample音源)
チェロは右、目の高さ。
ボーカルは中央、正面（前と同じ）。響き成分多め。1分20秒すぎのボーカル、高音の響きは上向き。２分台後半、響きが右、後方に向かう傾向が強い。 バス、ほぼ中央右。

44.1/16、リサンプリングなしでCCモード (ppap original音源 DAC:fireface UCX)
チェロは右、目の高さ。nano iDSD LEのときよりやや内側に寄る。
ボーカルは中央、正面やや上。しっかり肌理細やかに鳴る。1分20秒すぎ、高音の響きは上～左右に広がる。２分台前半、定位はしっかりしている。後半、響きが右、後方に向かう。
バス、中央右。

なんというか、定位について書かれている文面だけ見たら、LEでのオリジナル音源再生より、リサンプリングした音源の再生のほうが、UCXによるオリジナル音源再生に近いように見えなくもない。そして実際、聴いた音色の感触はそう感じられた。
リサンプリングすることに優位性があるなら、それは何処から生じるのか。
オリジナルデータのほうが正確なのは当たり前だ。リサンプリングがジッター低下につながる理由を探さないといけないってことだ。

構成図を見ながら考えてみる。

オリジナルデータ再生の場合は、NASからnfs経由で送られるflacデータをmpdがデコードしてalsaに送っている。
リサンプリングする場合は、NASからnfs経由で送られるflacデータをmpdがデコードしてlibsamplerateでDA-AD変換シミュレートし、そのデータをmpdがalsaに送っている。
ここで考えたのは、DA-AD変換シミュレートに際してデータがどこかにバッファされるはずだ、ということ。バッファされたデータを送り出すほうが、ジッターが減るのではないか。もともとmpd.conf上にバッファを設定する項目はある。しかしlibsamplerateのDA-AD変換シミュレートに使われるバッファは、たぶん別に用意されるはずだと思う。
バッファされたデータを送り出すということなら、RAMメモリ再生に近いと言えるかもしれない。

RAMメモリ再生で44.1/16にリサンプリングしたら、どう聴こえるだろうか。
試してみよう、、、と思ってた矢先、、、
、、、
nano iDSD LEが壊れたみたいだ、、、
入力の認識はしているようでインジケーターの色も変わるんだけど、音が出なくなった。

i2s DACでやってみようか、、、
聴こえ方がどうか、最初からしないといけないのか、、、
ppapのUCXと定位に差がなかったら、比較できないってことだな。

そういうわけで、piCore7でi2s DACを鳴らす環境をさっさと構築する。
というか、nano iDSD LEに繋がっていたras pi2からmicroSDを抜いて、config.txtを設定して、i2s DACを刺したras pi2に刺し直し、起動させるだけだ。
USBターミネーターは刺すけど、面倒なのでケースなしだ。

  PID  PPID USER     STAT   VSZ %VSZ CPU %CPU COMMAND
 1862     1 tc       S     133m 14.3   0 15.5 mpd

  PID  PPID USER     STAT   VSZ %VSZ CPU %CPU COMMAND
 1894     1 tc       S     133m 14.3   0  7.5 mpd

  PID  PPID USER     STAT   VSZ %VSZ CPU %CPU COMMAND
 1879     1 tc       S     133m 14.3   0  0.6 mpd

  PID  PPID USER     STAT   VSZ %VSZ CPU %CPU COMMAND
 1911     1 tc       S     133m 14.3   0  0.6 mpd

これはlibsamplerateによるアップサンプリングを行っている時のtop表示。
上が順に、192/24、96/24、44.1/16、44.1/16リサンプリングなし、だ。
サンプリング周波数が高いほど、CPU使用が多くなる。44.1/16はリサンプリングしようがしまいがCPU使用率が変わらない。それでも先日、聴き比べた時には確かに音は変わって聴こえたわけで、どこかで何かが何かしてるんだろう。

試聴だ。
音源は前回と同じ、幸田浩子「カリヨン」1曲目、カッチーニのアヴェ・マリア。

まず、リサンプラーなしの44.1/16、NAS音源。
チェロは右、目の高さ。、、これはUCXよりも中央寄りか？
ボーカルは中央、正面やや上。1分20秒すぎのボーカル、高音の響きが上向きに広がる。２分台前半、定位は比較的安定。後半、響きが上、右、後方に向かうけど、、定位自体は安定感がある。
バス、ほぼ中央右。

次、リサンプリングありの44.1/16、NAS音源。、、柔らかくなる。
チェロは右、目の高さ、、、だけどリサンプラーなしのNAS音源より、さらに内側に聴こえる。右中央？
ボーカルは中央、正面やや上。1分20秒すぎのボーカル、高音の響きは広がるが、、そんな上にいかない。２分台前半、定位は安定。後半、響きが横には向かわない、やや後ろに向かうことあり、、、定位は安定感がある。
バス、ほぼ中央右。

次、リサンプリングありの44.1/16、RAMメモリ音源に替える。
チェロは右、目の高さ。あれ、、NASよりも外に。
ボーカルは中央、正面やや上。NASより少し低め。1分20秒すぎのボーカル、高音の響きは少し上に広がる。２分台前半、定位は安定。後半、響きは横には向かわない、やや後ろに向かうことあり、、、安定感がある。
バス、ほぼ中央右。

リサンプラーなしの44.1/16、RAMメモリ音源。
チェロは右、目の高さ。NASよりも少し外で変わらず。UCXと比べてどうだろう、、、
ボーカルは中央、正面やや上。NASより少し低め。1分20秒すぎのボーカル、高音の響きは少し上に広がる。２分台前半、定位は安定。後半、響きは横には向かわない、やや後ろに向かうことあり、、、やはり安定感がある。
バス、ほぼ中央右。
リサンプリングのあるなしで、ほとんど変わらない。

リサンプラーなしの44.1/16、NAS音源に戻る。RAMと比べると少し硬いかな。
チェロは右、目の高さ。RAM音源のときよりも5度ほど内側にいるみたい。
ボーカルは中央、正面やや上。1分20秒すぎのボーカル、高音の響きが上向きに広がる。RAMより広がりは大きい。２分台前半、定位は比較的安定。後半、響きが上、右、後方に向かうけど、、定位自体は安定感がある。
バス、ほぼ中央右。

UCXで聴いてみる。リサンプラーなしの44.1/16、ppap方式。
チェロは右、目の高さ。NASよりも少し外。RAMメモリ音源と同じ位置。
ボーカルは中央、正面やや上。1分20秒すぎのボーカル、高音の響きは上に広がる。２分台前半、定位は安定。後半、響きは右からやや後ろに向かう。 バス、ほぼ中央右。

さて、、、図にしてみよう。

チェロの位置が変わるけど、どう評価したものやら。
本来は、リサンプルされたNAS音源の位置が正しいんだろうけど、より高性能なはずのDAC、fireface UCXの再生に近いのはRAM音源再生だ。そもそもコントラバスが中央で、本来の位置の右側から大きく外れているので、正確な再生はできていない中での試聴なので仕方ないかも。

ソプラノは、今回は前回よりも安定して鳴った。
定位のぶれが少ないのだ。
i2s DAC、侮れない。
数千円で買えるHATだから高級な音は望むべくもないので、普段はテスト用やサブシステムで使ってるけど、基本を押さえた音がする印象が以前からある。しかし空間を表現する音が少ないという弱点が逆に良い方向に作用したのかもしれない、のかな？

音色は、リサンプラーを通した音はRAMメモリ再生に近づくと言えば近づく。ソプラノの聴こえ方、響きの出方も似ている（試聴記録の文面、全く変えてないのは我ながらどうかと思うね、、）。
しかしチェロの定位が全く違う。これは、前回の結果と逆になったということだ。
そんなわけで、簡単に結論が出るもんじゃないんだろうけど。

今回はこのくらいにしておく。

piCore7をpiped pcm audio playのフロントにしたので、最近はこれで鳴らしていることが多い。mpd出力も使うんだけど随分減った。
いろいろあるんだけど、整理がてら書いていく。

まず、ppapだとsoftwareボリュームが使えない（4月8日、追記。これは間違い。mpd.confで設定したら使える）。
以前なら音が大きすぎるなと思ったら、ncmpcppを操作してサッと音量を下げることができたが、ppapだとアンプまで歩いて行かないといけない。出力がpipeだからデジタルで調節できないのだ。
まあ、歩けばいいんだけどさ。
何か手立てはないかと思ってるんだけど、できていない。
フロントでalsaからncatに送るようにしたら出来るのかしれないけど、まだ十分に試みていないのだ。

そういうわけで現状、RAMメモリ再生だったらsoftwareボリュームで音量調整ができるけど、ppapならフロントにNASをマウントできるので好きな音源をさくさく選べるという、それぞれの優位性がある状況。両者の音質を比較しないといけないんだけど、これもできていない。

昨年の秋にノイズ対策でUSBターミネーター、LANにフィルターなどを追加し、USB-029H2-RPを導入したところ、音の出方がずいぶん変わった。更にppap方式も追加なので、短期間にほんとにあれこれ変わったので、途中経過が分からないんだけど、どうなってるのか簡単にまとめておく。

まず、素の44.1/16flacファイルの再生音がかなり底上げされた。
ppapで聴く44.1/16は、何しろ堅実でまっとうな再生という印象で、今まで聴いたことがなかった安定感がある。
くっきりした鮮度が高い感触は、以前よりも好ましい方向に強まっている。アップサンプリングした音の方が当たりが優しくて聴きやすいというのはあるんだけど、以前と比べたら差が少なくなった。44.1/16の特徴と思っていた若干肌理が荒い感じは減って、アップサンプリングした時の滑らかな感触に近づいている。
考えてみたら、これってRAMメモリ再生では感じなかったことなのだ。
しかし素の44.1/16でRAMメモリ再生をしたのは随分昔のことで、最近はアップサンプリングしてばかりだった。だから、再生方式による違いなのか、ノイズ対策の方が効いているのか、正確を期すなら確認する必要がある。

アップサンプリングのほうは、改善しているようなんだけど、そこまで大きな変化はない。
以前だったら、44.1/16は384kHzにアップサンプリングしたほうが情報量が多いと言えたんだけど、今は軽々しく言い難い。ちゃんとソースを選んで本腰入れて比較しないと、実際のところがどうなのか分からない。
じゃあ両者の再生音は近づいたのかというと、聴いた感触の違いはむしろ今の方が大きい。
オーディオ的にどちらが優位かがはっきりしなくなり、素の44.1/16の安定感とアップサンプリングの感触の良さ、そういう聴こえ方の嗜好のほうがむしろ、選択に影響する度合いが大きくなったのではないか、という感じ。

そういうところで、nano iDSD LEでアップサンプリングの音を確認することに、どれだけの意味があるのかな、と思うようになった。DACによって違うってことは当たり前にあるってことはあるんだろうけど、じゃあ、アップサンプリングの優位性があるかどうかはDACによる、ってことになるのかな。

以前だったら、明らかに384kHzにアップサンプリングしたほうが良くて、リサンプラーによる違いも明白だったので、ここは突き詰める必要があると思っていたんだけど、現在の音は、そこまでやる意味が減っているような。好みの問題に帰着するならするで、いいんじゃないの？という。
以前の音は、ジッターを生じやすい環境だとアップサンプリング（ハイレゾ）が有利というのに当てはまっていたのかとも思うけど。
今はそうじゃなくなった、のかなあ、、、どうなのか？

かたや、fireface UCXのほうはどうかといえば、これもあれこれあってCCモードのUSB入力になった。
SPDIF入力の時は192kHzにアップサンプリングする優位性があるように感じていた。
CCモードは96/24までなんだけど、これはアップサンプリングした方がいいのかどうか、音色はかなり違うけど分からない。どっちもどっちでいいので選択に迷う。これも先々きちんと比較する必要があるんだろうなと思う。

ああ、、、ひょっとしたら音色の感触が違いすぎるので逆に比較が難しくなってるのかな、、、

アップサンプリングについては、下記アドレスのような問題？も指摘されている。まさか定位に影響するとは。

http://community.phileweb.com/mypage/entry/2408/20180123/58315/

Ａ：44.1KHz/16bit、44.1KHz/24bit、88.2KHz/24bit、176.4KHz/24bit
　　ボーカルは中央に安定　チェロは右中央　コントラバスは右

Ｂ：48KHz/24、96KHz/24、192KHz/24bit
　　ボーカルの定位はあいまいで不安定　チェロは中央、コントラバスは中央右

というように２分されます。ＡとＢの中でも微妙な差はあります。例えば、16bitよりも24bitの方が滑らかで耳障りがよく感じる…とか、ボーカルの安定度は48KHzよりも96KHz、192KHzの方がよい…などです。ただし、その差はＡグループとＢグループとの音像定位の差ほどではなく微妙です。

アップサンプリングはトラポですることができる一方で、DACチップでも行われる。このへん、兼ね合いはどうなのか。DACチップ内で行われるアップサンプリング自体で定位が変わるということは、なにしろ製品なのだから有り得ないと、思っていいんだよね？、、、
あと、リサンプラーによって違うんだろうかとか。

そんなこんなで、これからどうしようかと思ってたけど取り敢えず、nano iDSD LEで自分なりにアップサンプリングの位置付けを明確にしよう、というところから始める。つまり、素の44.1/16から384/32までのアップサンプリング、をきちんと聴き比べてみようということ。リサンプラーも変えて。

これはppapではやりにくい。たびたびバックエンドを再起動する必要があるからだ。
あと、前回のエントリーに追記したけど、フロントにRas pi2/piCore7を使った場合、アップサンプリングで使えるのは192kHzまでのようだ。うちのppapでは、300kHz台へのアップサンプリングは聴けない。384kHzまでは確認したいので、そういう意味でも使いにくい。
だからNASマウントのmpdで設定を変えながら聴くことになる。

せっかくなので試聴に使うのは前述アドレスのサイトで話題になっている幸田浩子「カリヨン」1曲目、カッチーニのアヴェ・マリアにする。
まず、44.1/16を聴いてみる、、、
さっそく、前述のサイトで説明されているのとは聴こえ方が違う。
ボーカルは中央に安定　チェロは右中央　コントラバスは右、ということなんだけど、うちではチェロが右でコントラバスが中央あたりに聴こえる。ボーカルは中央なんだけど、歌い始めはこもり気味。数秒で落ち着いたと思ったら、その後は上を向いたり右を向いたりしてるような。録音現場の反射を多く捉えているような聴こえ方。というか、後ろ向いてるの？、、、
そういう録音なの？と思っていたら、聴き込んでる人の解説がアップされていた。

http://community.phileweb.com/mypage/entry/3255/20180127/58351/

一時は右を向いたり左を向いたりしながら歌っているためと、録音のせいにしたりしていたんです。ですが、再生側を追い込んでいくとボーカルは前に出てきて、かつ歌声もぶれなくなりました。

追い込みきれていないということらしい。なんという恐ろしいソフトか、、、
確かにうちの環境は全く反論できない状態にあるが、そうそう追い込む暇はないんだな。
しかたない。
この状況でどう聴こえるかでやってみようか、、、

実際に試聴した時系列に沿って書いていく。

まず、リサンプラーなしの44.1/16。
チェロは右、目の高さ。
ボーカルは中央、正面やや上。1分20秒すぎのボーカル、高音の響きが上～左向きに。２分台後半、やや右、後方に揺れる。
バス、ほぼ中央。

ボーカルは1分20秒すぎと２分台後半の定点観測と、他に気付いたことを書いていく。

リサンプラーにSoXを使用。

88.2/24

チェロは右、目の高さ。
ボーカルは中央、正面やや上。1分20秒すぎのボーカル、高音の響きが上に向かう。２分台後半、定位がやや右、後方に揺れる傾向あり。
バス、ほぼ中央左。

ソプラノ、口元が正面に向かない感じの時が多い。そんな聴こえ方だ。基本的にそういうソースなんだけど、それでもあれこれやってみた結果、安定して再生出来た時は比較的前を向いて歌っているように聴こえる時間が多かったように思った。

96/24

チェロは右に定位。なんと、目の高さより高くなった。
ボーカルは中央、正面やや上、やや響きが広がりぎみ、かつ響きが固い。1分20秒すぎ、高音の響きが上向き、さらに後方、左にも。２分台後半、やや右、後方に揺れる傾向あり。
バス、ほぼ中央。

176.4/24

チェロは右、目の高さ。
ボーカルは中央、正面やや上。響きが固い印象。1分20秒すぎのボーカル、高音の響きが上向きに。２分台後半、響きが右、後方に揺れるように聴こえる。
バス、ほぼ中央左。

194/24

チェロは右、目の高さよりやや高い。
ボーカルは中央、正面やや上、やや響きが広がりぎみ、やや硬い。1分20秒すぎのボーカル、高音の響きは上向き。２分台後半、響きが後方に揺れる。硬い響き。
バス、ほぼ中央。

352.8/24

チェロは右、目の高さ。
ボーカルは中央、正面やや上。1分20秒すぎのボーカル、高音の響きは上～右向き。２分台後半、響きが右、後方に伸びるように聴こえる。
バス、ほぼ中央左。

384/24

チェロは右、目の高さよりやや高い。
ボーカルは中央、正面やや上、やはり、やや響きが広がりぎみでやや硬い。1分20秒すぎのボーカル、高音の響きは上～右。２分台後半、定位が右に揺れる。硬い響き。
バス、ほぼ中央。

SoXで聴いてきて、どうも44.1xのほうが伸びやかで聞きやすい印象。コントラバスの位置がなぜか44.1xで左に寄る。
48xだとチェロがやや上に上がるのと、ソプラノなど音色の響きが固くて聴き辛い印象。300kHz台となればましになるような気はしたけど、、、あんまり変わらないかな、、、

リサンプラーをlibsamplerateに変更。

一気に音色がやさしくなる！
これは違いすぎる。ここまでちょっと辛い試聴だったことに気付かされた。

88.2/24

チェロは右、目の高さ。
ボーカルは中央、正面（やや下がった）。やや左右に揺れる。1分20秒すぎのボーカル、高音の響きは上向き。やさしい響き。２分台後半、響きが前にでる。3分前、後方に揺れる傾向あり。
バス、ほぼ中央右。なんとまあ、SoXとは逆になった。

96/24

チェロは右、目の高さ。
ボーカルは中央、正面（前と同じ）。やや左右に揺れる。1分20秒すぎのボーカル、高音の響きは上～左右向き。２分台後半、やや右による傾向。
バス、ほぼ中央右。

176.4/24

チェロは右、目の高さ。
ボーカルは中央、正面（前と同じ）。やや左右に揺れる。1分20秒すぎのボーカル、高音の響きは上～左右向き。２分台後半、響き、定位ともに右による傾向。
バス、ほぼ中央右。

194/24

チェロは右、目の高さ。
ボーカルは中央、正面（前と同じ）。やや左右に揺れる。1分20秒すぎのボーカル、高音の響きは上～左右向き。２分台前半、定位は右に傾きがち。２分台後半、響きが右、後方に向かう傾向。
バス、ほぼ中央右。

352.8/24

チェロは右、目の高さ。
ボーカルは中央、正面（前と同じ）。響き成分多め。1分20秒すぎのボーカル、高音の響きは上向き。２分台前半、定位はやや右に傾く。２分台後半、響きが右、後方に向かう傾向。
バス、ほぼ中央右。

384/24

チェロは右、目の高さ。
ボーカルは中央、正面（前と同じ）。響き成分多め。1分20秒すぎのボーカル、高音の響きは上向き。２分台前半、定位はやや右に傾く。２分台後半、響きが右、後方に向かう傾向。
バス、ほぼ中央右。

libasmplerateの場合は、サンプリング周波数による差異がSoXほど大きくない。
それと、サンプリング周波数を上げていくと順当に音が良くなっていく感触があったので、何となくいい気分で試聴できた。まあ、アルゴリズムの有り様から考えれば、サンプリング周波数での変化は少ないはずだという予測はしていた。
ものは試しと、libsamplerateで44.1/16にリサンプリングしてみた。

44.1/16

384と変わらない？w
チェロは右、目の高さ。
ボーカルは中央、正面（前と同じ）。響き成分多め。1分20秒すぎのボーカル、高音の響きは上向き。２分台後半、響きが右、後方に向かう傾向が強い。さすがに384よりも硬い響き。
バス、ほぼ中央右。

聴き始めは違いがないのかと思ったが、やはりボーカルなどの響きはアップサンプリングした方がいい。
ここでリサンプラーなしと聴き比べる。

44.1/16、リサンプリングなし。

チェロは右、SoXの時ほどじゃないけど、目の高さより若干高いことに気付いた。
ボーカルは中央、正面やや上に上がった。1分20秒すぎのボーカル、高音の響きが上～左向きに。２分台後半、やや右、後方に揺れる。
バス、ほぼ中央。

一言で言うと響きが硬い。
libsamplerateをアップサンプリングなしで通した音の方がずっと聴きやすくなるようだ。これは化粧した音と考えた方がいいのかな、、、しかし聴きやすいほうがいいよな、、、というか、最近はnano iDSD LEで聴くことは減ってきているので、この結果にあまり神経質になる必要はないのだけど。

そういうわけで、fireface UCXでどんな鳴り方になるか聴いてみる。
44.1/16、リサンプリングなしでCCモード、ppap。
チェロは右、目の高さ。nano iDSD LEのときよりやや内側に寄る。
ボーカルは中央、正面やや上。しっかり肌理細やかに鳴る。1分20秒すぎ、高音の響きは上～左右に広がる。２分台前半、定位はしっかりしている。後半、響きが右、後方に向かう。
バス、中央右。

こんな感じ。
しかし定位がどうとかよりも音色の格が違う。
NASマウントのLEとppapのUCXの比較だから当たり前だ。

UCXでアップサンプリングも聴いてみるべきか、、、と思ったけど、、、もういいか。
うちでは使うならlibsamplerateと決まっているし、UCXとLEの結果が知れたからといって、だからどうなのかということもあるし。
ともかく、リサンプラーによって良くも悪くも音が変るし、リサンプラーの種類やサンプリング周波数によって変わり方が違うのも確認した。多分、DACによっても違うんだし。きりがないっちゃきりがない。

自分の納得がいくように、気持ちよく聴けるようにやれたら、それでいいと思う。
僕は、一種のゲームのような感覚でオーディオをやってるんだと思う。ひとつクリアしたら次の課題に移るという感覚。
そして幸か不幸か課題には事欠かない。

最近はアップコンバートに凝っている。
いろんな条件で比較しないといけないとは思うけど、真面目にやらないまま何となくあれこれ聴いている日々だ。
そんなわけで雑感だ。

どこから書いたものか。
まず、libsamplerateとSoXの比較だけど、全く出来ていない。
というか、もっぱらlibsamplerate系で聴いている。比較する暇がまだないのだ。
Volumioはlibresampleというプラグイン（と言っていいのかな？）でアップサンプリングするんだけど、これはlibsamplerateの派生らしい。piCoreでのメモリ再生でも、もっぱらlibsamplerateを使っているのだけど、やはりメモリの消費の傾向とか挙動が似ている。で、こればっかり使っている状況ということだ。
それで不満がないのでしょうがない。SoXと比較する暇はなかなかとれないし、、、
参考のサイトをメモ。

Free Resampling Software - Digital Audio Resampling Home Page
https://ccrma.stanford.edu/~jos/resample/Free_Resampling_Software.html

雑感だから文脈無視して思いつくまま書く。
前回のエントリー以降、アップコンバートによる音の変化を確かめていた。
Ras pi 2 + Picore7 + mpd + libsamplerateでどうなのか。
音質への言及はないが、下記の記事（2015年12月2日付）にうちでの再生と同様な結果がアップされている。

ラズパイ・オーディオでアップサンプリング！ CD音源を変換して高音質再生 (1/3) - Phile-web
http://www.phileweb.com/review/article/201512/02/1888.html

Raspberry Pi 2での試みについて書かれている。以下引用。

CDから取り込んだロスレス音源（44.1kHz/16bit、ALAC）で試した結果は、表1～3に示すとおり。「Fastest Sinc Interpolator」ではインターポレーション（サンプリング周波数を整数倍するときの補間処理）を速度優先で行うため、もっとも情報量が多くなる384kHz/32bitでも余裕で再生できた。 速度／精度のバランスが考慮された「Medium Sinc Interpolator」では、組み合わせによって明暗が分かれた。96kHz/24bitおよび96kHz/32bitはスムーズに再生できたが、192kHz/24bit以上の情報量では音が途切れがちとなってしまう。（中略） 精度を最優先する「Best Sinc Interpolator」では、アップサンプリング処理はほぼ困難だ。

こちらでも同様の結果。
Ras pi2でBest Sinc Interpolatorは無理。Medium Sinc Interpolatorは微妙。Fastest Sinc Interpolatorは安定して動作する。
Ras pi B+でVolumio1.55の場合はFastestなら192/24で問題なく動作する。MediumはPi2よりもっと微妙で実用にする意味が見つけにくいレベルかな。

面白いのは、サンプリング周波数と量子化ビット数の影響よりもlibsamplerateの設定の方が影響が大きいということ。
Pi2の場合だと、Bestは無理、Mediumは微妙、Fastestは安定だ。
Mediumの設定の時に、サンプリング周波数と量子化ビット数を調節してシステムを安定化させようとしても、なんだかあんまり関係無さそうなのだ。というのは、192/16では音切れがおきるけど、176.4/16だと大丈夫だね、と思って聴いていたら2、3日後に途切れるようになったり。
考えてみたら、libsamplerateでもっとも大きな負担になるのはDAD変換シミュレート自体だと思う（他の負担が少ないアップサンプリングの方法で、そこまでしてるのってあんまりなさそうな感じなのだ）。サンプリング周波数と量子化ビット数がどうかっていうのは多少は影響するものの、シミュレート精度に比べたら影響が少ないんだろうと思う。

さて、問題は音だ。
アップサンプリングについてツイッターでつぶやいていたら「アップサンプリングすると音の輪郭が人工的ににじむような気がします」というレスをいただいた。アップサンプリングされた音について、にじんで聞こえる、音色が変るという話は他でも読んだことがある（どこでか忘れたけど）。

実は、うちでもにじむような音が出ていた。
最初にpiCoreでアップサンプリングを試みて、音質は今までで最高と書いたときの音がまさにそうだったのだ。
これは、なんといえばいいんだろう、、、
ギラギラまばゆいような音で、後光が射してるとでも言えばいいのか、、、はっきり言って、何かがおかしい。それなのに情報量は増えて今迄聴こえなかった音が聴こえる感じなのだ。正直戸惑い、最高とは書いてみたものの、次のエントリーでは「ここまでいいのは怪しいんじゃないか、という気持ちにすらなる」と書かざるをえなかった。何しろ、鬼気迫る怪しい音なのだ。刀を構えた眼光凛々の剣豪に対峙してる感じ。「ああ、、そうですね、あなたホントに凄いよ（汗」と言わないとまずいんじゃないかという感じ。

しかし、それは長く続かなかった。
しばらくしてうちのPi2は電力不足で落ちたのである。鬼気迫るような怪しい音は、やっぱりあぶない音だったのだ。
電源を強化して後の音は、だいぶ落ち着いた。でも、なんとなく後光を背負った感じは残っている。一度落ちたからそう思うのかどうか知らないが、なんだか危なっかしい感触なのだ。176.4/16で当初は安定してると思っていたが、音切れを生じるようになったという経過は前述の通り。
MediumからFastestに変えたら後光はなくなった。
192/24での再生音の情報量はアップサンプリングなしの44.1/16よりも確実に多い。落ち着いていてシャープでより深く見通せる音だ。

どうも、ギリギリの条件でアップサンプリングしていると音がぎらつくような気がする。
電力の不足だったり、スペックの限界だったり、どういう影響なのか分からないが、何しろ音色が変わるのだ。派手なのでそっちのほうがいいという人もいるかもしれない感じだけど、そういう感じなので僕はほどほどにしたほうがいいと思う。
デジタル音楽再生ではシステムに余力があるほうがいい気がする。そのほうが安定して鳴るからだ。

そんなわけで現在、うちではRas pi2 / piCore7 / hifiberry Digi+が２台と、Ras pi B+ / volumio1.55 / RBD-02+が１台で運用中。
piCoreはメモリ再生用。volumioはNAS、ネットラジオでホームユースのBGM用。
どちらもアップコンバートなしには戻れなくなっている。

以下の記事（2016年7月11日付）では、DACチップについて問題提起している。

【藤本健のDigital Audio Laboratory】「アップサンプリング」で音は良くなる? 変わらない? 独自手法を提案する技術者に聞く - AV Watch
http://av.watch.impress.co.jp/docs/series/dal/1009623.html

DACがブラックボックスでアップサンプリング精度が疑問というのは、僕が感じていたことそのもので、とても興味深く読ませていただいた。しかしここには、ぼくが感じているもう一つの疑念には触れていない。
それは「そもそもDACチップってサンプリング定理を再生音に忠実に反映させるだけのスペックを持ってるの？」ということだ。

44.1/16では得られない情報が、同じデータを192/24にアップサンプリングした音だと得られている。
僕はずっと、ジッターの問題でデジタル再生音の違いが生じると思っていた。
しかし今、鳴っている音を前にして考えてみたら、デジタルトラポはRaspberry piとi2sボードで変わっていない。アップコンバートには負担が伴う。つまりジッターの条件は192/24のほうがよほど不利だ。

44.1/16のデータと192/24のデータは、サンプリング定理どおりの変換ならほぼ同じ波形が得られるはずのデータだ（アップコンバートに際して高域にわずかに減衰を生じるらしいが実質的には無視できると思う）。そもそも現在、アップサンプリングによる音質の改善については懐疑的な意見の方が主流だと思う。得られるアナログ波形は同じはずだからだ。
しかし現実に、うちの再生音には明らかな情報量の違いがある。

理由は、DACによる44.1/16の再生は不十分で192/24の再生はより十分に近づく、としか言えない。
得られるアナログ波形が違うのだ。
そもそもDACチップ内でアップサンプリングしなければ十分な再生ができないということは、44.1/16ではサンプリング定理に沿った再生ができないと現に認めてるということではないのか。

こんなことを考えながら普段から聴いてるわけではなくて、書き始めたらこんな所に流れ着いた。
音楽を鳴らしてる時はむしろ考えていない。
考えを整理しようとしていたら、なんということを書いてるんだろう、ということになった。
このあたりでやめておく。

前のエントリーに追記で、アップコンバートについてちらっと書いた。
Ras piからRas pi2にハードの性能が上がったので出来るんじゃないかと思ってのことだけど、こんなに変わっていいのか？と思うほどだ。
理屈で言えばハイレゾファイルを再生するのと同じじゃないかと思うけど、ずっといいような気がする。ここまでいいのは怪しいんじゃないか、という気持ちにすらなる。

僕が考えるアップコンバートの効果というのは、ジッターが多い環境でより多く得られるということなので、うちの環境はジッターが多いのかなということになるけど、そこは保留して、ちょっとmpdによるアップコンバートについて考えてみようと思った。

mpdでは、アップコンバートに際してlibsamplerateの使用を推奨している。
piCoreではlibsamplerateがtczで用意されていて、下記のコマンドで簡単にインストールできる。
tce-load -wi libsamplerate-dev.tcz libsamplerate-doc.tcz libsamplerate.tcz

これがインストールされていない環境でのアップサンプリングは、低品質ということらしい。
低品質とは、どういうことなのか。
libsamplerateによる高品質なアップサンプリングと比べてどう違うのか。

libsamplerateのサイトは以下。
http://www.mega-nerd.com/SRC/index.html

同サイトのSRC Qualityのページ。
http://www.mega-nerd.com/SRC/quality.html
API（Applications Programming Interface）のページ。
http://www.mega-nerd.com/SRC/api.html
Converterについて、Miscellaneous API Documentationのページ。
http://www.mega-nerd.com/SRC/api_misc.html#Converters

まず、SRC Qualityから引用。

Signal-to-Noise Ratio - a measure of how much noise the sample rate conversion process adds to the signal. This is measured in decibels (dB) and the higher this value the better. For most sample rate converters, the SNR will vary depending on the input signal and the ratio between input and output sample rates. The only valid comparison of SNR is between the worst case for for each converter.

Bandwidth - most sample rate converters attenuate high frequencies as part of their operation. Bandwidth can be measured by finding the frequency where the attenuation is 3dB and expressing that as a percentage of the full bandwidth at that sampling rate.

Speed - the faster the better :-).

難しい。ＳＮ比とスピードはなんとなく分かるけど、帯域幅（Bandwidth）って何なのだ。
「ほとんどのサンプルレートコンバーターはそれらの操作に伴って高周波を弱める。」という。
さらに訳してみる。
「帯域幅は、減衰が3dBである帯域を見つけて、サンプリングレートを全帯域幅として、それに対するパーセンテージ表示で測定値とする」という感じだろうか。どういうことだろう、、、

It should be noted that the first three converters above are based on the algorithm by Julius O. Smith which emulates the conversion of the digital signal to an analogue one and then sampling the analogue signal at the new sample rate.

次の引用は、いくつかのサンプルレートコンバータソフトに関しての言及。
訳してみる。
「ここで特記すべきことは、上の３つのコンバーターの基本はジュリアス O.スミスのアルゴリズムに基づいていることで、それがエミュレートするのは、デジタル信号をアナログ信号に変換し、そのアナログ信号を新しいサンプルレートでサンプリングする、という動作である」
つまりDA-AD変換をエミュレートするということか。

ちなみにここで上げられている３つのコンバーターとは、sndfile-resample、Resample、ResampAudioの３つである。
SoX、Shibatch(SSRC)、sr-convertも紹介されているが、これらは他のアルゴリズムということらしい。

次にMiscellaneous API Documentationから引用。

The details of these converters are as follows:

• SRC_SINC_BEST_QUALITY -
  This is a bandlimited interpolator derived from the mathematical sinc function and this is the highest quality sinc based converter, providing a worst case Signal-to-Noise Ratio (SNR) of 97 decibels (dB) at a bandwidth of 97%.
  All three SRC_SINC_* converters are based on the techniques of Julius O. Smith although this code was developed independantly.
• SRC_SINC_MEDIUM_QUALITY -
  This is another bandlimited interpolator much like the previous one. It has an SNR of 97dB and a bandwidth of 90%.
  The speed of the conversion is much faster than the previous one.
• SRC_SINC_FASTEST -
  This is the fastest bandlimited interpolator and has an SNR of 97dB and a bandwidth of 80%.
• SRC_ZERO_ORDER_HOLD -
  A Zero Order Hold converter (interpolated value is equal to the last value). The quality is poor but the conversion speed is blindlingly fast.
• SRC_LINEAR -
  A linear converter. Again the quality is poor, but the conversion speed is blindingly fast.

見覚えがある内容だ。
mpd.confの、audio_output_formatの設定だ。このサイトでも以前に取り上げたことがある。
http://blown-lei.org/endive/blosxom.cgi/audio_diary/20140709a.htm
http://blown-lei.net/endive/blosxom.cgi/audio_diary/20140709a.htm

SRC_SINC_*はSNRは全て97dB、bandwidthは97%、90%、80%と差がある。

「All three SRC_SINC_* converters are based on the techniques of Julius O. Smith although this code was developed independantly.」、訳すと「３つのSRC_SINC_*コンバーターは全てジュリアス O.スミスの技術に拠るものだが、そのコードは独自に開発されたものである」という感じか。

Julius O. Smith氏のサイトと思われるのが以下。
https://ccrma.stanford.edu/~jos/resample/

ZERO_ORDER_HOLDというのはwikipediaにあったり。読んでも僕には意味が分からない。
https://en.wikipedia.org/wiki/Zero-order_hold

ネット上を調べるうちに一目で分かる解説を見つけた。
直線補間アップサンプル（linear converter）も載っている。
http://community.phileweb.com/mypage/entry/2721/20151205/49583/

linearというのは本当にlinearなんだなあ、という感じだ。サンプル数が増える以外のメリットはなさそう。これで音質改善するというのは余程の場合だろうなあ、、、
ZOHは、linearに比べたらマシなの？、という感じ。

さて、どういうことか考えてみる。

まず、libsamplerate + mpdによる上位３つのリサンプリング方式はジュリアス O.スミス氏のアルゴリズムに基づいて行われていて、デジタルデータから元のアナログ波形を計算し、その波形のリサンプリングをエミュレートすることで新たなデジタル信号を作り出すということ。
一連の処理をするのに相応のPCパワーが必要だが、Ras pi2でもpiCoreで絞り込めば何とかなる。

PCのパワーがいらないアップサンプリングは元のアナログ波形を想定していない、ということなんだろう。それは前述のリンク先の画像からも明らかだ。
ちょっとそれでいいのかと思ったりするが、実際に過去の経験からは、それでも音質改善に繋がる場合があるというのはあるので、どうなってるんだろうとは思う。
一般的なDACチップで行われているアップコンバートでどのようなことが行われているのか以前から気になってはいたが、ここにきてやっぱり気になるという感じだ。

良質なリサンプリングとされている方式がDA変換をエミュレートするというのは考えさせられるところがある。
以前ネット上で、ハイレゾを作るのにアナログ変換を途中にはさむのはニセレゾじゃないかという議論があった。しかし、良質なリサンプリングはアナログ変換をエミュレートするのだ。
デジタル上のエミュレートで行われることと実際にアナログにするのは全く違うじゃないかって？まあ、そうなんだけどさ。

それから、リサンプリングの過程で高域の情報が失われるらしいこと。「帯域幅（Bandwidth）」という指標で計測され、libsamplerateでは上位の３段階でクオリティを選べること。

この時点でバイナリ一致とか気にすることが無意味になってきている。
リサンプリングでデータが変わる時点でバイナリ一致はないのだけど、アップコンバートした後でダウンコンバートしたら元に戻るのかな、というような曖昧な認識でいたのが違うのだということが分かった。このあたりは、ちょっと認識を改めないといけない。
（分からないのは、デジタルエミュレーションなのに何で高域が減衰するんだろうってこと、、、）

しかし、高域が減衰するといっても「SRC_SINC_FASTEST」でもbandwidthは80%であり、サンプリング周波数を仮に192kHzとしたら、3dB減衰するのは、、、
192 x 0.8 = 153.6(kHz)、、こんな計算でいいんだろうか。
これで可聴領域にどの程度の影響があるのか、はっきりしない。
もしかしたら、bandwidthは90%でもPCのパワーを必要とする「SRC_SINC_MEDIUM_QUALITY」より、bandwidthが80%でも負担が少ない「SRC_SINC_FASTEST」のほうが音がよくなる可能性もあるのではないか。

というか、その良くなってる音って何よってことになる。
つまり、もとのデジタルデータから引き出された音と言っていいのか、作った音じゃないのか、ということだ。

最近、注目されてる音楽フォーマット形式でMQAというのがあるそうなんだけど、従来の音楽ファイルよりも時間的な情報を重視していて音はいいらしい。これが実はバイナリ一致じゃないらしい？という話がある。バイナリ一致じゃないなら正確じゃないとは言えるけど、時間的情報が従来よりもきちんと再生されるなら、そのほうが正確な再生じゃないかとも思える。

ここらは考えだしたらきりがない。自分のスタンスを決めてやっていくしかないのだろう。

さて、音だ。
mpd.confの設定を変えて実際にどんな音になるのか聴いてみよう、と思ったところで息切れした。今後、余裕があったら比べることにする。

とりあえず気が付いたのは、アップサンプリングするならmpd.confのaudio_buffer_sizeの数値を上げる必要があるということ。
この数値が低いと、精彩を欠く音になる。
数値を上げすぎると音が出るまで時間がかかる。
Best Sinc Interpolatorの設定にしたら、88.2/16ですら音切れが起きる。これはRas pi2の限界だろう。

過去の経験では、アップサンプリングしないなら、audio_buffer_sizeはむしろ再生に不具合を生じない範囲で下げたほうが好ましいという印象があった。これはシステムにできるだけ負担をかけない再生ということなんだろうと思っていた。
これに対してアップサンプリングはシステムにより大きな負担を強いる方法で、audio_buffer_sizeを上げること自体はシステムへの負担増加になるとはいえ、アップサンプリングという更なる大きな負担への耐性をシステムが確保するためには、敢えてそうする必要がある、ということなんだろうと考えた。

そこでさっそくの番狂わせが、アップサンプリングなしの状態でも、audio_buffer_sizeが大きいほうが音がいいかもしれない、ということ。過去の経験は何だったのかという感じだ。
過去においては、NASに置いた音源での比較試聴だった。現在はRAMに音源を置いている。それが影響していたのかどうか。それとも他の条件が影響していたのか。今後、余裕があるときに考える。

しかしアップサンプリングなしの設定も含めていろいろ聴かないといけなくなった。なかなか大変だ。
当初は総当たり戦で比較視聴する気でいたが、比較する設定が増えすぎなので考え直さないといけない。

とりあえず今は、
samplerate_converter "Medium Sinc Interpolator"
audio_buffer_size "4096"
audio_output_format "176400:16:2"
buffer_before_play "25%"
という設定で鳴らしている。