ハイレゾのデモ音源を聴いていて気づいたのだが、手元の常用PCであるThinkPad R500(LinuxMint17.3-amd64-xfce4)は思いの外音が悪い。ThinkPadは昔から音にはひと通りの配慮があったのだが。まあ、まったくダメ、という訳ではなく、「何となくノイジーだよな」というレベル。

 

さて、HDDの空き容量が気になりだしたので、先日ようやく実用域に達したnfsにファイルを退避し、改めてサーバー上のハイレゾ音源を再生してみました。

 

そうしたらですね、音が変わりました。

 

クリアになりました。自分でも自分の耳を疑って(加齢の為、高域部分の聞き取りに明らかに難がある)、音源ファイルを替えて試してみたのですがどれも同じ傾向。

 

疑うべきはただひとつ。HDDへのアクセスの有無(あるいは多少)。ハイレゾはファイルサイズが大きいので、こんなところで差がでたのかも知れません。

 

しかし、ここで別の問題が。

手元のnfsは遅いので音飛びが生じるケースがありました。

 

何事も2つ良いことはないようです。

 

使っているプレイヤーはAudacious 3.8.2。LinuxMint17のリポジトリに収録されているのは少し前のバージョン(3.4.3)なので、Audaciousのサイトからソースを貰ってきて自前でビルドした。一般にx86だとビルドオプションの設定具合でバイナリの実行速度が大きく変わったりするがamd64では大差ない。R500(CPUはcore2duo)ではsse命令の世代がsse2からsse4.1に代わるくらいではなかろうか。何より、肝心のlibFLACはOSの既存品のままである。

 

ビット深度はAutomaticも選べるが、予め音源ファイルをmplayer で確かめて32に固定している。気休めである。

 

尚、configure 時にbuildstampを指定すると設定ダイアログの左下に表示されて便利。

 

自分宛てメモ

 

LinuxMintをVirtualBoxで動かしていて気づいたのだが、SlitazだとGuestAdditionsで生成されるモジュールの一つ(vboxvideo.ko)がロードされない。手動で modprobe とかするとエラーになる。

 

原因は最近のVirtualBoxにて、Linuxカーネルバージョン3.11未満及びxorgサーバー1.17未満を相手にしていないから、らしい。
Slitazはそれぞれ、3.2.71, 1.12.4である。

 

対策としては、VirtualBoxのサイトから旧バージョンのGuestAdditions(5.0.16)を貰ってきてインストールする方法があるらしい。

 

ということで、早速試してみたら取り敢えず解像度の件は解決。手持ちのディスプレイの最大解像度である1280x1024で表示できるようになった。

 

副作用が怖いな。

 

 

 

フォーラム参照先
http://forum.slitaz.org/topic/problem-installing-virtualbox-guest-additions-error-could-not-insert-vboxvideo-invalid-argumen

自分宛てメモ


tls(ssl)の設定
about:config
security.tls.version.min -> 2

LinuxMintの新バージョン、18.2(以下LM18,同様にLM17)がリリースされました。早速、手元の18.1(xfce4,amd64)をアップデート、またx86版(xfce,MATE)をVirtualBoxで動かしてみました。導入のしやすさは相変わらずで、誰でも使えるディストリビューションに仕上がっています。惜しむらくは日本語訳が不完全な箇所があることで、これは少し前に発覚した、「どこぞのウ◯◯ス◯ラ馬◯◯鹿ト◯ー◯◯シ◯ツがやらかしたライセンス抵触問題」が未だに尾を引いているのかも知れません。

 

さて、使いやすいLinuxMintですが唯一ややこしかったのがBluetoothの接続。LM17.3まで、そのままではオーディオデバイス(スピーカー)を認識してくれない場面があって苦労させられます。
原因はpulseaudioがbluetoothモジュールを正しく読み込んでくれないからなのですが、それでは、とxfce4の起動時点で読み込ませようと設定してもダメ。結局、デスクトップ起動後、手動で読み込ませるのが一番確実という不便さでした。

 

pactl load-module module-bluetooth-discover

 

しかし、使い始めこそ不便さを感じたのですが、慣れてしまうとむしろ好都合な事に気づきました。
bluetoothスピーカーは一度ペアリングしてしまうと、次回からは見つけた相手と自動的に接続しますが、時としてこれが煩わしいことがあるのですね。まあ、PC側のbtを止めておけば良いのですがスピーカー以外を繋ぐこともあるので、それはそれで煩わしい。

 

こんな時、pulseaudioにモジュールを読み込ませるか否か、で接続を制御できるという訳です。

 

LM18ではそんなこともなくなりました。UIもbluemanからblueberryに変わり、扱いやすさは改善されていますが、まだまだAndroidなんかに比べると遠く及ばないなあ、というのが実感です。

 

自分宛てメモ

 

/etc/exports
async

 

HDD
hdparm -t | -T

 

