Archive for the ‘Linux’ Category

半年くらい前から、LinuxでのテキストエディタにはAtomを使っていたのだが、全然良くないことに気付いた。僕の使い方(変なプラグインを入れたせい?)が悪いのか、頻繁に遅くなる。開いているファイルが多いと、ひどい時には数分間固まるし、そうでなくても、文字を打ち込むだけでも遅いから、GPMDBの改良作業の足かせとなって、大変イライラしていた。更に、それ以外に、山ほどプラグインを入れないと普通のエディタのようには使えない(まだ普通のに劣ることがある)など、基本的な機能が劣っている。

それで、前に使っていたjEditに戻ろうかとも思ったのだが、日本語のインライン入力ができないので(いろいろやればできるとは読んだが、面倒なのでしない)却下し、いろいろ試した結果、Kateにすることにした。忘れていたのだが、インストール済みだった。

が、KateでなくjEditにした時の記事を読んだら、Kateは「ハングした」とか書いてあったので、やっぱりjEditに戻ろうと思う。ありがたい、これも消していなかったので残っていた。今度は日本語のインライン入力の設定をしてみようか。

  •   0
  •   0

風邪ひいて調子悪いし、台風(今はまだ普通の雨)で外に出るのも億劫だしで、全くのプログラミング日和なのでw、昨日に引き続き、GPMDPの改良に余念がない。いや、余念があるから捗っているのかも知れない。僕の場合、別にプログラムをいじったりしたくはないのだが、音楽を気持よく聴きたくて、いろいろ考えるとできそうだから、仕方なくやっているのだ。

それはともかく、ついにGoogle Play Music (GPM)のプレーヤーGPMDPで音量の正規化ができた。我ながら大変強引な方法だし、いろいろ制限はあるが、とにかくできた。

方法は、基本的には昨日書いたとおりであるが、実際に作ってみると、細かいことがいろいろあったので、その辺りを書いてみる。

見つかった問題点

  1. 曲を再生中に再生ゲインを計算するために曲を取得すると、GPMは同時に1つの機器からしか再生できないので、次の曲の開始時にエラーになって、再生が停まってしまう。
  2. そのエラーダイアログの実装が汚く(まあ、元々がwebなのだから汚いというのは言い過ぎだが)、ブラウザ内のダイアログもどき(昔のワープロのようなもの)なので、xdotoolのようなツールで自動的に閉じるのが難しい。
  3. 曲の再生ゲインの計算が難しい。単純な最大値では聴感に合わない。実効値(どのくらい大きく聴こえるか ≒ 波形がどのくらい太くて黒いか)を求める必要が要る。
  4. GPMDPの音量のステップが段階的なので、細かい再生ゲインが反映されない。
  5. クラシックなどを聴く時のために、音量の正規化機能をon/offできるようにする必要がある。

実際に書き出すと少ないが、結構苦労した。

問題の解決

  1. GPMの同時再生エラーとエラーダイアログの問題
    • エラーダイアログが出たことを検出することすら難しいし、検出して自動で閉じるようにしても、音楽の再生中に勝手にマウスが動くのは鬱陶しい。
    • JavaScriptの機能で、ページ中にあるダイアログを探して、閉じようとしたのだが、なぜか、ダイアログもボタンも見つからず、どうにもならないので、一旦、後回しにした。
    • その後、手を抜きたかったので、曲の再生中でなく、曲間で一時停止して処理するようにしたので、最終的には、問題は起こらなくなった。それでも、処理はすぐに終わる(2秒未満: 下で訂正)ので、気になることは滅多にない。そもそも、正規化はラジオでしか使わないので、曲が間隔なしでつながることはないから、多少曲間が伸びても問題はない。(9/18 14:35 訂正: 実際に測定したら4秒前後だったが、ラジオのせいか、気にならないのは確かである。)
  2. 曲の再生ゲインの計算
    • 最初は最大値を使ったのだが、聴いてみると余り効果がなかった。
    • 値を調べると、多くの場合、最大値は100%近いので、ほとんどの曲で、正規化されていなかった。
    • 平均値を試したが、余りいい結果にならなかった。どういう訳か、平均値は小さいのに大きく聴こえる曲(The Cars "Heartbeat city": どういうことなのだろう??)があったからだ。
    • 処理に使っているffmpegにはloudnormという正規化する機能があるのだが、今のOSに入っている版には入っていないので諦めた。また、曲を正規化してもGPMDPでは再生できないので、余り便利でない。
    • 最終的には、ffmpegのastatsという機能で短時間の実効値(RMS)の最大値を取得することにした。理論的に正しいのか分からないが、聴いた感じでは良さそうだ。実効値を求める期間(時間)の設定が難しいのだが、昔のポップスを聴く限りでは1.75秒がいいようだ(ちなみに、この値は「異邦人」(1979)でチューニングした)。
  3. GPMDPの音量のステップが段階的
    • 今は音量を2.5%ステップにしているので、確かに細かい違いは反映されないが、聴いた感じでは分からない(細かい音量設定よりも、演奏の性質による違いが大きい)ので、今は保留している。
  4.  音量の正規化機能のon/off
    • 設定項目を追加すれば可能だが、いちいち開くのが面倒なので、再生メニュー(曲の右に出るもの)に追加することにした。
    • 追加はできたのだが、「ラベルの翻訳がない」という表示になってしまい、なかなか解決できなかった。
    • プログラム中のHTMLを良く見たら、<span>の属性(is="translation-key")で翻訳したラベルを使う指示をしているようだったので、それを止めるようにした(そんなものすごい機能があるとは、恐ろしい。脆弱性になるような気がするが、考え過ぎか)。
    • また、メニューでon/offするので、メニューのラベルが現在の状態を反映するように、設定変更時にラベルを書き換える(例: Onの場合は「無効にする」、offの場合は「有効にする」と表示する)ようにした(下図参照)。本来は、モードを示すアイコンなどを追加するといいのだが、それも面倒なので、このようにした。

再生メニューに音量正規化機能のトグルを追加

という訳で、随分苦労した気がするのだが、書いたらあっけないものだ。。。 実際には、Googleの検索と、そこから見つかった有用なページを書いてくれた方々に随分お世話になった。もし昔だったら、たった数日で、全く使ったことのない環境やプログラムをこんなにいじることはできなかっただろう。

それから、書く必要すらないことだが、もしWindowsを使っていたら、全く無理だったし、やる気も起こらなかっただろう。あれを使っていたら、どんなに普通のことでもなぜか大変になるから、ソフトウェアの正常な発展には大変な障害だとつくづく思う。

音量正規化の効果はおそらくあると思う(GPMDPの音量はちゃんと変化している: スライダーを表示させたままで見ていると、曲間でスライダーが自動的に動くのがおもしろい)のだが、気のせいかも知れない。上記のように完全ではないので、時々、小さく感じたり、大きく感じたりすることはある。ただ、以前は頻繁に音量を変えていたが、これができてからはほとんど変えていないので、やっぱり、効果はあると思う。

以下に、実装メモを書く。

  • 処理の流れ
    1. 曲が変わったイベントを待つ。 → 再生しようとしている曲情報が来る。
    2. 再生キュー(再生する曲一覧)を取得する。
    3. キューから曲のIDを取得(曲名、アーティスト名で検索)する。上記の曲情報には入っていないため。
    4. 計算済みの最大値が保存されていたら、使う。 → 9へ
    5. gmusicapiの機能を使い、IDよりstream URLを取得する。
    6. wgetにstream URLを指定して、曲を取得する。ただし、もしキャッシュにデータが残っていたら、再利用する。
    7. ffmpegのastatsフィルタでRMS(1.75s)の最大値を求める。
    8. 再利用できるように、いくつかの最大値を保存しておく。
    9. 最大値より、正規化するための音量値(%)を計算し、GPMDPに設定する。
    10. キャッシュ中の古いデータを消す。
    11. 1に戻る。
  • 制限事項
    • 再生ゲインはトラックモードのみ対応 (本質的に、アルバムモードには向かない。気長な人なら別)
    • 当初は、再生中にバックグラウンドで次の曲の処理をする予定だったのだが、暫定的に作ったものが結構うまく動いて、それ以上は面倒だったので、再生前にこれから再生する曲の処理をすることにした。
      • 上にも書いたが、処理は短時間(クラシックのような長い曲を除き、概ね24秒以内)に終わるので、曲間が長く感じることはない。
      • これならシャフルにも対応できるので、却って良かったのかも知れない。
    • 計算した再生ゲインの情報は保存しないので、過去に計算した値が再利用できない。(TODO)
    • GPM自体やwebページの仕様に大きく依存しているので、それらが変わったら、途端に動かなくなる(これはGPMDPも同様)。

 

