デフォルトのフォントの選ばれ方がおかしい

fonts.confは以下のようになっているのだが

    <?xml version='1.0'?>
    <!DOCTYPE fontconfig SYSTEM 'fonts.dtd'>
    <fontconfig>
     <match target="font">
      <edit name="lcdfilter" mode="assign">
       <const>lcddefault</const>
      </edit>
     </match>
     <match target="pattern">
      <test qual="any" name="family">
       <string>serif</string>
      </test>
      <edit binding="strong" name="family" mode="assign">
       <string>HannariMincho</string>
      </edit>
     </match>
     <match target="pattern">
      <test qual="any" name="family">
       <string>sans-serif</string>
      </test>
      <edit binding="strong" name="family" mode="assign">
       <string>Migu 1P</string>
      </edit>
     </match>
     <match target="pattern">
      <test qual="any" name="family">
       <string>sans</string>
      </test>
      <edit binding="strong" name="family" mode="assign">
       <string>Migu 1P</string>
      </edit>
     </match>
     <match target="pattern">
      <test qual="any" name="family">
       <string>monospace</string>
      </test>
      <edit binding="strong" name="family" mode="assign">
       <string>Ricty Discord</string>
      </edit>
     </match>
     <match target="pattern">
      <test qual="all" compare="not_eq" name="family">
       <string>sans-serif</string>
      </test>
      <test qual="all" compare="not_eq" name="family">
       <string>serif</string>
      </test>
      <test qual="all" compare="not_eq" name="family">
       <string>monospace</string>
      </test>
      <edit name="family" mode="append_last">
       <string>sans-serif</string>
      </edit>
     </match>
     <dir>~/.fonts</dir>
    </fontconfig>

なぜか、明示されていないフォントはラノベPOPになってしまう。
これはいくらなんでも可読性が低すぎるため、ラノベPOPのフォントファイルをリネームして後ろに回したところ、梅ゴシックになった。
しかし、依然としてボールドには梅ゴシックが使われる。

さらに、Skypeでは途中でフォントが変わったり、まぁ猛烈に読みづらい状態だ。

意味不明なことに、not_eqappend_lastしている部分は、

     <match target="pattern">
      <test qual="all" compare="not_eq" name="family">
       <string>sans-serif</string>
      </test>
      <test qual="all" compare="not_eq" name="family">
       <string>serif</string>
      </test>
      <test qual="all" compare="not_eq" name="family">
       <string>monospace</string>
      </test>
      <edit name="family" mode="assign" binding="same">
       <string>sans-serif</string>
      </edit>
     </match>

とすると、今まで正しく表示されていたアプリケーションメニューが梅ゴシックになり、依然としてfc-matchすると梅ゴシックが返る。

このbindingをstrongにしても結果は同じ、weekだと単に無視される。

この問題には長く悩まされていたが、sans-serifでなく、実体(例えばMigu 1P)を指定すると反映された。

だが、CinnamonのUIについては改善せず、これは~/.theme/<theme>/cinnamon/cinnamon.cssstage要素に対して指定されているものを変更する必要があった。

sans-serifを指定して動かない理由はわからず、その際の挙動についても理解に苦しむが、とりあえずここまで。

Mandriva Linuxは終わっていた

Mandriva Linuxというのをご存知だろうか。

Mandriva LinuxはかつてはMandrake Linuxという名前だった。
最初のリリースが1998年と古く、かなり人気もあった。

日本ではかなりマイナーだった印象がある。知っている人は少なかった。
Windowsユーザー向けに、学習しなくても使えるユーザーフレンドリーなOSとしてPRしていた。

同じようにユーザーフレンドリーで、KDEを採用しているSuSE Linuxと、このMandrake Linuxがヨーロッパにおける2大ディストリビューションであると認識していた。RedHat LinuxやDebianがヨーロッパでいまいちふるわなかったあたり(それでもこれらディストリビューションよりは上だったかもしれない)、ヨーロピアンはアメリカがお嫌いなのかなと思ったりもする。

インストーラなどこの2つのLinuxは共通点も多い。SuSEはドイツ、Mandrakeはフランスのディストリビューションだった。
企業の開発で、有償版を先行リリース、後から無償版をリリースするモデルも共通していた。
SuSEと違いMandrakeは日本語のリリースがなかったため、入手はなかなか苦労した。

SuSEは結局デスクトップディストリビューションをコミュニティ主導としてopenSUSEとした。Mandrivaはこれに遅れた印象があるが、実はopenSUSEの前にRedHatがデスクトップディストリビューションをFedora Communityに委ねることにしているし、Mandrivaもこれに続いて2012年、いままで遅れてリリースしてきたフリー版をOpenMandriva Lxというディストリビューションにフォークして、OpenMandriva Associationに移管し、Mandrivaは有償版に専念、という形をとっている。

そんなかつての人気ディストリビューションだけれども、終わってしまったらしい。

Mandriva社は2015年5月に倒産、これに伴ってMandriva Linuxは終了。さらにOpenMandriva Lxに関しても活発とはとても言えない。というか存在自体ほとんど知られていない。リリーススケジュールも守れずにいる。ちなみに、2014.2というバージョンが2015年6月に出たらしい。もうわけがわからないよ。

ちなみに、OpenMandriva、実はMandrivaベースではなく、Mandrivaからフォークしたロシアのディストリビューション、ROSAベースらしいなかなかびっくりな話だ。もうわけがわからないよ。
さらに、OpenMandrivaは次でLXQtベースに以降するもよう。Libreofficeも切るようなので、軽量ディストリビューションとしての生き残りを模索しているのか。Mageiaに対する敗北宣言か。

Mandrivaは昔から内紛が絶えず、2003年には主要人物だったTexstarがMandrakelinuxから派生したPCLinuxOSをリリースしているし、2010年にはMandrivaから分裂する形でMandrivaフォークのMageiaが誕生している。
PCLinuxOSはMandrakeのエッセンスをもちつつ、かなり多くの部分で異なる独立性の強いディストリビューションだが、Mageiaはフォークという印象が強いもの。

結局はMageiaがMandrivaを屠ったのだと思う。
Mandrivaを好むユーザーにとって、Mandrivaをフリーで手に入れられるのがMageiaだと認識できるレベルだったからだ。

MageiaはMageiaで、Mageia 5のリリースは遅れに遅れたものの、常にTOP 10圏内にはいるので、かなりの人気ディストリビューションと言っていいと思う。

もう、Linux Mintが不動の1位を築きつつあるが、Ubuntuが「初心者向け」としての地位を築いたのが大きかったろう。結局、よりフレンドリーなLinux Mintに流れたわけだし、Mandrivaの立場がなくなったのだろう。openSUSEのように明確な優位性や完成度があったわけではなく、かつNovellのようにエンタープライズエディションを持っていたわけでもない。

最近はかなりディストリビューションの淘汰が進んでいる印象がある。日本では紹介されないが、LXLEという軽量ディストリビューションが来てるようだ。もっとも日本にはLinuxBeanがあるので、彼ががんばっている間は盛り上がらない気がする。

そんな中で、有償で不自由で、似たようなもっと自由なものが存在し、初心者向けならもっとほかを選ぶという状況では、淘汰されるのは必然だったのかもしれない。

Mandrake/Mandrivaというと、割とシンプルな作り(低機能ともいうが、Network Managerなど扱いにくかった頃のものは重宝した)と、KDEの機能の活用、美しいQtテーマが印象に残っている。
また、sudoers

%wheek	ALL(ALL)=ALL	:NOPASSWD

とか書いてあったのも印象深い。

なんとも寂しい気持ちだ。おしゃれで、昔は憧れの存在だっただけに。

LinuxでAmazonプライムビデオを観る

Amazonプライムビデオが始まったので、試してみた。

