Page 1 / 22 :  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 Next › »

Jan 03, 2019

HP Compaq 6730bでFedora 28以上を使うときの注意点

うちの主力パソコンはCompaq 6730bなんだけど(そこそこ古い機種だね、、)、Fedoraをインストールして使っている。
これがFedora28以降にバージョンアップできなくなった。
クリーンインストールしても「TPM Error 2」と表示されて起動しない。 外付けHDDからだったら起動できるんだけど、そんなのでは扱いにくい。
無理になんとかしようとしたら、どこをどう間違えたやら内蔵HDDから起動できなくなったり。

仕方がないので27のままで使っていた。
どうしたものかと思っていたんだけど、対策がアップされていたのでメモしておく。

Fedora 28 Workstation Install Guide - Comment Page: 1
https://www.if-not-true-then-false.com/2018/fedora-28-workstation-install-guide/comment-page-1/

Andre Gompel
27th July 2018, 3:49 am

4) Post-install boor exhibited a GRUB bug (TPM error, etc…), so you need to disable the TPM to be able to use F28 !
On HP Notebooks, the TPM menu is grayed: enable the BIOS password, to enable it and be able to disable TPM !

上記引用の通り、BIOSにパスワードを設定したらTPMによるOS管理をしないように設定できるようになる。
一旦、管理しないように設定したら、BIOSのパスワードなしに戻しても構わないみたい。
これで「TPM Error 2」とか表示されなくなり、内蔵HDDにFedora28以降をインストールできた。というか、もはや28の季節は過ぎていて27から29へのアップデートをしたんだけど。

なんか、問題が。「tracker-store」というのがCPUを100%消費するのだ。ファンが唸りっぱなしになっている。
参考にさせていただいたサイトを列記。

CentOS7/SL7でtrackerを起動しないようにする方法
http://carpediemjournal.blog.fc2.com/blog-entry-39.html

tracker-storeが暴走
http://benzaiten.dyndns.org/roller/ugya/entry/tracker_store%E3%81%8C%E6%9A%B4%E8%B5%B0

GNOMEのtrackerによってCPU負荷が高くなりPCが重くなる時の対処法
https://www.archlinux.site/2018/07/gnometrackercpupc.html

こんなの27まではいなかったぞ。
と思ったけど、確認したら27でもインストールはされてるようだ。どういう事情で挙動が変わったのかね、、、
27のtrackerのキャッシュは35.9MBしかない。不調にした6730bに代わって中古購入した機体で、運用を始めてから半月も経っていない。
片や、29にアップデートしたばかりのマシンは数年に渡り使っていてtrackerのキャッシュは1GB。CPU100%でファン回りっぱなしが続いている。どうなってるんだろうと見ているうちに、キャッシュが増えていないのに気付いた。
このtracker-storeは何をしてるんだろうか。

上記のサイトを参考に「journalctl -xb」コマンドを打つ。
これは起動時からのログを表示してくれるらしい。下記のようなエラーが繰り返されている。
起動プロセスが終わっていないのか?

-- The start-up result is done.
 1月 03 16:40:46 fedora2 tracker-store[2394]: Cannot initialize database: error in view fts_view: no such table: main.nie:InformationElement_nie:keyword_TEMP (s>
 1月 03 16:40:46 fedora2 systemd[1481]: tracker-store.service: Main process exited, code=exited, status=1/FAILURE
 1月 03 16:40:46 fedora2 systemd[1481]: tracker-store.service: Failed with result 'exit-code'.
 1月 03 16:40:46 fedora2 systemd[1481]: tracker-store.service: Service RestartSec=100ms expired, scheduling restart.
 1月 03 16:40:46 fedora2 systemd[1481]: tracker-store.service: Scheduled restart job, restart counter is at 25.
-- Subject: Automatic restarting of a unit has been scheduled
-- Defined-By: systemd
-- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel

「Cannot initialize database」って、dbファイルは1GBのがそのままあるよ? これを初期化できないってか?
ということは、、、これ捨てたらいいの?
というわけで、、、「~/.cashe/tracker」ディレクトリ内のファイル10個ばかりあるのをまとめて「rm」で削除。
たちまち、ファンが静かになった、、、
リブートしてみる、、、
tracker-storeとtracker-extractが動いているが、CPU消費は大きくないしファンもそんなに激しくは回らない。
そのうち600MB弱のdbファイル、その他諸々ファイルが出来て、パソコンは静かになった。

以上、備忘録まで。

Posted at 18:55 in pc | WriteBacks (0) | Edit Tagged as: , , ,

Dec 30, 2018

オーディオ状況報告(2018.12.30.)

最近のシステム構成は下図のような感じ。

システム構成図

以前よりも随分すっきりした。
現状、ncatとaplayを使ったPPAPは上限が192kHzなので、768kHzにアップサンプリングでは使えない。結果、NASマウントで使うことになった。
USBアイソレータも、効果がはっきりしなくなった?ので外して様子をみている。
数台使っていたRas pi2が一線から退いた結果、非常にシンプルな状況に。

upnpを使ってフロントとレンダラーにして、というのもちょっと考えたけど、うちの環境でupnpはやりにくいし、出来るかどうか分からないのと、そこまでしなくてもいいんじゃないの?という気分もあって、当面はこのままで運用するつもり。
MQAを聴いてみたいというのが少しある。いつになるか分からない。

では、よい年の瀬を。

Posted at 18:27 in audio_diary | WriteBacks (0) | Edit Tagged as:

Dec 25, 2018

Compaq 6730bとTiny coreでアップサンプリング (768kHzアップサンプリングの音について)

うちにはhp社のCompaq 6730bが4台ある。先日までは3台だったが、増えて4台だ。
windows7が1台、Fedora27が2台。Tiny coreでアップサンプリングを試してるのが1台。同じ機種ばかり何台もあるのは、その方が機種固有の知識が少なくて済むということと、どれかが故障した時に簡単に代替が効くからだ。
今回、数が増えたのは故障のせいで、中古パソコン屋から新しいのが来るまでの間、思惑通りに他の機体で代替できたので、大きく困ることはなかった。

そんな6730bなんだけど、Fedora28をインストールしようとしたら上手くいかずに諦めたことがある。それ以降、どうもその機体が不調つづきで、今回、29をインストールしようとしても出来ず、というか、インストールしても起動せず「TPM Error 2」と表示されて、先に進まない。ついにはエラー表示もまともに出来なくなった。
諦めて、27に戻そうとしたら、内蔵HDDからは起動できなくなっていた。usbからの起動は可能なんだけど。
こんなことってあるのか?と調べたら、OSインストールでBIOSが壊れることがあるんだな。

Ubuntu 17.10にBIOSを「破壊」するバグが発覚!原因は?対応策はあるのか?問題の詳細と現状まとめ | Linux Fan
https://linuxfan.info/ubuntu-17-10-corrupting-bios

Insyde Software社のUEFIはHPでも採用してるようだけど、6730bがそうなのかはよく分からない。
fedoraをバージョンアップ出来ないのは、うちだけじゃないらしい。

Can't install F28 on my laptop, F27 installation works
https://forums.fedoraforum.org/showthread.php?318093-Can-t-install-F28-on-my-laptop-F27-installation-works

Bug 1582810 - F28 Workstation, GRUB loader bug : After booting in Windows, then Linux, there is a "TPM Error 2"
https://bugzilla.redhat.com/show_bug.cgi?id=1582810

そんなわけで、普通には使えない6730bが1台できたというわけだ。

上記の件、対策があったのでエントリーを上げた。

HP Compaq 6730bでFedora 28以上を使うときの注意点
http://blown-lei.net/endive/blosxom.cgi/pc/20190103a.html

内蔵HDDから起動できないというのは、BIOSをインストールしたら治るのかね?、、、
usbから起動できるならTiny Core Linuxは使える。日常的な使用に組み込み向きのTiny Coreはきついかな、、、
でも、音楽サーバーにはなるんじゃね?
apu2c4(今はもう売ってないんだね。apu2d4になっている)は安定して運用継続中なんだけど、他の機械でどうなのか試してみるのは面白そうだ。apuと同じCorePure64-7.2とmpd-0.19.19をインストールして、768kHzへのアップサンプリングを較べてみた。

スペックだけど、
apu2c4は、AMD GX-412TC(1GHzクアッドコア)に、メモリはDDR3-1333、4GBで固定。
6730bは、Intel Core 2Duo P8600 (2.40GHzデュアルコア)に、メモリは800MHz DDR2、1〜8GBで変えることができる。
メモリはapu2c4のほうが速い。
CPUの差は知識もないので分からない。6730bのほうが上等と思っていいんだろうか。
今回、6730bのメモリを1、2、4、6GBと変えて音楽連続再生してみた。最大の8GBは手持ちのメモリ基板が足りなくて試していない。

まず1GBで始めてみた。
音は悪くない。意外と行けるか、と思ったらじきにjitteringというのかな?、鈴を振るような雑音が聞こえ始める。さすがにCPUが速くてもメモリ1GBは足りないかな。ちなみにras pi2のメモリはLPDDR2で単純比較はできないけど、同じ1GBでも6730bのほうが余裕があるようだ。
2GBだと、もう少し持つけど、やっぱり雑音が。
4GBだとかなり行ける。やはりメモリは4GB必要なのかと思っていたら、1時間ほど鳴らすうちにjitteringが。
6GBでどうか。、、1時間ぐらいで時にプチノイズが出て、その後は落ち着いたかと思ったけど、1時間半でjittering、、、
ということは、DDR3なら4GBあれば十分と思われ(減らせるかどうかは試せない)、DDR2なら6GBでも足りない、ということかな。jitteringが乗ったら、一時停止して再生再開したら正常に戻る。何かの処理が滞ってそんなノイズを生じるのだろう。

CPUの違いによる差異はというと、端末画面でsshからtopを打つと%CPUは25%強でそんなに変わらなかった。
それ以上の事はよくわからない。
実際のところ、機械によって必要なメモリとかスペックは違うだろうし、今回はこんな結果でした、という以上の結論は出ないと思う。

ちなみにapu2c4と6730bで、音質比較は難しかった。
ブラインドでは絶対わからないし、そうでなくても明確な指摘はできない。
やや6730bのほうが落ち着いた音色に聞こえるような気がするが、気のせいだと思う。そもそも1時間過ぎたらノイズが乗る。

768kHzアップサンプリングの音質について書いておく。

うちの女房は僕よりも音質に厳しかったりするんだけど、子供の頃のかなり厳しいピアノ教育の賜物で、音楽が鳴っていたら頭の中で勝手に音符に返還されるんだそうだ。何かしたいこと(例えばメールの文面を考えるとか)をしてる時でも、音楽が鳴っていると本人の意思とは関係なく脳が採譜を始めてしまうので、非常に困るのだという。最近は子供がピーナツにハマってて、いつも「Linus & Lucy」とか「Skating」を聞きたがるんだけど、繰り返し聞かされてウンザリだと言っていたのだ。
その女房が、768kHzになったら「これならいつでも鳴らしていい」と言ったのだ。
ちょっと信じられない。
いったい、なにが今までと違うというのだろう、、、
まあ、その後、実際にいつ鳴らしてよくなったかといえば、そうでもないんだけどさ。

以前、初めて384kHzで鳴らした時は、明らかに192Hz以下とは違うステージの音だと感じた。
これ以上に上がるのかと思っていたんだけど、実際、768kHzにしてみたら上がってしまった。
使用するDACによって違うだろうとは思う。
ブラインドで分かるかと言われたら微妙なところ。分かる人には分かるんじゃないだろうか。

高音域はより肌理細かくリアルに。それは想定内だったんだけど、中低域の見通しが良くなったのは意外だった。
いや、スーパーツィーターで低域が改善するのをずっと昔に体験してるので、高域を改善すると低域も改善するというのは当然有りだとは思うんだけど、今回の改善の仕方はそれとは何となく違うのだ。
上流の段階で改善してるのが分かるという感じ。
低音の質感、リアリティが上がり、かなり聴き取りやすくなった。低域のhi-fi再生のリアリティってこういう感じで良くなるものなんだ、と初めて知った気がする。たぶん、スピーカーの低域再生能力が高かったら明確に表現されるんじゃないかと思う。4425mk2はサイズの割に下まで伸びてるとはいえ、キャスターを使ったセッティングは最低域を支えるには限界があるだろうと思う。

なんというのか、、、
384kHzまでは、音が良くなる度に、これ以上の音があり得るのか?と感じていたんだけど、768kHzを聞くと逆に、ああ、これ以上の音ってありだ、と感じた。更なるオーディオ再生の高みがあると確信したというのか。まあ、うちのシステムレベルでは上があって当たり前なんだけど、そういう話ではなく、オーディオ技術的に目指すべき場所的な感覚で。
技術者ではない自分がそういう感覚を持ってしまったのが意外なところ。
だから、そういうレベルを目指すのかと言われたら、最早どうだか分からないという感じ。そういう心境になるのもよく分からないところだ。

上で書いていること、どういうことなんだろう、と考えていたんだけど、自分なりに納得できるかな、という説明を思い付いたので追記しておく。

僕は、Hi-Fiオーディオ再生とは「音によってバーチャルリアリティを生み出すこと」という理解をしていた。
それはSM-SX100と4425mk2で今のシステムのベースを組んだ10数年前から認識し始めたことで、ずっとそれでやってきているのだ。リスニングルームに展開される音像音場表現をより良いものにしたい、そうすれば聴く者の感覚を鷲掴みにして音響による異世界に引きずり込み放さないような、そんな力を持つ再生音が得られるはず、そういう感じでやってきた。

384kHzまで、それは目論見どおりだった。
それがどうも、768kHzでは勝手が違った。

音は良くなっている。
でも、音の世界に浸ることが出来なくなった、とは言わないけど、なんというんだろう、、、
ステレオ再生によるバーチャルな音だと理屈では分かっていて、その音はリアルの一歩手前にいる感じで、、、
だから、もっと上があるということが、逆に分かる。
上が見えるから、もう少しで手に届きそうだという感じがする。理屈ではなく実感として、オーディオ技術が目指すべき更なる到達点がそこにある、という気持ちになる。同時に、なぜか、ここが限界ではないかという予感がする。

人形制作やバーチャルリアリティに関係する概念で「不気味の谷」というのがある。
https://ja.wikipedia.org/wiki/%E4%B8%8D%E6%B0%97%E5%91%B3%E3%81%AE%E8%B0%B7%E7%8F%BE%E8%B1%A1
引用する。

写実の精度が高まってゆく先のかなり高度なある一点において、好感とは正反対の違和感・恐怖感・嫌悪感・薄気味悪さ (uncanny) といった負の要素が観察者の感情に強く唐突に現れるというもので、(以下略)

世の中には、よく出来たオーディオを聴いて「音がリアルすぎて気持ち悪い」という感想を抱く人がいると聞いたことがある。
僕は今回、音像再生の精度が高まることで負の要素が強まったとは感じていない。
むしろ音が良くなって嬉しがって聴いている。
ただ、なぜか、音に浸りながらも、その音の前で、どこか途方に暮れる自分がいる。

不気味の谷という概念を思い出して、ああ、これかも、、と納得できるような気がした。
つまり、壁に突き当たったということだ。情報量を引き出し再生音を研ぎ澄ませていくという手法が限界ではないのかと感じているのだ。

今までは、音の情報量、リアリティを追求する方向で進んできたけれど、ここから先は同じ方向で進んでも、Hi-Fi再生によるバーチャルリアリティの魅力、有効性を高めることにはならないのではないか、ということ。

音響再生にも不気味の谷があるとしたら、それに触れた人間の感覚は陶酔から引き離されることになる。そこから先に目指すことになるのは、不気味の谷を越えた、バーチャルだと人の聴覚が気付かない、人の感覚を完全に騙すバーチャルリアリティを求めることになる。単に上質なバーチャルリアリティを目指すことは、既に目標ではない。
そんな雲を掴むような話、どうやって先を目指せばいいのか皆目見当がつかない。
しかし、そうではない方向性を選ぶのは、後退に等しい。
単純に更にサンプリング周波数を上げたら、谷を超えた違う世界が見えてくるんだろうか。しかし、多分そこは今迄僕が一喜一憂していたバーチャルリアリティなオーディオの世界とは違うような気がする。

そういえば、昨今はTV画像は4Kとか8Kとか言っているけど、情報量が増えたら、人はそのバーチャルな映像世界に入り込みやすくなるんだろうか。それは人にとって安心して没入できる世界なんだろうか。映像の情報量が一定水準以上に増えた時、そこに求められる音声は、もしかしたら、従来のバーチャルリアリティなHi-Fiでは通用しなくなるんじゃないだろうか。8Kの映像に合わせる音響は従来のステレオでは持たなくなる可能性が、ある?、、、

話が逸れた。

いったい此の先、どうするだろうかなあ、、、
音がいいから、ずっと音楽に浸ってたらいいというのが結論かもしれないけど。
実際それは可能なわけだし、768kHzまでしか現実的に無理なのだから。
さっきは後退に等しいと書いたけど、水準を維持したまま音色を変えてみる方法論もある。高級なプリアンプ使うとかDACを高級なのに変えるとか高級なケーブルやスピーカーに変えてみるとか、、、なんか気が進まんなあ、、、
今、気になるのはMQA。
これは録音の段階まで踏み込んだフォーマットだ。
音を研ぎ澄ませていく方向性に未来があるのかどうか、これを聴いたら何か新しい目星が付くならいいんだけど。

Dec 08, 2018

apu2c4で768kHzへのアップサンプリングに取り組む

Raspberry Pi2をPCトラポとして運用しているんだけど、やってみての感触から受ける印象だけなんだけど、384kHz以上へのアップサンプリングはRas Pi2初期型ではハードウェア的にいっぱいかな、という気がしている。
つまり384kHzが限界なのだ。
768kHzへのアップサンプリングは頑張っても出力できないだろうと思う。
DACを新しくしたのは700kHzの音がどうなのか確認する意味もあったので、ちょっと残念な状況。
そこでどうしたらいいか、ということを考えてみた。

まず、ハードの限界と考えるのでハードを変える。
選択枝として、まず「Raspberry Pi 3b+」が考えられる。
CPUのスペックが900MHzから1.4GHzに5割増し。うちのPi2は初期型なので、ARMv7からARMv8(64bit)にもアップすることになる。つまり64bit化が可能になる。メモリは1GBで変わらない。

課題がいくつか。
900MHzから1.4GHzへのアップで、どの程度の改善が見込めるのかという点がまず1つ。
64bit OSで使えたら処理能力アップが見込めるけど、使えるのかという点が2つめだ。

どんなOSが使えるのか。
今使っているpiCoreは、3b+への対応待ちで使えない。そして64bitへの対応はいつになるかも分からない。
raspbianは3b+で使えるけど64bitには対応していない。32bitだ。
この際なので64bitで使いたい。
ということだと、実はUbuntu、Fedora、Arch Linux、openSUSE、、と、いろいろ3b+に対応したOSがあったりする。どれか選んで、mpdをインストールして使うということになる。

ハードの選択枝はRas pi 3b+だけではない。
実は以前に、PCEngines社の「apu2c4」を入手していた。4GBのメモリを積んでるのでRAMメモリ再生機として使うつもりで入手したんだけど、結局、Ras Pi2で運用継続してしまったので、しまい込んだままになっていたのだ。
CPUはAMD 1GHzクアッドコアでほぼRas Pi2と同等だが、OSにRas Pi2で使い慣れたpiCoreの同系「Tiny Core Linux」のCore Pure 64か、dCore x86_64が使えるのではないかと思う。Tiny CoreはRAM上で動くというのも優位性と考えられる。
問題は、このハードは触らないまま今まで来てるということ。
つまり勝手が分からないのだ。
しかし勝手が分からないのは3b+でFedoraとかでも同じだ。

そんなわけで、まずapu2c4をTiny Core 64bit OSで動かしてみることにした。
参考にさせていただいたのは下記のサイト。

Tiny Core 6.1 64bit版のインストールと、dockerを動かそうとしたメモ
https://qiita.com/tukiyo3/items/d61b2054560451c47fdc

メモリ再生(8)~64bit版 Tiny Coreを使ってみる。~その1(イメージファイル配布)
http://flac.aki.gs/bony/?p=3535

インストールしたのは、CorePure64-7.2.iso。
CorePure64-9.0.isoは、SDカードへのインストールまでは出来たけどapu2c4で動かそうとしたら上手くいかなかった。
CorePure64-8.2.1.isoは試していない。

難儀したのは、なにしろ取り掛かって実際に触ってみないと、何をしたらいいのかよく分らなかったこと。何回か繰り返すうちに、だいぶ慣れた。
あと、OSインストールのベース機に使った64bitノートパソコンは日本語キーボードだったので、sshd_config.origのコピーに際して"_"の入力方法が分からなかったこと。Tiny Core OSには日本語キーボードのキー配列設定が入ってないのだ。
ネットで英語キーボードの配列を調べてなんとかした。「shiftキー」+「-キー」で"_"が打てた。
sshで接続したら、あとは概ね大丈夫だった。

tc@box:~$ uname -a
Linux box 4.2.9-tinycore64 #1999 SMP Mon Jan 18 19:59:34 UTC 2016 x86_64 GNU/Linux

tc@box:~$ cat /proc/asound/card*/pcm0p/sub0/hw_params
access: RW_INTERLEAVED
format: S32_LE
subformat: STD
channels: 2
rate: 768000 (768000/1)
period_size: 32768
buffer_size: 131072

これで、768kHz/32bitへのアップサンプリングを問題なく再生できるようになったかな、、、
今のところ、1時間以上連続再生してもノイズはない。
Tiny Coreの32bit OSだったらどうなのかは試していない。 音質評価はまだしていない。
でもとりあえず、シンディローパーのタイムアフタータイムが素晴らしく生々しい感じ。

以下、インストールのコマンドや記載内容など流れを羅列。
実際に触ったことがない人が見ても良く分からないと思うけど、自分用の備忘録だ。

備忘録だけなのも味気ないなと思ったので、分かりやすくなるように追記してみる。 まず準備するものを列記。

1)CorePlus-current.iso: Tiny Core Linuxのサイト(http://tinycorelinux.net/downloads.html)からダウンロードしたインストーラーOSのイメージファイル。「CorePlus」から落す。 うちではCD-ROMに焼いたけど、条件が合うならusbメモリに書き込んで使ってもいい。

2)64bit PC: インストールの母艦。 CorePlus-currentからの起動、SDカードへのOS書き込みと、SDカードにインストールしたTiny Coreからの起動を行う。 だから、まず必要な機能はCorePlus-current.isoを書き込んだメディアからの起動と、SDカードからの起動ができること、だ。内蔵DVDドライブとかusb接続のカードリーダー、何でもいいから、使うことになるメディアから起動できる機械を用意する。 且つ、CorePlus-currentから起動し、そこからSDカードに書き込みを行うので、2つのメディアを同時に使えるほうがいい(Tiny Coreはメモリ上で動くので、実はCorePlus-currentを起動した後はメディアは外せるんじゃないかと思うんだけど、試していない)。 64bit OSを動かすから、当然64bit PCである必要がある。 あと、sshで遠隔操作するのと、インストールするOSをダウンロードするので、ネットにつながる家庭内有線LANが使えること。 うちではhp compaq 6730b、サブマシンのノートを使った。内蔵DVDドライブとusb端子4つとSDカード端子が付いていてSDカードからの起動もできて扱いやすい。usbカードリーダーからの起動も使おうと思えば使える。