CPU
mpstat n

 

NFS
nfsstat

 

nfs上のflacを再生していてエラーが多発したので。mp3だと発生しないので、転送速度(容量)の問題か。

 

 

取り敢えず

sudo mount -t nfs 192.168.11.4:/home /mnt/nfs -o tcp,soft,timeo=5,bg,rsize=16384,wsize=16384

 

 

tcp使用時、rsize,wsizeは65536まで使えるらしい。デフォルトは32768とか。udpだと8192。大きければ良いというものではなく、サーバーがpoor(例えばPC)だったり回線が細かったりすると、タイムアウトするまでにパケットの転送が終了せずかえってパフォーマンスが低下するらしい。

 

手元の環境で試した(nfs上のファイルのmd5sumを取ってみた)ところ、32768及び65536でエラーが発生した。また、8192と16384とでは18秒程度と大差なかった。(なお、同一ファイルをクライアントにコピーし、md5sumをとったところ1秒未満で終了したので、この部分の時間は無視する)

大雑把に転送時間を計算すると17Mbps位(※)である。サーバーが遅い、回線が遅い(特にクライアントは無線LANで接続している)ということを考慮すればこんなものかも知れない。

 

他の手順との比較では、

FTP(サーバーpure-ftpd, クライアントgFTP)で9.375Mbps、SCP(サーバーDropbear、クライアントopenssh)では2.3MB/sと表示された(nfsよりわずかに速い程度)ので、nfsが極端に遅いということは無いと思われる。

 

※単純に転送バイト数に8を掛けているので。

サーバーを替えて試す。

 

サーバー LinuxMint17.3(i386,MATE) VirtualBox
クライアント LinuxMint17.3(amd64,Xfce4)

 

サーバー側の作業
テスト環境を新築した。OSが旧く、オンラインでアップデートする必要があるためVirtualBox側のネットワーク設定はブリッジとした。

VirtualBoxのGuestAdditionsもインストールした。
アップデート後、リポジトリからnfs-kernel-server をインストール。

 

サービスの起動方法
Mint17は昔ながらの方法で制御できた。18以降は試していない。
sudo /etc/init.d/nfs-kernel-server start | stop

 

 

クライアント側の作業
busybox mount でも、本来のmountでも正常にマウントできた。

 

エラー対策
障害が発生して(というより、クライアントの電源を落とす前にサーバーを落とした時)リトライがかかりっぱなしになる件
取り敢えず、mountオプションで、timeo=1,bg,softを付与してみたところ、端末で打ったlsはエラーメッセージを返して戻ってきた。
デフォルトのタイムアウト値は7(0.7秒)らしい。詳しくはman nfsを参照。

これで、Slitazで動かすサーバーに問題(という程のものでもない)があることの見当がついた。

 

サーバー Slitaz

クライアント LinuxMint 17.3(amd64,xfce4)

 

LinuxMintにもBusyboxはインストールされている。システム損傷時の緊急ツールとして用意されているものなので、アプレットはリンカとしては存在していない。

 

Slitaz(VirtualBox)の時とほぼ同じ方法でやってみたところ、正常にマウントされた。

 

sudo busybox mount -t nfs 192.168.11.4:/home /mnt/nfs -o nolock

 

/etc/fstab も読み込む。

sudo busybox mount -a

 

ここでエラーメッセージが。no_subtree_check は unknown option とのこと。このへんがBusyboxの辛いところ。余り凝ったことはできない。

 

にしても。

標準ツールでマウントできない、というのは謎である。サーバー側の問題なんだろうか。というか、以前はこんな面倒なことをしなくても確かに使えていた覚えがあるのだが。

 

7月1日追記

mount でも正常に動作することを確認。しかし、失敗する場合もある。回線速度が遅い、サーバーマシンの動作そのものが遅い、というのが根本的な原因のような気がする。

 

自分宛メモ

 

サーバー Slitaz

クライアント Slitaz(VirtualBox内)

 

※クライアント側のVirtualBoxにて、ネットワークの設定をNATからブリッジアダプターに変更する。これで仮想環境と実環境が同じネットワークに乗る(アドレスの割当は無線LANルーターで行う)。

 