FirefoxではFlashの更新をするように求められ、VivldiとChromiumで試すと再生が始まらない。

  • firefox 40.0.3-1
  • vivaldi 1.0.219.50-2
  • chromium 45.0.2454.99-1
  • chromium-pepper-flash 1:19.0.0.185-1

カスタマーサービスに問い合わせると、Linux/UNIX OS/Chrome OS上のChromeをサポートしているとのこと。

ダメ元で試してみた。google-chrome 45.0.2454.101-1パッケージで試してみたが、なんとこれで再生できる。

ちなみに、実際にChromeを試してみると、Chromiumと若干挙動が違う。
ChromiumだとZ400ではかなり停止し、動かないがGoogle Chromeなら結構止まるものの一応動く。

この違いはよくわからず、とりあえずPepperFlash全般での再生を可能にするようお願いした。

nVidia vs AMD (nvidia-driver vs catalyst) on Linux

AMD APU (Radeon R7)からQuadroに変わって猛烈に快適になった私のPC。これまで抱えていた非常に多くの問題が、なんだか勝手に解決した。

今までの苦労はなんだった。

そんなにRadeonがダメなのか?それとも、そんなにCatalystがダメなのか?
Windowsでもマウスカーソルが歪むという話は出ているのであまり良くはないだろうとは思うけれど、それともGeForceだと同じようなものなのか。

Phoronixの記事を見ると、この場合はLinux Gamingだし、しかもGeForceとRadeonだしではあるけれど、この情報から明らかなことがある。

RadeonよりもGeForce(グレード関係なし)。

RadeonよりもGeForceのほうがゲームで好まれるというのはあるが、WindowsにおけるそれはどちらかというとGeForceに最適されているからである、という話をきく。Radeonに最適化されたゲームにおいてはRadeonのほうが快適だというのだ。

だが、Linuxのこの結果は、10万円クラスのR9 Furyが3万円以下のGTX 950と同等というわけのわからない結果になっている。

つまり、Catalystはひどい、と。R9 Furyみたいなモンスターを腐らせてしまうくらいに。

AMDはLinuxサポートの強化とかいってなかったか?それでこれか?
様々な挙動不審も、CatalystドライバーがLinux向けにちゃんと作られていないからだろう。

LinuxBeanのアップデート不能問題

LinuxBeanのアップデートができなくなっていた。

E: Encountered a section with no Package: header
E: Problem with MergeList /var/lib/apt/lists/geekconnection.org_remastersys_ubuntu_dists_quantal_main_i18n_Translation-en
E: パッケージリストまたは状態ファイルを解析または開くことができませんでした

Remastersysのリポジトリ閉鎖に伴い、geekconnection.orgに変更されていたが、geekconnection.orgも閉鎖された模様。

暫定的処置としては、ソフトウェアソースからgeekconnection.org_remastersysを外す。
LinuxBean スクリプトの更新で対応される模様。

Linuxのメモリの本当の必要量を考える(メモ)

Linuxはメモリを可能な限り使う実装。

メモリが空いていれば、それはキャッシュやバッファーに使う。
bufferは、ファイルに対して書き込みが完了していない内容。dirty cacheとも言う。
cacheは、同期が完了しているファイルの内容。

プログラムの読み書きは、低レベルのI/Oを発行しない限り、bufferになり、cacheになる。これはLinuxカーネルがコントロールし、特に意識する必要はない。

Linuxのパフォーマンスの高さの理由のひとつとして、このメモリ利用が巧みである、ということが挙げられる。
Windowsはメモリを常に余らせてしまうが、Linuxは長期稼働していればいずれメモリのfreeは0になる。

このcacheは重要だ。なにせ、ディスクはメモリの100倍は遅い。いちいちディスクに対して読み書きしていたら、ものすごくストレスフルな環境ができあがる。

ユーザー空間のメモリはFile-backedとAnonymousがある。
File-backedはファイルと一致するもので、ファイルに書き出してしまえば解放することができる。
一方、Anonymousはプログラムが使っている内容であり、解放するためにはプロセスを殺すか(最終手段)、Swapに追い出すしかない。

File-backedはBuffers + Cachedだが、

Buffer = Active(file)
Cached = Inactive(file) + Shmem
File-backed = Buffer + Cache

ということになる。

こうした理由から、Memfreeがないからといってメモリ不足ではないが、「プログラムが空中で確保しているAnon分だけメモリがあればいい!」とか思うのは間違っている。
それだけあれば動くが、恐ろしくストレスが増す。

さて、ここで問題が発生した。

メモリはあればあるだけいいというのはあるものの、ずっと余裕がある場合は間違いなくそれ以上積んでもパフォーマンス向上にはつながらない。
では実際にメモリはどれくらい積めば、パフォーマンス向上が頭打ちになるのか。

最後にアクセスされたのがはるか昔で、いつでも解放できるメモリは空きも同然だ。だが、Linuxは特に不足しなければそれはそのままにする。
今の状態で十分なのか。それとも、もっと積めばパフォーマンスが向上するのか。さらに重い処理をしても余裕はあるのか。tmpfsにどれくらいファイルをおけるのか。
そして、新しいマシンを組む時にメモリはどれくらい必要なのか。

気になる。すごく。

ひとつの考え方としては、so(Swap Out)もsi(Swap In)もずーっと0のままであれば、それはあまりにも余裕がありすぎて、Swapを使うかどうかを判断する必要自体が全く無い、という状態なので、「ものすごく余っているから増やす必要はない」と考えていいが、

それでは気持ち悪くないか。

古いキャッシュだけ捨てられればわかるのになぁ、なんか方法ないかなぁ、と思って調べていたら、見つけた。

/proc/meminfoだ。

これをみると

MemTotal:       12291120 kB
MemFree:          568720 kB
MemAvailable:    8536348 kB
Buffers:          196976 kB
Cached:          7606960 kB
SwapCached:            0 kB
Active:          6458348 kB
Inactive:        4584444 kB
Active(anon):    3052444 kB
Inactive(anon):   298720 kB
Active(file):    3405904 kB
Inactive(file):  4285724 kB
Unevictable:       49344 kB
Mlocked:           49408 kB
SwapTotal:       4034556 kB
SwapFree:        4034556 kB
Dirty:               964 kB
Writeback:             0 kB
AnonPages:       3288328 kB
Mapped:           703892 kB
Shmem:             72480 kB
Slab:             390816 kB
SReclaimable:     328332 kB
SUnreclaim:        62484 kB
KernelStack:       12096 kB
PageTables:        48484 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:    10180116 kB
Committed_AS:    8082496 kB
VmallocTotal:   34359738367 kB
VmallocUsed:      173492 kB
VmallocChunk:   34359488508 kB
HardwareCorrupted:     0 kB
AnonHugePages:   1734656 kB
HugePages_Total:       0
HugePages_Free:        0
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB
DirectMap4k:     1635988 kB
DirectMap2M:    10930176 kB

のように表示される。

答ががっつり書いてあった。

Activeが最近アクセスされた領域、Inactiveがいつでも解放できるとマークされている領域。「はるか昔のいらないキャッシュ」はInactive(file)だ。

つまり、「余裕」とみなせるのは

Memfree + Inactive

ということになる。空き領域と、使われていない領域だ。
基本的にLinuxのメモリー確保は

  1. 空いているなら確保
  2. 使われていないのなら捨てて確保
  3. 使われているのなら、Active(file)の領域を(Dirtyならsyncしてから)解放するか、もちしくSwap

という順で行う。よって、Free+Inactiveが常に潤沢にあるのであれば、メモリ容量によるパフォーマンス低下は起こらない。

このことからメモリの追加に意味があるのか、そもそもメモリはどれくらい必要なのか、を推測する術が見つかった。