3)sshクライアントPC: ssh経由でOS、mpdのインストール操作からmpd起動までのほとんどを行うことになる。 sshが使えたら普段使いのPCで構わないと思う。

4)apu2c4: これを忘れてはいけなかった。現在は販売は終了しapu2d4が売られている。

準備ができたら、64bit PCを、CorePlus-current.isoを書き込んだメディアで起動する。 起動画面が表示されるので、下の方、「No X/GUI」と書いてあるのを選択し起動する。 CUI画面で起動するので、以下、流れを羅列。



##################    (boot 64bit PC CorePlus-current.iso CD-ROM No X/GUI : install openssh)
sudo passwd tc
tce
s
ssh
7 : 7. openssh.tcz
q
i
q
sudo /usr/local/etc/init.d/openssh start

CorePlus-currentが起動。ユーザーは「tc」になっている。 sshでログインできるように、passwdコマンドで「tc」のパスワードを設定。

tceコマンドで、opensshをインストールする。 「s」を打って「enter」、検索語入力になるので「ssh」、1からずらっと来て、7. openssh.tcz、と表示されるので「7」と打ち込むとopen.sshの説明が表示されるので「q」で閉じて、「i」でインストール。関連したものも含めてスイスイとインストールされる。「q」でtceを閉じる。

「sudo /usr/local/etc/init.d/openssh start」と打ち込むと、sshサーバーとして起動する。 これで、他のパソコンからsshでログイン、コントロールできる。



##################    (change machine : ssh login 64bit PC : install tiny core OS to SD card)
ssh tc@192.168.1.64

tce-load -wi tc-install.tcz
wget http://tinycorelinux.net/7.x/x86_64/release/CorePure64-7.2.iso

cp `which tc-install.sh` .
sed -e 's/vmlinuz/vmlinuz64/g' -e 's/core/corepure64/g' tc-install.sh > tc-install64.sh

おもむろに腰を上げて、sshクライアントとして使うPCに向かう。うちでは普段使いのノートPCを使った。 sshでCorePlus-currentが動いているインストール母艦にログイン。 ユーザー「tc」、パスは先刻設定したはず。ipアドレスは環境によって変わるので各個で確認のこと。

インストーラである「tc-install.tcz」をダウンロード、インストール。CorePlus-currentはインストールに使うOSなんだけど、なぜかインストーラをここでインストールしないといけないみたい。 続いて、インストールするOSのイメージファイル「CorePure64-7.2.iso」をホームディレクトリに落とす。 インストールスクリプト「tc-install.sh」をホームディレクトリにコピー。 そのスクリプトの書き換え。これをしないと、インストールできないということらしい。



### (insert SD card) ###
fdisk -l
sudo sh ./tc-install64.sh

i :iso-file
/home/tc/CorePure64-7.2.iso
f :frugal
2 :partition
4 : 4. sdb1
y : Would you like to install a bootloader?
Press Enter key : (Install Extensions from this TCE/CDE Directory)
4 : 4. ext4
y : Mark sdb1 active bootable? y/n
vga=normal syslog showapps waitusb=5 : Enter space separated boot options
y : Last chance to exit before destroying all data on sdb1

Installation has completed
Press Enter key to continue.

sudo poweroff

一旦、インストール母艦の64bit PCのところに戻って、SDカードを刺して、sshクライアントPCに戻る。 「fdisk -l」と打つと、64bit PC上のメディアの状況が一覧表示される。その中からSDカードのデバイス名を確認(うちではsdb1だった)。この確認を間違えると、母艦のOSが上書きされたりする大事故につながるので要注意だ。

「sudo sh ./tc-install64.sh」で、インストールスクリプトを走らせる。 「i」で、isoファイルからのインストールを選択。 次にファイルのアドレスを打ち込む。 「f」はfrugal。zipの「z」でもいいみたいだけど、今回は「f」を選んだ。画面には説明が英文表示されている。 パーティションにインストールするかどうか訊いてくる。パーティションでいいので「2」と応答。 インストールするパーティションを選択。今回は表示された中からsdb1を探して「4」。この数字はどこにインストールするかによって変わる。 ブートローダーをインストールするかどうか訊いてくる。「enter」で先に進む。 ファイル形式を訊かれるので「4」でext4を選択。 インストールするデバイスで起動可能にするかどうか訊いてくる。起動しないと困るので「y(yes)」。 オプションを訊かれるので、提示された例をコピペ。 「Last chance to exit before destroying all data on sdb1」と訊かれる。OSインストールするのでsdb1のデータが消えるのは仕方ないので「y」。

10秒ぐらいでインストール終了。 これでSDカードに「CorePure64-7.2」が書き込まれた。 「sudo poweroff」でインストール母艦をシャットダウンする。



##################    (change machine : boot 64bit PC SD card : install openssh, nfs)
uname -a
sudo passwd tc
tce
s
ssh
6 : 6. openssh.tcz
q
i

s
nfs
3 : 3. nfs-utils.tcz
q
i
q

cd /usr/local/etc/ssh
ls
sudo cp sshd_config.orig sshd_config
sudo /usr/local/etc/init.d/openssh start

インストール母艦の64bit PCのもとに移動。SDカードのCorePure64-7.2から起動する(必要ならBIOSで起動ディスクの優先順位を調整する)。 これからSDカードに書き込まれたCorePure64-7.2を使えるように設定していく。

「uname -a」でSDカードにインストールされたOSを確認できる。 Linux box 4.2.9-tinycore64 #1999 SMP Mon Jan 18 19:59:34 UTC 2016 x86_64 GNU/Linux、うちではこんな感じ。 sshでログインできるように、passwdコマンドで「tc」のパスワードを設定。

tceコマンドで、opensshをインストールする。 「s」を打って「enter」、検索語入力になるので「ssh」、1からずらっと来て、6. openssh.tcz、と表示されるので「6」と打ち込むとopen.sshの説明が表示されるので「q」で閉じて、「i」でインストール。関連したものも含めてスイスイとインストールされる。 続いて、うちではNASをマウントして使うつもりなのでnfsもインストールしておく。 最後は「q」でtceを閉じる。