Slitazフォーラムの過去ログ(http://forum.slitaz.org/topic/mountnfs-protocol-not-supported)によれば、util-linux-mountをインストールすると nfs mount/umountが壊れるらしい。

 

対策として、busyboxのアプレットを使う。

sudo busybox mount -t nfs 192.168.11.4:/home /mnt/nfs -o nolock

 

 

自分宛てメモ

 

いつの間にか、Slitazのnfsサーバーが動作しなくなっていたので。

 

このサーバーというのはいつもの音出しサーバーで、実験的にnfsを動かしてファイルサーバーにもしていた。転送速度が遅すぎるのと、サーバーにファイルを送るだけならmountしなくてもftpでもscpでも可能であること、何より、mountした後、クライアントよりもサーバーの電源を先に落としてしまうとクライアントが固まってしまう、という問題が解決できなかったので利用をやめていた。

 

で、本日、ある件で必要になり性懲りもなく起動しようとしたのだが。

 

/etc/init.d/nfsd start 等とやると、nfsd を modprobeしようとして「フォーマットが違うとか何とか」のエラーを吐く。

 

このサーバーに入れていたmodprobeはバイナリだったのだが、比較用に準備しておいた仮想環境上(virtualbox)のSlitazではkmodへのシンボリックリンクになっている。元々、kmodだったのを何かの弾みにmodprobeのバイナリを入れたのかも知れない。よく覚えていない。

 

ということで。

 

sudo tazpkg clean-cache

sudo tazpkg get-install kmod

 

取り敢えずサーバーは起動した。が、今度はクライアント側のLinuxMintで「このプロトコルをサポートしていない」とのことでマウントに失敗する。

 

先は長い。

 

 

 

簡単に箱庭環境を構築できるVirtualBoxは大変便利ですが、host - guest間のファイル共有方法で躓きやすいようです。
手元の環境でようやく解決をみたので、以下その記録。

 

host LinuxMint 17.3、ユーザーsakai
guest Slitaz rolling(32bit)、ユーザーtux

 

手順

 

host側 (ユーザーはsakai)


1. VirtualBox側でファイル共有するディレクトリを設定する。もちろん、フルアクセス。
共有名 program
パス /home/sakai/program

 

guest側 (ユーザーはtux)


1. Slitaz側でguestadditionを導入してvboxsfを使えるようにしておく。
2. sudo addgroup vboxsf
3. sudo addgroup tux vboxsf
4. mount point を作成。ここでは /mnt/program
5. id tux 等でuidを調べる。
6. /etc/fstab を設定
program        /mnt/program    vboxsf  defaults,uid=1000,gid=0  0 0
uidとgidを指定すること。
7. 再起動

 

これで、host側の /home/sakai/program が guest側の /mnt/program にマウントされます。

 

で、ですね。

 

guest側の/mnt にて ls -l で見てみると

 

drwxr-xr-x    1 tux      root         12288 Jun 28 11:23 program

 

当然、program 内で作成したファイル、ディレクトリのユーザー及びグループ名はデフォルトでは同様になります。

 

ls -l |grep slitaz_project
drwxr-xr-x    1 tux      root          4096 Jun 28 11:28 slitaz_project

 

ls -l slitaz_project
total 12
-rw-r--r--    1 tux      root           514 Jun 28 11:26 slitaz_project.geany
-rw-r--r--    1 tux      root           917 Jun 28 11:15 untitled.c

 

(後述しますが、slitaz_project.geanyというのはgeany(統合開発環境)のプロジェクトファイルです。)

 

 

上記ディレクトリ、ファイルはhost側では以下のように見えます。

 

ls -l |grep slitaz_project
drwxr-xr-x  2 sakai sakai   4096  6月 28 11:28 slitaz_project

ls -l slitaz_project

合計 12
-rw-r--r-- 1 sakai sakai  514  6月 28 11:26 slitaz_project.geany
-rw-r--r-- 1 sakai sakai  917  6月 28 11:15 untitled.c

 

このようにユーザーやグループ名の置き換えはVirtualBoxがやってくれます。至れり尽くせりですね。

 

 

これでhost-guest間でプロジェクトを共有できる!と喜んだのですが、思わぬ落とし穴が。

 

それは、geany のプロジェクトファイルに記録される情報が「そのプロジェクトを開いた時のもの」になる、というものです。


どういうことかというと、host側で編集すると下記のように記録されます。(引用は一部)

 

[project]
name=slitaz_project
base_path=/home/sakai/program/slitaz_project/

 

guest側でこのプロジェクトを開くと、記録されているbase_pathが異なる為、このままでは必要なファイルを見つけることができません。

 

しかし、うまい具合に解決できました。「プロジェクトファイルの格納場所をhostとguestで変えておけばよい」のです。

 

具体的には、guest側でgeanyを起動し、メニューの「編集 - 設定」で開いた「設定ダイアログ」の「全般タブ」の「その他タブ」にある(長いっ!)
「プロジェクトファイルをプロジェクトの基本ディレクトリに保存しますか?」をチェックします。
当然、host側ではチェックを外します。

 

 

 

これでプロジェクトの中身のファイルを共有しつつ、プロジェクトファイルを使い分けることができます。開くときに間違えるとややこしいことになりますが、それは使う側の責任でしょう。

 


Search

Calendar

S M T W T F S
1234567
891011121314
15161718192021
22232425262728
293031    
<< October 2017 >>

Archive

Mobile

qrcode

Selected Entry

Link

Profile

Search

Other

Powered

無料ブログ作成サービス JUGEM