MemTotal - ( MemFree + Inactive )

長期に渡り活発に使用して常に保たれるこの量が、余裕の量だ。
重い処理をした場合でも、その重い処理がその量以上に使おうとしなければ問題ない。

ということで見ると、だいたい5Gくらい余裕があるわけで、となると使っているのは7GBくらいか。
実感としては、起動時に3GB近い(Manjaro LinuxでCinnamon。Plasma Workspaceだともうちょっと多い)ので、間違いなく4GBなければ「まともに」動かないが(軽量環境を使う必要がある)、当然ながら4GBだとすぐに枯渇する。4GBで足りないのはわかるが、では6GBなのか、8GBなのかという話になる。

感覚的には、だいたい6GBくらいは使うという印象がある。
稼働時間が浅いうちの値がそれぐらいで伸びなくなるからだ。
よって、6GBだと不足する可能性が高い。

8GBで十分かどうかがよくわからなかったのだが、これを見ると、Swapがちゃんと確保されていれば、若干のパフォーマンス低下はあるものの、ちゃんと動きそうだ。
ただし、tmpfsを使うと明らかにすぐ不足するので、tmpfsの積極利用は控えたほうがいい。

12GB(私と同じ2×2+4×2か、あるいは2×6)ならば、おおよそ問題はないが、tmpfsにDVDイメージを置くとswapされる可能性がある。
また、ビルド時にtmpfsに大きなファイルを起き、ビルド自体が重いときついかもしれない。ただし、12GBでかなり重いopenjdk8-infinalityとMozc-UTをビルドしたが、問題なかった。

16GB(4×4か8×2)ならばかなり余裕があり、ほとんど気にする必要はなくなる。

というのが、今回調べた結論だ。

今回はenkai00さんのブログエントリを全面的に参考にさせていただいた。非常に有用な記事だった。ありがとうございました。

Manjaro Linux 0.8.13 セットアップ (5) Z400編

はじめに

システム更新

$ sudo pacman -Syuu

Grub設定。nomodesetを入れる

$ sudo nano /etc/default/grub

最新カーネル

$ sudo mhwd-kernel -i linux42

ビデオカード

$ sudo mhwd-gpu --setgl nvidia

再起動。

パッケージインストレーション

  • nss-mdns
  • bind-tools
  • encfs
  • ctags
  • leafpad
  • zsh

ホスト設定を行う。

必要ならchsh

  • medit
  • geany
  • geany-plugins
  • smplayer
  • smplayer-themes
  • smplayer-skins
  • opera-developer
  • cinnamon
  • plasma
  • kde-applications
  • fcitx-kkc

X関係に問題が出るので、Zshでホームディレクトリ上で(多分、extended_globを伴って)

$ rm .[xX](^(profile))

入力関係の設定をしておく。

  • emacs
  • xsane
  • fetchmail
  • spamassassin
  • razor
  • tasque
  • skype
  • skype-call-recorder
  • openssh
  • sshfs

sshの設定

  • lv
  • w3m
  • amarok
  • audacious
  • audacious-plugins
  • libcue
  • audacity
  • sox
  • zsh
  • gtkhotkey
  • libgcrypt15
  • inkscape-gtk3-bzr
  • sylpheed
  • ttf-tahoma
  • fcitx-anthy
  • ttf-ricty
  • ttf-migmix
  • ttf-rounded-mplus
  • ttf-migu
  • ttf-sawarabi-gothic
  • ttf-hanazono
  • ttf-mikachan
  • ttf-sawarabi-mincho
  • ttf-mona
  • ttf-sazanami
  • ttf-monapo
  • ttf-kibitaki
  • ttf-mplus
  • ttf-ume
  • ttf-kochi-substitute
  • ttf-ohruri
  • ttf-vlgothic
  • ttf-koruri
  • ttf-vlkoruri

Infinality, Java, Mozc-UTは猛烈に時間がかかる。

  • cairo-infinality
  • fontconfig-infinality
  • freetype-infinality
  • jre8-openjdk-infinality
  • fcitx-mozc-ut

続き

  • kde-gtk-config
  • ttf-tahoma
  • bundler
  • fcitx-anthy

    nVidia向けのビデオ関連。

  • libva-vdpau-driver
  • gst-vaapi

続き

  • gtk-theme-preference
  • font-manager
  • gtk-chtheme
  • alsaplay
  • gedit
  • gedit-code-assistance
  • gedit-plugins
  • evince
  • gnome-terminal
  • tomboy
  • mcomix
  • gnome-screenshot

Gnome Screenshotは設定が必要

  • xlhtml
  • vivaldi

Vivldiは必要か??
Wine関連

  • wine
  • winetricks
  • twine
  • wine-mono
  • q4wineyaourt
  • wine_gecko

Haskell (for pandoc)

  • ghc
  • cabal-install
  • alex
  • happy
  • texlive-core
  • texlive-langcjk

続き

  • chromium-pepper-flash
  • dialog
  • perl-tk
  • psutils
  • ruby-kramdown
  • livestreamer

ウェブブラウザ。

  • midori
  • qupzilla
  • rekonq

続き

  • xnviewmp
  • nkf

Gtk+2テーマ関連

  • oxygen-gtk2
  • lib32-qtcurve-gtk2-1.8.18-1
  • lib32-qtcurve-qt4-1.8.18-1
  • lib32-qtcurve-utils-1.8.18-1
  • qtcurve-gtk2-1.8.18-3
  • qtcurve-qt4-1.8.18-3
  • qtcurve-qt5-1.8.18-3
  • qtcurve-utils-1.8.18-3

Gtkテーマ, Sylpheed, Leafpad

Gtk+2アプリケーションの中に、Gtkテーマを原因にSegmentation faultを起こす奴がいる。

SylpheedはGtk+2専用テーマでなければいけない。場合によってはフォールバックできるが、できない場合もある。フォールバックできる場合も起動時間が全く異なってくる。

そこで、Gtk+ 2専用のOxygen-Gtkにしたのだが、なんとLeafpadはOxygen-Gtkで動かない(!)

QtCurveが最も簡単に解決してくれるが、それも嫌なので、Leafpadだけは代替プログラムを書いた。

#!/bin/sh

export GTK2_RC_FILES=$HOME/lib/alt-gtkrc-2.0

exec leafpad

で、alt-gtkrc-2.0でQtCurveを指定している。

Gtk+2フルなテーマは

  • Clearlooks
  • Industrial
  • Mist
  • Redmond
  • ThinIce
  • Xfce-redmondxp
  • Xfce-kolors
  • Xfce-dawn
  • Xfce-dusk
  • Xfce-cadmium
  • Silver

もしかするとoxygen-gtk3-gitを入れるとダメかもしれない。

なお、Gtk3はCinnamonで、Gtk2はgtk-chthemeで設定。

文字入力設定

入力関係のため、~/.xprofile

export GTK_IM_MODULE=fcitx
export GTK2_IM_MODULE=fcitx
export GTK3_IM_MODULE=fcitx
export QT_IM_MODULE=fcitx
export XMODIFIERS="@im=fcitx"
export DefaultIMModule=fcitx
export PATH=/home/aki/bin:$PATH

ログアウトしてログインしなおしたほうが良い。
gtk-query-immodules-*は必要なかった。

Gnome Screenshot

デフォルトの保存場所を変更する。

gsettings set org.gnome.gnome-screenshot auto-save-directory /path/to/directory

Maxthon

リポジトリ落ちしているので

$ git clone --depth=1 git://pkgbuild.com/aur-mirror.git
$ cd aur-mirror/maxthon-browser
$ makepkg
$ sudo pacman -U maxthon-browser-1.0.5.3-4-x86_64.pkg.tar.gz

英数キーでCaps Lockになる