sshサーバーとして動かすために、/usr/local/etc/sshディレクトリに移動。 sshd_config.origをコピーしてsshd_configを作る。ここで問題になるのは「_」の入力が日本語キーボードの表示のままに出来ないこと。CorePure64-7.2は英語キーボード配列しか認識していないからだ。日本語キーボードからだと「shiftキー」+「-キー」で「_」を入力できる。キーボードが英語キーボードだったら、こんな面倒はないかもしれない。 コピーができたら、opensshを起動。



##################    (change machine : ssh login 64bit PC : basic setting SD card)
vi .ssh/k*
ssh tc@192.168.1.64

vi /opt/bootlocal.sh

/usr/local/etc/init.d/openssh start
/usr/local/etc/init.d/nfs-client start
mkdir /mnt/music
mkdir /mnt/music/ariel
mkdir /mnt/music/titan
chmod -R 777 /mnt/music

vi /opt/.filetool.lst

etc/shadow
etc/passwd
usr/local/etc/ssh/sshd_config
usr/local/etc/
etc/fstab
etc/securetty
etc/inittab
sbin/autologin
/opt/bootlocal.sh

vi .ashrc

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

filetool.sh -b
sudo poweroff


##################    (change machine : boot apu2c4 SD card)

おもむろに腰を上げて、sshクライアントPCに向かう。 sshでCorePure64-7.2が動いているインストール母艦にログインするんだけど、アクセスする前に「vi .ssh/k*」で.ssh/known_hostsファイルを編集する必要がある。母艦にはdhcpサーバーからipアドレスを割り振られているんだけど、CorePlus-currentとCorePure64-7.2に同じアドレスが割り振られた場合(そうなる場合が多いと思うけど)、CorePlus-currentからもらった鍵はCorePure64-7.2には合わないのでログインを蹴られるのだ。 予めknown_hostsファイルに保存されているインストール母艦のアドレスの行を削除し、その上で母艦にアクセスする。 ユーザーは「tc」。パスは先刻設定した奴。

ログインしたら「/opt/bootlocal.sh」の編集。 この項は、うちに固有の設定をメモ書きしていて、他の人の参考にならない部分が多い。 しかし「openssh start」の設定は必須。これを設定しておかないと、起動したあとでログインできないSDカードが出来てしまう。 「nfs-client start」は、nfsなんて使わないという人には要らない。 mkdir云々は、うちの固有設定だ。起動時にmpdのmusic_directoryとNASのマウントポイントを作るようにしている。

次に「/opt/.filetool.lst」の編集。 参考にさせていただいたサイトからコピーしたままで、うちの環境では本当は何が必要かどうかは全く検討していない。

「.ashrc」の編集、これはうちに固有の設定。 うちではNASのマウントやmpdの起動はsshから行うのがデフォルト。コントロールは端末ソフトからncmpcppで行うので、そうした操作は苦にならないのだ。

「filetool.sh -b」でSDカードに設定を保存、poweroff。 これでインストール母艦の役割は終了。SDカードを母艦から抜き、apu2c4に刺して起動する。



##################    (change machine : ssh login apu2c4 : mpd install, setting)
ssh tc@192.168.1.90

tce-load -wi \
ncurses-dev.tcz ncurses.tcz make.tcz gcc.tcz compiletc.tcz squashfs-tools.tcz \
perl5.tcz bash.tcz automake.tcz bc.tcz glib2-dev.tcz boost-dev.tcz icu-dev.tcz \
pkg-config.tcz glib2-python.tcz dbus.tcz dbus-dev.tcz flex-dev.tcz gdbm-dev.tcz \
bison.tcz binutils.tcz autoconf.tcz libtool-dev.tcz bc.tcz cmake.tcz

tce-load -wi \
libsamplerate.tcz libsamplerate-dev.tcz \
alsa-config.tcz alsa-plugins.tcz alsa-modules-4.2.9-tinycore64.tcz alsa-dev.tcz alsa.tcz \
lame.tcz lame-dev.tcz libmad.tcz libmad-dev.tcz flac.tcz flac-dev.tcz curl.tcz

wget https://www.musicpd.org/download/mpd/0.19/mpd-0.19.19.tar.xz
xz -dv mpd-0.19*
tar -xf mpd-0.19*
cd mpd-0.19*
./configure
make
mkdir ../mpd
sudo make DESTDIR=../mpd install
cd
mksquashfs mpd mpd-0.19.19.tcz
md5sum mpd-0.19.19.tcz > mpd-0.19.19.tcz.md5.txt