PS. 前にも書いたが、どういう訳か、僕が聴くGPMのラジオで斉藤由貴の曲が頻繁に掛かる。今日は「悲しみよこんにちは」だ。好きな曲だが、今の彼女はそういう状況なのだろうか? というか、今でも彼女が現役でラジオ番組を持っていたことが驚きだった。

PS2. 本題とは関係ないが、GPMのおかげで分かったことを書く。

Winkの曲だとばかり思っていた「ふりむかないで」は、実はザ・ピーナッツの曲だった! そんな昔の曲にしては、全然違和感がなかったのがすごい。「ほう」と思った。(21:21)

PS3. この作業中に気付いたことがある。アプリをビルドして起動するのが意外に遅いのだ。もちろん何分も掛かる訳ではないのだが、一瞬ではないので、何度も繰り返すと結構イライラする。たかが(と言っては悪いが)JavaScriptなのに、ものすごく大量のモジュールが集まっているからなのだろう。そして、僕のPCが遅く感じたのは、これが初めての気がする。さすがに古くなったのかも知れない。(22:39)

(22:29 音量のスライダーが自動で動く動画を追加; 23:20 若干加筆・修正; 9/19 7:09: 実装メモ中の処理時間の訂正漏れ(4秒が正しい)を修正)

  •   0
  •   0

Google Play Music (以下GPM。実際にはアプリ(GPMDP)またはweb)には、いくつかの不満(改良したい点)があるのだが、いろいろな手段を組み合わせることで、全部ではないが、大分良くなった。以下に、概要を書く。

要改良点

  • 音量の正規化(再生ゲイン)対応 (特にラジオで、曲ごとに音量が大きく変わって不便なので、トラックモードだけでもいい)
  • 音量調整のステップを細かくしたい。今の半分程度に。
  • GPMDP
    • 「この曲が終わったら一時停止する」機能が動かない。
    • 英語での表示
    • マウスジェスチャ対応
    • ミニプレーヤーの改良 (情報量が少ない。使い勝手が悪い)
    • gmusicbrowser(GMB)との統合 (プレーヤーを1個にしたい)
  • リモコンで操作したい。

改良できた点

  • GPMDP
    • 「この曲が終わったら一時停止する」機能が動かない。
      • バグだったようだ。その機能のプログラム(src/renderer/windows/GPMWebView/interface/
        pauseAfter.js)を修正して、正常に動くようになった。
      • 基本的は、以下の修正をした。
        • Emitter.on('pauseAfter:show', ...)の(toast): pauseAfterに設定する値をPAUSE_AFTERからPAUSE_NEXTに変更した。
        • GPM.on('change:track', ...): 再生開始前は停める処理をしないようにした。
        • Emitter.on('pauseAfter:show', ...)のwindow.showToast: 停める設定後に表示されているダイアログ(?)で設定を解除すると、以後うまく動かなくなるので、解除する文字列(リンク)を表示しないようにし、解除はメニューで行うようにした。
      • PAUSE_AFTERは何に使うのか謎だし、手抜きなダイアログの処理には不満があるが、充分実用的だ。
    • 英語での表示 (暫定対応)
      • 以前書いたように、GPMのページのURLに"?hl=en"を追加した。
      • GPMDPの言語設定から自動で指定できるようにしたいが、そうしてもそれほど便利になる訳ではないので、やるなら、動的に変えられるようにしたい。
    • マウスジェスチャ対応
      • Linux用ジェスチャプログラムEasystrokeを使った。
      • これで、GPMDPでもブラウザと同様に、マウスジェスチャでページを移動(戻る・進む)することができるようになった。
      • 更に、Chromeでもジェスチャが使えるようになった(なぜか、右クリックが不便になるアドオンよりもずっといい)。
    • 音量調整のステップを細かく (9/16 11:48追記)
      • GPMDPが読んでいるGPMのページをVivaldiの開発者ツールで調べたところ、ページ内に音量調整用のスライダーの要素(id="material-vslider")があり、そこでステップが5に指定されており(下の例を参照)、その値を変更すれば、そのステップで動くことが分かった。
        • <paper-slider id="material-vslider" ... step="5" ...>
      • GPMDPの起動時にスライダーの要素を検索し、ステップを変更するようにした(下の例を参照)。
        • 要素の検索: slider= document.getElementById("material-vslider");
        • ステップの変更: slider.setAttribute("step", 新ステップ);
      • 新しいステップは2.5にした(整数でなくてもいいようだ)。
      • この方法は、GPMのページの作りが変わってしまったら駄目になってしまうが、その時はまた対応しよう。
      • また、この機能の有効/無効切り替えを、簡易に設定に追加した。

残りの実現に向けて

  • [済] 音量の正規化(再生ゲイン)対応
    • 基本的に難しいが、以下のような処理が可能かと思っている。この方式だとトラックのゲインにしか対応できないが、ラジオには充分である。
      1. 今の曲を再生中に次の曲のデータを取得して、再生ゲイン(≒最大の音量)を計算する。
      2. 計算した再生ゲインで再生音量を変える。(再生部を改造できない場合は、LinuxのGPMDPの再生音量を変える)。
    • 9/17に対応できた。(9/17 19:06)
  • [済] 音量調整のステップを細かく
    • GPMDPのソースを見て試行錯誤したところ、GPM(のweb部品?)では5%の倍数の音量しか受け付けないようだった。
    • それで、GPMDP自体の音量(LinuxのGPMDPの音量)を変えることを検討している。
    • この場合、新たな音量調整用のUIを追加する必要があるのが、面倒。
      • 元の音量調整機能を使い、GPMDP自体は5%ステップだが、LinuxのGPMDPの音量をうまく増減する(例:GPMDPで5%上げたらLinuxでは2.5%減らし、全体としては2.5%の増加とする)ことで、ステップが細かくできる気もする。が、表示と実際が乖離しそうな気もする。
    • 上記のように、簡易に対応した。(9/16 11:48)
  •  ミニプレーヤーの改良
    • 以下をやりたいが、ミニプレーヤーはGPMの部品のようなので、できるかは不明。
      • 曲名などを常に表示したい。ただし、再生制御は不要。(GMB同様にする)
      • キューを開けるようにしたい。あるいは、簡単に本体を開けるようにしたい。
      • 閉じて再度開くと位置が下がるのを直す。
  • リモコンでの操作
    • GPMDPでは、各種API(JSON, Web socket)やMPRISを使うことを考えている。
    • GMBもリモコンを使うので、切り替えを煩雑にせずに(可能なら切り替えなしで)併用できるようにしたい。そのため、実際に使うパターン(ユースケース)の検討が要りそうだ。
  •  GMBとの統合
    • 以下を検討しているが、必要(メリット)があるのか、良く考えたい。全体的なユースケースの検討が要りそうだ。
      1. ダミーの曲ファイルに曲やプレイリストのIDを入れておく。
      2. そこからGPMの曲の再生URLを取得して、GMB (→ GStreamer)で再生する。
    • GMBからGPMDPを制御できるようにするだけでも、いいかも知れない。

GPMDPはソースが公開されていて変更が可能なので、web版と比べて優位になった。

「この曲が終わったら停める」機能が動かない問題は、単純な間違いなのか、もっと奥深い問題があるのかは分からないが、とりあえず、うまく動いている。「こうやって直した」とGPMDPのフォーラムに投稿するといいと思うが、以前、別のフォーラムに投稿して情報を出したのに結局無視されたことが何度もあるし、この問題も以前に指摘されたのだが、なぜか"closed"(解決済み)になっているので、今は投稿する気が起こらない(もし欲しい方がいらっしゃったら、ここで公開します。ただし、その場合、公開するのは変更したソースコードだけですので、使うには開発環境(npm)が要ります)。

 

余談

GPMDPの言語はJavaScript(Node.js)なのだが、昔はブラウザで動くおまけみたいな言語だと思っていたのに、いつの間にあんなに発達したのかと驚く。最初から、あんなにまともなオブジェクト指向だったのだろうか? しかも、画面表示と関係のない処理すらやっているのは不思議だ(PHPも同様だが)。まるで、小さいガキだった親戚を久し振りに見たら、立派な大人になっていたかのようだ。

JavaScriptも馴染みがないが、Pythonより10倍くらい使いやすい気がする。

 