Archのevdevがいうこときかなくなっているので、.xprofileあたりに

setxkbmap -model jp106 -layout jp

Pandoc

$ export PATH=$HOME/.cabal/bin
$ cabal update
$ cabal install pandoc

openSSH

$ sudo systemctl start sshd
$ sudo systemctl enable sshd

ホスト設定

MDNS (Zeroconf)

/etc/nsswitchhost項目にmdns_minimalを追加。filesよりも後に。

fcitx-mozc-utのために

/etc/hostsdig japanese-usage-dictionary.googlecode.comした結果に基づき、このホストをIPv4で決め打ち。

ビデオの設定

Quadro2000でのVDPAUについては、単純にnon-freeでインストールしていれば、有効になっている。
nvidia-utilsでOKだからだ。

VA-APIについては、libva-vdpau-driverをインストールし、環境変数$LIBVA_DRIVER_NAMEの値にvdpauをセットするようにすれば良い。
私は~/.xprofileに記載した。

Smplayerは「ビデオ」タブで出力ドライバーvdpauに、
パフォーマンスタブのハードウェアデコードvdpauにする。

VLCについては、ハードウェアアクセラレーションによるデコードX11のVA-APIビデオデコーダーに設定する。

Flashは/etc/adobe/mms.cfgのコメントアウトされているEnableLinuxHWVideoDecodeを有効にする。


追記

Conkyを触ってみたのだが、AMD APUで発生していた

  • execiしていると2回目から表示が消える
  • RSSが取れないことが多い

RSSがとれないというのは、RSSのエントリが表示されない状態になる。Conkyの組み込みrssの話だ。取れたかとれなかったかの状態は永続するが、取れないことが圧倒的に多く、5つのRSSをまとめている部分に関しては、何十回も起動・停止しなければ十分に表示できなかった。

また、Conkyの負担もかなり大きかったので、結局使用をやめていたけれど、Z400になってなんの問題もなくなった。

やはりLinuxにはQuadroだ。

hp Z400 ( Intel Xeon W3565 + nVIDIA Quadro 2000 ) Manjaro Linux

経緯

事はデスクトップPCが壊れたことに端を発する。

起動不能となり、配線のチェックなども行ったものの解決せず、結局秋葉原まで持ち込み修理に出してきた。

BUYMORE秋葉原本店で購入したものであるため、Unicom秋葉原サポートセンターに持ち込み。
事前に、ケースが不要であることを確認し、電源と、マザーボード+メモリ+APUの状態で持ち込んだ。

ちなみに、台風のため(甚大な被害を出したあの雨だ)、翌日の持ち込みとなった。

秋葉原サポートセンターは非常にわかりづらい場所にある。随分探しまわってしまった。
総武本線の高架下沿いで、JRの駅からは中央通りをはさんで反対側、御茶ノ水方向で、KFCの向かいだが表ではなく裏側の向かい、マウスコンピューターの地下1階で、しかもその階段はサービスカウンター沿いの奥にある。

とりあえず持ち込んだはいいが、なんといっても台湾送りのため、1ヶ月程度はかかるもよう。その間仕事ができないというのは、とても困る。

暫定的な対応

とりあえずは、ProLiant MicroserverのSlaveディスク4台を抜き出し、Masterディスク4台を投入、Masterのキーファイルを入れ、Masterをマウントできるようにする。

SlaveをMasterに昇格させると数日分の作業データを失うこととなる。
基本的にはSlaveはMasterディスクの損失に対する存在だ。

これによってProLiant MicroServerで本来のデータが扱えるようになり、sshfsでアクセスすることでデータにはアクセスできるようになった。

だが、環境に関するデータは結構困る。
FUSEやNFSでマウントしているデータへのアクセスはかなり制限される。FUSE環境だとアクセスできるのが所有者に限られるためsudoが使えない、という程度はわかるが、なんとSpamassassinがちゃんと動かない。ちなみに、sudoでもsu -cでも動かないが、su -なら動く。

細かく様々制約され、「なんだか変な挙動」「なぜか動かない」が蓄積し、作業効率を大幅に下げる。

問題はそれだけではない。それをドライブする端末がないのだ。
ThinkPad e440は異常なまでに不安定であり、作業効率は10%も出ない。1分ごとにXが落ちて、その再起動に30秒程度かかるなど話にならない。

ちなみに、e440はWindowsの初期状態でもかなり不安定な挙動を見せる。もう、Lenovoのことはだいぶ嫌いになっている。

かといってとProLiant MicroServerの直接利用も性能的にも厳しいし、映像出力系にトラブルがあり、難しい。

対策の候補

いずれにせよ、必要だと分かっていた冗長系投入を遅延させていたのが問題であり、冗長系を投入するのが妥当だろう。
窮状にあって苦しいが、やむを得ない。

候補は以下だ

  • 直近の将来の要求である4k x3モニターが可能なメイン系(現行を冗長系へ) (14万円)
  • あくまでも冗長系の新品AMD A4マシン (3万円)
  • あくまでも冗長系の中古マシン (2万円)
  • 活用可能な中古マシン (4万円)

4k x3を可能にするのは、Quadro K1200が最低ラインのようだ。K620に関しては、DP Hubによる分岐もFQHDまでしかサポートしない。そのため、結構な額になった。なお、全体はSkylakeで構成することを想定した。

やはり、額が大きいことと、これからSkylakeも安くなっていくだろうし、USB CやDDR4メモリなど新規格が続々の中ではなかなか筋が悪い。

新品AMDマシンは構成が近いため、冗長環境を作りやすいが、既に問題が大量にあり、しかも十分なパフォーマンスがないというのに、さらに下位のものを選ぶのはなかなか厳しい。

さらに、メーカーが非常に評判が悪く、保証どころか修理すら預けられない感じであったため、それならば中古のほうが良いと判断し、最初に消去した。

2万円はCore i7-870、4GB RAM、GeForce 250GTマシン、4万円はXeon W3565, 4GB RAM, Quadro 2000マシンだった。

Windows的に、そしてベンチマーク的に測ればおそらく大差ない。実際ベンチマークを見るとXeon W3565が6,093、i7 870が5,480で、7700kは5,247となっている。

Skylake i7のベスト(i7-6700k)は10,957、4770kでも10,184ということを見れば、やはりふるさは否めない。
一方で逆の見方をすればそれで最新のKaveriよりも上なのだから、ハイエンドってすごいなぁ、とも思う。

GeForce GTS250は随分数字が小さいことに不安を覚えたが、この時は全世代のハイエンドである9800 GTX+(上から2番目)の名前だけを変えたのがGTS 250で、このシリーズでは上から6番目、下から4番目、とのことだ。

古いので、最新ゲームは結構きつそう。時代を感じる。

もっとも、もうこの世代になるとGeForceはOpenGLを切る方向だった。
LinuxはDirectXを使わないし、安定性を求めるならQuadroのほうがいい。nVidiaはQuadroに関してはLinuxのサポートも手厚い。

Windows上での性能は差が小さいが、私が使う上での価値はかなり差が開いている。妥当な価格差だ。

これだけの性能があれば、何かの時に助けてくれる気がする…ということで、hp Z400 workstationを購入した。

hp Z400 Workstation

2009年に投入された前期型型Z400ワークステーションは、CPUはXeon W3520からW3580までで、これら対して5250円の水冷オプションがある。

グラフィックスボードを持たない最小構成で22万円程度、Quadro FX1800を含むと27万円程度とのこと。

後期型はW3520はそのままだが、W3565, W3680, W3690とプロセッサが変更され、グラフィックスのラインナップも一新、QuadroだけでなくFireProも加わっている。
また、メモリスロットを4から6に増やし、最大24GBメモリをサポートするようになった。チップセットはintel X58とのことだ。

