Page 13 / 31 :  « ‹ Prev 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 Next › »

Jul 24, 2016

mpd + libsamplerateによるアップコンバートについて(2021.04. 追記あり)

2021.04.24. 追記。Phile Webにこのエントリーの焼き直しを投稿した。
https://community.phileweb.com/mypage/entry/5010/20210423/67551/

2021.04.27. 追記。投稿したところ、間違い指摘のレスをいただいた。
詳細は投稿先を参照ください。このエントリーにも指摘された内容について該当箇所に追記しています。

前のエントリーに追記で、アップコンバートについてちらっと書いた。
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 :-).

難しい。SN比とスピードはなんとなく分かるけど、帯域幅(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.

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

ちなみにここで上げられている3つのコンバーターとは、sndfile-resample、Resample、ResampAudioの3つである。
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.」、訳すと「3つの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による上位3つのリサンプリング方式はジュリアス O.スミス氏のアルゴリズムに基づいて行われていて、デジタルデータから元のアナログ波形を計算し、その波形のリサンプリングをエミュレートすることで新たなデジタル信号を作り出すということ。
一連の処理をするのに相応のPCパワーが必要だが、Ras pi2でもpiCoreで絞り込めば何とかなる。

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

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

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

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

しかし、高域が減衰するといっても「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」のほうが音がよくなる可能性もあるのではないか。

2021.04.27. 追記。
Phile Webへの書き込みにレスをいただき、上記削除した内容について間違っていることが分かった(いや、書き込んでみてよかった!)。
リサンプリング後の周波数ではなく「前後どちらか、低い方のナイキスト周波数からみた帯域幅」について、説明されているということだ。低い方のナイキスト周波数を目安にして、ノイズが含まれる高域にフィルターをかけないといけないから、そういうことになるということらしい。
言われて考えてみたら、なるほど、という感じだ。

あとで気付いたが、この件についてSRCのサイト、FAQに記載がある。
引用する。

http://www.mega-nerd.com/SRC/faq.html

Q3 : If I upsample and downsample to the original rate, for example 44.1->96->44.1, do I get an identical signal as the one before the up/down resampling?

The short answer is that for the general case, no, you don't.The long answer is that for some signals, with some converters, you will get very, very close.

In order to resample correctly (ie using the SRC_SINC_* converters), filtering needs to be applied, regardless of whether its upsampling or downsampling. This filter needs to attenuate all frequencies above 0.5 times the minimum of the source and destination sample rate (call this fshmin). Since the filter needed to achieve full attenuation at this point, it has to start rolling off a some frequency below this point. It is this rolloff of the very highest frequencies which causes some of the loss.

The other factor is that the filter itself can introduce transient artifacts which causes the output to be different to the input.

ここのあたりは昔、目に通したことはある筈なんだけど、、、たぶん当時は意味が分からなくて、そのままになったのだと思う。
ちょっと今回、記載があるのをみて驚いた、、、

ということは、bandwidth:80% というのは、44.1kHzをアップサンプリングする場合、17640Hzで3dB低下ということになる。もっと低い周波数から減衰は始まるはずなので、若い人なら高域が低下していると気付く人は、、、いるのかな、どうなんだろう。
音楽の楽音自体はピアノの高域が4000Hzぐらい。15kHzになると、僕には聴こえない。
最近、今回の指摘を受けて、MEDIUM_QUALITYの設定で聴いてみたのだけど、高域の違いというよりも、音楽全体の陰影、階調が深まったように聴こえる。ハードのスペックが数年前よりも上がっているので、いつの間にかMediumでも768kHzで再生できるようになっていたのだ(BEST_QUALITYでは、音が途切れて再生できない)。
これに気付いたことも今回の収穫だ。

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

最近、注目されてる音楽フォーマット形式で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%"
という設定で鳴らしている。

Jul 12, 2016

ハイレゾを作って再生してみる、など (追記:アップコンバートすることにした)

どこから書いたものか。
現在、うちのオーディオのメインシステムはpiCoreを使ったメモリ再生になっている。
volumio + NASの音も悪くないと思うんだけど、妻は音量を上げたらうるさいというのだ。まあ、それは認めるけどたいしたことないじゃんと思うのだけど、妻としては差が大きいらしい。メモリ再生だと音量を上げてもうるさくないという。確かに、僕もそう思う。
オーディオやってる僕よりも、実は妻のほうが音質にはうるさいのだ。僕はうるさくても案外平気で聴いていたりする。

同じファイルであっても、NASに置くか、RAM上に置くかで、大きな音質差が生じる。
つまり、44.1kHz/16bitの音源の扱いはそれほどデリケートだということだろう。

過去には、調子がよくないNASを良いものに替えることで、音質が改善した経験がある。
このときは、NASの交換に伴ってmpd.confの設定が変わってしまった。調子が悪いNASを使っていたときはアップサンプリングする設定の方が音がよかったのが、NASを交換したら、しない設定の方が音がよくなったのだ。

今回のメモリ再生の試みに関連して http://www.yung.jp/bony/?p=3595 こちらのサイトのオーナーyung氏が同様のことをコメントしている。つまり、mpdのアップサンプリングの設定をやめたというのだ。そのほうが音がいいと。

mpdのアップサンプリング設定をやめるとき、というのがあるようだ。
システムの状況が改善し、ジッターが充分に減ったときには、アップサンプリングしないほうが音がよくなる、ということらしい。

逆に、ジッターが多い状況だとアップサンプリングしたほうが良くなる場合がある。アップサンプリング自体がシステムに負担を強いることだし、アップサンプリング自体の品質がどの程度確保できるかもシステムによるので、やってみないと結果は分からない。

過去には、うちではMac miniからの光出力をDACに送る際に、Mac miniでアップサンプリングしていたことがある。
5mばかり光ケーブルを引っ張っていたのでジッターが多かったのだろう。
アップサンプリングすることで、かなり音質が改善した記憶がある。

あと、LANの受け手側のmpdでアップサンプリングしていたことがある。
前述したNASの調子が悪いときの話で、データの転送自体ですらシステムに大きな負担がかかっていた。ジッターが増えやすい環境だったのではないかと思う。そうした場合には、mpdによるアップサンプリングの品質が悪くても、しないよりマシで、したほうが音がよかった。

もっと昔、ニールヤングがリリースしたDVDのハイレゾ音源を、当時はPowerbook G4だったかで再生して、CDと比べて音がいいことに驚いたことがある。もしかしたら元々ミキシングが違うのかもしれないが。ずいぶんクリアになるんだな、と当時は思った。ミキシングが違うからという印象ではなかったのだけど。

そこでタイトルに戻るのだけど、ハイレゾだ。

ファイルをアップサンプリングして再生するということは、ハイレゾを再生するということだ。
アップサンプリングして送信するということは、ハイレゾを送信するということだし、アップサンプリングするということはハイレゾ化するということだろう。

CDからのリッピングファイルをアップサンプリングしただけのファイルやデータなんてニセレゾじゃないかという話があるが、僕はいろいろ考えては見たんだけど、まあ、それもハイレゾだろう、という結論に達した。
問題になるのは売り方だ。
ニセレゾというのは、売り方の問題に関わる言葉だ。
それとハイレゾファイルって実際どうなのか、という問題は別だ。

ここまでの話の流れから、ここで言いたいことは自明だろう。

ハイレゾ再生というのは、ジッターが多い環境での音質対策なのだと思っている。
ジッターが少ない環境なら、理論的に44.1kHz/16bitで充分なのだと思う。
ジッターが多い環境になると理論どおりのDA変換とはいかないので、44.1kHz/16bitの音楽再生だと音質劣化が無視できなくなるんだと思う。

話は単純で、サンプリング周波数が多くなったら単位時間当たりのサンプルが増えるので、DA変換に際してのジッターの影響による誤差が相対的に少なくなるのだろうと考えている。
得られる音質改善は対症療法的なものだ。
デジタル音源再生の音質改善の本質はジッター低減だと思うのだが、コンシューマーが取り組むには限界がある。というか、そもそもコンシューマーはジッターについて考えたりなんかしない。mp3で大音量のほうがいいのである。RAMに可逆圧縮ファイルを取り込んだりなんかしないのだ。

思うんだけどハイレゾ音源の利用というのは、もともとコンシューマー向きの再生形態でハイエンドオーディオ向きではないと思う。
ハイエンドコンポであればジッター対策もそこそこ施されているはずだから、恩恵が少ないのではないか。
むしろコンシューマー向きのジッター対策していないオーディオセットでこそ、CDとハイレゾの差がはっきり出るんじゃないかと思うし、コンシューマーは難しいことは考えずにハイレゾ使ったら音がいいねで済んじゃうほうが望ましい。ジッターが少なかったらCDで充分なんて薀蓄はコンシューマーには似合わないし、コンシューマー用の機器ではそもそもジッター対策は打ちにくい。

いや、違うかな、、、
家電店とかでコンシューマー向きのミニコンポとかの音を聴く機会があるけれど、なんというか厚化粧で、これならどんなCDでもおんなじように鳴るだろうな、という印象を受けることがある。あらを隠すことには大成功してるという感じ。これも技術的なノウハウがあるのだろう。
CDとハイレゾの区別は付かないかもしれない。
だとしたらハイレゾの恩恵を受ける層はいないってことになるのかな、、、

話がそれた。
ここで取り上げるのは、CD音源の44.1kHz/16bitのファイルを192kHz/24bitに変換して、メモリ再生したらどう聴こえるだろうかということだ。
ジッター対策を多少なりとも行った環境(メモリ再生環境とはそういうものだと僕は理解している)でハイレゾに意味があるのかということ。
これで意味があるなら、ハイエンドオーディオでもハイレゾに意味があるだろう。

変換に使ったソフトは以下のサイトから落とした。
TASCAM Hi-Res Editor
https://tascam.jp/jp/product/hi-res_editor/top

使った音源は、Pierre Boulez の the Complete Columbia Album Collection というボックスセットから、CD40 Bartok / The Wooden Prince の一曲目、「Introduction」。CDをリッピングして作ってあった 44.1kHz/16bit flacからwav を作成、これを、TASCAM Hi-Res Editorを使って、192kHz/24bit wav を作成した。これを xrecode II を使ってflacにする。
つまり4種類のファイルができる。
ふだん使っているのはflacだが今回は敢えてwavも聴いてみる。

ファイルを作った直後に Compaq 6710b / foobar2000 で再生してiPodのおまけだったイヤホンで聞き比べたら、なんとなく違うような気がする。自作ハイレゾファイルのほうが、いいんじゃないかな。
次に、NASにコピーして、そこからのデータを再生。Compaq 6730b / mpd でイヤホンで聴いてみた。これは、区別が付かない。区別が付かない上に、どうも明らかに精彩を欠く。NASから物理的にもかなり遠いというのもあるのだろうか。しかし、それだけ聴いていたら、それほど音が悪いとも思わないんだけど。比較してしまうと差が明瞭になってしまう。

7月15日、追記。
気を取り直して再度、NASからの音をイヤホンで聴いてみたら、若干だが自作ハイレゾファイルのほうが滑らかで繊細なニュアンスが伝わる音がするようだ。最初に聴いたときは落差に驚いて判別不能に至ったようだ。
訂正しておく。

piCoreでメモリ再生してみる。メインシステムでスピーカーからの音だ。

結果から言えば、わずかだが違う。
ジッターの影響が少なくなれば区別が付かなくなる、という想定だったのだけど、違いはメモリ再生でも聴き取れるように思う。
Ras piなんて使ってるからそんなもんだろと言われても他と比較する術はないが。
192kHz/24bitのほうが繊細でグラデーションが細やかな鳴り方だ。44.1kHz/16bitは勢いがあるけど、やや荒い。ロックには良いだろうけど。ロックは昔からノイジーな音楽で、若者はそのほうが共感できることがある。

困った。自作ハイレゾの方がオーディオ的には音がいい。
というか、CDをリッピングしたファイルから作ったハイレゾでも、ハイレゾとして機能するんじゃないのかな?

何が困るって、CD1枚をリッピングしたflac(うちのライブラリの基本はそれだ)からハイレゾファイルを作って再生するとしたらファイルのサイズがバカにならない。Ras pi 2 のメモリ1GBではとうてい足りない。Ras pi の何がいいって、i2sデバイスが簡単に設定できるところなのだけど、数GB以上のメモリを積んだ他のボードPCを利用するとなると、i2sの工作が大変だ。ソフトウェアの設定も、Ras pi のように簡単にはいかないはずだ。
となると、usb出力を使うことになる。
うちには使えそうなusbデバイスがないのだ。何か探すということになる。
しかし現状で鳴っている音を聞くと、、そこまでするニーズって、僕の中にあるの?と思ってしまう。

他の手段としては、Ras pi 2 に他のメモリを追加して使うとか。usbメモリを刺して、musicディレクトリにマウントしてしまえば数GB以上の空間として使える。若干システムの負担になるのがデメリットだけど、LAN経由でNASを繋ぐほどじゃないはずだ。
というか、ハイレゾ変換ファイルusbメモリ再生をするつもりなんだろうか僕は。
日常的な使用という意味では、メモリ再生以上にハードルが高い。音源を格納したusbメモリを再生出来るネットプレーヤーなどという製品が巷では販売されているのだし、もしかしたらそっちのほうが有望な選択肢なんて事になるやもしれない。

などと考えながら、購入した正規のハイレゾファイルのメモリ再生などしていると、必ずしもハイレゾの方がいい感じに鳴るとばかりは言えないように思えてきた。Waltz for Debbyは、CDからリップした44.1kHz/16bit flacのほうがなんだかいい感じなのだ。HDTracksから購入した96kHz/24bitのファイルがあるんだけど、どうも良くない。ぼんやりしている。以前からハイレゾってこんなかな?ソフトな音だよねと思ってたんだけど、明確になってしまった感じだ。
理由は、おそらくはマスターの劣化によるものだ。

ハイレゾのマスターは、米コンコード社でオリジナル・アナログ・テープより変換された2010年192kHz/24bitリマスターを基にしたDSDマスターが使用されているとか。対して、CDのほうは1997年のもので、アナログマスターテープに20bit K2スーパーコーディングを用いたHQCDだ。
10年以上の時間による経年劣化が、音に反映されているのではないか。
もうひとつ音源を所持していて、Complete Village Vanguard Recordings 1961(日本盤)というもの。これは2002年にデジタル・リマスタリングされたらしく、どうもベースの音が太い。別ものだ。
調べてみたら、Waltz for Debbyという音源はいろいろあって一筋縄に行かないらしい。

こうなると、古い音源が欲しくなる。
これ以上ここに書くと話がとっちらかるので止める。

さて。
ras pi2 + piCore7 は、usbメモリを刺したら自動的に認識してくれる仕様になっているようだ。

tc@box:~$ fdisk -l

Disk /dev/mmcblk0: 3965 MB, 3965190144 bytes
3 heads, 8 sectors/track, 322688 cylinders
Units = cylinders of 24 * 512 = 12288 bytes

        Device Boot      Start         End      Blocks  Id System
/dev/mmcblk0p1             342        2902       30720   c Win95 FAT32 (LBA)
/dev/mmcblk0p2            2903      322688     3837432  83 Linux

Disk /dev/sda: 8054 MB, 8054112256 bytes
49 heads, 29 sectors/track, 11070 cylinders
Units = cylinders of 1421 * 512 = 727552 bytes

   Device Boot      Start         End      Blocks  Id System
/dev/sda1               1       11071     7865328   b Win95 FAT32

tc@box:~$ mkdir music/usb
tc@box:~$ sudo mount -t vfat /dev/sda1 music/usb

上記コマンドでマウントポイントusbにsda1をマウントできる。
しかし、理由はよくわからないのだけど、これでmusic/usbmに音楽ファイルをsftpで転送出来るのかというと、うまくいかない。権限の問題じゃないかと考えたりしたのだけど、解決できなかった。
しかたないので、以下のようなコマンドでNASの音楽ディレクトリもマウントして、そこからsshでコマンドを打って音楽ファイルをコピーすることにした。

tc@box:~$ mkdir titan
tc@box:~$ sudo mount -o addr=192.168.1.80,nolock -t nfs 192.168.1.80:/titan /home/tc/titan

しかし、これもうまくいかない。 というのは、せっかくマウントしたusbメモリをメモリとして使ってくれないようなのだ。
piCoreはどうも、メモリが必要となるとまずはRAM、その次にmicroSDカードを使うように設定されているようで、マウントされてるusbメモリは目もくれず、まずRAMにデータを蓄積し、足りないとmicroSDカードにデータを蓄積していく。数GBのデータをマウントしたusbメモリに転送したつもりが、アンマウントして確認したら空っぽだった。
これでは音を出してもどこにあるデータを再生しているのかわからない。

つまり、usbメモリからの音を聴きたければ、あらかじめデータをusbメモリにコピーしてから刺さないといけない、ということだ。
解決法もあるのかもしれないが、発見できなかった。それでも、音が出るだけ御の字だ。

そんなこんなで、usbメモリに書き込んだファイルとLAN経由の音を比較してみる。音源はMiles DavisのSorcerer。
多少、usbのほうがいい感じ。細かいニュアンスがでるしアタック音のきつさが自然になる。
usbメモリに書き込んだファイルと、RAMに置いた音を比較してみる。、、若干、RAMのほうがいいかな。細かいニュアンスが出ている。比べたらusbのほうが荒々しい。
usbメモリを抜いたら、また変わるのかもしれないけど、ちょっと根気や記憶力が続かなくて比較できないと思う。

一応、音質の比較は LAN < usbメモリ < RAM、ということになった。
しかし、usbとRAMとの音質差はわずかで、激しい音楽の場合はusbでもいいんじゃないかな、という感じだ。

usbメモリにハイレゾ化したファイルを置くようにしたらRAMの不足を補えるかと思ったけど、どうも改善と悪化が打ち消しあってチャラになりそうな予感がする。
RAM再生で比較したら差を聴きとれた Boulez の Bartok / The Wooden Prince 「Introduction」を再生してみる。
RAMにCDからリップした44.1/16のflac、usbにそのファイルから作った自作ハイレゾ192/24のflac。

区別が付かない。
そう思いこんでるからかどうかわからないが、実際区別が付かない。残念だけど、usbメモリを自作ハイレゾの貯蔵庫にというアイディアはどうも無駄ばかり多いということになりそうだ。自作ハイレゾを本気で使う気ならメモリを数GB以上積んだマシンで取り組むべきなんだろう。

もしもusbメモリを貯蔵庫に使えるようなら色々と便利になるだろうにと思っていたんだけど、残念だった。今回はここまで。

7月19日、追記。

ふと思い立って、アップコンバートを試みることにした。
Raspberry pi B+ではとうてい無理だと思っていたんだけど、Ras pi2だったらメモリもCPUも強化されているし、出来るのではないか。
mpdの設定で、量子化ビット数はCDと同じ16のまま、サンプリング周波数を上げることにする。
libsamplerateは、tczが用意されているので、以下のコマンドでインストールできる。

tce-load -wi libsamplerate-dev.tcz libsamplerate-doc.tcz libsamplerate.tcz

mpdを再インストールして、.mpdconfを編集する。

サンプリング周波数192kHzでは、Medium Sinc Interpolatorではノイズ、音跳びでうまくいかなかった。
サンプリング周波数176.4kHzだったら、Medium Sinc Interpolatorで再生出来る。

音質は今までで最高だと思う。

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

Jun 14, 2016

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

現在のオーディオシステムについて記録。

OMRON
BY50S
QNAP HS-210
buffalo LSW4-GT8NSB --- LAN --- client PC (ncmpcpp/sftp/ssh)
planex FX08-mini
planex FX08-mini
Raspberry Pi 2
piCore7.0
mpd 0.17.6
HiFiBerry Digi+
(COAX : DH LABS D-75)
Raspberry Pi B+
Volumio 1.55
mpd 0.19.1
HiFiBerry Digi+
(TOS : SAEC OPC-M1)
rosendahl
NANOCLOCKS
(Word clock:192kHz)
Kripton
PB-500-2
TEAC
VRDS-25xs
(COAX > BNC)
RME fireface UCX
(TRS Phone > XLR : ZAOLLA ZSX-103M)
Kenwood DP-5090
(TOS > audio technica AT-HDSL1 > COAX)
Sharp SM-SX100
(協和電線 5.5sq Cabtyre)
JBL 4425mk2 (Space&Time omni8)
charge coupled network
FOSTEX T900A

下流は変わらないが、上流がいろいろ変わっている。

以前はibookとmpdを使ったusbオーディオが中心だったんだけど、そこからRaspberry PiとVolumio、i2sボードを使った方法に移行している。
更に、最近はRaspberry pi2のRAMに音楽ファイルを丸ごと読み込んで再生するメモリ再生方式も取り入れている。 なかなかこれがいい感じだ。

NASからRaspberry piまでの間にはハブを3つ噛ましている。
これはジッター軽減を目指しての所作。
しかしメモリ再生が中心になってくると、あんまり意味がないということになるかも。

DACはfireface UCXに変更になっている。
これに伴って、以前にSRC2496に使おうとしてうまくいかなかったnanoclocksを復帰させている。中古だから壊れているかもと思っていたら、ちゃんと繋がった。しかし、効果のほどは不明だ。
SRC2496はシステムから外れた。

VRDS-25xsは、リッピングしていないCDをちょい聴きするときに使う。ちょい聴き用だからデジタル出力をSM-SX100のデジタル入力に入れている。あんまり推奨される使い方ではない。
DP-5090は子供用。VRDS-25xsを子供に使わせるのはCDがトレイに付いたりして危なっかしい。なんでSM-SX100のTOSに直接入力していないかというと、SM-SX100のセレクターが不調でTOS入力が選択できないからだ。同軸入力はBNCとCOAXがあるので変換したら何とかなる。

SM-SX100は本当にいいアンプだと思うんだけど、生産終了し何年もたったシャープに修理に出すのがちょっと不安な感じになってきている。
nmodeのアンプを入手すべきか、などと考えたりする。

追記。
4425mk2のセッティングについて書き忘れていた。

転居以降、地震対策の名目のもと、キャスターの上にスピーカーをセッティングしている。
当初はまともな音が出なかったが、現在はそこそこ満足できる音が出ていると思う。
セッティングの状況は以下のような感じ。

1cm厚御影石ボード+T900A
0.5mm厚ゴムシート片 6枚
4425mk2
スピーカースタンドMST-40Hの天板
TAOC PTS-N 3個(スパイク受け)
TAOC TITE-46GP 3個(スパイク上向き)
3cm厚御影石ボード
ベニア板積層積み上げ
(間にスピーカースタンドMST-40Hの底板を含む)
楽走くん(キャスターボード)

結局、スピーカーの下に質量を詰め込んだ形になっている。
見た目は、客に見せられない。いつかなんとかしたいけど、、、

スピーカースタンドがお蔵入りかと思っていたら、天板と底板をネジを外して使うことになった。ベニヤ板を積んでなんとかしようとしたが、かさばる割に質量がない。比べたら鋳鉄板は相当重い。

しかしこれで俄然、音が引き締まる。
JBLのスピーカーは箱を鳴かせたほうがいいという意見をよく見るが、うちでは逆だ。エンクロージャーの上下を御影石と鋳鉄板でサンドして、箱鳴りを極力排除している。
エンクロージャーを鳴らさずに、その下のスパイクを上向きに使うことで、スピーカーからのエネルギーが下方に流れていくのを止めている、ということかな。
結果、不足気味だった低域がしっかり鳴るようになった。
スピーカーのエネルギーが、空気に伝わりやすく音に変換されやすくなったと思う。

以前はかなり絞っていたアッテネーターも、今は10時半~11時ぐらい。
つまり、過去に安定して鳴っていたときと同じ位置で使えている。

Jun 04, 2016

Raspberry Pi でメモリ再生を試みる2(raspbianにmpdをインストールする)

タイトルに2とあるが、実はメモリ再生はpiCore7よりも前にraspbianで成功していた。
そもそも、デバイスの設定をconfig.txtに書き込むとalsaが認識してくれるというのは、raspbianで試みて気付いたことだった。piCore7だけいじっていたときにはこれに気付かず、諦め、まあ気を取り直してraspbianでやってみっか、、、で、気付いたのだ。

ネットで探してもpiCoreのalsaの設定の仕方はよく分からない。
僕は出来合いのi2sDACでhifiberryから設定をもらえたので簡単だったが、USB-DACとかつなぐ場合の設定は全く分からない

それはともあれ。
大したことはないけど、これも備忘録にしておく。

raspbianをmicroSDにインストール、i2sデバイスを設定

僕が使ったのはRaspbian Jessie Liteだ。 https://www.raspberrypi.org/downloads/raspbian/ 上記のサイトからダウンロードできる。

これをmicroSDに焼いて、config.txtにi2sデバイスの設定を書き込む。
下記サイトを参考。
https://www.hifiberry.com/guides/configuring-linux-3-18-x/

raspbianをRas Piで起動した後で、/boot/config.txtに書き込んで再起動でもかまわない。
ちなみにpiCore7だとブート後はconfig.txtが見えなくなる。

ファイルイメージの拡張

Ras Piに刺して起動し、sshでログインする。
ユーザーはpi、パスワードはraspberry。

そこで以下のコマンドでファイルイメージを拡張しておく。ついでにローカル設定とかもしておく。
pi@raspberrypi:~ $ sudo raspi-config

alsaインストール

下記のコマンドでインストール。

pi@raspberrypi:~ $ sudo apt-get install alsa-base

swapを止める

ほっとくと100MB程がswapに取られてしまうので設定しなおす。
コマンドなど経過は下記のとおり。
本当はpiCoreでも止めたいんだけど、こっちは方法が分からない。まあ、音楽ファイル用にswapが使われるので放置でもいいんだろうけど、止めるほうがすっきりしてるんじゃないかという気がする。


pi@raspberrypi:~ $ free
             total       used       free     shared    buffers     cached
Mem:        445124     191848     253276       4460      12388     150836
-/+ buffers/cache:      28624     416500
Swap:       102396          0     102396

pi@raspberrypi:~ $ swapon -s
Filename				Type		Size	Used	Priority
/var/swap                              	file    	102396	0	-1


 pi@raspberrypi:~ $ sudo swapoff --all

pi@raspberrypi:~ $ free
             total       used       free     shared    buffers     cached
Mem:        445124     191848     253276       4460      12396     150852
-/+ buffers/cache:      28600     416524
Swap:            0          0          0
pi@raspberrypi:~ $ 


pi@raspberrypi:~ $ sudo apt-get remove dphys-swapfile
Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following package was automatically installed and is no longer required:
  dc
Use 'apt-get autoremove' to remove it.
The following packages will be REMOVED:
  dphys-swapfile
0 upgraded, 0 newly installed, 1 to remove and 0 not upgraded.
After this operation, 85.0 kB disk space will be freed.
Do you want to continue? [Y/n] Y
Can't set locale; make sure $LC_* and $LANG are correct!
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
	LANGUAGE = (unset),
	LC_ALL = (unset),
	LC_TIME = "en_US.UTF-8",
	LC_MONETARY = "en_US.UTF-8",
	LC_MEASUREMENT = "en_US.UTF-8",
	LC_NUMERIC = "en_US.UTF-8",
	LC_PAPER = "en_US.UTF-8",
	LANG = "en_GB.UTF-8"
    are supported and installed on your system.
perl: warning: Falling back to a fallback locale ("en_GB.UTF-8").
locale: Cannot set LC_ALL to default locale: No such file or directory
(Reading database ... 31037 files and directories currently installed.)
Removing dphys-swapfile (20100506-1) ...
Processing triggers for man-db (2.7.0.2-5) ...
pi@raspberrypi:~ $ 

pi@raspberrypi:~ $ sudo reboot

pi@192.168.1.116's password: 
Last login: Mon May 23 23:41:23 2016 from 192.168.1.52

pi@raspberrypi:~ $ free
             total       used       free     shared    buffers     cached
Mem:        445124      62396     382728       4456       6096      31940
-/+ buffers/cache:      24360     420764
Swap:            0          0          0
pi@raspberrypi:~ $ 

freeのメモリが250MBから380MB以上に増えている。

音楽ファイルの置き場をram diskで設定

以下のとおり。意味があるのかどうか分からないが。


pi@raspberrypi:~ $ df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/root       3.6G  890M  2.5G  26% /
devtmpfs        214M     0  214M   0% /dev
tmpfs           218M     0  218M   0% /dev/shm
tmpfs           218M  4.4M  213M   2% /run
tmpfs           5.0M  4.0K  5.0M   1% /run/lock
tmpfs           218M     0  218M   0% /sys/fs/cgroup
/dev/mmcblk0p1   63M   21M   43M  33% /boot

pi@raspberrypi:~ $ sudo vi /etc/fstab

proc            /proc           proc    defaults          0       0
/dev/mmcblk0p1  /boot           vfat    defaults          0       2
/dev/mmcblk0p2  /               ext4    defaults,noatime  0       1
# a swapfile is not a swap partition, no line here
#   use  dphys-swapfile swap[on|off]  for that
##### ramdisk
tmpfs       /home/pi/music     tmpfs    defaults,size=400m 0      0  

pi@raspberrypi:~ $ sudo reboot

pi@raspberrypi:~ $ df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/root       3.6G  890M  2.5G  26% /
devtmpfs        214M     0  214M   0% /dev
tmpfs           218M     0  218M   0% /dev/shm
tmpfs           218M  4.4M  213M   3% /run
tmpfs           5.0M  4.0K  5.0M   1% /run/lock
tmpfs           218M     0  218M   0% /sys/fs/cgroup
tmpfs           100M     0  100M   0% /home/pi/music
/dev/mmcblk0p1   63M   21M   43M  33% /boot

flacをインストール、mpdをインストール

以下のコマンドでインストールできる。

pi@raspberrypi:~ $ sudo apt-get install flac
pi@raspberrypi:~ $ sudo apt-get install mpd

あとはmpd.confを編集してmpdを動かすだけで音が出るはず。

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

Jun 02, 2016

Raspberry Pi でメモリ再生を試みる(piCore7にmpdをインストールする)-いろいろ追記あり

http://www.yung.jp/bony/ こちらのサイトで5月頃から興味深い試みの報告が行われている。
mpdサーバのRAMに音楽ファイルを読み込んで再生したら、NASをマウントするよりもサーバの負担が少ないので音質改善が見込めるのではないかという話だ。
うちでも昔、NASを交換したときの音質変化に驚いたことがある。
機種によってはcifs、nfsでマウントすることが負担になるNASがあるようで、そうした機種だと音が悪くなる。データの転送自体が不安定になってジッタが増加するのが原因だと思う。
そうした経験があったので「メモリ再生でNAS接続の負担から開放される」という話は、なるほどそうか、という思いだった。

試みたいが、うちにはTiny Core Linuxを走らせるハードがないから出来ないな、と思っていたら、Ras PiでPiCoreという派生OSを走らせることが出来るという。
これは面白そうだ。

結局、raspbianとpiCore7にmpdをインストールした。少々苦労したがなんとかなったので備忘録にしておく。
今回はpiCore7について。

2018年1月、追記。
このエントリーは読んでも分かりにくい面があるので、改訂版というのか、書き直しのエントリーをアップした。
分かりやすくするという目論みが成功したとは言い難いが。
piCore7にmpdをインストールする方法
http://blown-lei.net/endive/blosxom.cgi/audio_diary/20180103a.htm

microSDの準備。

piCore7はここから落としてくる。 http://tinycorelinux.net/7.x/armv6/releases/RPi/
これをmicroSDに焼く。

6月11日、追記。
Raspberry pi2以降の機種の場合は、こちらから落す。
http://tinycorelinux.net/7.x/armv7/releases/RPi2/
piはarmv6で、pi2以降はarmv7ということらしい。プロセッサーが違うということだ。

次に、下記のサイトから設定をもらってくる。hifiberryのデバイスの設定だ。
https://www.hifiberry.com/guides/configuring-linux-3-18-x/
以下にメモとして引用しておく。

DAC/DAC+ Light
dtoverlay=hifiberry-dac

DAC+ standard/pro
dtoverlay=hifiberry-dacplus

Digi/Digi+
dtoverlay=hifiberry-digi

Amp/Amp+
dtoverlay=hifiberry-amp

選択する機種によって設定が違うので合わせてconfig.txtに記載する。
ついでに、もとからある設定について下記のように記載変更した。
dtparam=i2c=off,spi=off,i2s=on,i2c_vc=off

piCore7を起動しsshでログイン。

microSDをRasPiに刺して電源供給するとpiCoreが起動する。
sshでログイン。
ipはxxx.xxx.xxx.116。ここらは環境によって変わる。
http://tinycorelinux.net/7.x/armv6/releases/RPi/README にも書いているが、userはtc、パスワードはpiCoreだ。

適宜、下記のコマンドで設定を保存していく。

filetool.sh -b

6月5日、追記。
ipアドレスを固定した。流れは下記のとおり。

tc@box:~$ ifconfig
eth0      Link encap:Ethernet  HWaddr B8:27:EB:36:8A:DF  
          inet addr:192.168.1.116  Bcast:192.168.1.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:775439 errors:0 dropped:92 overruns:0 frame:0
          TX packets:250166 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:1123681152 (1.0 GiB)  TX bytes:24070244 (22.9 MiB)

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

tc@box:~$ cd /opt
tc@box:/opt$ ls
alsa/         bootlocal.sh  bootsync.sh   shutdown.sh   tcemirror
tc@box:/opt$ vi eth0.sh

#!/bin/sh
pkill udhcpc
ifconfig eth0 192.168.1.82 netmask 255.255.255.0 broadcast 192.168.1.255 up
route add default gw 192.168.1.1
echo nameserver 192.168.1.1 > /etc/resolv.conf

tc@box:/opt$ ls
alsa/         bootlocal.sh  bootsync.sh   eth0.sh       shutdown.sh   tcemirror
tc@box:/opt$ chmod +x eth0.sh
tc@box:/opt$ ls -aFl
total 28
drwxrwsr-x    3 root     staff          200 Jun  4 12:46 ./
drwxr-xr-x   17 root     root           380 Jan  1  1970 ../
-rw-rw-r--    1 tc       staff          403 Jun  4 10:53 .filetool.lst
-rw-rw-r--    1 root     staff          145 Dec 31  2014 .xfiletool.lst
drwxr-sr-x    2 root     staff           40 May 31 08:36 alsa/
-rwxrwxr-x    1 root     staff          360 Jan 20  2015 bootlocal.sh*
-rwxrwxr-x    1 root     staff          272 Dec 31  2014 bootsync.sh*
-rwxr-xr-x    1 tc       staff          179 Jun  4 12:46 eth0.sh*
-rwxrwxr-x    1 root     staff          613 Dec 31  2014 shutdown.sh*
-rw-rw-r--    1 root     staff           31 Dec 31  2014 tcemirror
tc@box:/opt$ sudo vi bootsync.sh

#!/bin/sh
# put other system startup commands here, the boot process will wait until they complete.
# Use bootlocal.sh for system startup commands that can run in the background 
# and therefore not slow down the boot process.
/usr/bin/sethostname box
/opt/bootlocal.sh &
/opt/eth0.sh &

tc@box:/opt$ vi .filetool.lst

opt
home
etc/passwd
etc/shadow
etc/group
etc/gshadow
usr/local/etc/ssh/ssh_host_dsa_key
usr/local/etc/ssh/ssh_host_dsa_key.pub
usr/local/etc/ssh/ssh_host_ecdsa_key
usr/local/etc/ssh/ssh_host_ecdsa_key.pub
usr/local/etc/ssh/ssh_host_ed25519_key
usr/local/etc/ssh/ssh_host_ed25519_key.pub
usr/local/etc/ssh/ssh_host_rsa_key
usr/local/etc/ssh/ssh_host_rsa_key.pub
usr/local/etc/
etc/fstab
opt/bootlocal.sh
opt/eth0.sh

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

これでsudo rebootしたらipアドレスが固定される。

ディスクイメージを拡張。

以下の流れでディスクイメージを拡張。もともとは最低限の大きさなので、拡張しないと後で諸々のインストールに支障を生じる

tc@box:~$ sudo fdisk -u /dev/mmcblk0
Command (m for help): p

Disk /dev/mmcblk0: 7948 MB, 7948206080 bytes
3 heads, 8 sectors/track, 646826 cylinders, total 15523840 sectors
Units = sectors of 1 * 512 = 512 bytes

        Device Boot      Start         End      Blocks  Id System
/dev/mmcblk0p1            8192       69631       30720   c Win95 FAT32 (LBA)
/dev/mmcblk0p2           69648       93119       11736  83 Linux

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

Command (m for help): n
Command action
   e   extended
   p   primary partition (1-4)
p
Partition number (1-4): 2
First sector (8-15523839, default 8): 69648
Last sector or +size or +sizeM or +sizeK (69648-15523839, default 15523839): 15523839

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



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

tc@box:~$ 
tc@box:~$ sudo resize2fs /dev/mmcblk0p2
resize2fs 1.42.13 (17-May-2015)
Filesystem at /dev/mmcblk0p2 is mounted on /mnt/mmcblk0p2; on-line resizing required
old_desc_blocks = 1, new_desc_blocks = 30
The filesystem on /dev/mmcblk0p2 is now 7727096 (1k) blocks long.
tc@box:~$ 

この流れは http://tinycorelinux.net/7.x/armv6/releases/RPi/README にも書いているが、ちょっと不親切。
コマンドの使い方を調べる必要があった。

各種ライブラリやalsa、flacなどなどインストール。

下記のコマンドでいろいろインストール。

tc@box:~$ tce-load -wi gcc.tcz glib2-dev.tcz
tc@box:~$ tce-load -wi ncurses.tcz ncurses-dev.tcz make.tcz automake.tcz
tc@box:~$ tce-load -wi compile-essentials.tcz squashfs-tools.tcz bash.tcz bc.tcz
tc@box:~$ tce-load -wi pkg-config-doc.tcz pkg-config.tcz

tc@box:~$ tce-load -wi alsa.tcz alsa-config.tcz alsa-doc.tcz alsa-dev.tcz alsaequal.tcz alsa-locale.tcz alsa-modules-4.1.13-piCore+.tcz alsa-modules-4.1.20-piCore+.tcz

tc@box:~$ tce-load -wi flac-dev.tcz flac.tcz flac-doc.tcz libcue.tcz libcue-dev.tcz icu-dev.tcz icu.tcz

ぞろぞろ文字やらなにやらインストールの状況が端末に表示される。
なかなか面白い。

当方ではflacをcue sheetで扱えれば充分なので上記のような感じだけど、他に扱いたいファイル形式があるなら適宜必要なものを追加してインストールしておく必要がある。

alsaはユーティリティとかなくてもいいのか?と思ってたけど、なくてもデバイスの認識は出来て音も出るようだ。
この時点でこんな感じ。

tc@box:~$ aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: sndrpihifiberry [snd_rpi_hifiberry_dac], device 0: HifiBerry DAC HiFi pcm5102a-hifi-0 []
  Subdevices: 1/1
  Subdevice #0: subdevice #0

6月24日、追記。
wavを再生する必要性が生じたため、下記コマンドにてインストール追加した。
tce-load -wi libsndfile-dev.tcz libsndfile-doc.tcz libsndfile.tcz

mpdを再インストールしないといけない。
以前にインストールした後に残っていた、mpd、mpd-0.17.6、両ディレクトリをsudo rm -rfで削除。 あとは、下記の流れに沿ってmpd-0.17.6.tar.gzを再解凍して再インストール、で問題なく動く。

mpdのインストール。

将来的には分からないけど5月31日の時点では、tce-load -wi mpd.tcz ではインストールできない。
libopus.tczがないとかでエラーになる。

なのでソースから自分でコンパイルしてということになる。
以下、コマンドを羅列。

tc@box:~$ wget https://www.musicpd.org/download/mpd/0.17/mpd-0.17.6.tar.gz
tc@box:~$ tar xvf mpd*
tc@box:~$ cd mpd*6
tc@box:~/mpd-0.17.6$ ./configure
tc@box:~/mpd-0.17.6$ make

tc@box:~/mpd-0.17.6$ sudo mkdir ../mpd
tc@box:~/mpd-0.17.6$ 
tc@box:~/mpd-0.17.6$ sudo make DESTDIR=../mpd install
tc@box:~/mpd-0.17.6$ cd ..
tc@box:~$ 

tc@box:~$ mksquashfs mpd mpd-0.17.6.tcz
tc@box:~$ ls
mpd/               mpd-0.17.6/        mpd-0.17.6.tar.gz  mpd-0.17.6.tcz
tc@box:~$ md5sum mpd-0.17.6.tcz > mpd-0.17.6.tcz.md5.txt
tc@box:~$ ls
mpd/               mpd-0.17.6/        mpd-0.17.6.tar.gz  mpd-0.17.6.tcz  mpd-0.17.6.tcz.md5.txt

tc@box:~$ ls /mnt
mmcblk0p1/ mmcblk0p2/
tc@box:~$ sudo mv *tcz* /mnt/*2/tce/optional

コマンドの羅列にしたら、こんな感じ。
本当は間に文字やら何やらが表示される。

まずwgetコマンドでmpdのサイトからソースを落として解凍。
解凍されたディレクトリでconfigure、make。

ここから後が通常のlinuxと違うところで、mpdフォルダを作ってそこに一式まとめて、make installする。
その一式を、mksquashfsコマンドでtczファイルに圧縮。
md5sumコマンドで付録をつけて、/mnt/mmcblk0p2/tce/optionalディレクトリに送り保存する。
これで管理するのがtiny coreの作法ということだ。

次に、onboot.lstの末尾に、mpd-0.17.6.tczを追記する。

tc@box:~$ sudo vi /mnt/*2/tce/onboot.lst

ちなみに、mpd-0.17.6、mpd-0.16.8はインストールできた。 mpd-0.18.19、mpd-0.19.4、mpd-0.19.5はインストール自体ができなかったり実用にならなかったりしている。

RAMDISKでmusicフォルダを設定

6月5日、追記。
RAMDISKでmusicフォルダを設定などという余計なことはせず、普通にmusicフォルダのままがいいようだ。

RAMDISKは、raspbianにmpdをインストールした時に試してみたもので、特に問題なかったのでpiCoreでも設定していたんだけど、swapとの関係なのかどうなのか分からないが、ファイルの転送がうまくいかないようだ。
現在は/etc/fstabの設定は止めている。

tc@box:~$ sudo mkdir music
tc@box:~$ sudo chmod 777 music

tc@box:~$ sudo vi /etc/fstab
tc@box:~$ 
# /etc/fstab
proc            /proc        proc    defaults          0       0
sysfs           /sys         sysfs   defaults          0       0
devpts          /dev/pts     devpts  defaults          0       0
tmpfs           /dev/shm     tmpfs   defaults          0       0
/dev/zram0  swap         swap    defaults,noauto   0       0
/dev/mmcblk0p1  /mnt/mmcblk0p1  vfat     noauto,users,exec,umask=000 0 0 # Added by TC
/dev/mmcblk0p2  /mnt/mmcblk0p2  ext4     noauto,users,exec    0 0 # Added by TC

tmpfs       /home/tc/music     tmpfs    defaults,size=400m 0      0

これは意味があるのかどうか良く分からない。RAMDISKとして設定しなくても動くみたいだ。
sftpソフトでアクセスして/home/tc/musicに音楽ファイルを転送する。
mpd.confで、ここをmusic_directoryに設定する。

6月4日、追記。
homeディレクトリ以下にmusicフォルダを置くと、filetool.sh -bでmusicフォルダの音楽ファイルが記憶されてしまう、ということに今更気付いた。つまり、何かの必要があって再起動したら、その記憶されていた音楽ファイルが現れてくるということ。
通常運用し始めたらfiletool.sh -bを使う機会はそうそうないと思うけど、注意がいるかも。
そういう意味では、/musicとかfiletool.sh -bの影響を受けない場所を、bootlocal.shで指示して確保したほうがスマートかもしれない。

.filetool.lstへの追記

これは、うちの環境で意味があるのかどうか分からないんだけど、一応。

sudo vi /opt/.filetool.lst

以下の3行を追記している。

usr/local/etc/
etc/fstab
opt/bootlocal.sh

bootlocal.shにmpdを記載することでboot時に起動するとかあるようなんだけど、うちでは上手くいかなかった。sshでログインしてmpdコマンドを打って起動させている。

mpdの設定。

tc@box:~$ 
tc@box:~$ mkdir .mpd
tc@box:~$ mkdir .mpd/playlists
tc@box:~$ sudo cp mpd-0.17.6/doc/mpdconf.example ~/.mpdconf
tc@box:~$ 
tc@box:~$ sudo vi .mpdconf

mpd.confを設定する。
mpdのINSTALLファイルにデフォルト指定があるので、そのひとつの~/.mpdconfを選択。
music_directoryなどの設定、alsaを出力に設定。
後は勝手知ったるもので、好きなように設定したらいい。
auto_updateを有効にしておけば、ファイルを入れ替えたらすぐに反映されるので便利。

とりあえず、以上だ。

6月6日、さらに追記。

nfsでNASをマウントする

nfsでNASをマウントするコマンド。
addr=を使う必要がある。

tc@box:~$ sudo mount -o addr=192.168.1.80,nolock -t nfs 192.168.1.80:/titan /home/tc/music

上記のコマンドで、192.168.1.80のNASの共有フォルダtitanを、piCoreのmusicディレクトリにマウントできる。
これでメモリ再生とNASをマウントした場合の比較が出来るかな。
いまさら気付いたが、NASをマウントした場合はライブラリの自動アップデートが効かない。これはmpdのバージョンが古いせいだと思う。
参考にしたサイトは以下。
http://forum.tinycorelinux.net/index.php?topic=19913.0

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

Feb 02, 2016

NASの中のcue sheetの中を検索する

オーディオは鳴らすばかりで音質への配慮をしてない日々が続いている。
気がつけば年が明けて旧正月を迎えようとしている。
覚書として、cue sheetの中を検索する方法をメモっておく。
うちではNAS上のフォルダを手元のノートにマウントしてることが多いのでそこで使うことが多いが、やってみたらvolumioにsshでログインした時も使うことができた。
ただ、うちのvolumioはカーネルをアップしている。アップしてない場合は試していない。

リッピングをCD単位でflacとcue sheetにして管理しているとファイルが少なくて済むのはいいのだけど、個別の曲についてどのファイルに入っているんだろう?となったときに困る。
よく知ってるアルバムならわかるけど(例えばしっかりジョンはジョンの魂に入ってるとか)、クラシックになってくると1つのCDに複数の作曲者や演奏者がいることが当たり前だ。ファイル名にそれらを全部入れるわけにいかないし。
そういうわけで複数のcue シートの中を一括で検索したいということになる。

あちこち調べた結果、find、grep、パイプでlessで表示、でやれることがわかった。
以下、volumioでの流れをコピペ。

root@192.168.1.81's password: 
Linux volumio81 4.1.7+ #817 PREEMPT Sat Sep 19 15:25:36 BST 2015 armv6l
                       ___                                      
                      /\_ \                        __           
         __  __    ___\//\ \    __  __    ___ ___ /\_\    ___   
        /\ \/\ \  / __`\\ \ \  /\ \/\ \ /' __` __`\/\ \  / __`\ 
        \ \ \_/ |/\ \L\ \\_\ \_\ \ \_\ \/\ \/\ \/\ \ \ \/\ \L\ \
         \ \___/ \ \____//\____\\ \____/\ \_\ \_\ \_\ \_\ \____/
          \/__/   \/___/ \/____/ \/___/  \/_/\/_/\/_/\/_/\/___/ 
        
             Free Audiophile Linux Music Player - Version 1.55

                 C 2013 Michelangelo Guarise - Volumio.org
                    192.168.1.81 hifiberryDigi+

Volumio Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Tue Jan 19 06:15:14 2016 from 192.168.1.23
root@volumio81:~# ls /mnt
NAS  UPNP  USB
root@volumio81:~# cd /mnt/NAS
root@volumio81:/mnt/NAS# ls
hs210
root@volumio81:/mnt/NAS# cd hs*
root@volumio81:/mnt/NAS/hs210# ls
audio_check  classic  ethnic  jazz  kids  pop
root@volumio81:/mnt/NAS/hs210# find classic -type f -name "*.cue" -exec grep -C 1 -H -i "telemann" {} \; | less

volumioにsshでログインし、 マウントされてるNASの音楽フォルダまで移動する。
そこにはファイルが階層化されたディレクトリに分別されてるので、探したいフォルダの中のcue sheetの中を検索するという流れ。
hs210というディレクトリの下層に、audio_check classic ethnic jazz kids pop、というディレクトリがある。
一番下のコマンドは「classic」というディレクトリのなかの、末尾が「.cue」というファイルすべてを探して、その中の「telemann」という言葉を含む行を検索して、結果をlessで表示してね、って感じ(lessというのはlinuxのテキストビューアだ)。
コマンドにオプションが色々付いているけど説明は省略。

検索結果が、以下のような感じで表示される。
ごちゃごちゃした感じで、使いやすいというわけじゃないけど、ないのに比べたら相当助かっていると思う。

classic/111 years of Deutsche Grammophon Vol.2/23 Daniel Hope - Air. A Baroque Journey.cue-  TRACK 09 AUDIO
classic/111 years of Deutsche Grammophon Vol.2/23 Daniel Hope - Air. A Baroque Journey.cue:    TITLE "Telemann, GP - Concerto for violin, strings & continuo - 1 Adagio"
classic/111 years of Deutsche Grammophon Vol.2/23 Daniel Hope - Air. A Baroque Journey.cue-    PERFORMER "Daniel Hope"
--
classic/111 years of Deutsche Grammophon Vol.2/23 Daniel Hope - Air. A Baroque Journey.cue-  TRACK 10 AUDIO
classic/111 years of Deutsche Grammophon Vol.2/23 Daniel Hope - Air. A Baroque Journey.cue:    TITLE "Telemann, GP -Concerto for violin, strings & continuo - 2 Allegro"
classic/111 years of Deutsche Grammophon Vol.2/23 Daniel Hope - Air. A Baroque Journey.cue-    PERFORMER "Daniel Hope"
--
classic/111 years of Deutsche Grammophon Vol.2/23 Daniel Hope - Air. A Baroque Journey.cue-  TRACK 11 AUDIO
classic/111 years of Deutsche Grammophon Vol.2/23 Daniel Hope - Air. A Baroque Journey.cue:    TITLE "Telemann, GP - Concerto for violin, strings & continuo - 3 Presto"
classic/111 years of Deutsche Grammophon Vol.2/23 Daniel Hope - Air. A Baroque Journey.cue-    PERFORMER "Daniel Hope"
(END)

cue sheetのパスと、そこに記載された文字列が表示される。
ちなみに「grep -C 1」とコマンドを打っているので、検索に引っかかった行の前後1列も表示されている。この辺はオプションの設定次第で、-Aで後の行、-Bで前の行とか設定できる。「-C 1」の代わりに「-1」でもいいようだ。
うまくスクリプトに出来たらいいんだろうけど、そこまでは出来ていない。

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

Sep 28, 2015

Volumioのカーネルをバージョンアップしてみる(追記あり、さらに追記あり)

意味があるのかどうかは不明。以下に記録。

root@volumio:~# uname -r
3.18.5+
root@volumio:~# sudo rpi-update
 *** Raspberry Pi firmware updater by Hexxeh, enhanced by AndrewS and Dom
 *** Performing self-update
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 10206  100 10206    0     0  20820      0 --:--:-- --:--:-- --:--:-- 30648
 *** Relaunching after update
 *** Raspberry Pi firmware updater by Hexxeh, enhanced by AndrewS and Dom
#############################################################
This update bumps to rpi-4.1.y linux tree
Be aware there could be compatibility issues with some drivers
Discussion here:
https://www.raspberrypi.org/forums/viewtopic.php?f=29&t=113753
##############################################################
 *** Downloading specific firmware revision (this will take a few minutes)
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   168    0   168    0     0    166      0 --:--:--  0:00:01 --:--:--   234
100 48.0M  100 48.0M    0     0   113k      0  0:07:14  0:07:14 --:--:--  109k
 *** Updating firmware
 *** Updating kernel modules
 *** depmod 4.1.7+
 *** depmod 4.1.7-v7+
 *** Updating VideoCore libraries
 *** Using HardFP libraries
 *** Updating SDK
 *** Running ldconfig
 *** Storing current firmware revision
 *** Deleting downloaded files
 *** Syncing changes to disk
 *** If no errors appeared, your firmware was successfully updated to 7ee23ac1452ad57dcc0ef2c1f074060b4bd9338d
 *** A reboot is needed to activate the new firmware
root@volumio:~# reboot

root@volumio:~# uname -r
4.1.7+

以前、apt-get update、apt-get upgrade を試みたら動かなくなったことがあったので今回はどうかと思っていたが、今のところ、アップデート前と変わらない感じで使用出来ている。
音がスムーズになったような気がするが、たぶん気のせいだ。

10月4日追記。
うちは今、カーネルv4.1.7+、8+、9+のvolumioが混在した状況。
HiFiBerry Digi+がv4.1.7+、v4.1.9+、RBD-02+がv4.1.8+、ともに再生自体に不具合は生じていない。
ちょっと気付いたこととして、Digi+が付いてる奴のカーネルをv3.18.5+からバージョンアップしたら、音声ファイル再生をしていない時はデジタル信号を出力しないようになったらしい。というのは、v3.18.5+だったときは、再生していない時でもFireface-UCXのインジケータが点いていたけど、v4.1.7+、9+では再生していないときは消えている。

そもそも再生していない時に何を出力していたんだろうというのは今更な疑問だけど。
再生してない時に無音の信号が出っぱなしのほうが、再生環境によってはトラブルなく再生できるという話をどこかで読んだことがあるような無いような感じだけど、もしかしたらもとのv3.18.5+のvolumio1.55はそこらあたりを配慮してたのかもしれない。

もうひとつ、カーネルバージョンアップで音が出なくなることがあるらしい、ということでメモ。
下記のサイトで報告あり。
volumio1.55 ほーりーさん版のJessie化 : 新大陸への誘い
http://tackbon.ldblog.jp/archives/52383384.html
PCで音楽: Raspbian JESSIEへアップグレード
http://asoyaji.blogspot.jp/2015/10/rasbianjessie.html
Raspberry Pi - View topic - I2C, SPI, I2S, LIRC, PPS, stopped working? Read this.
https://www.raspberrypi.org/forums/viewtopic.php?t=97314

何でうちでは起きないんだろう、とか思ってたんだけど、たった今気付いたけど、ほーりーさん版だと起きるのかもしれない。うちのvolumioはvolumioのサイトから落としたままのものだ。ほーりーさん版は試したけど、うちではDigi+から音を出せなかったので使っていなかった。
音が出なくなった場合の対策が、上記リンクのサイトに書いてある。

10月10日、追記。
改めて、i2sDACのほうでほーりーさん版を鳴らしてみた。
i2sDDCだと鳴らせなかったが、DACだと簡単に鳴る。音は一皮むける感じがする。なるほどと思った。
これをカーネルバージョンアップしてみたら、v4.1.10+になった。たしかに音が出なくなる。
上記サイトの書いてあるとおり、/boot/config.txt に下記を追加。
dtparam=i2s=on
dtoverlay=hifiberry-dac
これでリブートしたら音が出る。ちなみにカーネルバージョンアップ前に書き加えていても問題ないようだ。

気付いたことがあるんだけど、i2sDACから音を出すとras piの赤いLEDが消えてしまう。音は問題なく出ているようだ。
これはカーネルとかvolumioの種類は関係ないみたい。
i2sDDCだとLEDは点灯したままだ。他のi2sDACだと違うのかもしれないが、持ってないので不明だ。

年が明けて2016年2月4日追記。
書き忘れていたんだけどi2sDACは、その後、程なくして壊れてしまったようだ。
DACとして認識されなくなった。
volumioを入れ替えても同じである。

思えば、ras piの赤LEDが消えていたのは前兆だったのかもしれない。あいまいな記憶だけど、もともと点いていたと思うのだ。

本当に壊れたのか、再確認しなくてはと思うまま放置している。
そういうわけで、現在うちで動いているvolumioは2台になっている。ともにDigi+で運用している。

2月11日追記。
結局、壊れてはいなかった。今日、volumio1.55で普通に動くのを確認した。
赤いLEDも普通に点灯している。

ただ、今更メインシステムに戻すのもなんだか無駄な感じだ。なにか、他に使い道はないだろうかと考えているところだ。

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

Sep 08, 2015

Volumio 1.55 をいじってみる

ちょっとこれは問題あるかもということに気付いたので、エントリの最後に追記した。

備忘録として。

sshでログインした時に表示されるアスキーアート(?)は編集できる。
/etc/motd を書き換えればいい。
うちでは3つのvolumioが動いていてsshでログインするので区別がつくほうがいい。

コマンドプロンプトにはデフォルトで「volumio」が表示されている。
これはウェブブラウザからのアクセス画面:systemで設定できるplayer nameがそのまま表示されているんだけど、これはネットワーク上のホスト名と同一なので、実はASCII文字のaからzまでと0から9の数字とハイフンしか使えないらしい。アンダーバーとか使った日にはsshでログインすると(none)と表示される。

これをsshからログインして変更してみる。
VolumioのベースはRaspbianで、RaspbianのベースはDebianだから、Debianでどうやるんだろうってとこで調べたら、/etc/hostnameの変更と、/etc/hostsの変更というのが引っかかってくる。
Vine Linuxとはやり方が違う。

sudo vi /etc/hostname

volumioとだけ書いてあるので書き換える。rootじゃ出来なくてsudoじゃないといけない。

sudo vi /etc/hosts

127.0.0.1       localhost
127.0.1.1       volumio

これもvolumioとあるのを変更。リブートで反映される。
と思ったら、反映されるのはsshでログインした場合のみで、ウェブブラウザからアクセスしたときのplayer nameは変わっていない。他で記憶されてるらしい。
ウェブブラウザからのアクセスは普段使わないのでよしとする。

さて、次。
sshでログインして、pstree -acp とコマンドを打つと以下のような表示が出る。

root@volumio:~# pstree -acp
init,1  
  ├─avahi-daemon,1912
  │   └─avahi-daemon,1913
  ├─dbus-daemon,1878 --system
  ├─login,2358 -f    tty1
  │   └─bash,2359
  ├─monit,2301 -c /etc/monit/monitrc
  ├─mpd,1972 /etc/mpd.conf
  │   ├─{mpd},1973
  │   ├─{mpd},1974
  │   ├─{mpd},1975
  │   └─{mpd},1976
  ├─nginx,2322
  │   └─nginx,2323
  ├─nmbd,2091 -D
  ├─php5-fpm,2036      
  │   ├─php5-fpm,2037                                     
  │   ├─php5-fpm,2038                                     
  │   ├─php5-fpm,2039                                     
  │   ├─php5-fpm,2040                                     
  │   └─php5-fpm,2041                                          
  ├─player_wdog.sh,2328 /var/www/command/player_wdog.sh startup
  │   └─sleep,2661 10
  ├─player_wrk.php,2365 /var/www/command/player_wrk.php
  ├─rpc.idmapd,1572
  ├─rpc.statd,1560
  ├─rpcbind,1529 -w
  ├─smbd,2159 -D
  │   └─smbd,2170 -D
  ├─sshd,2223
  │   └─sshd,2636 
  │       └─bash,2641
  │           └─pstree,2662 -acp
  ├─udevd,158 --daemon
  │   ├─udevd,272 --daemon
  │   └─udevd,282 --daemon
  └─winbindd,2271
      └─winbindd,2292

とりあえず、いらないっぽいプロセスをkillしてみようということで、avahi-daemon、winbindd、smbd、nmbd、player_wdog.sh、player_wrk.php、nginx、php5-fpm、monit、udevd、と止めてみているが、音はちゃんと出ているようだ。
以下のような感じにシェイプアップされる。

root@volumio:~# pstree -asp
init,1  
  ├─dbus-daemon,1880 --system
  ├─login,2361 -f    tty1
  │   └─bash,2362
  ├─mpd,1975 /etc/mpd.conf
  │   ├─{mpd},1976
  │   ├─{mpd},1977
  │   ├─{mpd},1978
  │   └─{mpd},1979
  ├─rpc.idmapd,1575
  ├─rpc.statd,1563
  ├─rpcbind,1532 -w
  └─sshd,2224
      └─sshd,2487 
          └─bash,2489
              └─pstree,2513 -asp

音が良くなったかというと、はっきりしない。
大して比較してないからはっきりしなくて当たり前なんだけど。しかし、なんか良くなってるという感じはする。音の鮮度が上がっているような。デジタルで音が良くなるっていうのは大抵そんな感じだ。

いちいちこれをコマンド打ってやるのも一興なんだけど、この際なのでlinuxの起動過程をいじって設定してみることにした。
/etc/inittabによると、/etc/rc2.dと/etc/rcS.dを起動時に読んでるらしい。

root@volumio:~# ls /etc/rc2.d | less

total 12
drwxr-xr-x   2 root root 4096 Jul 16 07:00 .
drwxr-xr-x 100 root root 4096 Jul 16 06:58 ..
lrwxrwxrwx   1 root root   18 Jul 25  2013 K02plymouth -> ../init.d/plymouth
lrwxrwxrwx   1 root root   17 Jul 25  2013 K05rsyslog -> ../init.d/rsyslog
-rw-r--r--   1 root root  677 Jul 15  2013 README
lrwxrwxrwx   1 root root   18 May 17  2013 S01bootlogs -> ../init.d/bootlogs
lrwxrwxrwx   1 root root   14 May 17  2013 S01motd -> ../init.d/motd
lrwxrwxrwx   1 root root   15 Oct 28  2014 S01samba -> ../init.d/samba
lrwxrwxrwx   1 root root   22 Apr  9  2014 S01transientlog -> ../init.d/transientlog
lrwxrwxrwx   1 root root   17 May 17  2013 S13rpcbind -> ../init.d/rpcbind
lrwxrwxrwx   1 root root   20 May 17  2013 S14nfs-common -> ../init.d/nfs-common
lrwxrwxrwx   1 root root   13 May 18  2013 S16atd -> ../init.d/atd
lrwxrwxrwx   1 root root   14 May 18  2013 S16dbus -> ../init.d/dbus
lrwxrwxrwx   1 root root   18 Jul 30  2013 S16dropbear -> ../init.d/dropbear
lrwxrwxrwx   1 root root   15 May 18  2013 S16exim4 -> ../init.d/exim4
lrwxrwxrwx   1 root root   14 Oct 28  2014 S16nmbd -> ../init.d/nmbd
lrwxrwxrwx   1 root root   13 May 18  2013 S16ntp -> ../init.d/ntp
lrwxrwxrwx   1 root root   18 May 17  2013 S16php5-fpm -> ../init.d/php5-fpm
lrwxrwxrwx   1 root root   21 Oct 28  2014 S16samba-ad-dc -> ../init.d/samba-ad-dc
lrwxrwxrwx   1 root root   13 May 18  2013 S16ssh -> ../init.d/ssh
lrwxrwxrwx   1 root root   14 May 17  2013 S16sudo -> ../init.d/sudo
lrwxrwxrwx   1 root root   22 May 17  2013 S16triggerhappy -> ../init.d/triggerhappy
lrwxrwxrwx   1 root root   17 Oct 28  2014 S16winbind -> ../init.d/winbind
lrwxrwxrwx   1 root root   22 May 18  2013 S17avahi-daemon -> ../init.d/avahi-daemon
lrwxrwxrwx   1 root root   14 May 18  2013 S17cron -> ../init.d/cron
lrwxrwxrwx   1 root root   15 Oct  9  2014 S17rsync -> ../init.d/rsync
lrwxrwxrwx   1 root root   14 Oct 28  2014 S17smbd -> ../init.d/smbd
lrwxrwxrwx   1 root root   14 May 18  2013 S17wicd -> ../init.d/wicd
lrwxrwxrwx   1 root root   13 Oct  9  2014 S18mpd -> ../init.d/mpd
lrwxrwxrwx   1 root root   15 Oct 28  2014 S19monit -> ../init.d/monit
lrwxrwxrwx   1 root root   16 Oct 28  2014 S19myruns -> ../init.d/myruns
lrwxrwxrwx   1 root root   18 Oct 28  2014 S19rc.local -> ../init.d/rc.local
lrwxrwxrwx   1 root root   19 Oct 28  2014 S19rmnologin -> ../init.d/rmnologin
(END)

root@volumio:~# ls -al /etc/rcS.d | less

total 12
drwxr-xr-x   2 root root 4096 Jul 16 07:00 .
drwxr-xr-x 100 root root 4096 Jul 16 06:58 ..
lrwxrwxrwx   1 root root   22 May 18  2013 K81plymouth-log -> ../init.d/plymouth-log
lrwxrwxrwx   1 root root   20 May 18  2013 K81x11-common -> ../init.d/x11-common
-rw-r--r--   1 root root  447 Oct 16  2012 README
lrwxrwxrwx   1 root root   22 May 17  2013 S01fake-hwclock -> ../init.d/fake-hwclock
lrwxrwxrwx   1 root root   21 May 17  2013 S01hostname.sh -> ../init.d/hostname.sh
lrwxrwxrwx   1 root root   24 May 17  2013 S01mountkernfs.sh -> ../init.d/mountkernfs.sh
lrwxrwxrwx   1 root root   14 May 17  2013 S02udev -> ../init.d/udev
lrwxrwxrwx   1 root root   24 May 17  2013 S03keyboard-setup -> ../init.d/keyboard-setup
lrwxrwxrwx   1 root root   26 May 17  2013 S04mountdevsubfs.sh -> ../init.d/mountdevsubfs.sh
lrwxrwxrwx   1 root root   20 May 17  2013 S05hwclock.sh -> ../init.d/hwclock.sh
lrwxrwxrwx   1 root root   22 May 17  2013 S06checkroot.sh -> ../init.d/checkroot.sh
lrwxrwxrwx   1 root root   32 May 17  2013 S07checkroot-bootclean.sh -> ../init.d/checkroot-bootclean.sh
lrwxrwxrwx   1 root root   14 May 17  2013 S07kmod -> ../init.d/kmod
lrwxrwxrwx   1 root root   17 May 17  2013 S07mtab.sh -> ../init.d/mtab.sh
lrwxrwxrwx   1 root root   20 May 17  2013 S08checkfs.sh -> ../init.d/checkfs.sh
lrwxrwxrwx   1 root root   21 May 17  2013 S09mountall.sh -> ../init.d/mountall.sh
lrwxrwxrwx   1 root root   31 May 17  2013 S10mountall-bootclean.sh -> ../init.d/mountall-bootclean.sh
lrwxrwxrwx   1 root root   16 May 17  2013 S11procps -> ../init.d/procps
lrwxrwxrwx   1 root root   19 May 17  2013 S11udev-mtab -> ../init.d/udev-mtab
lrwxrwxrwx   1 root root   17 May 17  2013 S11urandom -> ../init.d/urandom
lrwxrwxrwx   1 root root   20 May 17  2013 S12networking -> ../init.d/networking
lrwxrwxrwx   1 root root   17 May 17  2013 S13rpcbind -> ../init.d/rpcbind
lrwxrwxrwx   1 root root   20 May 17  2013 S14nfs-common -> ../init.d/nfs-common
lrwxrwxrwx   1 root root   21 May 17  2013 S15mountnfs.sh -> ../init.d/mountnfs.sh
lrwxrwxrwx   1 root root   31 May 17  2013 S16mountnfs-bootclean.sh -> ../init.d/mountnfs-bootclean.sh
lrwxrwxrwx   1 root root   13 May 17  2013 S17kbd -> ../init.d/kbd
lrwxrwxrwx   1 root root   23 May 17  2013 S18console-setup -> ../init.d/console-setup
lrwxrwxrwx   1 root root   20 May 18  2013 S19alsa-utils -> ../init.d/alsa-utils
lrwxrwxrwx   1 root root   21 May 17  2013 S19bootmisc.sh -> ../init.d/bootmisc.sh
(END)

とりあえず、デフォルトの起動過程が終了したあとに要らないプロセスを止める方向でやってみる。
最初から起動させない手もあるが、それでvolumioに不具合があっても困ると思って。

rcS.dの中で止めれそうなのはS02udevだけっぽい。
udevにシンボリックリンクを張りリネームする。
[root@localhost rcS.d]# ln -s ../init.d/udev K82udev

これでK82udevがudevdを止めてくれるはずと考えたが上手くいかない。これだとudevdは止まらないようだ。
rc2.dのS17avahi-daemonでも試したが、同じ。
止めたいものは最初から止めておくしかないっぽい。しかしudevは/devを管理するデーモンなので、起動後にNASをマウントする都合上、問題がありそうな気がする。、、もう、止めなくてもいいか、、。

rc2.dのほうは最初から止めてもいいのがあるかもしれない。
S17avahi-daemonをBS17avahi-daemonにリネームする。どんなファイル名でもいい。要するにSを死活化できれば、initから読み込まれないはずだ。
再起動してpstree -aspを打ってみたらavahi-daemonは起動していない。成功だ。しかし、、、以前には見られなかったプロセスが増えている、、。atd、cron、ntpd、thd、これじゃ何をやってるのか分からない。いろんなプロセスが連携しているので、何かを動かさなかったら停止しないままだったり代わりに動くものが出てくるのかもしれない。

どうもinitの挙動をどうこうするよりも、特定のプロセスをkillするスクリプトを起動後に動かすようにしたほうが良さそうな。
でも書き方がわからないんだけど、、。

いろいろ調べて、以下のコマンドでプロセス名からプロセスIDを引用してkillできると言う事が分かった。

pgrep "プロセス名" | xargs kill

ということなら、以下のようなシェルスクリプトを実行するようにしておけば一括で不要なプロセスを終了できる。
/usr/local/binに、例えばkills.shというファイルを作る。

vi /usr/local/bin/kills.sh

#!/bin/sh

pgrep "player_wrk.php" | xargs kill
pgrep "player_wdog.sh" | xargs kill
pgrep "nginx" | xargs kill

pgrep "monit" | xargs kill

pgrep "winbindd" | xargs kill
pgrep "smbd" | xargs kill
pgrep "nmbd" | xargs kill

pgrep "php5-fpm" | xargs kill

pgrep "avahi-daemon" | xargs kill
pgrep "udevd" | xargs kill

こんな感じで。
sh /usr/local/bin/kills.sh
このコマンドで複数のプロセスをkillできる。
IDが大きいものから小さいものへの順番で止めている。順番に注意しないとkillしたはずのプロセスが復活することがあるようだ。

さて、このコマンドを/etc/rc.localに記入する。 rc.localの記載はもともとはこんな感じ。

#!/bin/sh -e
#
# rc.local
#
# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will "exit 0" on success or any other
# value on error.
#
# In order to enable or disable this script just change the execution
# bits.
#
# By default this script does nothing.
/var/www/command/player_wdog.sh startup & > /dev/null 2>&1

exit 0

多分、exit 0の前の行に、sh /usr/local/bin/kills.sh、と書き込んでおけば何とかなるんじゃないだろうか。
と思ったら、たしかに何とかなるんだけど、余計なプロセスが残存する。
多分、スクリプトの実行が早すぎるのだろう、ということで以下のような記載に変更。

/var/www/command/player_wdog.sh startup & > /dev/null 2>&1
sleep 30;sh /usr/local/bin/kills.sh
exit 0

起動行程が全て終わった30秒後にスクリプトが実行されるという塩梅。
これで、きれいに要らないプロセスを終了できるようになった。秒数が少ないと上手くいかないようだ。

気付いたことで追記。
うちではウェブブラウザからvolumioの操作をしない前提で、mpd設定ファイルのportを6600以外に変えているので、起動の時点でupmpdcliが動かない、ということに今更気付いた。
portの設定変更なしに6600のままだったら、当然upmpdcliが動くのだけど、上記のスクリプトを使うとそれがkillされずに取り残されて、たぶん暴走するんじゃないかな、、、
#!/bin/shの下に、

pgrep "upmpdcli" | xargs kill
という1行を足せばその問題は回避されると思うのだけど。
もしもまるごとコピペして何かトラブったような人がおられたら、今更追記でごめんなさい。

Posted at 20:38 in audio_diary | WriteBacks (0) | Edit Tagged as:

Jul 26, 2015

Raspberry pi B+ / Volumio 1.55 の運用状況

春に転居して以降、メインのトランスポートをraspberry pi B+ / volumio1.55に移行している。
状況を記録しておこうと思う。

そもそもはi2s DACを試すために導入し音質に感心したのが始まりだった。odeon-liteは2010年代のDACに替えないといけないと思った。
さらにibook G4/vine ppc mpdがral-24192ut1を認識しない、つまり192kHz/24bitのハイレゾを鳴らせないという問題が追い打ちをかけた。持っている音源は少ないけど、聴けないじゃ困ることもある。

現在、Raspberry pi B+ / Volumio 1.55は3台。
最初にi2s出力をDAC RBD-02+に送るのが1台。次にusb出力をDDC ral-24192ut1の同軸出力経由でDAC fireface UCXに送るのが1台。
両者の音質の差異は今ではかなり少ない。ブラインドでは僕には聴き分けられないかもしれない。最初はかなり違っていたんだけど、転居して数ヶ月のうちにRBD-02+は高域強調傾向で浮ついた感じだったのが少なくなり、firefaceは落ち着きすぎでもう少しどうにかな感じがなくなった。
理由は不明。
エージングと、ras piを12mm厚のMDF板にネジ止め固定した効果は多少はあるのかも?
どんな違いを聴けるだろうかと思っていたんだけど、ほぼ同じになるとは。

ところが最近、DDC HiFiBerry Digi+を入手し使用開始している。
これも手軽に使えるキットだが、同封されてきたスペーサーが長すぎ。カッターナイフで短くして使う。ちょっと力と注意が要る。
ここから光出力をUCXに送る。
音色の感触は前からあった2つの中間ぐらい。だが若干だが情報量が多い気がする。音の陰影に深みがあり立ち上がりも早い。
同軸出力のほうがいいはずと思って聴いてみたらやっぱりそのようだ。今後は同軸で使う。

しかしそうなるとUCXの同軸入力数の関係でral-24192ut1はどこで使おうかという事になる。メインシステムからはお役御免となるのだ。
まあ、そういうこともある。どこかで使うこともあるだろう。

さて、いろいろ雑事を書いておく。
volumioのサイトからimgファイルを落としてmicroSDカードに書き込むところから。
windowsで焼くときはvolumioのサイトに書いてあるとおりWin32DiskImagerを使ってやればたいてい問題なく起動する。
問題はlinuxの場合で、うちのvine linuxだと何かと上手くいかない。

当初、rootだからいいやと思ってddで焼いて全く起動せず、sudo ddで焼いたらマシになったかと思ったけど、本当にマシになった程度である。
df -hで/dev/sdb1と表示されたらsdb1にすればいいのかと思っていたらsdbにしないと上手く焼けない。sdb1で焼いたら読めないカードができてしまう。
うまくいったと思っても起動しなかったりパーティションをマウントできなかったり不具合は多い。volumioのサイトから落としたファイルの問題かと思ったこともあったが、何回ダウンロードしても同じことだ。

そんな手間かけるよりwindowsで焼けば良かろうということなんだけど、それでもカードによっては起動してからが上手くいかない。
何か設定して再起動したら動かなくなったり。
原因がはっきりしない。
何枚か試したがカードの容量、メーカー、classなど関係ない様子。

30日追記。
関係ないわけでもなさそうだ。下記のサイトに情報がある。しかし、、うちで不具合出てるのOKになってるね、、、
RPi SD cards http://elinux.org/RPi_SD_cards

先人たちの努力の跡を見ても、SDやmicroSDとはそういうものだと達観して対処するほうが賢いようで、たまたま上手く動くカードが出来たらイメージファイルにしてバックアップしておくのが自衛策ということだ。そういうイメージを動かないカードに焼いたら動くようになることがある。
バックアップから焼くのはvine linuxでも問題ないようだ。
謎である。

そもそもSDカードでOSを動かすこと自体、不安定で無理があるという意見もあるようだ。
通常のras piのOS(raspbianなど)についてはusbメモリから呼び出し起動するという手法がネット上にはあるが、、、usb-ddcを接続した状態でusbメモリからvolumioを呼び出す試みはうちでは失敗した。起動しない。

30日追記。
volumioのフォーラムへの書き込みをみたら、似たような体験をする人は海外にもいるようだ。
Lost 2 SD Cards in 10 Days https://volumio.org/forum/lost-cards-days-t1597.html
Offload Volumio to USB? https://volumio.org/forum/offload-volumio-usb-t715.html
Filesystem for long living SD Cards https://volumio.org/forum/filesystem-for-long-living-cards-t720.html
ちょっと引用する。

The problem is that Volumio uses ext3 (if I rememer correctly) that has no Flash wear leveling support.

ほんとうかねこれは。動いてるカードもあるわけで、謎である。
raspbianはext4らしいけど、じゃあext4ならいいのかという、、、

さて、最初に戻る。
とりあえずvolumioのイメージを焼いたら、ちょっと手を入れる。
カードには2つのパーティションができている。
小さいFATのボリュームと、1.7GBのext3のボリューム。
小さいほうが起動に使われ、大きい方にvolumioの本体が入っている。
小さい方の、/boot/config.txt に以下の記述を追加。
デフォルトでは、4つのusbプラグへの総電流供給量が0.6Aになっているらしい。これを1.2Aに上げる。

safe_mode_gpio=4
max_usb_current=1

一旦起動してからsshでログインし書き込み再起動という方法もあるが、そもそもusb-dacをつないで最初の起動の時にusbへの電力供給やら設定の読み込みやらなどで電力を余計に消費してるんじゃないか、などと思っているので、起動失敗のリスクが減るんじゃないかという意味で起動前に設定を変えておこうという考え。
これを書いたからといって起動の成功率が下がることはない、と思う。

raspberry piはusbとlanの情報処理を1つのチップでしてる?という事らしく、構造的弱点らしい。そういう意味ではやはり、i2s出力を利用できたら利用するほうがトラブルは少ないんだろうと思う。
実際、うちで繰り返しトラブっているのはusb-ddcをつないでいるras piで、i2s出力につないでいる方はトラブルがない。まあ、usb-ddcをつないでいる方を中心にいじってるからというのもあろうけど、不具合が多いからそういうことになる。

一応、追記。
現在、Digi+を継いで問題なくメイントラポとして動いてるras piは、先日までusb-ddcを継がれて不具合を繰り返していた個体である。つまりras piの個体差による問題ではないということ。

起動したら、粛々とウェブブラウザ画面からアクセスして設定をしていく。
ネットワークのアドレスを固定。
AirPlayは使わないのでoffに(volumioの再起動が必要)。
ライブラリにNASを設定。
ライブラリのアップデートが済んだらウェブブラウザは閉じる。

sshでログインし、raspi-configから現在地の時刻を設定。
ファイルイメージの拡張は、しなくてもいいかな、、、
1.5Gが8Gとかになったとしても、不具合が起きるかどうかには関係無さそうだ。

ここまで上手くいっても安心はできない。
sshからrebootを打って、無事に再起動が成功すればとりあえず安心。

次にsshからログインし、/etc/mpd.confの設定書き換え。
なぜかsamplerate_converter "Fastest Sinc Interpolator"の設定が残ってるので一応#でコメントアウト。これは意味があるのかどうかわからないが。
うちでは複数のmpd、volumioを1台のノートから複数のアカウントのncmpcppで操作する都合上、ポート設定を変更。6600を6601とかに。
これでウェブブラウザからのアクセスを受け付けなくなる。
受け付けなくなるだけで、アクセスしようとしたらvolumioへの負荷はかかるんだけど。
何かウェブブラウザから設定したいことがあれば、ポート設定を戻せばアクセスできる。

敢えてウェブブラウザからの操作をしないのは、volumioの負担軽減に繋がらないかという目論見もある。
どの程度効くのか分からないが、不具合はたいていウェブブラウザでアクセスしてる時に起こるという印象がある。ncmpcpp単独でアクセスしてる時におかしくなるのは、記憶にないような気がするのだ。

しかし、そこまで言うなら、例えばRaspbian OSにmpdをインストールしたほうが安定してる可能性もあるんじゃない?という考えもあるかも。残念ながら、まだそこは試していない。
Raspbianにmpdをインストールしたあと、usb出力とかi2s出力とか設定するのかと思うと、ちょっと苦しい。そこまでする余裕があるかというと自信がない。
思えば、vine mpdだって実用にするまで相当の時間がかかったし。
そういう意味でvolumioの手軽さはありがたい。

さて。mpd.confの書き換え後、一応、sshからvolumioをreboot。
ここまで上手くいくようなら良くできたカードといっていい感じがするので、バックアップしとけばいいかも。
再起動や終了はウェブブラウザから指示しないほうがいいような気がする。気のせいかもしれないが、起動しなくなることのほうが多いような気がして。

raspberry pi / Volumioは、手軽だけど不安定なシステムだと思う。
なんでこんなの使うんだろうと思うんだけど、やっぱりそこそこ面白い上に音がいいからだろう。不安定だからといって、既成品に向かうという選択肢は逆に考えにくい。

とは言いながら、ras pi B+の場合はusb出力を使おうとしたらトラブルが多すぎる気がする。
i2sをS/PDIFに変換してというのは元の木阿弥感が強いとはいえ、usb出力より音質も安定性もメリットが大きい気がするし、当面はDigi+がメインのトランスポートになるだろうなあ、という感じだ。
今後はデーモンの切り込みとかしていければと思うけど、追々、ゆっくりだ。

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

Jun 28, 2015

VolumioのSDカード領域を拡張したのでメモ 追記:USBポートの電流出力上限を変更した

他のサイトを参考にVolumioのSDカード領域を拡張した。

http://raspberrypi.blog.fc2.com/blog-entry-25.html
http://raspberrypi.blog.fc2.com/blog-entry-86.html

今回は自分のサイトにメモ書き。

まずroot、sshでvolumioにログイン。
次に以下のコマンドで設定を変更する。

vi /usr/bin/raspi-config

292

上の画面はviエディタでファイルを開いたところ。
do_expand_rootfs()
という項目の中、
if [ "$PART_NUM" -ne 2 ]; then の「2」を「3」に書き換え保存する。これをしておかないと下記の行程が無効になる。

次に下のコマンドを打つ。
raspi-config

上の画面が出るので、1の Expand Filesystem を選択。
指示のまま再設定し再起動。数分後には領域が拡張されている。

なぜ今更こんなことしようとしてるかというと、いまひとつシステムが安定しないからだ。
i2s DACに出力してる方はいいんだけど、USBから出力してる方はなんでかすぐにクラッシュする。
多少なりともマシにならないか、ってこと。

30日、追記。

なぜクラッシュするのかつらつら考えてるんだけど、いまいちはっきりしない。
ファイルシステムを拡張して、今のところ安定してるけど今後どうなるか分からない。
というか、安定したシステムになるまで繰り返しSDカードに焼くので一苦労だ。

気付いた点。
設定変更後に再起動を要することがあるが、するならNASをマウントしてデータベースを作成したあとにすること。
これをしておかないと終了後に再起動しない。途中で止まりSDカード書き込みからやり直し。
理由は不明。
ファイルシステム拡張設定後に再起動が必要なんだけど、これをやっておかないと起動しなくなる。

SDカードの問題。
調子が悪いカードだと、正常に起動する確率が下がる。当然と言えば当然だけど。
しかし普段使えてるカードが使えなくなっていく理由がはっきりしない。負荷が増えると反応しなくなり、sshのアクセスも受付けなくなる。こうなるとカード書き換えしないと動かなくなる。
しかも、書き換えてもうまく起動しないことがある。

USBに出力すること自体が負担になっているんじゃないかと思われる節がある。
うちではRAL-24192UT1をUSB-DDコンバータとして使ってるんだけど、これに外部電源をつないで以降、多少なりとも起動に失敗することが減った。最近、他のDACやDDCだとどうなのかと思うことがある。
ちなみにRAL-24192UT1の消費電力は、電源電圧:5V(USBポート・ACアダプタのいずれかより供給)、消費電流:最大410mA、とのこと。
RAL-2496UT1は電源電圧:5V(USBポートより供給)、消費電流:最大500mAでras piで認識できなかった。
逆に、RAL-24192UT1はibookG4+mpdで認識できなかった。
ばくぜんと、前者は電力供給の問題で、後者はドライバの問題じゃないかと思っているのだけど。

とか考えてるうちに、こんなサイトが。
http://akkagi.info/20150316_web/
http://akkiesoft.hatenablog.jp/entry/20140727/1406443999
http://www.mugbot.com/2014/08/19/raspberry-pi-model-b-%E3%81%AEusb%E3%83%9D%E3%83%BC%E3%83%88%E3%81%AE%E9%9B%BB%E5%8A%9B%E3%82%A2%E3%83%83%E3%83%97/
いじってみたら変化があるだろうか。
それにしても、普段使いの装置であれこれいじるのはクラッシュ後の復旧が辛いので出来ればやめたい、のだけど、どうしようか、、。

7月16日追記。タイトルも追記。

上記のサイトを参考にUSBの電流上限を変更した。
特に問題なくvolumioは動いている。
Ras piの掲示板へのリンクは以下。
https://www.raspberrypi.org/forums/viewtopic.php?f=63&t=81736&start=50#p577877

/boot/config.txt に以下の設定を追加。
safe_mode_gpio=4
max_usb_current=1

Ras pi B+は、USBポート4つトータルで使える電流の上限がデフォルトでは0.6Aに設定されている。
設定を変更することでこれを1.2Aに変更できるとのこと。
これがUSB-DDCをつないでいる時の負担軽減につながるかどうかは明らかじゃないけど、安心材料ではあるかも。

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

May 02, 2015

転居後の状況

転居後は試行錯誤を細々ながら続けている。
多少はましになってきてので記載しておこうと思う。

4425mk2のドライバーには可変式のアッテネーターが付いている。
これを絞ってみたところ、なんとなくいいバランスになる。強かった高音域が押さえられて、相対的にはっきりしなかった低域が強く出るようになった。

4425mk2のアッテネーター

うちのサイトの過去ログを読むと、2007年頃にも絞って使っていたらしい。フローリングでよく鳴る床板の対策で試行錯誤していた時期で、キャスターを使っている現在とスピーカーの足回りの状況は似ているかもしれない。
その次の住居は床が固く、いつの間にか12時の位置になっていた。子供がいじっているということもある。
現在は9時の位置でも悪くない感じだ。
それ以上絞るとなると音質の劣化が問題になってくる。アッテネーターに使われている可変抵抗の影響が大きくなるのか、眠い音になるのだ。

そこで固定式のアッテネータを継いでみようか、などと考えている。
4425mk2はバイアンプに対応しているので、高域用の端子にだけアッテネータを付けるというようなことが出来る。固定式で音量を下げることが出来たら、可変抵抗アッテネータは開けることが出来る。可変抵抗の悪影響を減らすことが出来るはずだ。

スピーカーは部屋という空間の空気を制御する装置だ。
上手く鳴らすと室内の空気自体がひとつの生き物であるかのように動き始める。
聴覚的な宇宙を造成する装置だと言えるかもしれない。
オーディオという趣味について、音楽を聴いていないという指摘があるが、いつ頃からかそうかもしれないと思うようになった。僕にとって、オーディオという趣味のイメージは、ミュージシャンの音楽性を音源から引き出すことよりも、音源そのものが内包するイメージを現出させるニュアンスのほうが大きい。音楽性は個人的な感性だが、音源から情報を引き出し宇宙を現出させるのは物理学、電気工学の手法であり、つまり客観的に結果が自明なものだ。ベクトルが全く違うじゃないか。
いや、本来自明であるはずのものだ、と言うべきか。
コンポも音源もユーザーも多様で、一筋縄にはいかない。
オーディオと音楽鑑賞という趣味はしばしば同居していて、両者の比重はときと場合によって変わる。
音質とか関係なく音楽を聴いていることだってある。

転居して、部屋の容積が3倍以上になっているせいか、空気が簡単に動いてくれない印象を持っている。
スピーカーと音と僕、という感じなのだ。
空気自体が生命を持って踊るようにならないとオーディオは楽しくない。
いまひとつ物足りない感じがするのは、そうしたところから生じているような気がする。
でも、いずれなんとかしたいとこだ。

次に、スピーカーの下を見直した。
楽走くんの上に、当初は3mm厚のMDF板(これは転居前に床に傷がつかないようにスピーカー台の下においていたものだ)を敷き、その上に御影石のボードを置き、J1のコーン(S35S)でスピーカーを3点支持していた。
これだと御影石をはじくと若干だが高い音がして塩梅がよくない。
あと、若干だが床が振動していた。床が振動するのはよくない。ノイズ源だしスピーカーのエネルギーが無駄になっているという事だ。

まずホームセンターで合板を購入、カットしてもらって楽走くんの上に3枚重ねにした上に御影石ボードを置く。
現在はそれ以上は手を入れていないが、まあ、暇があったら何かまだ細工するかもしれない。

次にJ1をTAOCのTITE-46GPというのに変えてみる。
3個セットで1万円と比較的お手ごろ。重量級の鋳鉄の塊でTAOCらしい製品。
スピーカー2つなので2セット購入。
スパイクを上にして3点支持で使用。同梱されてるスパイク受け(これって多分、PTS-Nと同じものだね)をスピーカー側に使用する。
これが、表面を研磨してある御影石の上に乗せると案外すべる。スピーカーを押すとキャスターが動く前にインシュレーターがすべりそうな感じだ。
でもまあ、なんとかなるかな、、、

これで、だいぶマシになった。床の振動は減っている。

これは転居前からだけど、DACが代わった。
Odeon-lite から、RME Fireface UCX に変更した。

もともと録音用の機材なので、ちょっと最初は取り扱いに戸惑った。
アンプのSM-SX100に接続するためにTRS Phone-XLRの変換ケーブルが必要になったり、Windows機にソフトをインストールしてUSBケーブルで継いで設定をしないと音が出ないというのも、なかなか新鮮な体験だった。

設定をしてしまえば、あとはいい音を出してくれる。
転居前の時点で少し鳴らしたときはOdeon-liteより数段いい音が出るという感触だったが、転居後はいろんな要素が変わったので、いい音が出ているはずだから、ということで運用中だ。

デジタルトランスポートは、今は2台。
ともにRaspberry Pi B+ / Volumio 1.55だ。
1台からはUSB出力をRAL-24192UT1を通してSPDIF(COAX)をFirefaceに送っている。
もう1台はi2s出力をDACカード RBD-02+に送りアナログRCA出力をアンプに出している。

両者の音の違いは、今は検証しようという気にならない。
他に手を入れるべきところが多すぎるのだ。

あと、VRDS-25xsを復帰させた。
リッピングする間もなく聴きたいCDを聴けるように。これは勝手知ったる音がする。
SM-SX100のデジタル入力に直接つないだりして音質上は好ましくないとされていることをしてるが、この際まあいいか、という感じで使っている。気にしなければそんなに悪くない。

あれこれと手を入れるうちに音のほうは徐々に良くなってきた。
当初は欠落していた低域の量感やアタック感もそこそこ出るようになってきている。
臨場感も出てきている。
案外なんとかなるかも、と思えるようになってきた。

しかし、どういうものだろう。
久しぶりに振動の挙動についてあれこれ考えた。

昔、機械インピーダンスという考え方があるとネット上で教わった。
10年ほど前にもあれこれ考えてサイト上に書いたりしたんだけど、まとまった感じになっていない。
この場で多少整理しておこうかとも思ったけど、やはり自信がない。

機械インピーダンスについて検索したら、理解困難な数式が出てくる。
僕は高校数学で挫折した口なので、どうにもハードルが高い。そこで我流で解釈する感じになっていく。
そんなのブログなんかに書いていいものかどうなのよ、とか思う。
そんなわけで、現状報告で止めておく。

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

Apr 18, 2015

引っ越した

3月下旬に引っ越した。
その数ヶ月前からいろいろと家具や荷物の整理をして運べるものは運びする中で、この数ヶ月間はメインシステムは休眠状態だった。その間、雑誌の付録でしのいでいた。
4月中旬、ようやくメインシステムを梱包から解いてセッティングしたという状況。
環境は大きく変わるのでいろいろ設定しなおす必要があるとは思っていたが、やはり再生音は大きく変わった。

まず環境の変化。
以前は賃貸マンションのリビングに設置。
床はコンクリートにシートを張ったような構造で非常に固い。女房からは素足で歩くと頭に響く気がすると言われ不評だった。転居でかなり楽になったという。
広さは8畳程度で、そこにコンポや炬燵机その他を並べていた。

転居後。
実家のリフォームで2世帯住宅化。
床はコンクリートの上に板張りで、そこそこ固いがコンクリートそのもののようなことはない。
フロアは、20畳以上もあろうかという空間にリビング、DK、寝室のエリアが配置され境界がない空間。コンポの周囲は現在はほとんど何もない。

次にセッティングの変化。
以前はスピーカーをTAOCのスタンドに直置きして鳴らしていた。
現在はというと、いわゆる台車の上に乗せている。
台車というのは具体的には「楽走くん」という屋内搬送に使う道具で、転居に際して非常にお役立ちだったもの。
これの上に30kgの御影石ボードを置いて、その上にスピーカーを置いている。
トータルだと70kg程になると思うが耐荷重100kgということなので、たぶん大丈夫だ。
最初は御影石の上に直置きしてみたが、さすがにどうかという感じだったので今は手近のインシュレーターをかましている。

台車を使ってみようかと思った理由は地震対策だ。他の理由はない。
キャスターで支えるので、地震の際には横揺れを受け流し倒れない。直下型地震だと関係ないが、岡山という土地の特性から遠方の地震を想定し横揺れ対策でだいたいやれるだろうという判断。

音の変化はどうなのか。
セッティング当日は、ろくな音が出ない。アンプが目覚めるまで最低でも3日かかるからだ。
それを差し引いてもちょっといただけない感じだった。
しかし梱包を解いてセットするので体力を使い果たしたので、そのまま放置。
3日後、少しマシになってきたけど全く焦点が定まらない音なのでインシュレーターを使用。J1の黒いコーンとTAOCのステンレス製スパイク受けを組んで3点指示で受ける。
これで、かなりマシになった。

今の時点で一番気になることは低域が弱いこと。ほとんど聴こえない。アタック感もほとんどない。
中高域がそれなりに鳴っているのに対して、バランスが悪すぎる。
ボリュームを上げても、広い部屋の空間に吸い込まれてしまうのかエネルギー感が全く感じられない。中高域ばかりが大きく感じられて騒がしい。
キャスター使用にした時点で低域の弱さは予想はしていたけど、実際に聴くとここまでとは、と感じる。

もうひとつは、聞こえるはずの音が聞こえてこないということ。
ワルツ・フォー・デビーの、グラスがチャラチャラいうのが聞こえにくい。
あれがきこえないと臨場感が全くない。高域は出ているので聞こえていいはずと思うのだけど、何故か聞こえない。
部屋の音響が影響している可能性を考えている。なにしろ、リスニングポイントの背後が壁じゃなくて空間なのだ。コンポの左右も壁が斜めで、スピーカーからの1次反射がリスニングポイントに届かないセッティングになっている。
以前から考えたらありえない状況だ。

とりあえず、キャスター止めようかな、と思い出しているけど、そこは比較してからの判断とする方針。

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

Nov 26, 2014

I2S DACとRaspberry Pi B+を導入 - Volumioでcue sheetを使う方法

11月中旬から、Raspberry Pi B+ / Volumio を弄っている。
I2S出力による音声再生には興味はあったが後回しにしてきていた。
始めたら手が掛かりそうな印象だったのと、音がいいとは言ってもDAC交換が出来ないというのは気に入らないという気持ちもあった。
しかし手軽そうなキットがあったので、やってみようということになった。
あと、聴いてみないことには何ともいえないというのもある。

実際に聴いてみたら、これは評判になるのが当たり前だと思った。
cue sheetが使えないと思っていたが、外から他のクライアントでアクセスしたら簡単に使用できた。これは非常に助かる。

さて。
まずRaspberry Piを入手。
DACは下記のサイトで扱っているのにした。
Raspberry Pi model B+ 用 DAC カード RBD-02+ LINUXCOM ネットショップ
関連サイト。
Raspberry Pi Model B+ で I2S DAC を動かす Linux Computing

このDACカード、RBD-02+は半田付けなしでRaspberry Pi B+に接続することが可能。
実際に触ってみて思ったのは、ピンに刺すのが意外に大変ということ。
I2S信号がきている40ピンのピンヘッダにDAC基板を刺すのだけど、かなり固い。慎重に力を入れないと針が曲がりそうだ。外すのも気をつけないと針を折りそうだ。
ネジ止めもちょっと力が要る。
そうは言っても、手軽で簡単に組み立てることが出来るキットだと思う。

VolumioのOSはmicroSDに書き込んで使う。
http://volumio.org/
Get Started
上記のサイトにやり方が書いてある。
VERSION 1.51をダウンロード。
解凍しimgファイルを、上記サイトの「FLASH IT」の項目、LINUXに書いてあるとおりにmicroSDに書き込む。
これをRaspberry Piに刺して、LANに継ぐ。
電源のmicro USB端子にケーブルを継ぐ。

Ras Pi本体の赤と緑のLEDが点灯しっぱなしで、何も起きない。
DACのLEDはかなり明るい。まぶしい、、。
ウェブブラウザでvolumio.local/にアクセスを試みるも繋がらない。
ここで気付く。
LAN端子のLEDが点灯していない。アクセスなんか出来るわけがない。

これは壊れてるか?
http://www.raspberrypi.org/downloads/
上記サイトからNOOBSをダウンロードしてみる。
これはRas PI純正?のOSインストーラだ。
問題なく順調に起動し、RaspbianがmicroSDにインストールできた。問題なく動く。
Ras PiのLEDはどれもきれいに点滅している。

ここで気付いた。
NOOBSをSDカードに書き込む際にはFAT形式にフォーマットしないといけないと、解凍したファイルに書いてあった。
FAT形式のmicroSDに、もう一度Volumioを書き込んで起動を試みてみる。
前と同じで何もおきない、、、
ext3、ext4でもだめだった。
Volumioのバージョンを落としてみる。1.4、1.5、、、起動すらしない。

ここまではVine Linux 6.1で試みていた。
数日後、気持ちを切り替えてWindows7で試みる。
Volumioのサイトに書いてあるとおり、Win32DiskImagerでFAT形式にイメージを書き込んでみる。
今までのことが嘘のように起動した。
ようやくウェブブラウザからVolumioのコントロール画面を拝むことが出来た。

何でこんな顛末になったのか、よく分からない。
Vine Linuxで作ったFAT形式に何か問題があったのは確かだろうけど、今の時点では再現性の検証をしていない。
何でNOOBSが動いてVolumioがだめだったのかもよく分からない。

2015年2月11日、追記。
Volumioが1.55にアップデートされているし、諸般の事情で再度マイクロSDにVolumioを書き込んでみた。
やはりvine linuxのddコマンドでやると上手くいかない。
Windows7で書き込むと問題なく動く。
これは他で聞かない問題だし、当方で特有の問題なのかもしれない。

記述忘れを追記に追記。
Volumio1.55では前述のDACボードはまだ試していない。

7月13日、追記。ようやく原因がわかった。
いつもそうだが、分かったらバカみたいな話だ。

僕はrootだったら何でもできるというふうに理解していた。
でも、実はそういうわけではなかったということだ。
このトラブルの最初から僕はrootで作業していて、
[root@localhost abk1]# dd bs=1M if=/Download/Volumio1.55PI.img of=/dev/sdb みたいな感じでコマンドを打っていた。
rootだからsudoは要らないと思っていた。
ふと思い至って、
[root@localhost abk1]# sudo dd bs=1M if=/Download/Volumio1.55PI.img of=/dev/sdb と打ったら、問題なく動くカードができた。
rootでもsudoが必要だったのだ。

1年以上前のエントリーに追記。
上記のsudoで上手くいくというのは一瞬の思い込みだった。やっぱり上手くいかないことが多い。謎のままだ。

何はともあれ、Volumioは起動した。

ひとつだけ、困ったことがあった。Volumioの通常のコントロール画面からは、flacファイルはPlaylistに読み込むことが出来るが、cue sheetを読み込むことが出来ない。
うちの音楽ファイルの殆どはCDからリッピングしたflacとこれに対応するcue sheetだ。
cue sheetが読み込めないようだとCD1枚分のflacファイル毎しか選択できない。
曲の選択が出来ないのは、とても不便だ。

Volumioにsudo、sshでアクセスして、少し調べてみる。passはvolumio。

root@volumio:~# mpd -V
Music Player Daemon 0.19.1
(中略)
Playlist plugins:
extm3u m3u pls xspf asx rss soundcloud cue embcue

Volumioのmpd自体はcue sheetに対応している。
ローカルで使われているmpdクライアント(mpcらしい)が対応していないために、使えないということらしい。
だったら外からcue sheetに対応してるクライアントでVolumioにアクセスしたらどうか。
うちでメインに使っているncmpcppはcue sheetに対応している。

ncmpcppのconfigファイルの、mpdサーバのIPアドレスを書き換えてVolumioにアクセスしてみる。
VolumioのPlaylistが表示された。アクセス成功。
NASの階層を辿り、cue sheetをPlaylistにaddすることも可能。再生も問題ない。
ncmpcppからVolumioを操作してcue sheetを使用することが出来た。

ここで、ウェブブラウザからVolumioにアクセスしてみる。
ncmpcppで表示されていたとおりに、cue sheetに記載されている曲がPlaylistにずらりと表示されている。
曲の選択、再生、削除もウェブブラウザから可能だ。
ウェブブラウザからのアクセスではcue sheetをPlaylistに加えられないが、加えられてしまえばそれ以外の操作は出来る、ということらしい。

今回、「cue sheetに対応したmpdクライアント」という情報は意外にないということに気付いた。
うちで使っているncmpcppとgmpcは対応していることが分かっている。
他はどうか知らない。
Volumioでcue sheetが使えないのを理由に諦めている人がおられるようなら、こうしたクライアントを使ってVolumioを操作したらいいと思う。

ちょっと追記。
ncmpcppは、0.5.8 (2011-10-11)でcue sheetに対応している。
mpdは、ver 0.16 (2010/12/11)の時点で対応しているようだ。libcueなしでよくなったのはver 0.17 (2012/06/27)からだと思う。

関連リンク。
Music Player Daemon
Clients

音のほうは、あちこちで評価されているとおりだと思う。
今後のコンポの構成を考えないといけない。

でも、Ras Piの音を聴く前に、新しいDACを注文してしまっているのだ、、、まあ、DACとして使わなくても他で使いようがありそうなのでいいのだけど、、、

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

Oct 01, 2014

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

前回が昨年の4月。現在のオーディオシステムについて記録。

BY50S HS-210
(LAN: KB-FL7-05BK)

mac mini4.1 2.4GHz 8GB
OSX 10.6.8
audirvana plus / itunes
96/24 TOS
(TOS: HK50/huji parts)
AT-HDSL-1
TOS > RCA
(RCA: 型番不明)
ibook G4 12" 512MB
Vine Linux 5.2 ppc
mpd 0.17.3
USB
(USB: RAL-2496UT1付属ケーブル)
RAL-2496UT1
USB > TOS
(TOS: OPC-M1/SAEC)
DP-5090
44.1/16 RCA
NBR271
RCA > BNC
(BNC: BNC59/HOSA)
BJC-XP-TRC
BNC > XLR
SRC2496
>> 96/24 RCA
(RCA: D-75/DH LABS)
PB-500-2 odeon-lite
(RCA: basis1.4/AC Design)
SM-SX100
(5.5mmスケアキャブタイヤ/協和電線)
4425mk2 (omni8/Space&Time)
T900A

前回と比べて、すごく変わっていない。
こんなに変わってなくていいのかというぐらい。

しかし、NASが変わっている。
これは思っていた以上に大きかった。
何が大きいって、快適に使用できるというところからまったく違うし、音質も改善してmpd.confの設定内容もそれに連れて変わってしまった。

まあ、この1年でこれだけなのはしかたない。

表には記載していないが、普段使用のCompaq 6730bにmpdとncmpcppをインストールしてLAN経由でNASをマウントして使っている。
メインシステム以外でちょっと音楽を聴きたいというときに便利だ。

ただし6730bはメインシステム用クライアントとしても動作しているので、6730bのmpdは別のアカウントから動かす必要がある。
つまり1つのマシンに複数のアカウントを作って各々にncmpcppの設定をしてやれば、そのマシン1つで複数のmpdサーバを操作出来るということだ。

今回の場合の設定は、
mpd_host = "localhost"
mpd_port = "6601"
としている。
mpd_port = "6600"ではメインシステムと混線するので"6601"など別の数字にしないといけない。
portは各々のソフトに数の割り振りがあるので注意は要る。

これで、メインシステムで子供のためにアンパンマンのマーチを鳴らしながら、こっちはこっちで6730bのイヤホンでベートーベンの運命を聴くというようなことが、簡単に出来る。
アカウント切り替えの手間を惜しまなければ、だが。

こんな風にして複数のmpdサーバを1つのノートで操作出来るのは、使い方のアイデアによっては便利で面白いんじゃないかと思っている。
すぐに何か始めるわけではないけど、将来的には何かに利用してみたい感じだ。

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

Sep 11, 2014

加入者網終端装置(CTU)の設定でネットワークを分割する

いくらか追記。
若干、表現の修正あり。
あと、おそらくは不正確な内容を含むのでご注意を。

9月16日、追記。
この連休はシステムをあれこれいじっていたんだけど、当初得られた変化が,その後はどうも得られない。
何故なのか考えていて思い至ったことは、CTU装置を再起動したことだ。
AirMac Expressの音飛びと格闘していた頃、iTunesの再起動で一時的にシステムが安定するということがあった。
今回の当初の変化は、CTUの再起動で何か電気的に整理されたことによるものかもしれない。
まるで68kマックみたいな話だが。

ということで、当面は当初得られたと思われた効果が、その後は得られないという感じだ。
まあ、オーディオやってるとそんなこともある。

19日、追記。
CTUを再起動したらLANが安定したことを5月の時点でここで書いていたのをすっかり失念していた。

家庭内LANが安定しないとネットオーディオネットワークオーディオの音質に悪影響があるというのは、ずいぶん前に認識していた。
覚書として以前の顛末の記録をリンクしておく。
曲が再生中に止まるケース | Apple サポートコミュニティ

いろいろやってるが、知識なしに手探りでやってるので恥ずかしい。
今もそうした傾向は変わってない気がするが。
なにが知識がないといって、ipアドレスのことすら理解しないままにいじっている。
よくこんなんでやってたわと思うのだが、言い訳するようだが、ipアドレス、ネットワーク、あとサブネットマスクについて、分かりやすく書かれた書籍は少ない。僕なりに勉強してはいたが、分からなかったのだ。
僕の理解力が低いのかもしれないが。

だから今回、サブネットマスクを使ってネットワークの分割を試みるのは非常に骨が折れた。
だから後日の参考のため書き留めておく。

そもそもは、ウェブを巡回したりYouTubeを見たりするパソコンと、オーディオ再生に関わるmpdサーバやNASが同じネットワークにあるのはどうなのか、というところから始まっている。
前述のAirMac Expressのケースでは、Safariを使うだけで音が飛ぶということが書いてある。
うちでは数台のパソコン、2台のスマホ、ゲーム機が家庭内LANにつながっている。
TCPはもちろん、動画などUDPのパケットがネットワーク上を巡っている状態だ。
これらはオーディオ的にはノイズなので隔離したい。

いくつか、そうした趣旨で書かれたエントリーがある。
以下にリンク。参考にさせていただいた。

音のよいネットワーク構成 | PCオーディオ実験室
ネットワークプレーヤ用ネットワーク - 2014.07.27 - デジファイのおと
M3のオーディオ部屋: LANの接続で音が変わる

以下はサブネットマスクに関連してリンク。

IPアドレス サブネットマスク 早見表|ahref.org
サブネットマスク計算(IPv4)/サブネット一覧(早見表) CMAN インターネットサービス
DHCP設定は正しいか?~DHCP設定の確認と利用~ - @IT

サブネットマスクの設定を変えることで、LANのネットワークを分割することが出来る。
物理的なLANケーブルの構成も適正にすれば、ノイズになるパケットをmpdの周辺から排除することが可能かと減らすことが出来ると思われる。

ネットワークについてリンクなどを追記。

ブロードキャストとマルチキャスト mileruntech
ブロードキャスト・アドレスの種類 - @IT
WEBを構成するネットワーク
サブネットマスクとルート集約

パケットが巡ってくること自体を防ぐことは出来ないが、その後の処理の仕方の違いによって負担が違ってくるようだ。ネットワークを切り分けることで、mpdサーバにとって簡単な処理ですむパケットが増える、という解釈が可能だろうか。
異なるネットワークのパケットが巡ってくるのを完全に遮断するには、ルータ、L3スイッチングハブを使うか、LANケーブルの接続を切るしかないかもしれない。

うちはフレッツ光マンションタイプに契約していて、それをベースに家庭内LANを組んでいる。
DHCPサーバは加入者網終端装置(CTU)が担っている。
このCTUの設定を変える必要がある。
以下に設定画面の画面。
ウェブブラウザからCTUにアクセス、ログインし詳細設定からリンクをたどると設定画面が出てくる。

フレッツ光のサイトとCTUのマニュアルにリンクしておく。
フレッツ・光プレミアム(インターネット接続サービス) サポート情報
加入者網終端装置(CTU)・ガイドブック[ファミリー/マンションタイプ用] 第14版(pdf)

以下、今回やったことを記載。

IPアドレスはデフォルトの192.168.24.1で固定。
変えてみての試みは今回はしていない。

マスク長をデフォルトの24から27に変更。
マスク長が3増えるということは、ネットワークのサイズは8分の1になる(2の3乗=8)。
これに伴い、払い出し開始IPアドレスを192.168.24.51から192.168.24.4に変更した。
マスク長が27だと、CTUが管理するIP数が256の8分の1だから32になる。払い出しが51からだと払い出せなくなる。
デフォルトが51からになっている理由はよく分からない。マスク長が24ならそれでも問題ない。

IP数が32ということは、内訳はどういうことになるのか。
最初は0で、これはネットワークのアドレスになる。
1はルーターのアドレス(192.168.24.1)。
32番目の31は、ブロードキャストアドレスというもので、ネットワーク内のすべての端末にデータを送信するために使われるので、個々のホストPCには使えない。
つまり、使えるアドレスは32-3=29個、ということになる。
払い出し個数が、デフォルトの50のままでは多過ぎるので25にする。一般家庭の家庭内LANであれば十分な数だ。
これらをDHCPサーバであるCTUが管理するということだ。
IPアドレスで言うと、192.168.24.0から192.168.24.31を、CTUが管理することになる。
ネットワークにPCなどを継ぐと、これらのアドレスの中から使えるアドレスをCTUがPCに割り振ってくれる。

ここでmpdのほうを見てみる。
うちではmpdサーバのibook G4に192.168.24.60。NASのhs-210に192.168.24.61を当てている。
サブネットマスク長を24から27に変えると、ひとつのネットワークのIP数は256から32になる。
つまりmpdとNASは、CTUが管理するネットワークから外れる。
ネットワークアドレスが192.168.24.32のネットワーク、つまり192.168.24.32から192.168.24.63のネットワークに含まれることになる。
こっちには192.168.24.0のネットワークで流れているパケットは流れ込まない、はず。
流れ込まないなら、かなり静かな環境になるはずだ。

mpdクライアントとして使っているCompaq 6730b Vine Linuxは、メニューのクリック→プルダウンで簡単にネットワーク設定を変えることが出来る。普段はCTUから供給されるアドレスで使いながら、mpdの操作をするときやNASの設定に用があるときだけIPアドレスを192.168.24.50とかに変更して、mpdのネットワークに入ればいい。
これは意外に快適だ。
下の画像は、ネットワークの設定の記録。

問題は、hs-210がウェブにアクセスできないこと。
アップデートなど告知が出ない。無論、アップデートも出来ない。
出来るようにするためには、そのたびにCTUの設定を変えるしかない。
この問題をクリアしようと思ったら、間にルータを挟むことになる。それはそれで面倒だし、ルータのノイズが気になってくるところなので、悩ましいとこかもしれない。

音は良くなっている気がする。
上手くいえないが、ぐっと落ち着いた感じがする。

と思ったけど、まだ判断するのは早すぎるかもしれない。

Posted at 18:19 in audio_diary | WriteBacks (0) | Edit Tagged as: ,
Page 13 / 31 :  « ‹ Prev 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 Next › »