ls /mnt
ls /mnt/*1
ls /mnt/*1/tce

sudo mv *tcz* /mnt/*1/tce/optional
sudo vi /mnt/*1/tce/onboot.lst

vi .mpdconf

sudo rm -rf mpd*
cp /mnt/*1/tce/onboot.lst onbootlst.txt
sudo vi /mnt/*1/tce/onboot.lst
filetool.sh -b

SDカードをapu2c4に刺して起動、apuのipアドレスを確認、sshクライアントPCからユーザー「tc」でログイン。 あとは音楽再生環境を構築していく。

mpdインストールに必要な環境や、libsamplerateやalsaなど必要なライブラリをインストール。 今回はmpd-0.19.19をインストール。 ここらの流れは、詳細が必要なら他のエントリーを参照のこと。

http://blown-lei.net/endive/blosxom.cgi/audio_diary/20180103a.html
http://blown-lei.net/endive/blosxom.cgi/audio_diary/20180529a.html

このあたりにmpdのインストールについて書いている。piCore用のエントリーだけど、似たようなものだ。 注意点は「mpd-0.xx.xx.tcz」と「mpd-0.xx.xx.tcz.md5.txt」を保管するディレクトリがpiCoreとは違うこと。うちでは今回は「/mnt/mmcblk0p1/tce/optional」だった。環境によってどう違ってくるか分からないので、確認した方がいいかな。

.mpdconfは、各個の環境に合わせて設定。 不要になったファイルをrm -rfで消去。 最後に「onboot.lst」を整理して、filetool.sh -b、で保存。

ほとんど.ash_historyファイルとかからのコピーとか。
ipアドレスとかパーティションやディレクトリのNo.とか、環境が違ったら他の数値になったりすることがあると思う。

Oct 21, 2018

ADI-2 DACとpiCoreで、384kHz以上を鳴らしてみる

最近、ADI-2 DACがメインのDACになった。
導入した目的には384khz以上にアップサンプリングして聴くというのがあって、なんとか出来たので、顛末を書いておく。

ADI-2 DACを導入して以降、ras pi 2/ppap/192khzで聴いていた。
普通に384khzで継ぐと、リーン、、、と、薄い金属が震えるような雑音が再生音に乗るのだ。jitteringっていうのかな。多少、プチプチいうノイズもある。ネット上にはADI-2 Proとras pi 2のケースで報告がある。以下引用。

https://www.forum.rme-audio.de/viewtopic.php?id=25703
RME User Forum

Volumio installation was straight-forward but I am getting some jittering (clicks) during the playback.

ADI-2 DACにはWindows用とMac OSX用のドライバが付属していて、これでusb接続を最適化していると思うんだけど、Linux用のドライバはないので、こっちが工夫しないといけない。

一時はras pi 3b+を導入して無線LANでNASマウントしてusb出力したらどうだろうか、などと考えていたんだけど、5ちゃんねるに書き込みがあって、3b+の有線lanが微妙ということらしい。それって、3b以前はどうなんだろうか。
無線lanを使う分には問題ないのかな、、、下記は書き込まれていたリンク。

https://volumio.org/raspberry-pi-3-b-plus-audio-review/
THE NEW RASPBERRY PI 3B+ AUDIO-RELATED REVIEW

As usual, I started playing my “Raspberry killer” track: a 32 bit, 678 kHz .wav file from my NAS. And… What a terrible disappointment: loads of crackles and a whole lot of lost packets.
Tried then with DSD, 24/192 flacs, and even 16/44.1 flacs. All sounded just terrible. So, indeed the new USB BUS did change USB Audio performances, unfortunately, it did for the worst.

Luckily though, I then tried to play the same files from a USB drive (and not from a NAS), and magic happened: spotless playback up to 32\768. Seemed that taking ethernet (I was connected on wired connection) out of the equation did the trick. So connected the PI via wifi and restarted without ethernet: same result, HI-Res Music playback was just perfect to my USB DAC.

しかし、他の解決策も5ちゃんねるにあった。下記、引用する。

ethtool -K eth0 tx-tcp-segmentation off tx-tcp6-segmentation off
(イーサネットチップで行っているパケット処理をオフにしてCPUで行うなうようにする)
パケットロスの発生はドライバのできによるものらしいのでベースのOSでドライバ更新されればvolumioにも反映されるようです(直す気があるかどうかは不明)

上記コマンドによる設定変更は記憶されないのでもしうまくいった場合/etc/rc.d/init.d/localにコマンド書き込んで起動時に自動実行させる必要があります
ギガビットイーサの速度が出ないときの対策なので今回の件にあてはまるかは未知数ですけどね

これは実は、piCore、pi 2用の対策ではないのだけど、
書き込みを参考に、ras pi 2/piCore9で、ethtoolを使ってみた。
他の書き込みによると、moode audioではデフォルトで設定されているらしい。
ethtool -s eth0 speed 100 duplex full というコマンドも対策として上がっていて、3b+だと有効な場合があるようだ。

tce-load -wi ethtool-doc.tcz ethtool.tcz
sudo ethtool -K eth0 tx-tcp-segmentation off tx-tcp6-segmentation off

どうも、自分が何をやってたのか、はっきりしないんだけど、、、
インストールして設定のコマンドを打って、nasマウント/384khzでノイズなしで聴けるようになった。768khzでも、設定前には全く音が出なかったのが、数秒だけど音が出る。残念だけどその後は途切れ途切れになる。
volumio2を試した時は768khzでも音が出たんだけど、プチプチノイズが乗るので使用を諦めた。384khzでもときどきある。piCore9で768khzだと途切れ途切れでプチプチノイズどころではない。反面、384khzだと問題なく聴ける。
この辺、何処をどういじったら違ってくるのか、よく分からない。

音を比較したら、nasマウント/384khzのほうがppap/192khzより少しだけ細やかな音がする。ごちゃっと塊のように聴こえていたオーケストラの弦楽が、ほぐれて滑らかに聴こえてくる感じ。少しだけの変化なんだけど、音楽としては案外大きな違いに感じられる。

しかし、この時点ではppapのras pi 2はethtoolによる設定をしていない。同じ設定をしないと単純な比較はできないと思った。

ethtoolをインストール。
ethtool -k eth0、ethtool eth0 で設定前の状態を確認。
sudo ethtool -K eth0 tx-tcp-segmentation off tx-tcp6-segmentation off で設定、、、
ethtool -k eth0、ethtool eth0 で設定後の状態を確認、、、設定表示に変化なし。
なんなんだろうこれは。。。

実は、nasマウント/384khzのほう、コマンドを打つ前と後で設定表示の変化を確認していなかったことに今更気付く。ということは、コマンドが本当に効いたのかどうか、実は分からないということなのか?
5ちゃんねるの書き込みには設定変更は記憶されないとあるが、どうも、picore9だと、記憶されているような。というのは、リブートしても効果が続いているからだ。
いや、それって、コマンドで設定変更されてないという可能性もあるんじゃないのか。

piCore9を1から焼いて試してみる。
結果から言うと、、、どうも、ethtoolは関係ないらしい。インストールしなくても384khzの音が出ている。
現在の.mpdconfの設定は下記のような感じ。

samplerate_converter                "Fastest Sinc Interpolator"
audio_output_format                 "384000:24:2"

audio_buffer_size "32768"
buffer_before_play "20%"

audio_buffer_size を奢るというのが決め手だったらしい。
そうなのか?おっかしいなあ、、、

11月6日、追記。
日々あれこれと聴いてるうちに、ときどき、チリ、、、チリ、、、とノイズが入ることに気付いた。
まあ、アナログみたいなもんかと思って無視することもできるんだけど、対策を検討、、、
audio_buffer_size "65536"
buffer_before_play "20%"
こんなところで、とりあえず様子を見ている。おさまったように思うんだけどな、、、

さて、改めて、音の方はというと、やはり情報量はnasマウント/384kHzのほうが多い。音の勢いは、ppap/192kHzのほうがあるように聴こえる。この辺り微妙で、でもよく聴くと、ppap/192kHzは微かに音が滲んでいるせいで強く聴こえるということが分かる。nasマウント/384kHzのほうが正確だ。

例えばジョージウィンストンのLinus & Lucyとか聴くと、ppap/192kHzだと「この重いピアノの音は何?」って思うんだけど、nasマウント/384kHzだと「ああ、重い音なんだこれは」と納得がいく感じ。楽器の特性によるものか演奏の仕方によるものか僕には判断が付かないけど、ニュアンスが伝わって音色を理解しやすくなる。
アストラッド・ジルベルトのデビューアルバムも、以前は眠たく甘ったるいだけの声で蓼食う虫も好きずきだと思っていたのが、384kHzにアップサンプリングしたら、表情があるリアルな女性の歌声だと分かるようになった。今回、改めてこの音源の音質について調べて、実は初期のアナログプレスで「VAN GELDER」の刻印があるのが音がいいとされている、ということを初めて知った。正直、以前だったらそんなこと調べる気にもならなかったんだけど。

nasマウントでここまで音の表情が出るんだから相当だと思う。
なんだかノウハウの信憑性に疑問があるが、とりあえず音が出て、その音がいいので、今のところはそれでいこう、という感じ。

ついでに、/mnt/mmcblk0p2/tce/onboot.lst を編集してシステムを軽くしておく。

mc.tcz
openssh.tcz
boost-dev.tcz
libsamplerate-dev.tcz
libsamplerate-doc.tcz
flac-doc.tcz
libcue.tcz
libcue-dev.tcz
icu-dev.tcz
libid3tag-dev.tcz
libmad-dev.tcz
mpg123.tcz
mpg123-dev.tcz
mpg123-doc.tcz
lame-dev.tcz
lame-doc.tcz
libmpdclient-dev.tcz
libmpdclient-doc.tcz
alsa-oss-dev.tcz
alsa-oss-doc.tcz
alsa-plugins-dev.tcz
alsa.tcz
alsa-utils-doc.tcz
alsa-utils-locale.tcz
mpd-0.19.19.tcz

音の変化は、どうなんだろうなあ、、、正直、明らかな変化は感じない。悪くなってはいないと思う。
サンプリング周波数が高くなると変化が目立たなくなるんだろうか。

768kHzではどうなのかという課題がある。

前述のpi 3b+のレビューでは、usbメモリの768khzハイレゾファイル再生に問題なしとある。うちはアップサンプリングするので、それよりも負荷は多い。 しかも、pi 2でどうなのか。LANがボトルネックということなら、RAMメモリ再生でどうなのか。

44.1/16ファイルの768khzアップサンプリング再生を試してみる。「audio_buffer_size」を90000まで上げる。音が出始めるまで数十秒かかり、音が出て数十秒間は再生できた。その後は途切れ途切れで音楽にならない。audio_buffer_sizeが小さい値だと、最初から途切れ途切れになる。
どういうんだろ、libsamplerateでアップサンプリングするのが間に合わないのかな。もしかしたら、SoXだったら上手くいくかもしれない。しかしpiCore9でSoXはリポジトリにsoxr.tczがないので使えない。

オーバークロックしてみるという手があるかも。

arm_freq=1000
core_freq=500
sdram_freq=500
over_voltage=6

こんな設定で鳴らしてみたら、実用にならないのは同じだが、多少マシになった。
ということは、ras pi 3b+のほうが可能性があるということか、、、

さて、piCore7はppap/192kHzが上手くいかなかったから最近は使ってなかったんだけど、オーバークロックしてSoXのアップサンプリングが使える。と思って、やってみたけど、ダメでした。192kHzでもjitteringが乗る。
192khz以上のアップサンプリング音源をADI-2 DACで聴くには、piCore9以降が必要みたいだ。

将来的には、ppapで384kHz以上が使えるようになったら使ってみたいと思う。

あと、Ras pi 3b+を入手して、無線でNASマウントしてみたい。
lanとusbを1チップで処理するras pi 2はusbオーディオでは不利だ。3b+なら無線LANとusbで、入出力の処理を別の経路に振り分けることができる筈だ。前述の3b+のレビューによると無線lanは使えそうだ。
問題は、piCoreがまだ3b+に対応してないこと。対応するのはpiCore10で、現在はベータ版がリリースされている。いろいろ手を入れて使うにはスキルが要る。普段使ってないが、raspbianでいいじゃんという考えもある。piCoreが対応するまでのつなぎには充分かな。余裕ができてからか。

Posted at 09:25 in audio_diary | WriteBacks (0) | Edit Tagged as: , ,

Sep 26, 2018

raspberry piをncmpcppサーバーに仕立ててみた

最近はmpdクライアントが少なくなってきていて、いつだったかiPad用の定番ソフトがアップデートされないというので話題になった。現在もいくつかのソフトが残っているが、昔のようにいろんなソフトから好きなものを選べるという感じではなくなっている。
うちのデジタルオーディオ環境はCDをリッピングした flac + cue sheet が基本なので、mpd + cue sheetに対応したmpd client という手法を捨てられない。数千のアルバム単位のflacファイルを、曲ごとに切り分けるなんて作業は絶対に自分ではしたくない。
そういうわけで、cue sheet対応のncmpcppが使えるのは非常に有難い。開発終了にならないことを祈っている。

今回は、Linux用のクライアントソフトであるncmpcppを、ssh経由でwindowsやmacで使えないかという話だ。
うちでは家族の希望を聞いて、音楽を鳴らすことがある。だから、女房や子供が使うPCからオーディオを操作できたほうがいいんじゃないかという考えは、以前からあるのだ。

ncmpcppはターミナルソフト上でcuiで動くクライアントだ。
cuiと云いながら実際は、ターミナル「画面上」に表現された階層的な空間を、主にショートカットキーと補助的なマウス使用で、移動、選択、決定、指示を打ち込むことで操作するという、下手な文章で書いたらよく分からないけど、かなりgui的な性格を持っている。
個人的には、神憑り的に使いやすいと思っている。
不満といえばライブラリーブラウザが文字表示の一覧表(かなり使いやすいと思っている)で、itunesのようなアートワーク表示ができないことぐらいだ。アートワークを見て聴きたい曲を探すというのができたら、ほんとうに僕にとって完璧なクライアントなんだけど、、、cuiなんだから無理言うなって感じだ。

Fedoraでncmpcppを使っている画面をスクリーンショットしてみた。
これはプレイリスト画面。「1」キーで表示される。

Fedora playlist

この際なので、いくつかスクショを追記することにした。
以下の画像はFedoraのncmpcppではなく、Fedoraからssh経由で表示したraspbianのncmpcppのスクショだ。

下は、ブラウザ画面。「2」キーで表示。
mpdは、musicディレクトリがそのまま階層化されたライブラリになるんだけど、それがそのままブラウザ表示される。カーソルキーとショートカットキーでディレクトリを移動しスペースキーでプレイリストに追加する。慣れれば快適だ。

Fedora browser

次は検索画面。「3」キーで表示。
タグやファイル名から検索する。日本語も検索できる。

Fedora search

最後はヘルプ画面。「f1」キーで表示。非常に細かい。
普段、音楽を聴くだけなら、そんなにたくさんのキーは使わないんだけど、ちょっと目がまわる感じだ。

Fedora help

ちょっと気になることがあって追記。
ヘルプ表示を下方にスクロールしていくと以下のような記載がある。

Keys - Browser

Delete : Delete selected items from disk

ブラウザ表示の時に、何か音源等を選択して「delete」キーを押すと、ディスクから削除されるらしい。
じゃあ、実際やってみたら削除されるのかというとそういうことはなくて、代わりに下記のような一文が表示される。

Flag "allow_for_physical_item_deletion" needs to be enabled in configuration file

設定ファイルで設定しないと使えない機能ということだ。
逆に言えば、設定してしまえば、使えてしまう機能というわけで、さすがに[yes/no]は表示されるんじゃないかと思うんだけど、注意して使いましょうね、という感じ。

最初は、ncmpcppそのものをwindowsやmacにインストールできないかと考えていた。だけど、ncmpcppはlinuxのソフトなわけで、windowsやmacではインストールする環境を作ることから大変なのだ。
どうしようかと思っていたんだけど、先日ふと、macやwindowsからsshを使って、ncmpcppが動くlinuxにログインしたら、macやwindowsでncmpcppを使えるってことにならないか、と気が付いた。

うちではノートパソコン2台にlinux(Fedora)をインストールしていて、日常の使用とかncmpcppの運用に使っている。試しにこれらのlinux機2台で、sshによるncmpcpp共用を試みたところ、全く問題なく違和感なく使うことができた。
次にうちにあるwindows機、mac機から、sshでFedora機にログイン。ncmpcppを起動。表示に使われるフォントの違いによるものか、受ける印象は多少異なるものの、問題なく使用できた。

これでいいじゃん、と思ったんだけど考えてみると、うちだとこれでいいけど、一般的には簡単にncmpcppを動かせるlinux機が置いてある家庭は少ない。しかし、部屋のすみに転がって埃を被ってるraspberry piを使ったら簡単に出来るんじゃね?というのを思い付いた。
この際、うちでもやってみよう、ということだ。
下図のようなイメージ。

mpdとクライアントを同じサーバー機にインストールするというのはよくあるし、操作端末にクライアントをインストールして使うというのもあるけど、敢えてmpdと操作端末の間にクライアントを設置するというのは、あんまり見ない気がする。

使用したのは、Raspberry pi B+。本当に使わずに放置されていた機体だ。
まず、piCoreで出来ないか試したけど、これが意外にncmpcppのインストール自体が面倒で却下。
ncmpcppのサイトには「Most of the popular Linux/*BSD distributions have ncmpcpp in their repositories, 」と書いてあるんだけど、piCoreのtczには登録されていない。

raspbianでどうか。
これが簡単にncmpcppサーバーになってくれる。
リポジトリにncmpcppがあるので「apt-get install ncmpcpp」とコマンドを打つだけでインストールできて、あとはconfigファイル、bindingsファイルで設定したら使えるようになる。バージョンもncmpcpp 0.7.4なので比較的新しい。
ちなみにFedoraのリポジトリにあるのはncmpcpp 0.8.2で最新だ。Fedoraはラズパイでも動くらしんだけど、これはこれで大変そうなので今回はやめている。Cent OSだと0.5あたりだったか、、、かなり古いバージョンだったと記憶する。それで普段使いをFedoraにしたという経緯がある。

今回、ncmpcpp専用機をraspbianで仕立てたけど、mpdが動いているラズパイにncmpcppをインストールしてしまうという手もある。しかしうちでmpdが動いているのはpiCoreで、ncmpcppのインストールが手軽にとはいかない。それにmpdサーバー機に余計な負担は要らないだろうというので、別にした。

Raspbianでのncmpcppインストール、設定のしかたについて、簡単に記載しておく。

まず、raspbianを設定。
raspbian stretchをダウンロード。microSDに書き込んで、bootディレクトリにsshファイルを作る。
ラズパイに刺して起動。
ipアドレスを確認しsshでログイン。ユーザーは「pi」、パスワードは「raspberry」。
コマンド「sudo raspi-config」で初期設定。
いろいろ設定するけど、ここでは多くは説明しない。ラズパイの解説サイトを参考にして欲しい。

さて、設定ができたら、ncmpcppをインストールする。
「apt-get install ncmpcpp」とコマンドを打ったら、文字がぞろぞろ表示される。
程なくインストール終了。

次に「man ncmpcpp」と打つとncmpcppのマニュアルが表示され、設定をどうしたら良いか書いてある、、、
けど、けっこう読むのは面倒だ。

ユーザーのホームディレクトリ(今回の場合、piディレクトリ)に.ncmpcppディレクトリをつくり、そこにconfigファイルとbindingsファイル、2つの設定ファイルを置く。
ファイルの原本がどこにあるかは「man ncmpcpp」と打ったときに表示されるマニュアルに記載されている。一般的には「/usr/share/doc/ncmpcpp」にあるので、これを持ってきて使えばいい。

その設定内容なんだけど、何十項目もあって、ちょっと僕自身が把握しきれていない。画面のカスタマイズをする項目もあって、昔に多少いじったこともあるんだけど、すっかり忘れてしまった。
しかし、絶対に設定しなくてはいけない項目は意外に少ない。それ以外はデフォルトのままでも使えてしまう。

configファイルで設定しておくのは、

mpd_host = "192.168.1.xxx"

mpdサーバーのip アドレス。
これだけは必ず設定しておかないと、mpdとncmpcppがつながらない。
各自の環境に合わせてアドレスを設定する。
あとは、タグエディターを使用したかったら設定しておかないといけない項目とかあるんだけど省略。僕はタグの管理は他のソフトで行っているのでよく知らないのだ。

Bindingsファイルではキーボードショートカットを設定できる。デフォルトのままで気に入らない場合は、ここで設定変更してしまえばいい。
僕の場合、「back space」キーで曲再生がリプレイするのが気に入らなかったので「t」に変更してある。

#
#def_key "backspace"
#  jump_to_parent_directory
#
#def_key "backspace"
#  replay_song
#

デフォルトはこんな感じ。コメントアウトされているけど、ブラウザ画面で上位ディレクトリへの移動、プレイリスト画面でリプレイが設定されている。
この下に、下記の4行を書き加える。

def_key "backspace"
  jump_to_parent_directory
def_key "t"
  replay_song

こんな感じ。これでリプレイを「t」キーに設定できる。
他には「f1」キーでヘルプ表示なんだけど、これがFedoraの端末ソフトのヘルプ表示と競合したので(これもf1キーでヘルプ表示の設定)、ターミナルのほうの設定を変えている。それができないようなら、ncmpcppのほうの設定を変えることになっていたかな。

これで「ncmpcpp」とコマンドを打てば起動する。
設定が正しければ、使いたいmpdの状態が反映された画面が表示されるはずだ。

windows7にsshソフトをインストールしてラズパイにログイン。「ncmpcpp」とコマンドを打った画面が以下。
ちょっとレガシー感あるけど、フォントの設定とか変えたらかっこよくできるんじゃないかな、どうだろう。
見てくれは兎も角、ちゃんと使える。
MacだともっとFedoraの画面に近くなるのだけど、スクショは省略。

ウィンドウズ

9月30日、追記。Macについて。

使えるのは使えるけど、よく見たら「back space」キーがない。
Macの「delete」キーが、通常の「back space」として機能する。「delete」の機能は「fn + delete」で代替する。これはMacの約束事らしい。数十年、Macとwindowsを触ってきて、初めて気付いた。
これは紛らわしいので、他のキーに設定してしまうのもありかもしれない。

もうひとつ、「f1」キーでヘルプ表示が機能しない。
アップルは最新型でfキーを廃止したり、ノーマリゼーションというものを甘く見てるようだ。
これはbindingsファイルで使えるキーに設定しないと、慣れないうちは使いにくい。
幸い「h」キーが空いているので、下記を書き加えて設定した。これでMacでもヘルプ表示できるようになる。

def_key "h"
 show_help

mac、windowsで使えるのは確認したが、iPadのような端末でどうなのかは試していない。うちには今どきタブレット端末がないのだ。android携帯にsshソフト(JuiceSSH)をインストールして、使えるかどうか試してみた。
現在は使えているが、最初は下記のようなエラーが表示された。

pi@raspberrypi:~ $ ncmpcpp
Reading configuration from /home/pi/.ncmpcpp/config...      
Terminal doesn't support window title, skipping 'enable_window_title'.

「enable_window_title」というのはncmpcppのconfigファイルに記載されている設定で、デフォルトは「yes」。端末ソフトのウィンドウのタイトルバーに「ncmpcpp 0.7.4」と表示するかどうかの設定だ。androidのsshソフトにウィンドウタイトルがないから、こういうことになったらしい。
設定を「no」にしたら動くかというと、エラー表示されないまま止まってしまう。

繰り返しログイン、ログアウトするうちにncmpcppの操作画面が表示された。
これで使えるかと思ったんだけど、表示されただけでキーボードからの指示を受け付けない。ソフトウェアキーボードだからかどうかは、はっきりしない。
実際のところ、ncmpcppの操作はほとんどキーボードで行う。キーのひとつひとつに役割が振られていて、例えば「p」は一時停止、「r」はリピート、「s」は停止、「y」は1曲のみ再生などなど。ライブラリの階層移動や曲の選択もキーボード操作で行うので、キーボードに反応しないのでは使えない。
あんまり無理はしないほうが良さそうだ。

とか思っていたら、数日後に試みたら使えるようになっていた。
何が良くて何が悪かったのか、分からないままだ。
Android操作画面のスクリーンショットをアップしておく。

アンドロイド1 アンドロイド2

問題なく動くのかといったら、ひょっと何かの拍子に画面表示が不安定になる。
他の画面に切り替わった後で、戻したら曲順が正確に表示されていないとか不具合が生じる様子。
上の2つ目の図がそのスクリーンショット。一旦「exit」して、再度「ncmpcpp」を打ったら正常に戻る。扱いには注意がいるようだ。

使えるけど画面が狭いので不便だ。もっと画面が大きいタブレットだったら違うかな、、、
あとソフトキーボードに「delete」キーがない。これはデフォルトではプレイリスト上で選択した曲を削除するキーなので、使えないのは痛い。bindingsファイルで、使えるキーに設定したらいいかな。「d」あたりがいいのかな。

こんなのできるようにしたよ、と女房に言ったら「誰が使うの?」と言われてしまった。
大丈夫、想定内だ。

Posted at 19:24 in audio_diary | WriteBacks (0) | Edit Tagged as: , ,

Sep 17, 2018

RME ADI-2 DACを導入した

9月上旬、RME ADI-2 DACを導入した。
ChordのDACにしようか、ADI-2 Proにするかとか、それ以外のメーカーか、、、
ずいぶん悩んだけど、決めるときはあっけない。1万以上のポイントに釣られたわけじゃない。いや、釣られたけどさ。釣られるなりの理由はあるさ。

音の方は、意外にUCXよりもいい感じ。
この程度違うなら買い替えはありだな、と思った。
ただ、UCXは本領を発揮してないんじゃないかという疑いがある。
というのは今までに、spdif入力(CDP、hifiberry-digiなど)と、ラズパイpiCore7のusbでCCモードは使用経験があって、CCモードのほうがいいと思って使ってきているけど、UCXのusbにはmacやwindowsにインストールしたTotalMix FXを使って音を出す方法があるのだ。というか、それこそが本来の使い方だ。最適化されてるんじゃなかったかな。
今までにそういう使い方はしたことがない。
CCモードはあくまでiPadへの最適化で、Linuxは想定外だ。
だから、UCXとADI-2 DACの音質の違いを見極めようと思ったら、それをやってみないといけない、と思っている。
何時になるかわからない。先のことだ。

ADI-2 DACだけど、ネット上に他にレビューがいくつかある。うちでどうなのかだけ書いとこうと思う。

まず電源だけど、プラグ差込口にストッパーがついていて、刺して捻ったらしっかり固定できるようになっている。
というか、捻らなくてもちゃんと固定しているんだけど。USXのが抜けやすい感じだったのとくらべたら、そうとう安心感がある。
じゃあ、ストッパーがない電源プラグが使えないのかと言ったらそんなこともなく、うちではiPowerをつないで音が出ている。ふつうの5.5mm×2.1mmのプラグでいいようだ。
電源アダプターの違いによる音質比較はまだしていない。付属アダプターでも案外充分というレビューを読んだことがあるが、そうだろうな、とは思う。

マニュアルを読みながらセッティングしていくのだけど、UCXはマニュアルがないとどうにもならない(というか、読んでも難しい)という感じだったが、ADI-2 DACは時々参照するという感じだ。

さて、まずはUCXに刺しているusbケーブルを抜いて、ADI-2 DACに差し替えてみる。PPAPで24/96。簡単に音が出た。
次に、別のラズパイを用意して、新規でpiCore7を焼いたmicroSDで起動、mpdをインストールして、NASマウント再生環境を作る。
問題ないかなと思ったら、、、どうもおかしい。
グールドのピアノにときどき、鈴を細かく鳴らすかのような「リーン、、」というような音が乗るのだ。
こんな音、ソースに入ってないよね? 他のソースでも同様。
アップサンプリングを設定してたんだった、、、これを止めたら、消えた、かな、、、
しかし、なんか気持ち悪いね。
ADI-2 DACは768kHzまで使えるはずなんだけど、piCore7でアップサンプリングで指定しても音が出ない。384kHzでは前述のノイズで全くだめ。192kHzでも、ときどきノイズが混じるので、使いたくない。
アップサンプリングなしの設定だとCDリッピングファイルは普通に鳴るようだけど、ハイレゾファイルだと高い周波数のはノイズが乗る、、、
どういった塩梅かね、、、

ちょっと思いついて、piCore7をpiCore9にバージョンアップしてみた。使われているalsaのバージョンが違う。
これで、192kHzはノイズなしに使えるようになった。
でも、368kHzではまだ鈴の音のようなノイズが乗る。

今年の4月、alsaがバージョンアップして、aplayerが192kHzより上のサンプリング周波数にも対応したらしい。aplayer以外がどうなってるのかは、よく調べていない。新しいDACにusb接続する場合、PCトラポにも新しさが求められることがあるのかな。
Macで384kHz以上で動くからLinuxでもいけるかな、じゃダメなのかもしれない。
というか、それだから手を出せなかったんだけどさ。
UCXだって、導入当時はそれで随分迷ったのだった。
usb接続って、そういうところでもハードルがあるんだよね。何か音楽信データ号伝送のデフォルト仕様があればいいんだろうけど。

piCore9に最新バージョンのalsaをインストールしようとしてみたがうまくいかなかった。
そういうわけで、今はpiCoreのバージョンアップ待ちだ。
そのうち768kHzを伝送できるようになるんじゃないかな、たぶん。

現状は、piCor9.03でPPAPで、max192kHzで使用継続中だ。piCore9だったら、192kHzまでの使用なら問題ないんじゃないかな。
もしも問題があるようなら、ここに追記していこうと思っている。

9月30日、追記。
久しぶりにvolumio2をいじってみた。いやあ、進化してるねえ、、、
問題なく768kHzを再生できる。

10月9日、追記。上記を訂正。
問題ないかと思ったけど、768kHzで聴いていたらプチプチいうノイズが入ってくる。
384kHzだったら、だいたい問題ないけど、それでも少しプチノイズが入ることがある。
ちなみにSoXがデフォルト。libsamplerateもインストールされてるようだけど簡単には使えないような仕様。
volumioのバージョンは2.457。

sshでログインしてみる。

volumio@volumio:~$ aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: ALSA [bcm2835 ALSA], device 0: bcm2835 ALSA [bcm2835 ALSA]
  Subdevices: 7/7
  Subdevice #0: subdevice #0
  Subdevice #1: subdevice #1
  Subdevice #2: subdevice #2
  Subdevice #3: subdevice #3
  Subdevice #4: subdevice #4
  Subdevice #5: subdevice #5
  Subdevice #6: subdevice #6
card 0: ALSA [bcm2835 ALSA], device 1: bcm2835 ALSA [bcm2835 IEC958/HDMI]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 5: DAC52973504 [ADI-2 DAC (52973504)], device 0: USB Audio [USB Audio]
  Subdevices: 0/1
  Subdevice #0: subdevice #0
volumio@volumio:~$
volumio@volumio:~$ cat /proc/asound/card*/pcm0p/sub0/hw_params
closed
access: MMAP_INTERLEAVED
format: S32_LE
subformat: STD
channels: 2
rate: 768000 (768000/1)
period_size: 32768
buffer_size: 131072
volumio@volumio:~$ aplay --version
aplay: version 1.0.28 by Jaroslav Kysela 
volumio@volumio:~$