最小構成+水冷を99,750円で提供していたらしいが、最初構成で買う人がいたのだろうか?

SASモデルもある。SASモデルでなくてよかった。

私が購入したモデルは、Xeon W3565プロセッサ, 4GB RAM, Quadro 2000の水冷モデル。
SATA仕様で、電源は475Wブロンズ、X58チップセットの後期型だ。

光学ドライブを搭載している。DVD-ROMドライブやBDドライブもあったようだが、DVDスーパーマルチドライブだった。

Xeonについて

Intel XeonはIntelのワークステーション/サーバー向けのCPUである。

ワークステーション向けは処理性能が高く、サーバー向けはコア数が多くて発熱が抑えられている。

Xeonのワークステーション向けの下位モデルは、民生用で最上位のCore i7 Extreameシリーズと同等品となり、またそれ以上のモデルが用意されている。

基本的には民生用のCoreシリーズと比べると高性能だが、それだけでなくECCメモリーへの対応や、CPUあたり6本のメモリスロット、マルチCPUのサポートなどより高度な性能要求や安定性に耐える仕様となっている。

その分各部品は割高だ。マザーボードも非常に高価だが、ECCメモリーなども地味に痛い。

Quadroについて

nVIDIA Quadroは、nVIDIAの映像処理向けグラフィックスボードだ。

民生用のGeForceがDirectXに特化した「ゲーム用」であるのに対し、3Dグラフィックデザイナー、CADアーティスト、映像クリエイターなどに向けてOpenGLに特化した仕様としている。

また、安定性もかなり高められており、他画面出力にも強くトレーダーにも適している。

nVIDIAはQuadroについてパッケージにLinuxへの対応を明記している。

ドライバーサポートはnVIDIAのほうが全体に手厚い。
ただし、ビデオドライバのパフォーマンスは、Windowsはおろか、FreeBSDと比べてもはるかに低いのが残念なところだ。

Z400の内部とシステム

配線は余り過ぎない長さになっており、さらにそれがまとめられた上にカバーまでかけられている。

カバーはメモリも覆うようになっていて、放熱上不利に見えるが、もしかしたらエアーコントロールによってむしろメモリ放熱が考えられているのかもしれない。

5インチオープンベイが3つ、3.5インチシャドウベイが2つ、3.5インチオープンベイに見えるが実際は使いみちのない塞がれたベイがひとつある。

SATAコネクタは6で、SATA 2.0 3Gbps。
ただし、SATA電源コネクタは5。空きの4ピンがふたつあり、電源増設は可能。

PCI関連は

  • PCI e2 x8
  • PCI e2 x16
  • PCI e x8
  • PCI e2 x16
  • PCI
  • PCI

となっている。

メモリスロットは6、最大搭載可能量は24GB。標準では2GBx2が積まれていた。トリプルチャンネル仕様。

おそらくはスタビライザーとして昨日するのであろう緑色のステーがQuadroに向かって伸びている。

基本的には緑色の部分は工具なしで操作できる部分だ。パネル自体はハンドル式になっており、必要な工具は増設時のトルクスのみか。

BIOS式でUEFIなし。

BIOSは、起動ロック、ディスクの暗号化に対応。また、RAIDコントローラを持ち、RAID構築が可能。

WoLに対応。ハイパースレッディングのOn/Offが可能。カバーセンサーについては有効・無効を設定可能。

設定項目は非常に少ない。

ブートデバイスの選択は、Optical, USB, Diskのみ。WindowsとLinuxの切り替えは基本的にはデバイスの起動順序を利用する必要がある。

また、Opticalを指定すればOptical Driveを読みにはいくのだが、ブータブルなCDを入れていてもスルーされてしまうことが結構あった。

OSはWindows 7 Professional。ちなみに、この個体はhpのデフォルトではなく、ショップで入れて認証したものが入っている。

Windowsエクスペリエンスでは、だいたい7.0から7.5。ディスクだけは5.9にとどまった。Windowsのディスクは250GB HDDである。UEFIをサポートしないため、ブートディスクの容量は2.2TBが上限となる。

メモリ増設

あとから知ったのだが、hpは

  • DDR3-1366 DIMM ECC Unbufferedのみ対応
  • hp以外のメモリは使用不可
  • ECCとNon-ECCを併用すると、メモリエラーとなり起動しない

と言っている。また、調べてみると

  • ECCとNon-ECCを混ぜることはできない
  • BIOSで有効・無効が切り替えられるのなら、無効にすればNon-ECCメモリが使用できる。常に有効であるなら使用できない。いずれにせよ混ぜることはできない
  • 否、無効にしてしまえば混ぜてもNon-ECCとして動く

とある。

CFD ELIXIR W3U1600HQ-4Gを追加した。

「おそらくはNon-ECCの、DDR3-1600メモリの4GBx2」である。

メモリチェックはちゃんと通ったし、LinuxもWindowsも問題なく機能する。
よくわからないが、とりあえず気にしないことにした。人には勧めない。

なお、最初から1366のメモリが積んであるにもかかわらず、1066で動作している。

HDD

完全にデスクトップを代替しようとすると、Windowsは「音楽系ソフトを入れる別なディスクが必要」となる。

ディスクは6、マウントは5でいいと思ったのだが、実際はディスクは7、マウントが6必要であることに気がついた。

これは、Windows + Windows DATAで2台、Linuxシステムで1台、btrfsプールで4台だ。
PCIeカードでコネクタは間に合うし、電源はなんとかするとしてもマウントがない。

1台はSSDなので、適当に固定すれば良いのだが、HDDはそうもいかない。しかも、光学ドライブがあるため、マウントはさらにもうひとつ必要なのだ。

結局は、全てHDDに充てることで解決したが、実は方法はあった。

マウントに関してはiStar USA BPN-DEを利用した。

これは、5.25インチベイに固定するHDDラックで、5インチベイx2に対して3.5inch HDDx3を固定できる。
ガシャポン式で、コネクタはSATA 6Gbps。トレイなし、ホットスワップ非対応だ。

このラックは、SATAコネクタは3本(当然)必要だが、電源コネクタは2つでまかなえる。そのため、これを使うと電源増設が不要だ。

WindowsのHDDの割り当てが1台しかないため、音楽をこちらに移すことは諦めたが、このラックを使って入れ替えれば可能であることに気がついた。

それどころか、入れ替える前提であるならば光学ドライブを残すことすら可能だ。

しかし、どの程度抜き差しして大丈夫なものか、よくわからないため、しょっちゅう交換する使い方は不安がある。

なお、これらの固定方法はやや特殊。ドライブ自体にまずガイドネジを取り付け、ベイ開口部から挿入する、という形だ。
5インチベイのラックについては、上段が若干ネジ穴位置が低く、ネジを入れてしまうとガイドを通らなかったので、下段のみにネジを入れて固定した。

ネジはシャーシに固定されている。これはProLiant Microserverと同様だ。マイナスドライバーも受け付けるが、基本的にはトルクス。これはProLiant Microserverと規格が同じで、レンチが流用できた。

Linux上での性能

まず、この通り

$ cpupower frequency-info
analyzing CPU 0:
driver: acpi-cpufreq
CPUs which run at the same hardware frequency: 0
CPUs which need to have their frequency coordinated by software: 0
maximum transition latency: 10.0 us.
hardware limits: 1.60 GHz - 3.19 GHz
			available frequency steps: 3.19 GHz, 3.19 GHz, 3.06 GHz, 2.93 GHz, 2.79 GHz, 2.66 GHz, 2.53 GHz, 2.39 GHz, 2.26 GHz, 2.13 GHz, 2.00 GHz, 1.86 GHz, 1.73 GHz, 1.60 GHz