PS. GPMでいろいろな曲を聴いていると、結構、マスタリングが駄目な曲がある。例えば、途中で途切れてしまったり、曲間に「ザッ」という雑音が出るものがある。あと、ダイジェスト版のように短縮された曲もあった。膨大な曲数なので、たまに壊れていたり、おかしかったりするのだろう。まあ、買う前に分かるので、ありがたい。でも、それを指摘する簡単な手段がないのは、どうかと思う。まあ、Googleらしいが。

 

(9/16 11:48 音量調整のステップを小さくできたので、追記; 9/17 17:39 昨日の追記の日付が間違っていたので修正)

  •   0
  •   0

近頃見つけた豆知識やら小技を(検索してもすぐには分からなかったので、誰かの役に立つかもしれないから書く)。統一感がないが、あまり分量がないのでまとめて書く。なお、以下はUbuntu系で確認したことで、他のディストーションでも可能かは不明。

1. Linux on MacBookのトラックパッドでの右クリック

近頃、(Intel CPUの)MacにはLinuxを「普通に」インストールできることを知った。LinuxがわざわざMacに対応している(できる)とも思えないから、Macの中身はWindows PCと同じなのだろうか? あの、先進的で美しく、非の打ち所のないアポー先輩が、まさかそんなことするのか? ふーんw

まあ、それはどうでもいいが、インストールして使ってみると、トラックパッドの右下端を押しても右クリックにならなくて、がっかりした。検索すると、「2本指でクリックすればいい」と出て、実際にできたのだが、すごく不便だしスマートでないので、なんかやる気をそがれる。でも、

できまーす!

丹念に調べたら、設定すれば、トラックパッドの右下端を押して右クリックにすることが可能なことが分かった。

ポイントは、synclientというプログラム(Synapticsドライバのユーティリティー)である。「(仮想的な)右クリック」と判定する領域(のトラックパッド中での上左端と下右端の座標)を、synclientの以下の引数に指定して起動すればOK。

  • RightButtonAreaLeft:仮想右クリックの上左端のX座標 (X1)
  • RightButtonAreaTop: 同上左端のY座標 (Y1)
  • RightButtonAreaRight: 同下右端のX座標 (X2)
  • RightButtonAreaBottom: 同下右端のY座標 (Y2)

実行の書式:

synclient RightButtonAreaLeft=X1 \
RightButtonAreaTop=Y1 RightButtonAreaRight=X2 \
RightButtonAreaBottom=Y2

なお、トラックパッドの大きさ(座標)は/var/log/Xorg.0.logに記録されているので、そこから適宜、右クリックに使う領域を計算して指定する(例: 右端・下端から10%)。

注意事項は、Y座標が(通常の想定とは)上下逆(数値が小さい方が上だったか)なことである。うまく行かない場合は、上下逆に考えること。

上記は設定ファイルに書くことも可能のようで、そこでは割合(%)で指定できるので綺麗だが、試していない。

参考: Synaptics タッチパッド (ArchWiki) : まったく、ArchLinuxのドキュメントはとても有能だ。いつもお世話になっている。

PS. トラックパッドについては、上記の他に、(普通のノートPCのように)右端や下端で上下・左右スクロールできるようにも設定できるので、そこは結構便利だと思う。

2.Linux on MacBookのディスプレイのバックライトの輝度の保存と復旧

Linuxをインストールしたままでは、バックライトの輝度が起動のたびに最大になってしまってまぶしく、げんなりする。そこで、検索したら、輝度の値がファイルに入っているので、システムの終了前にそれを保存し、起動後に復旧させれば良いことが分かった(grubに指定する方法もあったが、うまく行かなかった)。

実際のファイルは、/sys/class/backlightにいくつかのディレクトリがあり(ディスプレイデバイスごとにあるようだ)、それぞれの下のbrightnessである。

cat /sys/class/backlight/DEV/brightness など(DEVはデバイスの名前)で輝度が取得でき(例: 128)、

echo X > /sys/class/backlight/DEV/brightness などで輝度を設定できる(Xは設定する輝度)。

実際には、保存と復旧スクリプト(例: mb-backlight)を作り、systemctlで有効化する。スクリプトは、引数が"stop"の時(終了時に呼ばれる)に輝度をどこかのファイルに保存し、"start"の時(起動時に呼ばれる)に保存しておいた輝度を設定するようにする。

注意事項は、値を保存する場所に/var/runを使うと、ここはRAMディスクのようで、終了時になくなってしまうので、別の場所を指定する必要があることだ。

PS. 普段使ってないので試していないが、キーボードのライトも同様にできるはずだ。

余談: MacBookでのLinux、それなりに動くのだが、なぜか変なキーが入ってしまうことがあるなど今一つなところがあり、そもそも本体がずっしりと重いこともあって、使い続けたいかというと「うーん・・・」だ。でも、もしMacBook(のハード)を使うことを強制されたら、僕にはmacOSより(もちろん、Windowsよりも)ずっといい。

3. LinuxでDropboxにサインインできない(「アプリが古い」?)