どうもalsaのバージョンだけの問題でもないようだね、、、
piCore9のaplayはversion 1.1.1だ。
また暇なときに調べる。

Posted at 16:48 in audio_diary | WriteBacks (0) | Edit Tagged as:

Aug 28, 2018

fireface UCXの電源をiPowerに替えてみた

前回、UCXの電源アダプター出力に自作のフィルターをかませてみたら失敗だったという話を書いた。
今回はその後の状況の話。

まず、UCX用自作フィルター1号の出来があんまりだったので、2号を作成した。
2号と言っても部品は全く同じもので、5.5/2.1mmのプラグ(オス、メス1対)と0.027μFのフィルムコンデンサー。何が違うかというと、配線とか半田付けを若干丁寧にしてみましたというもの。あと、1号で補強のつもりで塗りたくっていたグルーガンの接着剤を使っていない。

使ってみて音はどうかというと、意外に2号は1号のような副作用がない。1号は音がこもり覇気がなくなってしまったけど、そこまでの感じがないのだ。よく聴くと、ちょっとだけ音が丸いかな。継いだままにして1、2日と様子を見ていたら、なんとなく効果が出てきた。丸くなっていた音が出るべきところは出るようになり、逆に音色のニュアンスがフィルターなしの時よりも出るようになった。外して聴いてみたら、なんとなく耳障りな感じがする。少しコントラストが悪くなる感じ。
フィルター2号は使える。
1号とほとんど同じ構造なのに、ずいぶん違うもんだと思った。
しかし考えてみたらケーブルとか被膜で音が変わるんだし、接着剤を塗ったかどうかは意外と大きいのかもしれない。

UCXの電源を改善したら音が良くなるというのはあちこちで言われている。楽器用電源(YAMAHA PA-6の代替品)を入手しようとして果たせなかった顛末は前回書いたけど、PA-6はネットショップで売られていることもある。しかしなんだか割高で、付属品の電源で大きな不満はないし、どうしようかなと思っていた。
しかし、簡単な自作フィルターでも確かに変化がある。
この際だから、最近評判がいいiFI-AudioのiPowerを使ってみることにした。

うちではUCXの電源アダプターはUPS(omron BY50S)のAC出力コンセントにつないでいる。
理由ははっきりしなくて、Ras piとかといっしょに安物の電源タップにつないでノイズが多い環境にするよりUPSのコンセントひとつ充てがうほうが良かろうと思ったんだろうけど、実際に音質に差があるかどうかは確認していない。
今回、とりあえずiPowerは電源タップにつないでみた。
というのは、iPower本体の形状とUPSのコンセント使用状況の関係で刺せなかったのだ。UPSには4つコンセントがあって3つが埋まっている。残っているコンセントにiPowerを刺そうとしたら、既に刺さっているプラグが邪魔で刺せない。刺すには使っているプラグをいくつか抜かないといけない。

書き忘れていたが、前述の電源タップはUPSの出力コンセントに刺している。つまり、壁コンセント→UPS→電源タップ→iPowerと繋がっている。UPSには電源タップが2つと、UCX付属品ACアダプターが刺さってる状況だ。

iPowerと、付属品ACアダプター自作フィルター付を比較、、、
あんまり差がない?
継いだ直後に比較ではiPowerに分が悪い。継いだまま様子を見る、、、あんまり変らんかな?

電源タップに刺したままでどうなのよというのはある。
ホームセンターでACプラグを買ってきて、UPSとの接続用コードを自作した。
この際なので、UPSにつなぐ側はコンセント形状に合わせて接地極付きのプラグにした。そのほうが刺した時に物理的に安定すると思う。購入費は400円ぐらい。iPowerにつなぐ側は100円程のありふれた家庭用ACプラグを使った。長さは30cm程度でコードはこれも家庭用の安価な奴だ。
これでiPowerと付属品ACアダプターの条件が同じになる。

ここで、出てくる音に違いが出て来た。
iPowerを使った方が楽器の分離が良く音色の階調が深くなる。極端に大きな差はないけど、UCXは電源にこだわったほうがいいと思った。
自作フィルターとiPowerを併用したら若干音色が柔らかくなる。ごく僅かに情報量が減るように聴こえないこともないけど、音色が柔らかいので音量は上げやすいので副作用は少ない気がする。意外と好みで使い分けてもいいような。
まさか、もしかして、、こっちのほうがいい?、、、判断は保留しておく。

Aug 12, 2018

USB電源用のDCノイズフィルターを作ってみた

7月は岡山も水害があり、仕事の同僚が被災したりして、どうにもブログを書くとかいう気分になれなかった。他にもいろいろあった。
でも、なんとなく最近になってぼちぼちでも再開しようかという気持ちになれたので、書いていこうと思う。

タイトルにあるように、USB電源用のノイズフィルターを自作してみた。
自作と言うのは恥ずかしいぐらいのもので、半田付けしたから自作、みたいな。例によってGNDと+をキャパシタで繋いだだけで、何Hzのノイズを狙ってとか考えもなく、あわよくば高周波を減らせたらいいや、手元にある部品を使って様子を見よう、で作ってしまったようなものである。うちにあるのはそんなのばっかりだ。

オスメスのusb端子はウェブ通販で購入。メス端子のほうに基盤がついていて、オス端子を半田付する。キャパシタは地元の部品屋で購入した0.027μF。
半田付の固定だけでは強度が心許無いので、写真の状態の後、ヒートガンで固めている。
うちのras piに使っているusb電源は、いくつか変遷した後、現在はELECOMのAVA-ACU01という小物になっている。白地に顔が付いたバージョンで、ゆるキャラ系だ。1個500円で売られていたものを複数まとめ買いして携帯の充電に使ったりしていたんだけど、試してみたら意外にいいんじゃないかな、ということでオーディオに使うようになったのだ。
いいといったって、オーディオ用の電源などは試してないので、ほんとうはiPowerとかのほうがいいんだろうなあ、などと思ってるんだけど、3つ買ったら2万円になるし、ちょっと手持ちの部品を試してみてから検討してもいいかな、ということで、やってみた。

結果は、意外にいいような。
音が滑らかになり奥行が出て、微かにまとわりついていたギラつきが消えて音色がより分かりやすくなった。
まだ改善の余地があったと比べて気付いた。
以前からときどき試聴に使っているエネスクのルーマニア狂詩曲2番とか、1年前よりもずっと聴きやすく美しく鳴るようになってきているんだけど、さらに気持ちよく鳴るようになった。

ロック音源の関係で驚いたことは、THe Whoの「Live at Leeds」を聴けるようになったということ。
聴けるってどういうことかというと、僕はこのCD音源を学生のころに購入して、あんまりにも音が悪いと思って聴き通せず中古屋に売った(他の物を買う元手にしないといけないので)という経緯があるのだ。ノイズっぽいし籠っていて精彩を欠くという再生音。ただ、当時のオーディオシステムはトータル数万円のシスコンで、スピーカーは16cm?フルレンジ?にプラスチック製で直径1cmのドームツイーターが付いていて、ツイーターの傍に耳を近づけても音が聞こえなかった。マイルスのトランペットとコルトレーンのサックスを聴き分けられないという代物だった。
しかしその後、これを持っていないというのはロックファンとしていかがなものかという気持ちに負けて、再購入したのである。その後、システムが変わっても良い音だと思ったことは全くなかったし、そもそもパッケージにノイズなんかは気にするなという旨のコメントが予め書かれているのである。最後まで聴き通した記憶が無い。

その音源が、あろうことかTAS Super LP Listに載っているのである。
http://www.theabsolutesound.com/articles/2018-tas-super-lp-list/

まあ、リマスターで再発のアナログ盤なので、初期CDとは別物だろうけど。
しかし、どこにか優秀録音の片鱗があるのかもしれない、聴いてみないといけないと思って聴いてみたら、なんと、意外に聴けるのだ。パチパチノイズが入っている(8794年のCDでリマスター前のものだ。リマスター後は消えている)けど、ロック演奏の生々しさは、確かに音源に記録されていて、最初から最後まで感動を持って聴き通せたのである。
リマスターCDはどうなのよと思って入手したらノイズが消えていて、初期CDより聴きやすくなっている。音が明るいというのかな。ただ何というのか、、、Live at Leedsってなんだか、ヘビーな初期CDのほうが自分には馴染む気がする。好みだろう。
しかしなるほど、名盤とされるだけのことはあるんだこれはと、ロック聴きだして35年でようやく理解するに至った。