available cpufreq governors: ondemand, performance
current policy: frequency should be within 1.60 GHz and 3.19 GHz.
				The governor "ondemand" may decide which speed to use
				within this range.
current CPU frequency is 1.60 GHz.
boost state support:
	Supported: yes
	Active: yes
	25500 MHz max turbo 4 active cores
	25500 MHz max turbo 3 active cores
	25500 MHz max turbo 2 active cores
	25500 MHz max turbo 1 active cores

ここで躓かれても困るが。ただ、ondemandperformanceしかないのか。

ハイパースレッディングをONにした状態だと、

$ nproc
8

これも当たり前。

実際、感覚としてはA10-7700Kとはまるで違う。
A10-7700Kは3.4GHzだというのだが、実際に動かしているとほとんどの場合、2.4GHzで動作する。負荷がめいいっぱい高い状態でも2.6GHz、2.8GHzがせいぜいで、フリーズするような状態になってもそんなものだ。

ベンチマークなどで見る性能には、はるか届いていない。というか、モバイル用Celeronのほうがさくさく動く始末だ。

それに対して、Xeonは圧倒的に速い。細かく停止するようなトラブルもない。

メモリは4GBでは圧倒的に足りない。yaourtでビルドできないパッケージが結構ある。
/etc/yaourtrcで設定すれば回避できるが、結局メモリが足りないという問題の解決にはなっていない。

12GBあれば日常的には問題ない。
ただし、一時的であれtmpfsに大きなファイルを置くと圧迫される可能性がある。
とはいえ、実際に使われる範囲としては、6GB前後というのが私の感覚なので、tmpfsに半分とられてもswapもあるし、12GBというのは、おおよそ問題ない気がする。

ただ、そもそも圧迫されている状態になった時にバッファとして使える領域が非常に少ないため、16GBあったほうが安心ではある。

Xeonがとにかく速く、メモリを増設した時のパフォーマンスは本当に感心する。
それだけ良いようだと、最新のワークステーションはどれほどのものなのか…

Quadro 2000 と Linux

さて、問題のQuadroだ。

AMD A10-K7700はAMD R7グラフィックス相当だが、Catalystドライバを使っていても

  • セカンダリディスプレイのマウスカーソルが歪む
  • VDPAU/VA-APIともに使用できない
  • Xのパフォーマンスが非常に悪い。描画のもたつき、プチフリーズが多い
  • Chrome系ブラウザが動作しない。画面が表示されたり消えたりする。プロセスが増えるとまずダメ
  • Skypeで画面が歪む。変色し、緑色の線が入る
  • マルチデスクトップは正常に機能しない

これなら安定して動作するIntelグラフィックスのほうがいいのではないか…と思ってしまう。パフォーマンスも非常に悪い。

対するQuadroは、これらの問題が見事なまでに発生しない。
100時間以上を費やし、動作しない理由の究明に勤しんだVDPAU/VA-APIも、いともあっさりと動いた。動画再生は非常に快適だ。

ただし、VLCで「DRM経由のVA-API」にすると動作しない。「XのVA-API」にする必要がある。

驚いたのはImageMagickの処理が飛躍的に高速化したことだ。
従来1分は余裕でかかっていた処理が3秒以内に完了する。おそらく、数時間かかっていたmogrifyの負担も著しく軽減されるだろう。

とにかく安定している。問題らしき問題が発生すること自体稀だ。

ただし、デスクトップで動作していたOpera Devloperは動作しない。フリーズしてしまう。また、Chrome系のChromiumなどは動作はするものの、入力に対する反応が著しく遅い。Blinkの神経質さが気になる。

Blink系ブラウザではMaxthonが正常に動作するが、Maxthonは現在AURから落ちてしまっている。旧リポジトリから入手可能だ。

これからは事実上Blink以外の選択肢が失われていくように思うのだが、Blinkの動作の不安定さは非常に気になる。WebKit系は動作するが、非常にもっさりだ。

結論

LinuxのグラフィックスボードはQuadro。

AMDのCPUのパフォーマンスが出ない理由はよくわからない。ビデオもCPUも、Windowsではそれほど悪くないように感じるのだ。

ただし、Windowsではオーディオデバイスのほうが見事に落ちまくる。ASIOドライバを使うようなデバイスは、やはりIntelのほうが最適化されているのだろう。AMD CPU不可というものもあるくらいだし、完全な互換性はないのか。

で、AMD APUのパフォーマンスはWindowsの時よりもはるかにしょうもないものに見える。非常にストレスフルな性能だ。

結局のところ、Intel CPU + Quadroという、普通の組み合わせ(Quadroは普通ではないが、Linux的にはむしろ妥当だ)が一番いいようだ。

愛着のある、はじめての自作PCとの比較がこのようなことになって、とても残念だが、だが、このような蓄積は仕事上必要だと思うことにしよう。

高度なことを求める人にLinuxを動かすハードウェアとしてAMD APUは勧められない。

VDPAU/VAAPIが動作しないのは、ディストリビューション的な事情かもしれないが、少なくともマウスカーソルが歪むという問題はディストリビューション問わず発生した。Skypeに関しても同様だ。

これが、Radeon全般の問題なのか、7700K固有の問題なのか、はたまた私の7700Kの問題なのか、あるいはCatalystの問題で将来的に解決されるのか…といったことはわからない。
ただ、マウスカーソルが歪む問題は、やはりRadeon * CatalystにおいてWindowsでも報告されている。

スペックだけをみればAMDの製品はLinuxのほうを向いているかのようだが、事実はそうではないらしい。

Markdownで書かれたスライドをHTMLとポータブルPDFと印刷用PDFにする

Aki SI&EのPR用に書いたものだが、Markdownで書き、Web(HTML)、配布用PDF、印刷用PDFの3種類を生成する考えでいた。

手でやろうかと思っていたのだが、再生成の回数も多そうだったので、自動化できるようにした。

Markdownで記述したドキュメントと、オリジナルサイズの画像ディレクトリ、mogrify -geometry x300でリサイズした画像ディレクトリが用意されている。
Web用のものについてはHTMLで出力し、リサイズされた画像のWebサーバー上のコピーを参照しなければならない。

PDFについては、MarkdownをLaTeXに変換してという方法もあるにはあったが、画像を含めた細かなデザインを施したかったため、HTMLをベースにPDFに変換することにした。

MarkdownコンバータはRubyのKramdownを使用。改ページはないため、wkhtmltopdfを用いてPDFに変換することとした。
参照しているディレクトリの違いで2回ループを回す。

それぞれHTMLは別に出力し、テンポラリファイルとして出力したHTMLを元にPDFのテンポラリファイルを生成、unitepdfを使ってこれを結合する。

専用のコードなので多くをハードコーディングしているが、これで正常に機能する。

#!/usr/bin/ruby
# -*- mode: ruby; coding: UTF-8 -*-

require 'kramdown'
require 'erb'

def treat_md(file, findex)
  $article_body = doc = Kramdown::Document.new(File.read(file)).to_html
  
  $article_title = doc[/<h1[^>]*>(.*?)<\/h1>/, 1]
  
  foot = Array.new
  if findex > 0
    foot << '<a href="' + ( SOURCEFILES[findex - 1].sub(/\.md$/, '')  + ".html" ) + '">前へ</a>'
  end
  
  foot << '<a href="/si/" target="_top">Aki SI&Eトップページへ</a>'
  
  if findex < ( SOURCEFILES.length - 1 )
    foot << '<a href="' + ( SOURCEFILES[findex + 1].sub(/\.md$/, '')  + ".html" ) + '">次へ</a>'
  end
  
  $article_footer = foot.join
end


