lightmpdのメモリまわりで分かった少しばかりのこと
Lightmpdの仕組みが少し分かってきました。
それは、lightmpdの開発者であるデジファイさんからコメントをいただいたからです。
コメント欄に埋もれさせてしまうのはあまりにも勿体ないので、ここに再録しておきます。
linuxにはramdiskとtmpfsの２つのメモリディスクがあります。
ramdiskは実メモリ上に作成され文字通りディスクドライブになります。
実際につかう場合はこのドライブ上にファイルシステムを作成する必要があります。
ramdisk上にファイルを作成するとその分 /proc/meminfoのMemFreeが減ります。
そのデータを削除してもMemFreeは増えません
ramdiskのドライブの数はkernelのbuild時に決まります。
lightMDPでは/dev/ram0 から /dev/ram7までの８ドライブ使えます。
このうち/dev/ram0は/にマウントされています。
各ramdiskの容量はkernelの起動時に指定します。lightMPDでは64Mbyteです。tmpfsは仮想メモリ上に作成されます。これはディスクドライブというよりファイルシステムです。
tmpfsは/proc/meminfo のShmemの示す領域に作成されます。
tmpfs上にファイルを作成するとその分Shmemが減ります。tmpfs上のファイルを削除するとその分Shmemが増えます。
tmpfsは実メモリが足らなくなるとswapされる場合があります。lightMPDにはswap領域がありませんので、
メモリが足りなくなるとエラーになります。（多分 out of memory)lightMPDのルートファイルはramdisk上に作成されています。
ファイルシステムはromfsなので書き込みが出来ません。
これだとシステムとして動作しないので、/var,/tmp を tmpfsでマウントしてあります。
実際の/varは/var.romにあり起動時に/var.romを/varにコピーしています。tmpfsの領域を増やす場合は
mkdir /var/mnt
として /var/mntにマウントして下さい。(mount のコマンドはassiさんのコメントを参照して下さい)
lightMPDの/etc/fstabはinitrd内にあり、これを修正するには
○initrdを分解してディレクトリ構造を取り出す。
○etc/fstabを編集
○ディレクトリ構造からinitrdを作成という手順を踏みます。
これは全てlinux上での操作になります。
これが出来るとetc/fstabだけではなくinit.d内のファイルも変更できるので起動時にファイルのコピーなどできるようになります。
linuxのメモリディスクやlightMPDのbootシーケンスについてはdigifilabにまとめる予定です。(raspiのv102をリリースしてからになります）
initrdの変更を急ぐ場合はその旨リクエストしていただければその部分だけ先に解説します。
きちんと理解できない部分もあるんですが（－－；、本来はRead Onlyのlightmodeの「/tmp」や「/var/tmp」にファイルがコピーできちゃうのは、それらのディレクトリが「tmpfs」でマウントされているからだと言うことは分かりました。
また、その「tmpfs」でマウントされる領域は、Linuxではメモリ全体の50％というのがデフォルト設定だと言うことも分かりました。
ですから、「APU1D4」のように4Gbのメモリが搭載されている場合は、概ね2Gbまでコピーが可能となり、その上限を超えるとエラーメッセージがでます。
「cp: write error: No space left on device」
メモリの残量が減ってくると音質的にはあまり芳しくないという報告もあるのでこの上限2Gbは守っておいた方がいいようですが、コマンドラインから一時的に拡張することは可能です。
mount -t tmpfs -o size=90% tmpfs /var/tmp/
これだけで、「/var/tmp/」にコピーできる容量が50％から90％に引き上げることができます。
実際にやってみるとこんな感じです。
最初はこんな感じです。
# df -h
Filesystem Size Used Available Use% Mounted on
/dev/root 53.7M 53.7M 0 100% /
devtmpfs 1.9G 0 1.9G 0% /dev
tmpfs 1.9G 0 1.9G 0% /dev/shm
tmpfs 1.9G 0 1.9G 0% /tmp
tmpfs 1.9G 1.2M 1.9G 0% /var
次ぎにお呪いをします。
# mount -t tmpfs -o size=90% tmpfs /var/tmp/
# df -h
Filesystem Size Used Available Use% Mounted on
/dev/root 53.7M 53.7M 0 100% /
devtmpfs 1.9G 0 1.9G 0% /dev
tmpfs 1.9G 0 1.9G 0% /dev/shm
tmpfs 1.9G 0 1.9G 0% /tmp
tmpfs 1.9G 1.2M 1.9G 0% /var
tmpfs 3.4G 0 3.4G 0% /var/tmp
「/var/tmp」に3．4Gbが割り振られているように見えます。
そこで、ここにセルのベートーベン交響曲全集をコピーしてみます。Windowsから容量を確認すると約3．31Gbです。
# cp -r /var/lib/mpd/Music/Beethoven/Symphony_Complete/Beethoven_sym_Szell_60s/ /var/tmp/
#
と言うことで、全集が丸々コピーされました。
クライアントソフトから確認するとこういう感じになります。
#df -h
Filesystem Size Used Available Use% Mounted on
/dev/root 53.7M 53.7M 0 100% /
devtmpfs 1.9G 0 1.9G 0% /dev
tmpfs 1.9G 0 1.9G 0% /dev/shm
tmpfs 1.9G 0 1.9G 0% /tmp
tmpfs 1.9G 1.2M 1.9G 0% /var
tmpfs 3.4G 3.3G 130.6M 96% /var/tmp
「/var/tmp」に割り振られた3.4Gbの96％が使われているのが分かります。
メモリをほぼ使い切った状態なので、一般的には音質的なデメリットが指摘されています。実際に1曲だけコピーした状態と聞き比べてみると、透明感が落ちていささかくすんだような音になっています。
一般的には、こういう無茶はしない方がいいと思いますし、音楽を聴くという目的から考えても、何も無理をしてまで全集をまとめて突っ込む必要はありません。
しかし、それでも「NAS」経由の音よりはメリットがあるように感じますから、外部ストレージからの読み書きが一切発生しないというメリットは大きいようです。
デジファイさんも指摘しておられるように「tmpfs」は仮想メモリ上に作成されるファイルシステムです。つまりは、音楽データはまさにメモリ上に存在する訳なので、そのデータをアプリケーションソフトが扱うときにデータの読み書きは一切発生しません。
アプリケーションソフトというのは、何処がボトルネックになるかによって「CPUバウンド」と「IOバウンド」なソフトに二分されます。
「IOバウンド」なソフトの典型がデータベースです。
mySQLなどのデータベースソフトは格納されているデータの読み出しに要する時間が実行時間の大部分をします。考えてみれば分かることですが、1億件とか10億件を超えるようなデータから検索条件に合うデータを引っ張ってこようとすれば、その大部分はその膨大なデータを読み込むことに費やされ、読み込んでしまえば処理は一瞬で終わります。
つまりは、扱うデータの量が大きくなればなるほどソフトは「IOバウンド」になる傾向があると言うことです。
ただし、MPDの「IOバウンド」がなくなることで音質的にどれほどのメリットが発生するのかは不明です。このあたりは、単位時間あたりにどれくらいのデータの読み書きが発生しているのかを計測することが第一歩になると思われます。
なお、このマウントされた「/var/tmp/」をアンマウントすると以下のように綺麗さっぱりとなくなってしまいます。クライアントソフトから見えていたデータも消えてなくなります。
# umount /var/tmp/
# df -h
Filesystem Size Used Available Use% Mounted on
/dev/root 53.7M 53.7M 0 100% /
devtmpfs 1.9G 0 1.9G 0% /dev
tmpfs 1.9G 0 1.9G 0% /dev/shm
tmpfs 1.9G 0 1.9G 0% /tmp
tmpfs 1.9G 1.2M 1.9G 0% /var
Linuxの奥深くて不思議な世界の一端を垣間見たような気がしました。
私にとっての良い音とは
ここからはあまり役に立たない話です。（＾＾；
コメント欄を拝見していると、当然の事ながら「音が良くなった」「それほどじゃない」「変化なし」「これは逆効果」などの音質に関する評価がたくさん書き込まれています。
それはそれで当然なのですが、しかし、ここでふと一つの疑問がわき起こります。
それは、そのコメント欄で「音が良くなった」という報告の背景に存在する「音」は、私にとっても本当に「良い音」なのだろうか、逆に、私が「良い音」と報告した音が、他の人にとっても「良い音」なのだろうか、と言う疑問です。
当然の事ながら、「良い音」の絶対的な基準等というものは存在しません。ですから、それぞれの人にとっての「良い音」のスタンダードは千差万別です。
その千差万別の基準をもとにして論議せざるを得ないことが、オーディオの世界の辛いところです。そう言えば、オーディオ関係のサイトでは、始めは和やかにスタートした論議も最後は罵詈雑言の投げつけ合いで幕になると言うことをよく見かけます。
その背景には、全く異なるスタンダードに依拠して共通の話題を論議しているという不幸が存在しています。
そう言えば、昔こんな事がありました。
前から、ワンちゃんを連れた若い女性が歩いてきて、すれ違った後に「可愛いね」と話が始まったのですが、しばらくするとなんだか話がかみ合わないことに気づきました。原因はすぐに分かったのですが、私はワンちゃんを見て「可愛いね」と声をかけたのに対して、相方はそれを「若い女性」のことと受け取ったからでした。
ただ、面白いのは、これほど基準がずれていても、「可愛い（音がよい）」という感覚的な表現に頼って話しているとかなり長時間にわたって「会話」が成り立ってしまうと言う怖ろしい事実です。
ですから、前回にメインシステム紹介をしたのであれば、今回は「私が考える良い音」についても報告しておく必要があると感じた次第です。
まず、今の私がオーディオに求めているものは、「録音された演奏の評価を誤らない」という一点に尽きます。
昔は、聞いていて楽しいことが最優先だったのですが、今は「誤らない」と言うことが全てに優先しています。
こんな事を書くと、またまた「修行僧」みたいなと笑われそうなのですが、15年にもわたってパブリックドメインとなった歴史的演奏を紹介する「クラシック音楽へのおさそい～Blue Sky Label～」を運営している身にとっては仕方がないことだと考えています。
だからといって、お前は一切の評価を誤っていないのか、と突っ込まれると、それは「そんな事は絶対にありません」と答えるしかありません。
それに、そこでもオーディオと同じように「良い演奏」という基準の曖昧さがつきまとうのですから、それもまた何処まで行っても「私が考える良い演奏」の域を出るものではありません。
私がここで言っている「評価を誤らない」というのは、再生の杜撰さによって、私自身の判断を「誤らせない」と言うことです。
そして、私が数あるオーディオメーカーの中でLINNを高く評価しているのは、「録音された演奏の評価を誤らない」という一点において、他のメーカーよりも抜きんでていると感じるからです。
そして、lightmpdによるメモリ再生が「良い」と判断したのも、まさにその一点に尽きます。
聞いたことがある人ならばすぐに納得していただけると思うのですが、LINNの音というのは実に「普通の音」というか「素っ気ない音」がします。ですから、オーディオマニアにはいたって評判が悪いそうです。
そりゃぁ、そうです。
あのバカ高いシステムを組んで、こんな「普通の音」しかしないのならば、投資する甲斐がないというものです。
ところが、実際に演奏活動している人からは非常に評判がいいのです。その一番の理由は、日頃自分たちが演奏してる場で聞く音との違和感が最も少ないからです。
今の時代に「原音再生」などと言う言葉を持ち出すつもりはありませんが、いわゆるオーディオ的な味付けがきわめて少なくて、ソフトに収められた情報を非常に高い純度で再現していることは間違いありません。
私も、この数年は、「音」についても「演奏」についても、できる限り誤らないように、自分の中のスタンダードとして「演奏会」には積極的に足を運ぶようにしています。手近なところでは、飯森 範親を首席指揮者に招いたセンチュリー交響楽団がなかなかにいい演奏を聴かせてくれるので、昨年からは月に一回は足を運ぶようにしています。（4月定期のマーラーの9番の終楽章は素晴らしかったです！！）
そして、あらためて確認したのは、生のオーケストラというのは、いわゆるオーディオショーなどで聞かされる重厚で艶やかな響きはしないということです。
何処かの誰かさんがいつも言っているような、ドスン・バスンというような低音は存在しません。コントラバスやパイプオルガンの低音は常に風のように軽いのです。
そして、弦楽器群はいかにも「擦っている」という音です。
木管楽器は結構鋭い音がしますが、それでもその鋭さは耳を刺すような音とは異なります。
それから、センチュリー交響楽団の演奏精度が高いことも寄与していると思うのですが、それぞれの楽器部の分離は意外なほどにクリアで、トゥッティの中のトライアングルの音やハープのアルペッジョなどもはっきりと聞き取れます。（朝比奈時代の大フィルは中で何をやっているのかは全く聞き取れなかった＾＾；。もちろん、だからそれが駄目とはならないのは言うまでもないことです。）
当たり前の話ですが、実際のコンサートで鳴り響いている音はオーディオ的にデフォルメされたような音ではなく、普通の音で鳴り響いています。
しかし、その普通の音の背景には紛れもなく演奏家の気迫が漲っています。
問題はこの「気迫」です。
普通の音で鳴り響いていて、そのまま最後まで普通に鳴り響いて終わりであれば、そんなオーディオの音は聞くに値しません。
LINNの音が素晴らしいのは、最初聞いたときには聞く人の耳をとらえるような華やかさや特徴は乏しいのですが、聞き進んでいくうちにその普通の音の背景に込められた演奏家の気迫が迫ってきます。それはLINNが持っている驚くべき純度の高さを背景にして、最後はシステム全体で音をまとめている完成度の高さがうかがえます。
そして、このLINNのシステムを作っている連中は、実際の演奏会の音を熟知していることがはっきりと分かります。
それは、例えば、一瞬の休止の間にあらん限りの力をため込んだオケが、指揮棒の一閃を待って渾身のトゥッティを繰り出すときです。そこで私たちが一番聞きたいのは指揮棒の一閃で繰り出されるトゥッティではなくて、その休止の間にあらん限りの力をためこもうとするオケの気配なのです。
こういう部分は、実際のコンサートではヴィジュアルの助けがあるので、その気迫は手に取るように分かります。しかし、音だけのオーディオでその部分を伝えるのは至難の業なのです。
しかし、そういう部分を聞き取れるように力を尽くさないと、最初に述べたように「評価を誤って」しまうのです。
ですから、システム全体において、できる限りオーディオ的な色づけを排する方向に向かっているのです。そして、「lightmpd」によるメモリ再生に音がいいと報告したのは、まさにその様な文脈において「音がいい」と判断したのです。
実は、その意味では、「Tiny Core」でのメモリ再生は、「lightmpd」と較べると非常にオーディオ的な音がして「魅力的」です。それを聞いていると、そんな堅苦しいことは捨ててしまって、こういう世界に浸ればいいじゃないかと思ってしまう自分がいます。
どちらかと言えば素っ気なくて、平面的な音がする「lightmpd」に較べれば艶やかで美味しい音です。
おそらく、オーディオに何を求めるのか、言葉をかえれば「いい音」とは何か？と言う問いかけには大きく分けて二つの考えがあるんだろうと思います。
一つは、できる限りソフトに収められた情報を正確にもれなく拾い出そうとする人たち、もう一つは、ソフトに収められた情報を一つの素材として自分なりに美味しい料理に仕立てたい人です。
いささか荒っぽい二分法ですがそれほど本質は外していないと思います。そして、私の立ち位置は限りなく前者の立ち位置の一番端っこの方に向かっていると言うことです。
でも、時々、「Tiny Core」の世界も楽しんじゃったりするんですが・・・。（＾＾ｖ
OSの違いでこれほど音が変わるものかと驚かされます。
＜追記：2016年8月24日＞
その後、「Tiny Core」を使った「メモリ再生」に取り組んでいくうちに、この厚めの低域の上に艶やかな響きを展開する音こそが「再生ファイル」本来が持っている音ではないかと思うようになってきました。言葉をかえれば、ネットワークを介してファイルを転送する「ネットワーク再生」では、低域部分を中心として、この美味しい部分がどこかで抜け落ちているのではないかという疑念が拭いきれないのです。
ただし、その事で、私が考える「良い音」の基準が変わるものではありません。