TAS Super LP Listはアナログ音源なんだけど、CDでもいいかと思って最近は参考にしている。
ポピュラー系にはLive at Leedsのように意外な音源もアップされていて、どう料理するか考えろというリストなのかなこれは、と思うようになった。

そんなこんなで、電源アダプターのDCラインというのは対策しやすいのかな?と思って、fireface UCXのDC入力プラグに、上記のフィルターと似たような構造のアダプターを作って噛ませてみた。どうだったかというと、こっちは全く駄目で、再生音がこもり覇気がなくなってしまった。
ひとつ覚えではやはり無理みたいだ。
こっちのほうこそiPowerを使ったほうがいいのかな、、、

UCXの電源といえば、1年も前になるかもしれないけど、楽器店で電源アダプターを注文しようとしたことがある。楽器用のものを流用して音質アップを図ろうとしたのだ。受付でにこやかにどういったご要件でしょうか、と尋ねてくるお姉さんに、これこれの代替品の電源アダプターが欲しいんですがと切り出したところ、たちまちお姉さんの表情がかき曇った。そして、何を言われたかは全く覚えていないのだけど、対応できない理由について、なんでそんな顔して話す必要があるのかというような、苦虫をかみ潰したような、親の仇を見るかのような表情で話すのである。こちらは平静を装いながら、いや、難しいんならよろしいんです、、、と精一杯の応答を絞り出したのだった。
いったい、何があったんだろう。

オーディオで気になることは他にもいろいろとあるんだけど、まず、alsaがバージョンアップしてaplayで扱えるサンプリング周波数が上がったこと。

http://www.alsa-project.org/main/index.php/Detailed_changes_v1.1.5_v1.1.6

aplay: Adjust sample rate limits to support newer hardware
There are number of devices that support up to 384 kHz sampling rate and some devices up to 768 kHz sampling rate. This patch increases sanity check limit to 768k in order to support testing of such hardware.

しかし、まだpiCoreには移植されてないんだよね。自分でコンパイルも試みたけど難しい、、、
まあ、使えるようになるまで待とうかと。

これが使えるようになれば、384kHzとか768kHzにアップサンプリングしたPCM音源をPPAPで鳴らすことが出来るかもしれない。
768kHzが使えるDACがCHORDとかRMEから発売されている。
こういうのに入力したらどんな音が出るだろうと思うんだけど、、、
これらのDACは、MQAに対応していない。RMEとかサイトでMQAを推してるのに対応してない。
フィルターとかクロックとかで高度な技術を使っている分だけ、対応に時間がかかるというのはあるんだろうか。
どうしようかなと。

MQAは、誰も言わないみたいだけど、僕が勝手に考えてるのは、見当違いかもしれないけど、PCMよりもジッターの影響を受け難いのではないか、ということ。
つまりノイズ管理やクロック精度の重要性が低くなり、デジタルオーディオの一番厄介な部分の労力が減ることになり、かなり気楽に構えていても安定して良い音が得られるようになる、のではないかと、思ってるのだけど。
あちこちの説明を読むと、PCMには出来ないところに踏み込んだ技術のようだ。
過去のCD導入の時は音がいいと言われながら違ったし、ハイレゾも音がいいと言われながらそうなの?という感じだし、今回は、確かに音がいいと言われながら普及するといいなあと思っている。
でも僕自身、試聴機会がないので、なんとかならないかな、と思っている。

Jun 30, 2018

ようやくNASを追加した

デジタルオーディオはノイズとの戦いということで、いろいろ些細な変化で音が変わる。
アナログの場合はノイズや歪みも味のうちという場面があるけど、デジタルだと悪化要因にしかならない。

先日は、イーサネットハブを外したら音が変わるという、デジタルオーディオをやっている人間にとってはよくあるあるある状況に陥って、もとに戻してみたりしてるのだけど、戻してみても精彩を欠く。
何が原因だろうとしばらく悩んだけど、LANターミネーターが足りないから端子だけ差しておけばいいか、と思って刺していたLANケーブル端子(ターミネーターに加工前で、端子に10cm足らずのケーブルが付いている。抵抗が足りなくて製作が滞っているのだ)が怪しいと思い至り、外してみたら音が戻った。
こんなのを刺していた
10cmのケーブル端がノイズを拾っていた?ということらしい?
もしかしたら、僕が知らないだけでよくあることなのかもしれないけど、やはり体験すると感心するやらあきれるやらで、いろいろと細かいことだよな、と思う。

音がいいのはいいんだけど、敏感すぎるのも扱いにくいよなあ、と思う事がある。
昨日と今日で、なんとなく違うのだ。
気圧のせいやら電圧のせいやら、よく分からない。
好きでめんどくさいことしてるんだから誰にも同情されんだろうけど、もうちょっと大雑把にやれないかなとか思ったり。
まあ、そうもいかないのは分かってるんだけどさ。

6月20日現在、下図のような感じで継いでいる(変更追記。文章の流れで、図の位置を上に上げた)。

LAN接続図

先日外したハブというのはFX08-mini(hub 5)で、以前は数を継げるほど音が良くなるハブと言われていた。うちでも3台までは継げてみたことがあるけど、まあ2台でいいかということで減らして、最近は1台だけPPAPのフロントとバックエンドの間に挟んでいた。
ふと、なくてもいいんじゃないの?と思って外したら、思わしくなかったのだ。

このハブは、何をしているんだろうという。
ないならないで精彩を欠くので、デジタル信号の打ち直しとか安定化とか、そういうことをしてるんだろうと思う。
一方で、端子に刺さったケーブルは悪化要因にもなるのだ。切れ端で悪化するなら、ケーブルそのものも悪化要因になる可能性はあるのかな。
音が精彩を欠いたのは、ハブを外したからじゃなくてケーブルが違ったからかもしれない。つまりハブからRas Piまでの距離が違うのだ。片やFX08-miniから50cm程度で、FX08-miniを外したらGS105Eまで1m以上と、そこそこの差があって、これが実はいけなかったんじゃないのか。とか。いや、もしかしたら、ケーブルは端をターミネートしてるかどうかのほうが影響が大きいのかもしれない。経験的に音が悪化するのはケーブル端に何もつないでいない時だ。でも、そもそもハブが違うじゃんというのもあったり。
わけが分からないね。

引きずってた案件としてNASを追加したいというのがあって。
ストレージ使用量が全容量の4分の3を超えたので、いずれ対策が必要になるのは分かっている。NASを追加するとしたらどう設定しようかというのも悩みだし、追加するとなるとハブの何処に刺すのということが出てくる。ハブ足りないから追加しようか、とか。
PCトラポからの距離はどの程度まで許容されるのか。漠然とした印象ではトラポとNASが近いに越したことはないという印象なんだけど、実際にそこはどうなのか、とか。

そんなわけで昔使っていたBaffaloのハブ(hub 2)を戻している。ここにNASやサブクライアントPC、DHCPサーバーとの連結など、ノイズ源になりそうなものをまとめてみようという考え。
サブクライアントPCは音源データをNASに送るのに使っている。普段、ncmpcppでmpdを操作してるのはwlanで継いだクライアントPCが主なんだけど、無線lanボードの通信速度が遅すぎて、ギガバイト以上のリッピングファイルやハイレゾファイルのNASへの転送には全く使う気になれないのだ。有線だと違うんだけどダイニング周りにケーブルを引き回す気になれない。サブクライアントPCは有線で継ぐことができる場所に置いている。
FX08-mini、GS105EへのLANケーブルの接続は最小限にして負荷を減らし、使わないLAN端子はOFFにしたりターミネータを刺してノイズ低減に努める。サブシステムのほうはトラポのRas pi/piCoreで384kHzまでアップサンプリングするからノイズに耐性があるはずなので、96kHz上限のメインシステムよりノイズ対策は緩い。
とか、もったいぶったことを書いているが後付けの理屈で能書きだ。

NASは型落ちのhs-251を入手して、どういう設定で継ぐか延々迷っていたんだけど、もうRAID1でいいやってことにした。
他の選択枝となると、HDD2台でRAIDを組まずに運用する方法だけど、そうなるとバックアップの管理が重要になってくる。RAID1のほうがNAS自体の耐障害性信頼度が高い分、バックアップ管理の重要度は減るんじゃないかな。RAID0とか他の組み方はデメリットが大きくて考えにくい。
RAID1だとNAS2台で運用せざるを得ないんだけど、音への影響はどうなんだろう、、、
NAS2台をマウントすることになるras piへの負担が増えるのと、ネットワーク内のノイズ源が増える。
考えてばかりいても仕方ない。
やってみよう。
ということでやってみたら、以外に音への影響は小さいのかな?
1台のときとの差を聴き取れないような。
というか、、、
NASというのは時々リブートしたほうがいいのかな、と思った。安定動作のために。
あとhs-251のほうが210よりも機械としてのスペックが高い分、スペックが高い音が出ている。これはなるほどなあと思った。
当面、これでいくことにした。
役割分担としては、hs-251がクラシックの音源、エスニックや環境音のライブ録音音源、ハイレゾ。hs-210にはロック、ジャズ、JポップなどポップミュージックのCDリッピング音源を担当してもらう。

以前は、hub 3(GS105E)に接続が集中していて、今回、NASを増やすのを機にハブを増やしている。
NASやサブクライアントPCのhub 3への接続を、新しく追加したhub 2に移してみたところ、音のほうはなんとなく落ち着いてしっとりした感じになった印象がある。クリアネスは低下していないと思うので、悪くはないだろうという判断だ。踏み込んでじっくり時間をとった試聴はしていないので、印象なんだけど。
情報量が低下しているようなら考え直さないといけないけど、たぶん大丈夫だろ。

ほんとうは、hub 3からhub 5まではハブ1台で済まそうと思えばできるんだけど、以前からの流れでは数珠繋ぎになっていた。hub 5のFX08-miniを外したら思わしくなかったというのは前述したとおり。じゃあ、hub 3とhub 4を1台にまとめたらどうなんだろうとか考えたんだけど、まとめるより分岐させることにした。
メインシステムはfireface UCX CCモードでPPAPだけど、サンプリング周波数・ビット深度を固定しないといけないので、CDリッピング音源への対応が中心になる。ハイレゾは24/96までだ(しかし今回、これが今まで以上にいい音で鳴ってる気がする。NASの力だろうか、、、)。
ハイレゾ音源は192kHz以上のもあるし、ある程度は柔軟に対応できる環境も残しておきたいし、RAM音源再生ができる環境も維持しておきたいとも思っていて。これらの機能を、とりあえずサブシステムに振り分けることにした。

そうした諸々の結果が上の図のようになっている。
どうなることかと思っていたけど、意外にもパフォーマンスは改善している。今後もこの調子でいきたいところだ。

Posted at 21:37 in audio_diary | WriteBacks (0) | Edit Tagged as: , ,

Jun 08, 2018

piCoreのonboot.lstを編集してタスク軽減を目指す

先日、piCore7で作るPPAP Frontというエントリーをアップした。
http://blown-lei.net/endive/blosxom.cgi/audio_diary/20180529a.htm

その中で、/mnt/mmcblk0p2/tce/onboot.lst を編集することでタスクを減らせるという話を書いた。