TEMPLATE = <<'END'
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" http://www.w3.org/TR/xhtml1/dtd/xhtml1-transitional.dtd">
<html>
  <head>
    <title><%= $article_title %></title>
    <meta http-equiv="content-language" content="ja" />
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
    <style>
body {
% case $mode
% when :Web
  font-size: 130%;
  color: #333;
  font-weight: bold;
  margin: 0px;
  padding: 0px;
% else
  font-size: 18pt;
  color: #000;
  font-weight: bold;
  margin: 2cm auto;
  padding: auto;
% end
  background-color: #fff;
  font-family: "Migu 1C"
}   

h3 {
  font-size: 135%;
}

#Container {
  margin: auto auto 100px;
  max-width: 950px;
  text-align: center;
}

img {
% case $mode
% when :Web
  height: 300px;
% else
  height: 18em;
  max-width: 100%;
% end
}

ul {
  text-align: left;
  margin: auto 1.8em;
}


#ArticleFooter {
% if $mode != :Web
  display:none;
% end
  position: fixed;
  bottom: 0px;
  margin: 0px;
  width: 100%;
  max-height: 100px;
  background-color: #339;
  color: #fff;
  text-align: center;
}

#ArticleFooter a {
  padding: 0 0.8em;
  text-decoration: none;
  color: #fff
}