Dropboxアプリにサインインしようとした時、何度やっても、「アプリが古い」とか言われて失敗するので、近頃Dropboxが(勝手に)仕様を変えてしまって、まだLinuxが対応できていないのかと諦めていたのだが、しつこく検索したら原因と対処が分かった(→ [SOLVED] Dropbox can't 'sign-in' or install newer version.)。

本当にLinuxのアプリが古いので、~/.dropbox-dist を削除して、再実行すればいい。

まったく拍子抜けした。

これだったら、古いファイル名を表示するとか、「更新しますか?」とか聞いてくれてもいいと思うのだが・・・

  •   0
  •   0

ある夜、ふとPCの状態表示画面を見ると、あるHDD(新HGST)の温度が高くなっていた。高々2℃程度ではあるが、ずっと下がらず、原因も分からないので、気持ちが悪かった。原因として考えられたのは、以下である。

  1. たまたま気温(室温)が高かった。
  2. そのHDDに頻繁なアクセスが行われていた。
  3. そのHDDの内部で処理が行われていた。
  4. 冷却ファンの調子が悪い。

室温が高かったのなら、他のHDDやSSDの温度も上がるはずなので考えにくいし、アクセスや内部処理にしても、ちょっと調べた感じでは、特に何も行われていなかった。ファンについても、回転数は下がっていなかった。

それで、室温とPC内部の温度は違うのではないかと思い、HDD温度と同時に内部温度を測りたくなって、Amazonを調べたら、おもしろそうなUSB温度計があった。Linuxでも(純正ドライバではないが)使えるもので、約800円または約1600円だった。

「あと少しで注文」というところで、ふと思い付いた。「マザーボードの温度は、室温に同期(室温+α(=マザーボードの固定的な発熱))しているのではないか?」と。そうであれば、温度計を使わなくても、室温の推定ができる。実際、マザーボードの温度は、この時期は約32-34℃でほとんど変わらないので、室温に同期している可能性が高い。

そして更に思い付いた。ケースファンはマザーボードの温度で回転数制御しているのだが、マザーボードの温度がほとんど変わらないから、回転数も変わらず、制御している意味がない。それで、その回転数制御機能をHDDファンの回転数制御に使えないものだろうかと。

ただ、(以前も書いたように、)HDDの温度は外部ハードウェア(センサ)で取得できない(HDDのSMARTという仕組みで取得する)ので、回転数制御チップ(SuperIO)に入力されていないので、SuperIOの自動制御機能は使えない。ただ、手動(=プログラム)でファンに入れる電圧(またはパルス幅)を変えて回転数を設定することはできるので、HDDの温度に応じて回転数を制御するプログラムを作れば、HDDファンの回転数制御も可能だ。

おもしろそうだったので、早速作ってみた。最初の版は、昨日の夕方に30分くらいでできて、それなりに動いた。処理内容は以下のとおりである。

  1. 各HDDの温度を求める。: hddtempコマンドを使った。
  2. 最高の温度を求める。
  3. それに応じたファン回転数設定値(0-255)をファンの回転数制御レジスタに書き込む。: SuperIO(NCT6775)の"Smart Fan IV mode"同様の単純な比例計算にした。
  4. 次の処理時刻まで待つ(約30秒)。
  5. 1に戻る。

なお、元々HDDファンを接続していた端子は回転数(出力電圧)を設定(変更)できないので、ケースファンの端子と入れ替えた。また、今までは、HDDファンの騒音を減らすため、回転数を下げるために抵抗を介して接続していたが、今度はソフトで回転数が変更できるので、直結にした。代わりに、ケースファンの回転数が丁度良く(約900rpm)なるように、抵抗(100Ω)を使用した。

例によって、それからが長かった。結局、今日丸一日、調整や改良に費やした。改良の内容は以下のとおりである。

  • 回転数設定値の変化が少ない時は、更新しない。: ファン回転数の精度が良くなく、同じ設定値で30rpm程度上下し続けるため、頻繁に変更しても意味がない。
  • HDD温度が設定以下なら、ファンを停める。 : 静音化のため。
  • HDD温度が設定以上なら、通常より回転数を高くする。: 冷却が間に合わずに過熱することを避けるため。
  • HDD温度を移動平均する。 : HDD温度は一時的に微妙に上下することがあるので、その影響を避けるため。また、1℃単位でしか取得できないHDD温度を、もう少し細かく(小数点以下の値を出す)扱いたかったため。
  • HDD温度で直接制御するのでなく、HDD温度とマザーボード温度との差で制御するようにした。: 本来のHDDの発熱量は室温からの増分だから、室温を無視して回転数を設定しても、無意味だと考えたため。上述のとおり、マザーボード温度は室温と同期している(マザーボード温度= 室温+約5℃)と考えられるので、HDD温度とマザーボード温度との差を使うことにした。 → 失敗だった。詳細を追記する。(7/19 20:17)
  • 上の制御をしている時、(マザーボード温度との差でなく)HDDの絶対的な温度が設定値以上になったら、通常より回転数を高くする。 : システム負荷や気温が高くてマザーボードが熱くなった時に、HDDの過熱を防ぐため。→ 上が失敗だったので、取りやめた。(7/19 20:17)
  • マザーボード温度も移動平均する。
  • 想定しているマザーボードでない場合にエラーで終了する。: 忘れて別のPCに移してしまった場合の対処。

改良の結果、プログラム(スクリプト)の行数は4倍近くに膨れ上がったが、今のところ、うまく動いている。一番熱い新HGSTの温度(の青)は、概ね37-38℃に保たれている。CPU負荷が大きい時(の右の、オレンジと緑が山になっている部分)でも、マザーボード温度(の一番下の青)が上昇することはなかった。そのため、HDDファンの回転数(の一番上の緑)もほとんど変わっていない(中の急な山や谷は、プログラムの修正中の一時的なもの)。

ただ、暑く感じる時でもマザーボード温度がほとんど変動しないのが気になる。体感的な問題か、エアコンのせいだろうか? 論理的に考えれば、ペルチェ素子や水冷などの吸熱機構なしで、物の温度が(周囲の温度から独立して)一定に保たれることはあり得ないので、 室温に同期しているのは確かで、部屋に居る(=PCを動かしている)時はエアコンを動かしているので、室温はそれほど変動していない(せいぜい±1℃程度)が、体感温度が変動していると考えるしかない。ちょっと長期的に見てみたい。

(7/19 20:38追記) HDD温度と(室温と並行に変化する)マザーボード温度との差でファン回転数を制御する効果を調べるため、日中にPCを動かし続け、その間のHDDやマザーボードの温度やファン回転数の変化を調べた。

なお、室温も記録しようと、スマフォ(Nexus 4)のタイムラプス撮影用アプリ(EasyLapse)で15分おきに温度計を撮影していたのだが、大変期待外れなものだった。撮影開始の1時間後にスマフォがスリープしてしまっていて、たった4枚しか撮影されていなかったので、すごくがっかりした。また、撮影した画像は動画にするしかなく、動画に変換すると、「撮影したデータ」(静止画と思われる)が削除されてしまうし、「データ」を取り出す機能もないので、全く役立たずだった。このような用途には、「インターバル撮影」で検索した方が良かったようだ。

その結果、HDD温度とマザーボード温度も並行に変化しており、日中、室温がかなり高くなり、帰宅時に約30℃になっていたにも関わらず、ファンの回転数がほとんど上がっておらず、HDD温度は40℃まで上がっていた。

この原因を考えると、確かにHDD自体の発熱は室温との差なのだが、HDD温度もマザーボードと同様に、室温と並行に遷移するため、差は常にほぼ一定になるので、その差でファンの回転数を制御しても、ほとんど回転数が変化しないのである。

ちなみに、最高温度は、室温: 30℃(推定)、マザーボード: 35℃、HDD: 40℃だった。マザーボードとHDDの温度のグラフの形状は似ているので、それぞれは約5℃の差で並行に遷移するようだ(HDDがアイドル時)。

だから、やはり、絶対的なHDDの温度でファンの回転数を制御することに意味があるのだろう。そして、いくら室温が高くても(HDDの温度より低ければ)、風を当てればHDDは冷えるのだ。

マザーボード温度は、室温の推定には使えるが、冷却の制御には使えないようだ。名案だと思ったが、残念だ。

(7/22 7:12 グラフを追加)

(7/22 7:07追記) その後、回転数制御に絶対的なHDDの温度を使う方法に戻し、設定を調整して、再度、PCに苦行をさせてみたw 昨日の朝から夕方まで、冷房を停めた室内でPCを起動したままにして、その間の外気温・室温(注)、HDD温度、マザーボード温度、ファン回転数を記録した。以下に結果を示す。

測定終了時(19時頃)の状況(気温・室温以外は、その日の最大値だった):

  • 外気温
    • 今回: 30.0℃
    • 前回: 27.4℃
  • 室温
    • 今回: 32.8℃
    • 前回: 30.7℃
  • HDD(新HGST)の温度
    • 今回: 41.0℃ (室温+8.2℃)
    • 前回: 40.0℃(室温+9.3℃)
  • マザーボードの温度
    • 今回: 36.0℃ (室温+3.2℃)
    • 前回: 35.0℃ (室温+4.3℃)
  • HDDファンの回転数
    • 今回: 1216 rpm (通常時: 約1050rpm)
    • 前回: 1036 rpm (通常時: 約1050rpm)

今回は、期待どおり、HDD温度に合わせてファンの回転数が変化した(約100rpm/3℃)。ファンの回転数がほとんど変化しなかった前回と比べて、以下のようなことが分かった。

  • HDDの室温からの増分は、前回より1℃しか低くなかった。→ まだファンが遅い? 室温が高くて冷えない? HDDの熱容量は大きいので、1℃でも効果があったと考えられる?
  • マザーボード温度の増分も、前回より約1℃低かった。HDDファンが速くなった効果?

結論としては、期待ほどではなかったが、それなりにファン回転数制御の効果が見られたので、しばらく使ってみることにした。なお、ファンの回転数は約200rpmの余裕があり、まだ高速化することも可能だが、効果は疑問だし、その分うるさくなるので、更に高温になった場合に備えることにする。

注: 外気温と室温は、「beeCam Easy連写」というインターバル撮影アプリで温度計を撮影していたのだが、間抜けなことに、ACアダプタの電源を入れ忘れていて、約4時間でスマフォ(Nexus 4)が落ちてしまって、失敗した。また、このアプリも画像を外部に取リ出せないので、期待外れだった。次回(やるとしたら)は別のを使おう。どうも、名前に"Easy"と付いているのは良くない気がする。

 

PS.アイデアが浮かんで、プログラムを作って、更にアイデアが浮かんで来て、それを実現していくのはおもしろかったのだが、この制御の仕組みは今のマザーボード(ASUS P8H67-V)に大きく依存しているので、もしPCを新しくしたら、このプログラムはまず使えない。少なくとも、同じメーカーでないと無理だろう。その点が、ちょっともったいない気がする。でも、考え方は転用できるし、おもしろかったから良しとしよう。

そういう意味では、今のPCのハードとLinuxは、さまざまなカスタマイズをしてしまっていて、新しいPCに移転させるのは、ものすごく手間が掛かる気がする。カスタマイズした自分ですら、(記録はあるけど)何をどうしたか思い出せないので、同じことをやれる自信はないし、する気分にもならない。まあ、バックアップはあるし、まだ壊れていないので、その時に考えたい。

(7/18 6:24 加筆・修正)

  •   0
  •   0

近頃は暇なことが多いので、自分の興味のあることができる。今週は、Linuxのプログラム(正確にはスクリプト)の改良をしたのだが、かなり劇的に改善できたので、悦に入っている。

そのスクリプトは、使っているディスプレイ(2台のうちの1台)の欠点を補うために必要になって、少し前に作ったものだ。スクリプトと言っても、実際には、Actionaという、X Window System(以下、X11)の処理を自動化する(例: ボタンを押す)プログラムで動かすプログラムである。

問題のディスプレイは、電源を切ったり省電力モードになった後に復帰すると、一瞬、PCとの接続を切ってしまうようなのだ(普通のディスプレイは、本当にPCとの接続ケーブルを外さない限り、そんなことにはならない。だから、そのディスプレイは腐っている)。そのため、Linuxは新しくディスプレイが接続されたと思って、そのディスプレイをどうするかというダイアログを、もう片方のディスプレイに出してしまう。そのダイアログの中のボタンを押してどうするか指定しない限り、問題のディスプレイには何も表示されない。

毎回それだったら、さすがにそんなディスプレイは捨てたくなるので、上記のActionaを使って、ディスプレイの再接続後にダイアログが出たことを検出して、そのボタンを自動的に押すようにした。

概ねうまく動いていたのだが、タイミングが悪いとうまく働かなかったり、スリープからの復帰に対応していないなどの問題があったので、直しながら使っていた。が、段々、Actionaの使い難さに嫌気が差して来た。プログラムといっても、BASIC程度のもので、制御構造が貧弱(基本的にGOTOしかない)なので、見やすいプログラムが書けず、保守性が悪いので、ちょっと直そうとするだけで、さまざまな落とし穴に落ちる。大幅な変更はかなり苦労する。

それで、何とかしてActionaを使わないで済ませられないか考えた。まずは、プログラムを見やすくするために、シェル・スクリプトにすることにした(というか、他に手軽な選択肢はほとんどない)。そして、幸い、ダイアログを探したりボタンを押したりする処理は、別の自動化プログラムxdotoolでできることが分かった。それで、今週の中頃に作ってみたら、うまく行った。

が、前から思っていたのだが、短時間(数秒間)でもダイアログが出て、スクリプトがそれを消すまでは自分が操作できないのが嫌だったし、Windowsじゃあるまいし、ダイアログのボタンを押すしか方法がないってのも馬鹿らしいと思い始め、ダイアログを使わないで済ませる方法を探したら、xrandrというディスプレイの設定のためのコマンドが見つかった。それを使う方法は、Actionaを使う前に検索して知っていたのだが、その時はどうもピンと来なかったので、使わなかったのだ。ちなみに、このコマンドは新しいようで、昔のX11にはなかった。そのために、すぐに思い浮かばなかったということもある(あと、その名前は何から来ているのか、謎だ)。

それで、今週の後半にxrandrを使ってプログラムを作り直した。更に、ダイアログを出さない方法(Linuxのデスクトップ環境の設定だった)も見つけたので、ダイアログを見つけて閉じる処理も不要になり(そのため、xdotoolも不要になった)、結局、最初とは全く異なる、すごくシンプルなプログラムになった。省電力モードなどからの復帰時にダイアログは出なくなり、一瞬で問題のディスプレイが使えるようになった。

ソフトは作る時(正確には動き出した時)はおもしろいけど、こうして、思わぬ展開でうまく(ドラスティックに?)改良できた時も、かなりおもしろい。

PS. ちょっと気に入らないのは、Windowsの時は、同じディスプレイが何も問題なく使えていたことだ。Windowsはディスプレイの状態や設定をうまく記憶しているのかも知れない(単に、何もしてないだけかも知れない)。Linuxにだってそういう機能があってしかるべきだが、今は分からない。もし見つかれば、作ったスクリプトが不要になる。新たに作る・動かすプログラムは少ない方がいい(プログラムなんて、作らないに越したことはない)から、例えそれまでの作業が無駄になったとしたって、それが理想の状態だから、作ったものを捨てるのは全く惜しくない。そして、そういう工夫もおもしろい。

  •   0
  •   1

先日、JACK(Linuxのサウンドシステムの一つ)のプラグインのPEQ(パラメトリック・イコライザ, 実際にはCalf Studio Gearの12バンドイコライザ、以下"EQ12")をなるべく少なく使って補正ができないものかと思った。何度もいじるのは面倒ではあったのだが、興味はあるのでちょこちょこ試してみたら、できそうな気がしたので、さっき本格的に測定・調整した。そうしたら、予想外にいい結果が得られた。何かの間違いではないかと思うほどだ。

鍵は、EQ12の"Lowshelf"というフィルタを使ってみたことだ。これは、指定した周波数以下を一定量増減できるフィルタである(下図左側の階段状の部分)。今使っているグライコ(DEQ2496)では、ある範囲の中低域を平坦に下げているので、それを代用できそうな気がしたのだ。ただ、実際には下限までずっと下げている訳ではないので、Lowshelfだと超低域のレベルが減少するおそれがあった。それでも、試しに設定してみた。

更に、もう一つの挑戦として、ある程度の差は許容して、PEQの数を極限まで減らして、音の劣化を減らそうとした。というのは、DEQ2496でPEQを多用すると音が悪くなった(耳が詰まる感じ)からである。この時は時間がないのとマイクを設置するのが面倒なので、音をマイクから取らず、ライン出力と入力を直結して特性を測り、DEQ2496のものに近づくようにした。結局、LowshelfとPEQ 1個(右、86Hz)だけで実現できたのだが、どうも信じられなかった。ただ、聴いた感じでは大きな問題はなかった。

試しに作った最小構成のPEQ

そしてさっき、細かく測定・調整したのだが、驚くほどすんなり完成してしまった。10回未満の調整で問題ない特性になり、それをDEQ2496と比較したら、(55Hz付近の谷の深さを除いて)ほとんど差がなかった。55Hzの深さの違いは、Lowshelfで一律に落とした影響だろう。

DEQ2496と比較 (灰: DEQ2496-LR; 黒: PEQ-LR; 青: PEQ-L; 赤: PEQ-R)

意外だったのは、直結して測った特性(イコライザ自体の特性)には差があったことだ(まあ、Lowshelfとグライコで設定した特性は違うのだから、当然ではあるが)。

直結して測った特性の比較 (水色: DEQ-L; オレンジ: DEQ-R; 青: PEQ-L; 赤: PEQ-R)

結局、測定して得られた特性を見てグライコで細かく調整して「補正」しようとしても無駄な、「手強い」領域(部屋の特性のせいか、音量を下げても下がらず、上げても上がらない)があるようだ。

なお、最終的にPEQは2個しか使っていないので、使うイコライザを12バンドから5バンドのもの(EQ5)に換え(設定値を移植した)て、更にシンプルになった。こんなにシンプルなら、音の劣化(フィルタによる位相の変化や歪みの増加が関係しているのではないか)が少ないことが期待できる。

作ったPEQの設定を5バンドイコライザに移植

ただ、聴いた感じだと、DEQ2496とは少し違う気がする(PEQ特有の、耳が詰まる感じが少しある)が、今朝からずっと(DEQ2496に戻しても)そうなので、今日は耳の調子が悪いのかも知れない。しばらく試してみたいと思う。

前にも書いたが、今のスピーカーの設置場所(出窓)の特性が意外に素直(低域が少し強いだけ)なことに驚く(実際には、下げても下がらない箇所は共鳴しているのだろうから、「素直」とは言えない気もする)。これなら、グライコじゃなくても、普通のトーンコントロール(しかもバスのみ)でも代用できそうなくらいだ。今までの、細かい調整の苦労は何だったのかとすら思える。

それから、DEQ2496のPEQでもLowshelfフィルタに近いものが実現できそうなので、あとで試してみたい。

そして、ソフトでの処理だと、さまざまな種類の仮想的なエフェクタを気軽に「取っ替え引っ替え」でき(ダウンロードすれば、いくらでも追加できる)、それらの接続も自由に変えられ、調整も楽で設定の保存も容易で、すごく便利なので、DACを買う気が盛り返しそうな気配がする。が、実際には、DACを新たに買わなくたって、DEQ2496の内蔵のを使えばいいのだ。だから、ソフトでプロトタイプを作って効果を検証し、可能なものはDEQ2496に移植するのが良さそうだ。それが一番安価で安定だ。

難なくDEQ2496に移植できた。PEQにLowshelfモードがあるようだ。そして、直結での測定結果はほとんど同じ特性になった。プロ用機材に共通の機能・仕様(この場合、イコライザのカーブ)は結構あるのかも知れない。

グライコ(DEQ2496)に移植 (水色: ソフト-L; オレンジ:ソフト-R; 青: DEQ2496-L; 赤:DEQ2496-R)

ちょっと聴いた感じもいいので、しばらくこれで試す。(23:37)

今思い付いたのだが、ソフトのイコライザで55Hzが少し深くなっている件を解消するには、Lowshelfでなく、幅広いPEQ(中心が150Hz付近)を使えば何とかなりそうだ。あとで試そう。(5/20 0時)

今回は細かい調整に苦労したが、できた。使用したPEQは、左が1個(200Hz)、右が2個(79.6, 200Hz)と少なく、補正量も5dB前後だが、特性は以前とほぼ同じにできた。上で気に入らなかった55Hzは、もちろん問題ない。

上段(L+R): 緑: 今回(PEQのみ); 灰: オリジナル(GEQ+PEQ); 中段(L, R): 青: L; 赤: R; 下段(直結(=補正量)): 青: L; 赤: R

150Hz付近の山を調整しなかったので少し大きくなっているが、+4dB程度で自分の許容範囲内なので、PEQを増やすよりは良い思ってそのままにした。聴いた感じは全く問題なく、耳が詰まる感じもない。ソフトと本物のイコライザでは、微妙な特性の違いがあるのかも知れない。「本物」といっても、内部はDSPで、やっぱりプログラムでできているのだが。

余談: 実は、この前に作った設定は、例の440Hzの山を調整しなかったせいか、ピアノの特定の音(モーツァルト ピアノ協奏曲 第18番 第1楽章の始め)が強く聞こえたので、PEQの位置や強さを修正した。

なお、補正量はオリジナル(GEQ+PEQ)とは概形は似ているものの、細かいところは結構違う。補正が効かない・無意味な領域が多いようだ。

補正量の比較 (水色: オリジナル-L; 青: 今回-L; ピンク: オリジナル-R; 赤: 今回-R)

という訳で、まさに「悟りの境地」とでも言うようなシンプルの極みに達し、イコライザの断舎離ができた。しかも、何も買わずw、ソフトも変えずに済んだ。補正量のグラフなんてすごくすっきりしたから、(聴いても分からないけど)音質も良くなったのではないだろうか? 最終的には、DEQ2496の機能の1/10くらいしか使っていない(GEQなんて全然使ってない)が、あれをここまでしゃぶりつくした人も少ないのではないだろうか。

それにしても惜しいのは、部屋の構造によってできていると思われる、60Hzと600Hzの谷だ。どうにかして解消できないものかと、つくづく思う。(5/20 10:42)

 

PS. 測定に使った、マザーボードのサウンドインタフェース(Realtek)は、意外に特性がいい。というのは、間違ってイコライザを入れずに直結して測定したら、約20Hzから15kHzで平坦だったのだ(もちろん、特に入力がそうでなかったら、ここまでの測定や調整は全部無意味になる)。

オンボードのサウンドインタフェース(Realtek)の特性

入出力のアナログ回路が、それなりにちゃんと作られていることが分かる。もちろん、専用の機器に比べてノイズや歪は多いのだろうが、普通にスピーカーで聴くのには充分なんじゃないかと思った。たぶん、屋外で聴く数十万円のポータブルDAC+アンプなんかよりはずっといいだろうw まったくASUS(ボードのメーカー)は侮れないな。(5/20 10:43)

PS2. その後、問題の60Hzの谷を解消・改善できないか検討したのだが、無理そうな感じだ。まず、原因が分からない。部屋を引き戸で半分に仕切ってもほとんど変化がなかったので、縦方向ではないようだ。また、横にあるクローゼットの扉を開閉しても変化がないので、横方向でもない。

だから、おそらく上下方向の定在波だと思う。シミュレーションすると、スピーカーの位置や聴く場所を変えればいいことは分かるのだが、いい場所がない。上下に動かすにしても、50cmから1mくらい動かさないと変化がなさそうだが、そんなに動かすのは無理だ。

だから、打つ手はない。ただ、いくつかいいことに気付いた。どういう訳か、左右で谷になる周波数が10Hz近く違うので、60Hzの音が完全に出なくなる訳ではなく、その付近では片チャネルは何とか出ているのだろう(谷の重なる58Hzが最悪なポイントだ)。そして、低音は方向感が鈍いので、不自然には聞こえないのではないのではないか。

また、谷はシャープだが、最悪なポイントがピンポイントで一つの音になっているのではなく、ある程度の幅で音になっているはずだし(ここによれば、12音音階では、60Hz付近の音は約3Hz刻みのようだ)、楽器には倍音成分もあるから、その音が弱くはなるが、完全に聞こえなくなる訳ではないのではないかと推測する。

そもそも、60Hzの音を聞いてみると、すごく低くて単体では使われそうもない音のような気がするから、実害はなさそうであるw

一方、場所が変わって500-700Hzの広い谷は、ピアノの鍵盤でいうと51(シ)-57(ファ)番、真ん中辺りのよく使われる場所で、影響のある音の数も多く、実害がありそうなので、何とかしたくなってきた。(5/21 14:29)

  •   0
  •   1

先日、どうしてもスリープ(サスペンド)後の復帰がうまくできなくて、諦めた(と書いた)JACK(Linuxのサウンドシステムの一つ)だが、実はしつこく継続していた。暇なのと、興味があったのと、(理論的には)できないはずはないと確信していたのと、PC(Linux)ごときに降参するのが嫌だったのである。

厭きずに検索していたら、2つほど有効そうな情報が書かれたページが見つかり、そのうち1つがビンゴだった。

僕の問題は、長時間のスリープ後の復帰時に、JACKのサーバとクライアント(例: 制御プログラム、音楽プレーヤー、イコライザ)との接続が切れてしまって回復せず、音が出なくなるということだった。上のページは、それを解決する策を(僕の期待とは違っていたが)実に簡潔に(基本部分はたった2行で)示していた。

ポイントは、スリープ前にJACK制御プログラム(qjackctl)経由でJACKのサーバを停め、復帰時にqjackctl経由で開始することだ。(おそらく、復帰時に停めて再開させるのでも充分だろう)。

試したところ、復帰後もJACKで再生できるようになった。が、それでも完全ではなく、以下のような問題があった。

  • サーバを停めるせいか、JACKのクライアントからサーバへの接続は自動的には再開しないことがほとんどなので、駄目なクライアント(例: イコライザ)を再起動するなどの処理が要る。
    • これに関連して、gmusicbrowser(GMB)がスリープ時にエラーダイアログを出すのが鬱陶しい(それでも再生はできるようだ)。
  • 同様に、JACK関連の設定(例: alsa_outによるJACKからALSAへの転送)も消えてしまうので、再設定が要る。

それで、スリープ時と復帰時に必要な処理を追加して、復帰後にもうまく再生できるようになった。ただし、GMBは余り再起動したくなく、すぐにエラーダイアログを消すこともできないから、ひとまずPulseAudioに音を出す設定にし、JACKに転送するようにした。正式に使う時は対処が要る(ただ、PulseAudio経由での問題は音が出るまでの遅延が大きくなる程度だし、聴いてみて音質の劣化は感じられないので、そのままでも大丈夫そうな気がする)。

対処したところ、以前あったいろいろな問題(例: 復帰後に接続(パッチベイの結線)が回復しない)も解決した。

ただ、個人的には、サーバへの接続なんて自動的に回復すべきだと思っているから、この対処は気に入らない。それで、qjackctlやJACKサーバの設定を調べたが、関係するものはなかった。おそらく、クライアントの設定の問題なのだろうが、すべてのクライアントの設定なりプログラムを直すのは無理だから、仕方ないのだろう。

晴れてJACKが使える(=ソフトでグライコを実現できる)ようになり、今日までの数日間、グライコの代わりの外付けDAC(それもPC内に入れたいと思っていた)は何を買おうか迷ったのだが、結局、買わないことにした。というのは、そもそも、DACを内蔵した本物のグライコ(DEQ2496)がちゃんと動いていて、音にだって満足しているのに、わざわざ別の物に替える必要がないからだ。新しい物を買うのは楽しいが、やっぱり、手段を目的にするのは良くないと思う(それでも、買いたい気分が-90dBくらい残ってそうだw)。

あと、今の低価格DACは中国や台湾のものがほとんどで、確かに性能も外見も悪くない感じではあるのだが、紹介の文章が胡散臭い(→ : 性能を向上させたと書いている割には仕様をどこにも記載しておらず、最も重要な電源(本人もその重要性を力説している)を添付も別売りもしておらず、なぜかブログで、おまけにケバい!)し、(アンプの話ではあるが)危ういトラブルが結構あるし、中の配線がしょぼかったりするのも、(60dBくらい)買う気をそいだ原因だ。今はUSB接続のみの物がほとんどになってしまい、光接続対応のものの選択肢が少ないのは残念だ。

余談: 「昔処分してしまった小さいDAC(Styleaudio CARAT-TOPAZ Signature)があれば、気軽に試せたのに」と今になって思うが、まあ仕方ない。

それで、今は以下のような結論・方針でいる(途中経過を省略しているので、論理が飛躍している)。

  • JACKの(グライコでなく)PEQだけで補正ができるか、その結果がグライコより良いか調べる。: JACKのPEQ(Calfのイコライザ)は各PEQを合成した補正量がグラフで見えるので、見えないグライコのPEQよりも補正結果が変になる可能性が低くなり、少ないPEQで補正できるのなら、その方が音が良くなる可能性があると思ったので。
  • 上がOKなら、グライコからJACKでの補正に切り換える。
  • そして、特性の測定を楽にするため、内蔵のサウンドカードを買う。: JACKとREW(特性測定プログラム)でサウンドデバイスを共用する場合、測定ごとに入力を設定し直す必要があるので、内蔵のオーディオを測定専用にして、その手間を省きたいため。
  • 外部DACは、グライコが壊れたら購入を検討する。

今朝、測定用の内蔵サウンドカードも不要になりそうなことが分かった。オンボードのサウンドデバイス(Realtek)を使っているのだが、それは、入出力が光とアナログの2系統ずつあるので、REWが使う入力デバイス(アナログ)とJACKに割り当てる入力デバイスを変えればいいのだ。基本的に、JACKでは録音しないので、JACKに光を割り当てた。すると、REWでの測定のたびに入力デバイスを設定し直す必要がなくなり、何回でも測定できた。それが分かる直前まで、ちょっと思い付いて、USB接続のオーディオインタフェース(こんなの)を物色していたというのに。トレビアン! (5/18 19:18)

(5/18 22:14 わずかに加筆・修正)

  •   0
  •   0

昨日の投稿でちょっと書いた、音質調整(正確には、再生系の特性の補正)のためのグライコ(DEQ2496)をソフトで代替する件の見通しが立った(と思ったのだが、結論は追記を参照のこと)。

昨日、軽い気持ちで始めたのだが、さまざまな困難(というか、分からないこと)があった。でも、検索と先人の業績のおかげで、やりたかったことが概ねできることが分かった。

要求事項

  • DEQ2496と同等のイコライジング(31バンド、左右独立)をPCのソフトで行う。
  • イコライジングした音(スピーカー用)としていない音(ヘッドフォン用)を同時に別々に出力できる。
  • プレーヤーソフトgmusicbrowser(GMB)だけでなく、他の普通のアプリやOSの音も出せるようにしたい。

試行錯誤の内容(概略)

  • グライコ探し
    •  Linuxのグライコを検索して出て来た、以下のソフトは、バンド数が足りなかったり、左右独立でないので、使えないことが分かった。
      • Pulse Audio Equalizer, alsaequal, mbeq (swh-plugins), PulseEffects, CAPS audio plugin suite, Jamin
    • GMBのイコライザ(実際にはgstreamerのイコライザ)を改造して拡張するのは、特性測定時に測定ソフト(REW)の音をイコライジングできないので不採用とした。
    • Calf studio gearのイコライザは、30バンド・左右独立で、DEQ2496と同等なので、候補にした。
    • zam-pluginsのサイトには、31バンド・左右独立のイコライザ(ZamGEQ31X2)が書いてあるが、実際のパッケージには入っていないので却下した。
  • Calf studio gear (以下Calf)を動かす。
    • Calfが動くJACK(Linuxのサウンドシステムの一種)で音を出すのにとても手こずった。結局、デフォルトのデバイスでなく、明示的に光デジタル出力を指定すれば良かった。
    • 音の経路(例: スピーカーに出す前にグライコを通す)を指定するのも難しかった。qjackctlには「パッチベイ」という配線のような機能があるのだが、どういう訳か、使っているうちに設定を無視して直結し、イコライジングした音としていない音が重なってしまうので、使うのを諦めてjack-plumbingというコマンドを使った。この機能はありそうだと思っていたのだが、実際にはどうすればいいか分からなかったのだが、コマンド名から、もしやと思った。
  • イコライザを設定して、音を聴いてみる。
    • DEQ2496とは若干周波数やゲイン(音量)の刻みが違っていたが、正式に使う時に微調整することにし、おおまかな値をCalfのイコライザ(Equalizer 30 band)に設定した。
    • おそらく、各バンドのフィルタの特性はDEQ2496とは異なるので、実際の微調整は必須だと思う。
    • 聴いた感じでは、特に問題はなく、聞き慣れた普通の音が出ている。
  • OSや通常のプログラムの音も出力できるようにする。
    • pulseaudio-module-jackというモジュールを使い、標準のPulseAudio(Linuxのサウンドシステムの一種)に出る音がJACKに出せるようになり、ブラウザ(Vivaldi)の音が出た。
  •  2系統独立出力できるようにする。
    • チップ自体に機能があるので、ドライバを何とかすれば2系統出力できそうだからと、ダメモトでRealtekのサイトのLinuxドライバを入れたら、音が出なくなった(古い物を無理にインストールしたせいだろう)。バックアップからドライバを戻して復旧した。
    • 実際には、ドライバ自体は独立出力に対応しているので、alsa_outというプログラムにアナログ出力を受け持たせて、それに、以下のように音源を分岐して入れるようにして、イコライジングしない音も出るようにした。
      • 音源 → イコライザ → 光出力
      •   └→ アナログ出力
  • qjackctlが使いにくい問題への対処
    • JACKの制御のためにqjackctlが要るので、JACKは止めてALSA(もう一種のLinuxのサウンドシステム)にしたかったが、CalfはALSAでは使えず、他に要求を満たすイコライザがないので諦めた。
    • qjackctl以外のプログラム(Cadence)を試したが、もっと使えない(設定が保存できない?)ものだったので、諦めた。(5/8 7:21 追記:設定保存のメニューはないが、保存できているようだ)
    • qjackctlに指定できる、サーバ起動後の実行スクリプトが今一つまともに動かないので、上記に書いてきた機能を実現するためのいろいろな処理を行う起動用スクリプトを作って、そこからqjackctlを起動することにした。
  • その他
    • JACKは、位置づけとしては、WindowsのASIOのようなもののようだ。
    • 恐ろしいことに、JACKの試行錯誤中はOSすら不安定になった。今後は大丈夫か、ちょっと心配だ。
    • 複数のサンプルレートには対応しないようだ。設定していないサンプリングレートでも変換するから聞けないことはないが、本当は切り替えて欲しい。が、CD(44.1kHz)さえちゃんと聴ければ、とりあえずは問題ない。おそらく、いろいろな音をミックスして出すポリシーなのだろう(まあ、それが普通だ)。
    • イコライジングをソフトで行うため、CPU負荷は上がった。Calfのプロセスは、15%前後のCPU使用率となり、load averageは1前後になっていることが多い。ただ、全体的なCPU使用率(前述の使用率とは測っているプログラムが異なる)は4%未満なので、大きな問題はないのかも知れない。
    • なぜかOS(正確にはThunderbird)の音がJACKから出ないので、今後の課題だ。→ PulseAudioの「出力装置」の設定でJACKを「代替として設定」(右のチェックボックスをクリック)したら出るようになった。「代替」というのは、デフォルトのことだろうか? (17:59)

設定・操作画面

JACKで音質調整+2系統独立出力を実現した。(左上から時計回りに、JACKの制御(qjackctl)、音の経路設定(qjackctl)、30バンドグライコ(Calf)、Calfの制御)

30バンドグライコと音の経路設定は、なかなかの見物だ。

今後の予定

  • 複数のサンプルレートを自動で切り替えできないか、調べる。
  • 安定性を確認する。また、音質の異常や音飛びなどがないかを確認する。
  • 録音(入力)にも対応させる。(特性を測定する時)
  • DEQ2496でのイコライジングを止めるのか、熟考する(今は、興味を除いては、止めることに特段のメリットはないので、DEQ2496の故障時のバックアップや故障後の代替手段に位置付けるのがいいように思う)。
  • 実際の特性を測って、イコライザを調整する。

知らなかったものを試した結果、やりたかったことができて結構おもしろかったけど、疲れた。そんな訳で、あっという間に連休が終わりそうだ。。。

(19:39追記) モーツァルトのピアノ協奏曲23番を聴いていて、何となく音が悪い(元と違う: わずかに響きが違う感じなのと、ピアノの音がほんの少し平板的に聞こえた)気がして、気のせいなのか、イコライザの特性の差のせいかと思っていたのだが、ふとDEQ2496のパネルのLEDを見たら、思わぬ落とし穴を発見してしまった。DEQ2496はグライコだけでなく、数点だけPEQ(パラメトリックイコライザー)も掛けていたのだ。

だから、ソフトでDEQ2496を代替できるのはもう少し先だ。もちろん、CalfにはPEQもあるだろうから、不可能ではないだろう。が、やっぱり、そこまでしてやる気はなくなって来たというのが、正直なところだ。という訳で、この投稿の最後は、

To be continued?

(5/7 4:21追記) スリープからの復帰後に音が出なくなっていた。jack-plumbingが処理に失敗して、音の接続ができなくなっているようだ。jack-plumbingを再起動しても直らない。JACKのサーバが異常になったのだろうか。

これでは使い物にならないので、JACKは諦める。DEQ2496が壊れたら、その時に改めて考えよう。

(5/7 10:35追記) 結局、その後スリープからの復帰の問題にはまってしまった。この問題が解決したかは分からないが、GMBの出力が勝手に接続される問題は解決できた。勝手に接続するのはGMBのようで、再生をストップした後で再度再生する時に、デフォルトの出力先("system")に接続している感じだ。それで、qjackctlのパッチベイの設定で、systemの入力を「排他的」にすると、一つの出力(ここではCalfの出力)しかから接続されないようになって、勝手に接続されなくなる。

なお、qjackctlのパッチベイを使うことにした理由は、jack-plumbingがスリープに対応していないからではないかと思ったからだ。

また、alsa_outはJACKサーバが起動していない場合、勝手にサーバを起動するため、余計なサーバ(jackd)が起動していたことが分かった。本当のJACKサーバは今はjackdbusのようで、これはqjackctlが起動するので、alsa_outはqjackctlの後で起動するようにした。これもスリープに関係しているのではないかと予想(期待)している。

なお、昨夜、PEQも仮に設定してみた。しかし、音の違いは良く分からなかった。違いを判別するには、測定してみる必要がありそうだ。

(5/8 6:25追記) その後、興味本位で特性を測定したくなってしまって、連休の最終日を潰してしまった。

測定にはマイクの音を入力する必要があるのだが、測定ソフトREWがJACKに対応していないので、手こずった。最初に試した時は、うまくいったと思って測定したら、やけにいい特性が出て、「実はグライコは要らなかった??」と思い掛けたのだが、それは科学的でないし、実際、聴いたら音が良くなかったので、何かおかしいと思って調べたら、雑音(内部的なハウリング?)を録音していたようだった。

結局、JACKがオーディオインタフェースを専有するために、REW(標準サウンド(ALSAかPulseAudio)を使用)が録音できなくなっていたのが原因だった。もう一枚オーディオインタフェースがあれば楽だったのだが、ないので試行錯誤した。いろいろ調べて、JACKの制御プログラムをqjackctlでなくCadenceにし、JACKでは出力だけするように設定すればいいことが分かった。ただし、REWが何かおかしいようで、測定のたびに入力を設定し直す(一旦別のに設定して戻す)必要があった。

それでようやく測定ができた。結果としては、暫定的な設定で大きな問題はなかったが、右が少しずれていたのでグライコとPEQを微調整した。なお、PEQは必要だった(左右別のグラフを見ると分かる: 左: 80Hz付近、右: 150Hz付近に山がある)ので、Calfの"Equalizer 5 band"(これはグライコでなく、PEQ)を使用した。

調整前の特性は以下のとおり:

調整後の特性は以下のとおり:

左右一緒だと、調整前後の差は分からない。なお、左の220Hz辺りが強いことに気付かなくて調整しなかったのだが、本当に使う時に調整しようと思う。

結論としては、Linuxのソフト(JACKとプラグイン)でグライコ(DEQ2496)を完全に代替できる。ただし、使うためにはさまざまな面倒があるうえ、前述のように、JACKにはスリープの問題(今、別のプログラム(Cadence)を試している)があるので、当たり前のことながら、(技術的興味や物減らしへの熱意は別として、)DEQが使えるのなら使った方がいいだろう。

補足: 物減らしの面では、今はDEQのDACを使っているので、仮にDEQをなくしたとしたら、別の、ある程度良いDACが要るので、あまりメリットはない。それどころか、新しい物を買うという点で言語道断だ。だから、この方式は、DEQが壊れた時だけ意味がある。

PS. JACKのスリープからの復帰で再生できなくなる問題は、Cadenceでも駄目だった。JACKのサーバとの通信ができなくなるようだ。いくら技術的におもしろくたって、こんなに出来が悪いのでは、使い物にならない。よくこれを「プロ用」と言えると思う。これで、完全に諦めることができた。(5/8 19:55)

  •   0
  •   0

毎年恒例の、オーディオ再生系(部屋も含む)の特性の確認。

去年Linuxに移行したので、今回はちょっとしたトラブルがあった。移行した時、それまで使っていた測定ソフトSpeaker WorkshopがWine(LinuxでWindowsのソフトを動かせる(かも知れないw)ソフト)で動くことを確認していたつもりだったのだが、実際には、音の再生がまともにできず(再生が短時間で終わってしまう)、測定できなかった。仮想環境(VirtualBox)のWindows 7で動かしても駄目だった。

それで、慌てて代替ソフトを探したら、ありがたいことに、すぐにいいものが見つかった。Room EQ Wizard (REW)というソフトだ。去年は結構探しても見つからなかった気がするのだが、今回は"Speaker Workshop alternative"で検索したのが良かったようだ。

REWはSpeaker Workshopの10倍はいい感じだ。使いやすいし、機能も豊富だし、安定している。

Room EQ Wizardの測定結果の画面

実は、今日はだるくてやる気がなかったので、ソフトを見付けて動くのが分かったら終わりにしようと思っていたのだが、余りにいい感じなので測定までしてしまった。

その結果、問題がない(前回から大きな変化がない)ことが分かった。以下に、グライコ(DEQ2496)で調整後のスピーカー出力(左右同時再生)の特性の測定結果を示す。

使用したソフトの違いにより、今回はスイープ信号で、前回と前々回はM系列の擬似雑音で特性を測定している。また、今回は1/12oct(オクターブ)の、前回と前々回は1/6octの平滑化をした。今回は、グラフが0dB付近になるように数十dB下げた。なお、前回との比較図は、グラフィックソフト(gimp2)で前回の縦横のスケールを調整して重ねて作成した。

なぜか、前回より若干特性が良くなった感じだ。具体的には、低域(40-60Hz)のレベルが4dB程度上がり、55Hzの谷もその分浅くなっている。比較図には載せなかったが、前々回に近い感じだ。マイクの位置の違いによるのか、部屋の条件が変わったのか分からないが、まあ、良い分には問題ない。

なお、今回は鋭い谷がいくつかある(150, 320Hz付近)が、平滑化の違いによるものではないか。それから、500-600Hzの谷はいつも深さが変動するので、余り気にしていない。

一行でまとめると、

60Hz〜20kHzで±5dB、40Hz〜20kHzでも-10,+5dB

と、なかなかいいと思う。逆に、低音や高音なんて、そんなにちゃんと出ているのかとさえ思う。余談だが、測定している時、測定が終わったと思って画面を見ると、実際には超高音(10kHz以上?)がまだ出ていて、もはやそんな音はかすかにも聴こえず、ハイレゾなんて全く不要なことを実感させられる。。。

なお、REWを使う時には、いくつかのコツがあるようだ。

  • デフォルトのサウンド(Preferences→Soundcard)設定では音が入出力できなかったので、試行錯誤したところ、出力も入力も"default [default]"にするとうまく行った。紛らわしいが、これはREWのデフォルト("Default Device")とは異なり、Linuxのデフォルトという意味なのだろう。
  • 最初はマイクからの入力ができなかったが、上記の設定や、マイクの接続端子(マイク/ライン)やPulseAudioのミキサーの設定(設定→プロファイル)を変えていたら、なぜかうまく行くようになった。

 

参考: システム構成(前回からの変更点のみ)

  • 周波数特性測定プログラム: Room EQ Wizard V5.18
  • OS: Linux Mint 18.1
  •   0
  •   0