sudo vi /mnt/*2/tce/onboot.lst

mc.tcz
openssh.tcz
boost-dev.tcz
libsamplerate-dev.tcz
libsamplerate-doc.tcz
flac-doc.tcz
libcue.tcz
libcue-dev.tcz
libid3tag-dev.tcz
libmad-dev.tcz
mpg123.tcz
lame-dev.tcz
lame-doc.tcz
libmpdclient-dev.tcz
libmpdclient-doc.tcz
mpd-0.19.19.tcz
nmap.tcz

ついにここまで削ったが、ちゃんと音は出ているようだ、、、

tc@box:~$ df
Filesystem                Size      Used Available Use% Mounted on
tmpfs                   833.2M     11.0M    822.2M   1% /
tmpfs                   462.9M         0    462.9M   0% /dev/shm
/dev/mmcblk0p2            3.6G    177.9M      3.3G   5% /mnt/mmcblk0p2
/dev/loop0                1.1M      1.1M         0 100% /tmp/tcloop/mc
/dev/loop1                1.9M      1.9M         0 100% /tmp/tcloop/openssh

(中略)

/dev/loop53             512.0K    512.0K         0 100% /tmp/tcloop/sqlite3
/dev/loop54             128.0K    128.0K         0 100% /tmp/tcloop/libudev
192.168.1.80:/titan       2.7T      2.0T    670.6G  76% /mnt/music/nas

55個になった、、、
じゃあ音はどうなのかというと、例によって比較はできてないんだな、、、
これ以上は削るわけにはいかないような気がするし、この手法で出来るのはここらあたりまでかと思う。

今回は音の比較をしたという話だ。
結論から書くけど、音は良くなる。前の状態には戻したくないな、と思う程度の変化はある。

うちにはメインシステムで運用しているRas Pi以外にテスト運用に使うのが数台あってダイニングの本棚の底のほうに隠すかのように置いてある。前のエントリーをアップした時点では、こうした試験運用piCoreで音が出している、という状況だった。
LANの状態は下図のような感じ。

クライアントPCノートでfront1にsshでログイン、onboot.lstを編集してはリブートし、back-end1に音声データを送って試してみた。ある程度までタスクを減らせたのは前述のとおり。
back-end1に繋がってるのは小さいデスクトップ用モニタースピーカーなので音質評価は難しい。

front1から、メインシステムのback-end2にデータを送ってみる。リビングのJBLの4425mk2から音が出る。
まあ、こんなもんかな、、、
ふだんfront2/back-end2で鳴らしているのに比べると、むしろ音は良くない。

これは想定内でもあって、というのは図を見れば分かるんだけど、front1からback-end2への伝送経路はとても長い。
音源データの流れは、
NAS - hub2 - hub0 - hub1 - front1 - hub1 - hub0 - hub2 - hub3 - back-end2
と、こんな感じ。
hub0はルーターとDHCPサーバーも兼ねていて、そこをデータが通過するのも更に条件を悪化させているんじゃないかと思う。
front2からback-end2への流れは、
NAS - hub2 - front2 - hub2 - hub3 - back-end2
こんな感じ。
front以降に通過する段階がずいぶん違う。
この状況だったらonboot.lstを編集していないpiCoreのほうが音がいい。
というかタスク軽減による効果がはっきりしない。

ということで、front1に刺してあるonboot.lst編集済みmicroSDを抜いて、front2に差し替える。両方とも同じRas pi2初期型だから差し替えるだけで問題なく動く。pi2後期型だとどうなのか分からないけど。

編集なしと比べてどうなのか。、、、
微妙に違う。
というか、front1とfront2の大きな差に比べたら、差は少ない。
しかし、少ないとはいえ無視できないレベルの改善はあって、OSが不安定になるとか問題がないようならonboot.lstを編集しタスクを減らしたほうが良さそうだ。

そんなことを考えながら続けてあれこれ聴いてみるうちに、なるほど、これは戻れないかもと思うようになった。
音のリアリティ、SN感が高く細やかで雑味が少なくなる感じ。音場表現もより安定し深みが出て、前後も見易くなるようだ。

今回はPPAP運用の流れでonboot.lstを編集したけど、PPAPで使うかどうかに関係なくpiCoreでmpdの音を改善しようと思ったら試みていい方法だと思う。Ras pi1台でのmpd運用の時でも音質改善する可能性がある。

Posted at 15:15 in audio_diary | WriteBacks (0) | Edit Tagged as: , ,

Jun 05, 2018

ブログにTAGを使う

久しぶりにblosxomをいじっているんだけど、いろいろ忘れていてなかなか大変。

http://noone.org/blog/English/Computer/Perl/Blosxom%20plugin%20tagging.html
こちらのサイトからtaggingプラグインを落としてきて、pluginディレクトリに放り込んだら簡単に動く、とはいかなくて、設定しないといけない。
英語でよくわからないんだな、、、

#  Use $tagging::tag_list for the story tag list,
#  $tagging::global_tag_list for a global tag list (also called tag
#  cloud, e.g for head.html or foot.html), $tagging::current_filter
#  for the currently used tagging filter (if any) and
#  $tagging::related_tags for a list of tags related to the current
#  filter.

「$tagging::global_tag_list」を使うと所謂タグクラウドを表示できてなんとなくかっこいいんだけど、これをやるとpagingが上手く機能しなくなるんだね。これは10年前と変わっていないっぽい。
どうっしようかな、ってなことで「$tagging::tag_list」をstory.htmlフレーバーに書き込んで、エントリーにタグが表示されるようにした。
「$tagging::current_filter」をhead.htmlに書いてフィルタリングの状況を表示させる。
これだとタグでフィルタリングしていないときにはpagingが機能する。
本当は、フィルタリングしたときにも機能して欲しいんだけど、しかたない。

Posted at 12:02 in blosxom | WriteBacks (0) | Edit Tagged as: ,

Jun 05, 2018

PPAP (piped pcm audio play) 関連サイトアドレス集

前回、前々回とPPAP関連のエントリーが続いている。
2月以降、取り上げてはいるんだけど、このサイトではPPAPについて詳しい説明はしていない。
詳しいことは発案者の記載などをあたってもらう方がむしろ良いかとも思うので、今更だけど関連のアドレスを記載しておく。

オーディオ道 ゆきて帰りし物語 | PHILE WEBコミュニティ
http://community.phileweb.com/mypage/entry/4787/20180104/
http://community.phileweb.com/mypage/entry/4787/20171227/
http://community.phileweb.com/mypage/entry/4787/20171218/

Home · papalius/symphonic-mpd Wiki · GitHub
https://github.com/papalius/symphonic-mpd/wiki
Home | symphonic-mpd
http://mpd.sytes.net/ja
セパレート構成まとめWiki
https://github.com/papalius/symphonic-mpd/wiki/%E3%82%BB%E3%83%91%E3%83%AC%E3%83%BC%E3%83%88%E6%A7%8B%E6%88%90%E3%81%BE%E3%81%A8%E3%82%81Wiki

PPAPは、もともとはsymphonic-mpdに関連して提案されたmpdの運用方法だった。
symphonic-mpdを単体で運用するよりも、役割分担させてセパレート構成にしたほうがいい音がするというのが始まりだ。セパレート構成というアイデア自体は数年前からPCオーディオのノウハウとしてポピュラーなものになっている。しかし「ncat - aplay」の連携で音を出すというアイデアが公の場に上がったのは、たぶん、ここが初めてだろうと思う。
この方法に、発案者のパパリウス氏が「PPAP (piped pcm audio play)」と名付けたのだ。パパリウス氏はsymphonic-mpdのディストリビューターだ。
今年1月中旬以降、symphonic-mpd関係のサイトは公開を中断したまま更新されないままとなっている。
何がどうなっているのか心配だけど、

とかなんとか、書いていたら6月2日に復活した!
http://community.phileweb.com/mypage/entry/4787/20180104/58139/
symphonic-mpd v0.5.0

PPAPの考え方自体はsymphonic-mpdでしか適用できないものではない。Linuxであれば、おおよそどんなディストリビューションでも応用し使う事ができて、ほとんどの場合、確実に音質向上が期待できるアイデアだと思う。
実際、lightMPDベースのバックエンドも公開されている。僕はpiCoreでやっているけど、確かに音が良くなっている。

Windowsのほうでは「DLNAプッシュ再生方式」が話題になっている。
http://community.phileweb.com/mypage/entry/2408/20180523/
PCオーディオに見て、触って、聴いてみる-Ⅴ その4
http://kotonohanoana.com/archives/20430
【ネットワークオーディオTips】DLNAの「プッシュ再生」について

プッシュ再生方式は、すごくPPAP方式と似ている。
DMRとDMS+DMCの役割は、そのままPPAPのバックエンドとフロントの役割と同じに見える。同時期に同じような構成、考え方がウェブ上で話題になっているというのも不思議な感じだ。将来、こういうコンセプトに影響を受けた製品が商品化されることがあるかもしれないとか、考えたりする。

そもそも、symphonic-mpdはストイックなディストリで、今もサイトに「アプローチに逆行すると判断したものはバッサリ断捨離している尖ったディストリビューション」と掲げている。PPAPはもっと間口が広くてゆるいコンセプトだと思う。僕は、ずいぶん方向性を変えるんだな、と驚いたものだった。
v0.5.0では、以前の方向性に戻っているのかな、、、
現時点では、本家のsymphonic-mpdでPPAPを続けるつもりがあるのかどうか分からない。PPAPは間口こそ広いけど、サンプリング周波数を固定しないといけないとか意外と扱いにくい面があるし、もしかしたら突き詰めてコントロールするには不向きと判断されるかもしれない。

せっかくアイデアとして世に出たものなのだし、うちでは成果があるのだからpiCoreでゆるゆる運用していくつもりだ。
間口が広いPPAPだから、そういうのもありだろうと勝手にそんな風に考えている。

Posted at 10:08 in audio_diary | WriteBacks (0) | Edit Tagged as:

May 29, 2018

piCore7で作るPPAP Front

piCore7でppap (piped pcm audio play)を試みる
http://blown-lei.net/endive/blosxom.cgi/audio_diary/20180301a.htm

3月に上記のエントリーを上げて、前回はバックエンドのエントリーを上げた。
フロントのエントリーがないのも、ちょっとね、と思って独立したエントリーにまとめることにした。新しいことはあんまりないんだけど。

課題としては、
フロント化に最小限必要な環境を見つけたい
mpdをOS起動時に自動起動できないか、といったところなんだけど、よく分からないところは分からない。

最初にお断り書き。
このエントリーはRaspberry pi2の使用を前提として書いている。
3以上は所有していないしB+以前の機種で仕事量が多いフロントを受け持たせる気に僕自身はなれないという事があるので。
アップサンプリングとか負担が多い仕事をさせずに動かすならB+とかでも問題ないかもしれないけど、そこはうちではやっていないので分からないところだ。

まず、microSDにpiCoreを焼いて、ras pi2に刺して起動して初期セッティングする。
詳細は、こちらのエントリーを参照のこと。
http://blown-lei.net/endive/blosxom.cgi/audio_diary/20180103a.htm
piCore7にmpdをインストールする方法

以下、sshでログイン後の流れを.ash_historyファイルからコピペ。

filetool.sh -b
sudo fdisk -u /dev/mmcblk0

sudo resize2fs /dev/mmcblk0p2
vi /opt/eth0.sh
chmod +x /opt/eth0.sh
vi /opt/bootsync.sh
vi /opt/.filetool.lst
filetool.sh -b

ここまでで、基本的な初期セッティングは終了。
バックエンドとほとんど同じだ。
出力をpipe - LAN経由でするのでi2s出力の設定は要らない。ネット上を探したらHAT形式のLAN出力ボードみたいなものもあるみたいなんだけど、、いや、USB出力だったっけ?、、そういうのを使う場合以外は要らないという意味だ。

今回は、先にmpdをダウンロードし解凍し、INSTALLファイルを確認する。
バージョンは0.19.19.

wget https://www.musicpd.org/download/mpd/0.19/mpd-0.19.19.tar.xz
xz -dv mpd-0.19*
tar -xf mpd-0.19*
less mpd-0.19*/INSTALL
Dependencies
------------
gcc 4.7 or later - http://gcc.gnu.org/
clang 3.2 or later - http://clang.llvm.org/
Any other C++11 compliant compiler should also work.

Boost 1.46 - http://www.boost.org/

GLib 2.28 - http://www.gtk.org/
General-purpose utility library.

最低限、これだけは必要ということか。ずっと更に下の方を読んでいくと、他にも必要なものが書いている、、、
取り敢えず、下記をインストールしてみる。

tce-load -wi \
gcc_base-dev.tcz gcc-doc.tcz gcc_libs-dev.tcz gcc_libs.tcz gcc-locale.tcz gcc.tcz \
glib2-dev.tcz glib2-doc.tcz glib2-locale.tcz glib2-python.tcz glib2-dev.tcz \
glibc_add_lib.tcz glibc_apps.tcz glibc_base-dev.tcz glibc_gconv.tcz glibc_i18n_locale.tcz \
glib-networking-dev.tcz glib-networking-locale.tcz glib-networking.tcz \
boost-dev.tcz boost.tcz

tce-load -wi \
flex-dev.tcz flex-doc.tcz flex-locale.tcz flex.tcz \
gdbm-dev.tcz gdbm-doc.tcz gdbm-locale.tcz gdbm.tcz \
bison-dev.tcz bison-doc.tcz bison-locale.tcz bison.tcz

ls /usr/local/tce.installed/

実際には、こうしたコマンドに表記されているもの以外にも関連のあるものがあれやこれやとインストールされる。

次にmpdが使うライブラリやエンコーダーをインストール。
以前はalsa関連はまとめてインストールしていたけど、考えてみたらPPAPのフロントではalsaを使わない。だったらなくても問題ない?ということで、コマンドからalsaを省いてみた。

tce-load -wi \
libsamplerate-dev.tcz libsamplerate-doc.tcz libsamplerate.tcz \
flac-dev.tcz flac.tcz flac-doc.tcz libcue.tcz libcue-dev.tcz \
icu-dev.tcz icu.tcz libid3tag-dev.tcz libid3tag.tcz \
libmad-dev.tcz libmad.tcz mpg123.tcz lame-dev.tcz lame-doc.tcz lame.tcz \
libmpdclient-dev.tcz libmpdclient-doc.tcz libmpdclient.tcz

しかし関連があるということで、alsa-devとalsa-modules-4.1.13-piCore_v7+がインストールされている。

この時点でmpdのコンパイル、インストールを試みたけど失敗。
./configureで、いろいろ足りないみたいなことを言ってくる。
何が足りないのかは、本当はlogを読まないといけないのだけど、、、

手を抜いて、、、下記追加。

tce-load -wi \
binutils-dev.tcz binutils-doc.tcz binutils-locale.tcz binutils.tcz \
ncurses-dev.tcz \
make-doc.tcz make-locale.tcz make.tcz \
automake.tcz autoconf-doc.tcz autoconf.tcz libtool-dev.tcz libtool-doc.tcz \
compile-essentials.tcz squashfs-tools.tcz bash-locale.tcz bash.tcz \
bc-doc.tcz bc.tcz pkg-config-doc.tcz pkg-config.tcz cmake-doc.tcz cmake.tcz

こんなところでどうか。
予めダウンロードして解凍したmpdを、もう一度コンパイル。
コマンドを羅列。

cd mpd-0.19*

./configure --enable-pipe-output
make
mkdir ../mpd
sudo make DESTDIR=../mpd install

寝てる間にmakeさせたので、そこでかかった時間は分からないけど、install過程はスムーズに終了。