#ArticleFooter a:hover {
  text-decoration: underline;
}
    </style>
  </head>
  <body>
    <div id="Container">
    <%= $article_body.gsub(
      %r{src="img/},
      %(src="#{$img_type}_img/)
    ) 
    %>
  </div>
    <div id="ArticleFooter">
      <%= $article_footer %>
    </div>
  </body>
</html>
END

$article_body = nil
$article_footer = nil
$article_title = nil

SOURCEFILES = Dir.entries(".").select {|i| i =~ /\.md$/ }.sort

# HTML
$img_type = "/img/si/intro_slideshow/resized"
$mode = :Web

SOURCEFILES.each_with_index do |x, i|
  begin
  treat_md(x, i)
  File.open("out/#{x.sub(".md", ".html")}", "w") do |f|
    f.puts(ERB.new(TEMPLATE, nil, "%<").result)
  end
  ensure
    $article_body = nil
    $article_footer = nil
    $article_title = nil
  end
end

# Web PDF
$img_type = "resized"
$mode = :PDF

SOURCEFILES.each_with_index do |x, i|
  begin
  treat_md(x, i)
  fn = "out/_tmp_#{x.sub(".md", ".html")}"
    File.open(fn, "w") do |f|
      f.puts(ERB.new(TEMPLATE, nil, "%<").result)
    end
  system('wkhtmltopdf "%s" "%s"' % [ fn, fn.gsub(".html", ".pdf") ])
  ensure
    $article_body = nil
    $article_footer = nil
    $article_title = nil
  end
end

system 'pdfunite out/_tmp_*.pdf out/portable.pdf'
system 'rm out/_tmp_*'

# Printable
$img_type = "original"
$mode = :PDF

SOURCEFILES.each_with_index do |x, i|
  begin
  treat_md(x, i)
  fn = "out/_tmp_#{x.sub(".md", ".html")}"
    File.open(fn, "w") do |f|
      f.puts(ERB.new(TEMPLATE, nil, "%<").result)
    end
  system('wkhtmltopdf "%s" "%s"' % [ fn, fn.gsub(".html", ".pdf") ])
  ensure
    $article_body = nil
    $article_footer = nil
    $article_title = nil
  end
end

system 'pdfunite out/_tmp_*.pdf out/printable.pdf'
system 'rm out/_tmp_*'

完成したものについては

Google DOCs Viewerはスライドショー向きではないので、ウェブ版を使うか、PDFをダウンロードするのがお勧め。

「ハイレゾ」とポータブルオーディオプレイヤーとFiio X1/3/5

突然だが、あなたは外で、ポータブルオーディオプレイヤー、いわゆるiPodとかウォークマンとか言われるやつ、あるいはスマホで音楽をきいたりするだろうか?
個人的な見解だが、これについては結構分かれる気がする。
およそ

  • 常に聴いている
  • 特定のタイミングで聴く
  • 持っているが大抵忘れる
  • 聴かないし、他の人が聴くのも不快だ

というところではなかろうか。
ここは、まあ音楽が好きで、できれば良い音で聴きたいという気持ちがある、という前提で話を進める。
外でもそのように聴きたいかは別の話だが、まぁポータブルオーディオを家で聴いてもいいわけだから、適宜想定してほしい。

ちなみに、私は寝ている時以外は(場合によっては寝ている時でさえ)常に音楽を聴いていたくらいだったが、突発性難聴になりやすくなり、またそこまでの音楽状態に入れないこともあって、最近はかなり減った。

ハイレゾとは

「ハイレゾ」という言葉を最近耳にする人は多いのではなかろうか。

元々は「ハイデフオーディオ」(ハイディフィニションオーディオ。HDオーディオ)と呼ばれていた。

CDのデジタルデータは44.1kHz/16bitのPCMオーディオである。これはサンプリングレート/量子化ビット数で表している。

サンプリングレートは波形の横軸(時間)、量子化ビット数は縦軸(振れ幅)をどれだけ微細にデータにするかだ。
音はあくまで振幅幅と振幅時間で決まるため、幅と時間しかデータとしてはない。
PCMオーディオは極めて単純に、それをビットマップにしたものになる。言ってみれば、波形を方眼紙に書き、線が通ったマスを埋めるという考え方だ。
サンプリングレートが高くなればマスの幅が小さく、量子化ビット数が増えればマスの高さが小さくなる。

振幅時間は音の高さである。
早く振幅すれば音が高くなる、というのは小学校の理科で習ったことだろう。
Hzは「1秒あたりの反復回数」を示す単位である。サンプリングレートのHzは1秒間にその回数点を打つということだが、音の波は行って戻って一回である。
そのため、サンプリングレート44.1kHzで表現可能な最大の音高は、22.05kHzである。

ただし、実際はちょうどサンプリングのタイミングで波の頂点が来るのでなければ22.05kHzはサンプリングできない。
少しでもずれていればナイキスト周波数によって音は低く見えてしまう。
20kHzがちゃんと聞き分けられる人は少ないが、この歪はわりと聞き取ることができ、それが音が悪く聴こえる原因でもある。
サンプリングレートが向上すれば、より高い音まで正確に表現できる。

ちなみに、44.1kHzという中途半端は、当時レコーディング・スタジオで広く使われていたSonyのデジタルテープ機材の仕様からきている。

一方、振幅幅は音の大きさである。大きく震えるものは音が大きいのも同様に理科で習う。
量子化ビット数が増加した場合、「大きな音が表現できる」というよりは、「音の大きさが細かく表現できる」。
大きい音は最終的にボリュームで同じにしててしまうのだから、小さい音まで繊細に表現できるのが大きい。

このCD音質を越えるサンプリングレート、量子化ビット数を持っているものを「ハイレゾオーディオ」と呼んでいる。
ただし、レコーディングで使われる48kHz/16bitはこの限りではない。これはJEITAがCDスペックを44.1-48kHzと定義しているため。

DSDについて

DSDというものを聴くこともあるかもしれない。

これはΔΣ変調を利用したものであり、PCMとは全く性質が異なる。

データ上はノイズまみれなのに素晴らしく良い音が得られる。
ただし、それはΔΣ変調を用いて復号化して音にできる場合のみであり、DSDの直接再生をサポートしていない場合は、一旦PCMに変換することになる。
この場合、DSDの「軽い」「音が良い」というメリットはなくなる。

そして、ΔΣ変調の原理上、一切の編集ができない。
どんなに音が良くても、このために一発録りしかできないのであり、ライブ音源以外ではまず使えない。
そして、ライブ音源をそこまで高音質にする必要があるかは、個人的には疑問だと思う。

最高の演奏家のプレイを、一発で録ったものを聴きたい人以外にはあまり意味がないかもしれない。

ちなみに、レコーディングをDSDでやると、高品位なPCMに変換しても劣化が少ない。
現在音楽制作で使われるPCMは192kHz/24bitがせいぜいだが、将来的にもっと高品位なPCMが使われるようになった場合に、
DSDのレコーディングデータがあれば、より高音質な音源を作ることができる、というメリットがある。
アナログ時代のものは、元のデータが劣化していくため、進化した後世の技術で高音質化することは極めて困難なのだ。

実際良いの?

意外とわかるものだ…というのが私の感想。
とはいえ、私がそもそも40kHzが確実に聴き分けられる耳を持っているので特殊な話にはなる。

とはいえ、可聴音域が20kHzだから、という主張は、もうちょっと理科を勉強すべきだと思うし、よくあるオカルトとは明らかに違う。
音を聴いてこれはどちらかと言われて当てられるほどではないが、聴き比べてどちらがよかったかはまぁ聴き分けられるのではないか、と思うレベルには違う。

そもそも、私は聴いた時かなり不安だった。聴き分けられないんじゃないか、いやどうせ無理だろう、恥ずかしいなぁ、と思っていた。
だが、あっさり分かったので、それくらいには違う。
別に、同じ楽曲で2つ聴き比べてどっちがハイレゾかを当てるブラインドテストならしてもいいというくらいに自信がある。

ちなみに、制作で高品位なデータが求められるのは、加工の過程でデータが損失しやすいからである。
特に、16bitでのヴォーカルレコーディングは簡単に0dBを越えてしまうため、なかなかしんどい。24bitではかなり余裕をもったセッティングが可能。

実際ハイレゾで聴くには

  • データがハイレゾである
  • データ的にハイレゾを取り扱える(ダウンコンバートせずに)
  • D/A装置がハイレゾを音声信号に変換できる(ダウンコンバートせずに)
  • オーディオ装置が20kHzを越える音域を損なわずに伝送・再生できる

が必要となる。
オーディオ装置側はちょっと微妙な話で、デジタル側と違って「ハイレゾ対応」なんて謳ってなくても再生できるものは再生できる。
実際、私が愛用するULTRASONEも、昔から40kHzを越える音域の再生に対応していたという。

ただ、音が出るのと綺麗に出るのは全く違うし、しかもスピーカー装置は歪が非常に大きいものなので、スピーカー装置によってハイレゾの音源を活かせるかどうかは大きく変わってくる。
近年の機材は進化が激しく、最新の良いものは高域まで綺麗にでるようになっている。そのため、近年作られた良いものであれば、ハイレゾの音源を活かすことができるだろう。

ただし、活かしきるためには、192kHzの音源ならば96kHzまで再生できなければならない。出ないことはないかもしれないが、クリーンに出せというと、かなり困難な要求になる。

なお、実際に音に関して影響を及ぼすのは、サンプリング周波数よりも量子化ビット数のほうだ。
実際、音楽制作では48kHz/24bitに関してはよく使うが、192kHz/16bit

ハイレゾ自体についての結論

人に押し付けたり、噂やデータに縛られず、気持よく聴ける音を聴きましょう。

ポータブルオーディオプレイヤーについて

Fiio Xシリーズはハイレゾに対応したプレイヤーだそうだ。
SonyのWALKMANはハイレゾに対応したものは10万円近くするので、かなりお手頃ということになる。

FiioはOYAIDE社のブランドだが、ポータブルヘッドフォンアンプ、USB DACもある。
こちらはポータブルオーディオプレーヤーで、多彩なファイルフォーマットに対応し(私が使用するOgg FLAC, Ogg Vorbis, MP3のいずれにも対応)、トップモデルのX5 2nd Generationに関しては量子化ビット数24bit、サンプリングレート192kHzまで対応し、DSDは2.8MHzと5.6MHzの両方に対応する。

大容量SDカードに対応し、X5 g2についてはスロットが2つあるために、128GB SDXC 2枚を搭載できる。
デジタルコアキシャル伝送に対応するあたりなかなか器用だ。

かなり魅力的ではあると思う。

では私はハイレゾにこだわるか?

いいえ。

制作においてはゆらぎが嫌なので、なるべく不確定要素を減らす意味でデジタルで、しかもかちっとした音でやっているが、リスニングになるとウォームなほうが良いと思うのだ。

むかしからあるようなアンプなど、ウォームでいい。真空管はやっぱりいい音がする。別に持とうとは思わないけれど。扱いが面倒だし。
アナログ側に音を良くする余地がいくらでもあるので、ソース側での変更というのは現状あまり費用や手間に対して効果が薄い、ということだ。

どちらかといえばこういう確実な変化があり、それが論理的に裏付けられるもののほうが好きではあるものの、だからといって優先するかと言われると…

何よりも、まず音源がない。
CDは44.1kHz/16bitだし、ハイレゾ環境で聴く音源がない。
しかも、私が聴くのはだいたいマイナーな音楽なので、余計にない。別にAKB48あたりをハイレゾで聴きたいとも思わないし。

また、しょぼい私のライブラリのCDのFLACだけでも149GBほどある。
PDAPは192kbpsのOgg Vorbisにしている(つまり音質を劣化させている)が、それでも32GBのSDカードだとおさまらない。
欲しいCDはいっぱいあるので、それも考えるとFLACですらPDAPに収めることは困難だ。
SDカードが尋常ならざる容量増加を見せない限りは、ハイレゾ音源を持ち歩こう…とはあまり思わない。
だいたい、そこまで集中して聴ける環境もないため、Oggでもあんまりわからないというのが正直なところ。家で聴いてる分には、両方のファイルが含まれるようにすると「んっ?」と思うので、Ogg VorbisとFLAC自体はわかるということになるのだが。

PDAPがハイレゾになるメリットはあまりない。どちらかというと、家でもPDAPで聴く、という人向けだろうか。
それならそれでありだとは思う。ただし、家のオーディオならオーディオ機器を据え置き前提の物にしたほうが確実に幸せになれる。
もちろん、それに対して3.5mmプラグで接続するんだ!というのならそれは止めないが。

X5に関しては、3300mAhという大容量バッテリーを搭載していながら、再生時間が10時間と短いことが痛い。1日に10時間以上聴く場合は普通にあるし、バッテリーで稼いでいるため、充電に時間がかかる。

また、私が要求するFMラジオ、ICレコーダーなどの機能はなく、純粋に音楽ファイルを再生するだけのプレイヤーである。本当に外出先でも音に猛烈にこだわる…という人なら価値はあるだろうが、私の価値観では、雑踏の中、歩行などによるノイズ(自分の身体の音が自分にきこえたり、聴覚をゆらしたりする)もあるし、そんなにいいヘッドフォンで聴いていられるわけでもないし、集中もできないという環境でそこまでの音を追求する気になれない。

個人的には音の質の問題よりも、COWON M2の「わかりやすい演出的な音の味付け」のほうがポータブルであるならば向いているように思う。
もし、音源の入手性が改善してハイレゾ音源が当たり前になり、ストレージ容量も極めて大きくなって全部詰め込んでも余裕があるという状態になれば、わざわざ劣った音で聴く必要もないし、ハイレゾなんかいらないと肩肘張る必要もないと思うのだが、現時点ではどうしてもというものではないと思う。
縁があるのであればハイレゾにすればいいし、特に最先端を行きたいわけでもなく、ハイレゾどっぷりでいくプランがあるのでもなければまだ整っていないかな、という印象だ。

また、「良い音」と「好い音」に隔たりがあることも踏まえて、自分にあった選び方をするのが、音楽で幸せになるポイントだと思う。