cd
mksquashfs mpd mpd-0.19.19.tcz
md5sum mpd-0.19.19.tcz > mpd-0.19.19.tcz.md5.txt
sudo mv *tcz* /mnt/*2/tce/optional
sudo vi /mnt/*2/tce/onboot.lst

~/ディレクトリにmpd-0.19.19.tcz、md5.txtファイルを作って、/mnt/mmcblk0p2/tce/optionalにコピー転送。
onboot.lstを開いて、一番下に「mpd-0.19.19.tcz」を追記。

これでインストール完了。

あとはmpd.conf、mpdの動作環境を作成していく。

cp m*9/doc/mpdconf.example .mpdconf
sudo rm -rf mpd*

vi .mpdconf
mkdir .mpd
mkdir .mpd/playlists

filetool.sh -b

上記ではダウンロードしたのをコピーして、/home/tcに.mpdconfを作っている。
でもコピーじゃなくても、mpdが読める場所に書式に則って作ってあれば構わない。~/.mpdconfはmpdで指定されているデフォルトmpd.conf設定のうちの1つだ。

sudo rm -rf mpd* で、インストールに使った諸々のデータを削除しておく。
これはインストールが終わったら使わなくなる残骸で、残しておくとfiletool.sh -bを打つたび、microSDカードに上書き保存されることになる。システム運用していたら、アップデートしたmpdの音楽データベースをsshからfiletool.sh -bを打って保存する必要が度々あるんだけど、この残骸を予め削除しておいた場合は数秒で終わる。残していたら数分かかる。
使わないデータを長い時間をかけて保存する行程を繰り返す必要はないので。

下記はmpd.confの記載例。
詳細はmpdのUser's Manual等を参照のこと。自分の使いたいように設定する。
https://www.musicpd.org/doc/user/index.html The Music Player Daemon - User's Manual

PPAP(aplay)で扱う事ができるサンプリング周波数の上限は192kHzなので注意。

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

auto_update     "no"

mixer_type "software" ## hardware, software or none
## replay_gain_handler "none" ## software, mixer or none

samplerate_converter "Fastest Sinc Interpolator"
audio_buffer_size "8192"
buffer_before_play "20%"
audio_output_format "96000:24:2"

audio_output {
type "pipe"
name "ppappipe"
always_on "yes"
command "/usr/local/bin/ncat 192.168.1.82 4444"
}

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

上記のmpd.confだと、replay_gain_handlerの設定が読み込めないというエラーでmpdの起動に失敗したので、コメントアウトしている。alsa関連でインストールしていないものが多いので、そのせいだろうか。

上記のmpd.confに合わせてmusic_directoryを設定する必要がある。
bootlocal.shにコマンドを記述しておくとOS起動時に実行される。起動時にmusic_directoryを作って、NASのtitanディレクトリをマウントするように設定。

vi /opt/bootlocal.sh

bootlocal.shに下記を記述。

mkdir /mnt/music
mkdir /mnt/music/nas
mkdir /mnt/music/ram
touch /mnt/music/ram/dummy.cue
chmod -R 777 /mnt/music
mount -o addr=192.168.1.80,nolock -t nfs 192.168.1.80:/titan /mnt/music/nas

設定を忘れず保存すること。

filetool.sh -b

忘れてはいけない、、、最後になってしまったが、nmapをインストールする。


tce-load -wi nmap.tcz

以上で、piCore7のフロント化、完成。

sudo reboot

sudo rebootで再起動すると、NASをマウントした状態になる。
使用に際してはsshで再度ログインして、mpdを起動させる仕様。自動起動にはしていない。mpdを起動させたらあとはmpdクライアントで操作できる。

この状態で「df」コマンドを打つとこんな感じ。

tc@box:~$ df
Filesystem                Size      Used Available Use% Mounted on
tmpfs                   833.2M     11.4M    821.8M   1% /
tmpfs                   462.9M         0    462.9M   0% /dev/shm
/dev/mmcblk0p2            3.6G    177.9M      3.3G   5% /mnt/mmcblk0p2
/dev/loop0                1.1M      1.1M         0 100% /tmp/tcloop/mc
/dev/loop1                1.9M      1.9M         0 100% /tmp/tcloop/openssh
/dev/loop2                4.4M      4.4M         0 100% /tmp/tcloop/gcc_base-dev

(中略)

/dev/loop137            128.0K    128.0K         0 100% /tmp/tcloop/libudev
/dev/loop138            128.0K    128.0K         0 100% /tmp/tcloop/libtasn1
192.168.1.80:/titan       2.7T      2.0T    670.6G  76% /mnt/music/nas

139個のtczがインストールされて、その多くが待機状態になってるということかと。
ちなみに最初に作ったフロントではどうかというと、

tc@box:~$ df
Filesystem                Size      Used Available Use% Mounted on
tmpfs                   833.2M     11.3M    821.9M   1% /
tmpfs                   462.9M         0    462.9M   0% /dev/shm
/dev/mmcblk0p2            3.6G    187.0M      3.3G   5% /mnt/mmcblk0p2
/dev/loop0                1.1M      1.1M         0 100% /tmp/tcloop/mc
/dev/loop1                1.9M      1.9M         0 100% /tmp/tcloop/openssh
/dev/loop2              896.0K    896.0K         0 100% /tmp/tcloop/nmap-doc

(中略)

/dev/loop155            128.0K    128.0K         0 100% /tmp/tcloop/libtasn1-dev
/dev/loop156            128.0K    128.0K         0 100% /tmp/tcloop/libtasn1
192.168.1.80:/titan       2.7T      2.0T    670.6G  76% /mnt/music/nas

157個。新しい方が20ほど少ない、、、どうなんでしょうなあ、、、

前からちょっと気になっていたことを試すことにする。ひょっとして、onboot.lstを編集したらタスクが減るんじゃないかな。

mc.tcz
openssh.tcz
gcc_base-dev.tcz
gcc-doc.tcz
gcc_libs-dev.tcz
gcc-locale.tcz
glib2-dev.tcz
glib2-doc.tcz
glib2-locale.tcz
glib2-python.tcz
glibc_add_lib.tcz
glibc_apps.tcz
glibc_base-dev.tcz
glibc_gconv.tcz
glibc_i18n_locale.tcz
glib-networking-dev.tcz
glib-networking-locale.tcz
boost-dev.tcz
flex-dev.tcz
flex-doc.tcz
flex-locale.tcz
gdbm-dev.tcz
gdbm-doc.tcz
gdbm-locale.tcz
bison-dev.tcz
bison-doc.tcz
bison-locale.tcz
libsamplerate-dev.tcz
libsamplerate-doc.tcz
flac-doc.tcz
libcue.tcz
libcue-dev.tcz
libid3tag-dev.tcz
libmad-dev.tcz
mpg123.tcz
lame-dev.tcz
lame-doc.tcz
libmpdclient-dev.tcz 
libmpdclient-doc.tcz 
binutils-dev.tcz     
binutils-doc.tcz     
binutils-locale.tcz  
ncurses-dev.tcz      
make-doc.tcz         
make-locale.tcz      
automake.tcz         
autoconf-doc.tcz    
libtool-dev.tcz     
libtool-doc.tcz     
compile-essentials.tcz
squashfs-tools.tcz    
bash-locale.tcz       
bc-doc.tcz            
bc.tcz                
pkg-config-doc.tcz    
pkg-config.tcz        
cmake-doc.tcz         
cmake.tcz             
mpd-0.19.19.tcz       
nmap.tcz              

当初のonboot.lstの記載はこんな感じ。これをrebootを繰り返しながら書き換えていく、、、
どうも、必要となれば引っ張り起こされるtczと、起こされないので最初からリストしておかないといけないtczがあるようだ。

mc.tcz
openssh.tcz
boost-dev.tcz
libsamplerate-dev.tcz
libsamplerate-doc.tcz
flac-doc.tcz
libcue.tcz
libcue-dev.tcz
libid3tag-dev.tcz
libmad-dev.tcz
mpg123.tcz
lame-dev.tcz
lame-doc.tcz
libmpdclient-dev.tcz
libmpdclient-doc.tcz
mpd-0.19.19.tcz
nmap.tcz

ついにここまで削ったが、ちゃんと音は出ているようだ、、、

tc@box:~$ df
Filesystem                Size      Used Available Use% Mounted on
tmpfs                   833.2M     11.0M    822.2M   1% /
tmpfs                   462.9M         0    462.9M   0% /dev/shm
/dev/mmcblk0p2            3.6G    177.9M      3.3G   5% /mnt/mmcblk0p2
/dev/loop0                1.1M      1.1M         0 100% /tmp/tcloop/mc
/dev/loop1                1.9M      1.9M         0 100% /tmp/tcloop/openssh

(中略)

/dev/loop53             512.0K    512.0K         0 100% /tmp/tcloop/sqlite3
/dev/loop54             128.0K    128.0K         0 100% /tmp/tcloop/libudev
192.168.1.80:/titan       2.7T      2.0T    670.6G  76% /mnt/music/nas

55個になった、、、
じゃあ音はどうなのかというと、例によって比較はできてないんだな、、、
これ以上は削るわけにはいかないような気がするし、この手法で出来るのはここらあたりまでかと思う。

Posted at 13:31 in audio_diary | WriteBacks (0) | Edit Tagged as: , ,

May 27, 2018

piCore7で作るPPAP Back-End

piCore7でppap (piped pcm audio play)を試みる
http://blown-lei.net/endive/blosxom.cgi/audio_diary/20180301a.htm

piCore7でPPAPバックエンドは恐ろしいほど簡単にできる。
そう思っていたら、後から「こうすれば良かった」とか出てきてるので上記のエントリーに随時加筆訂正を入れていたんだけど、読みにくすぎる。

問題になっているのはバックエンドに関してだけだ。
なので、piCore7 PPAP Back-Endの作り方を、独立したエントリーにまとめることにした。

まず、microSDにpiCoreを焼いて、i2s DACの設定など必要に応じて記載して、ras piに刺して起動する。
詳細は、こちらのエントリーを参照のこと。
http://blown-lei.net/endive/blosxom.cgi/audio_diary/20180103a.htm
piCore7にmpdをインストールする方法

以下、sshでログイン後の流れを.ash_historyファイルからコピペ。

filetool.sh -b
sudo fdisk -u /dev/mmcblk0
sudo resize2fs /dev/mmcblk0p2
vi /opt/eth0.sh
chmod +x /opt/eth0.sh
vi /opt/bootsync.sh
vi /opt/.filetool.lst
filetool.sh -b

ここまでで、基本的なセッティングを終了。
続いて、nmapとalsaをインストール。

ras pi B+の場合。

tce-load -wi nmap.tcz alsa-modules-4.1.13-piCore+.tcz alsa.tcz

ras pi 2の場合。

tce-load -wi nmap.tcz alsa-modules-4.1.13-piCore_v7+.tcz alsa.tcz

これだけでいいのか、という感じ。

続いて、bootlocal.shを編集。
コマンド設定を書き込んで、piCore起動時にバックエンドとして機能するようにする。

vi /opt/bootlocal.sh

16/44.1のデータを受ける場合は、下記をbootlocal.shに追記する。

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

下記は24/192のデータを受ける場合。
192kHzがaplayで扱うことができるサンプリング周波数の上限なので、PPAPの上限も192kHzになる。

/usr/local/bin/ncat -kl 4444 -e "/usr/local/bin/aplay -D plughw:0,0 -M --period-size=512 --buffer-size=4096 -t raw -f S24_LE -r192000 -c2"

https://linux.die.net/man/1/aplay
aplay(1) - Linux man page

前回のエントリーで書いたけど、piCore7の場合は「-D plughw:0,0」の記載がなかったら、dmixが起動して48kHzにリサンプリングされる。
しかし、alsa-modules-4.1.13-piCore_v7+.tczとalsa.tczしかインストールされてない状態だと、mpdの再生自体が止まるようだ。ncmpcppに「paused」が表示されて、音が出なくなる。これら以外のalsa関連のtczがインストールされていないと、dmix自体が動かないし出力もしないらしい。
dmixがインストールされていないんじゃないかな。
というか、dmixがなかったら音が出ないのか?、、
あれこれインストールするより「-D plughw:0,0」を指定したほうがシンプルだし扱いやすくていいと思う。

この「hw」「plughw」という文字列だけど、どうもあちこちで説明の内容が違う。
環境によって違ってくるのか「aplay -l」で表示されるデバイス名を指定できるという話や、plughwを使うとリサンプリングされるという話もある(えぇー?)。
しかし、うちではplughwを記載したら、確かにフロントから出力したとおりのサンプリング周波数が表示されるんだよね、、、

以前に使っていた、
/usr/local/bin/ncat -kl 4444 -e "/usr/local/bin/aplay -M --period-size=512 --buffer-size=4096 -t raw -f S24_LE -r192000 -c2"
というようなコマンドだと、前述の通り音が出ない。alsa-dev.tcz alsa-doc.tcz alsaequal.tcz alsa-locale.tcz、、まあ、どれが働くのかわからないけど、これらがインストールされていたらdmixが働いて48kHzに変換された上で、音が出る。

/usr/local/bin/ncat -kl 4444 -e "/usr/local/bin/aplay -D hw:0,0 -M --period-size=512 --buffer-size=4096 -t raw -f S24_LE -r192000 -c2"
だったら「paused」が表示されて音が出ないんだけど、alsa-dev.tcz alsa-doc.tcz alsaequal.tcz alsa-locale.tczを追加インストールしても、「paused」で音が出なかった。「-D hw:0,0」はあちこちでdmixによるリサンプリングをさせない設定とされているんだけど、どうもpiCore7ではうまく機能しない。

/usr/local/bin/ncat -kl 4444 -e "/usr/local/bin/aplay -D plughw:0,0 -M --period-size=512 --buffer-size=4096 -t raw -f S24_LE -r192000 -c2"
これだったら、こちらの求めるように機能して音が出る。どこかでそうなるように設定されているのかもしれないけど、よく分からない。
現状、変換せずに音が出てくれたらいい、という感じだ。

閑話休題。

忘れないように設定を保存しリブートすれば、PPAP Back-Endとして機能する。

filetool.sh -b
sudo reboot

以下、Ras pi 2で設定して「df」を打った結果。

tc@box:~$ df
Filesystem                Size      Used Available Use% Mounted on
tmpfs                   833.2M      9.5M    823.7M   1% /
tmpfs                   462.9M         0    462.9M   0% /dev/shm
/dev/mmcblk0p2           28.3M     13.1M     13.6M  49% /mnt/mmcblk0p2
/dev/loop0                1.1M      1.1M         0 100% /tmp/tcloop/mc
/dev/loop1                1.9M      1.9M         0 100% /tmp/tcloop/openssh
/dev/loop2                4.9M      4.9M         0 100% /tmp/tcloop/nmap
/dev/loop3              768.0K    768.0K         0 100% /tmp/tcloop/alsa-modules-4.1.13-piCore_v7+
/dev/loop4              256.0K    256.0K         0 100% /tmp/tcloop/alsa
/dev/loop5                1.1M      1.1M         0 100% /tmp/tcloop/glib2
/dev/loop6               68.0K     68.0K         0 100% /tmp/tcloop/libssh2
/dev/loop7              256.0K    256.0K         0 100% /tmp/tcloop/ncurses
/dev/loop8                1.5M      1.5M         0 100% /tmp/tcloop/openssl
/dev/loop9              292.0K    292.0K         0 100% /tmp/tcloop/libnl
/dev/loop10             128.0K    128.0K         0 100% /tmp/tcloop/libpcap
/dev/loop11             128.0K    128.0K         0 100% /tmp/tcloop/lua-lib
/dev/loop12             384.0K    384.0K         0 100% /tmp/tcloop/libasound
/dev/loop13              28.0K     28.0K         0 100% /tmp/tcloop/gamin
/dev/loop14              36.0K     36.0K         0 100% /tmp/tcloop/libelf
/dev/loop15             256.0K    256.0K         0 100% /tmp/tcloop/pcre
/dev/loop16             384.0K    384.0K         0 100% /tmp/tcloop/libgcrypt
/dev/loop17             128.0K    128.0K         0 100% /tmp/tcloop/libusb
/dev/loop18              36.0K     36.0K         0 100% /tmp/tcloop/bzip2-lib
/dev/loop19             128.0K    128.0K         0 100% /tmp/tcloop/libgpg-error
/dev/loop20             128.0K    128.0K         0 100% /tmp/tcloop/libudev

インストールされたtceの一覧。

tc@box:~$ ls /usr/local/tce.installed/
alsa                            libelf                          libudev                         openssh
alsa-modules-4.1.13-piCore_v7+  libgcrypt                       libusb                          openssl
bzip2-lib                       libgpg-error                    lua-lib                         pcre
gamin                           libnl                           mc
glib2                           libpcap                         ncurses
libasound                       libssh2                         nmap
tc@box:~$ 

piCoreはループバックデバイス機能を使って、インストールしたファイルをイメージであるかのように扱いRAM上に展開する。で、合ってるのかな?
結果、軽量なシステムのはずだけどプロセスが多くなるみたい。
削れるものはあるかもしれないけど、僕のほうでは無理せずにこのまま使っている。

>
Posted at 12:55 in audio_diary | WriteBacks (0) | Edit Tagged as: ,
Page 1 / 22 :  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 Next › »