OS X Lionで無理矢理XV Editorが動かせるか挑戦してみた。


 私は現在音楽製作とXcodeの勉強用にMacを所持しているのですが、2011年11月現在未だにOSはSnow Leopardです。

 というのも、私がローランドのXV-5050というシンセサイザの音色エディットに使っているXV EditorというプログラムがOS X Lionでは今現在サポートされていないため、アップグレードしたくでも出来ないのです。今回はこの動かないXV EditorをなんとかLionで動かせないかと試行錯誤してみた末の失敗記録です。

OS X LionでXV Editorが動作しないたった一つの理由

 ご存じの通り、OS X LionではRosettaが切り捨てられました。
Rosettaとは、Power PCコードで構成された従来のMac OS XアプリケーションをIntel CPU上で動作させるための機構なのですが、ローランドのXV EditorもPower PCコードで構成された古いアプリケーションの一つなのです。

 つまり、RosettaをサポートしないOS X Lionではどう頑張ってもXV Editorは動かせないのです。

古いOSを入れたくても入れられないのがMac

 実はMacには大きな罠があり、あるモデルにプリインストールされているOSよりも古いOSにはダウングレードできません。
例えばOS X Lionがインストールされて出荷されているMacに以前のバージョンのSnow Leopardをインストールしようとしても出来ません。無理矢理インストールしようとしても弾かれます。

 つまり私が将来的にMacを新調した場合、その時期に登場したOSより古い物はインストールできず、つまりはSnow Leopardもインストールできない、ということになります。

 ということは、動作にSnow Leopardが必要なXV Editorはこのままでは新しいMacでは動かせないと言うことになります。

ならば、無理矢理動かしてみよう。

 私の脳内の声:「Rosettaは廃止されたけど、エミュレータの選択肢は他にもあるよね。ほら、Windowsアプリを他プラットフォームで動かすWineとか」

 というわけで、何もMac用のXV EditorにこだわらなくてもWindows用があるじゃないか、と気づいたためさっそく検証開始です。

 ※私はOS X Lionを所持していないため、実際には「Rosettaが無い」という環境を想定してSnow Loopardで実験を行いました。

WineBottlerという選択肢

 WineBottlerとは、Wineをベースに設定や環境構築をより簡単にしたパッケージで、これを使うとWindows用のアプリケーションを一発でMac用のアプリケーションに変換できるという素晴らしいツールです。実際にWindows用のInternet Explorer等がまるでMacのアプリケーションであるかのように動きます。

 今回はこれを利用してWindows用のXV Editorを無理矢理Mac用に変換してみました。

左のアイコンがWineBottler、そして右のアイコンが実際にWindows用のXV EditorをMac用に変換してみたもの。

winebottler.png

動くことは動いたのだが

 早速WineBottlerを使ってMac用に変換したXV Editorを立ち上げてみます。

xveditor_launching.png

 ところが、起動してしばらくすると「XV-5050との接続を確認できない」とのエラーを告げるダイアログが表示されます。
このソフトはコンピュータとXV-5050の間でMIDIを使い双方向通信を行い、データの同期や機器の接続チェックなどを行っています。従ってXV-5050が接続されているにもかかわらずこのようなエラーが出ると言うことはMIDIの入出力がうまく働いていないということになります。

xveditor_error.png

 ちなみに、画面上の鍵盤をマウスでクリックするとXV-5050から音が出ましたので、どうやらMIDIの出力のほうは上手く動いているようです。

なぜBoot Campでは駄目なのか

 Wineを使ってうまく動かないのであれば、Boot CampでWindowsを動かしてその上でWindows用のXV Editorを動かす方法が一番確実かもしれません。

 しかし、シンセサイザの音色というのは、単体で鳴らした場合と実際に楽曲を流しながら鳴らした場合では同じ音色なのにずいぶんと違った聞こえ方をします。従って、私がいつもシンセサイザの音色を作る場合には同時にシーケンサーを立ち上げて実際に曲を再生しながら作っていきます。単体でエディタのみを走らせる、ということはめったにありません。そして、私が使っているシーケンサーはDigital Performer、これはWindows版が存在しません。つまりいくらBoot Campで確実にXV Editorが動くからといって私のケースでは残念ながら諦めるしかないのです。尤も、Mac用のDigital PerformerをWindows上で無理矢理動かす手段があれば別なのですが。

結局はRolandの対応待ち

 現在Rolandの公式サイトではMac OS X への対応状況というページに同社のハードウェアやソフトウェアのOS X Lionの対応状況が公開されています。わりと頻繁に更新されているようですが今のところXVに関する情報は全く掲載されていません。結局現在の所はRolandの対応を待つしか無いのかもしれません。ただ、XV-5050はかなり古い機器ですのでこのまま対応されずに終ってしまう可能性も否めません。

それでもすごいWineBottlerの可能性

 今回はXV Editorの使用には至りませんでしたが、それでもWineBottlerを使ってWindows用のアプリケーションがMac用に変換され、実際に動いてしまう様は見ていて感動しました。ひょっとしたらXV Editor意外にも有用な音楽用アプリケーションがMacで動作するかもしれませんし、今後いろいろ試してみる価値はありそうです。

 WineBottlerの入手先はこちら → https://winebottler.kronenberg.org/

.NET FrameworkのBeginGetResponseメソッドが実行中のスレッドをブロックしてしまう件


数日前の事ですが、当サイトで公開しているDMMアフィリエイトの商品リンク作成ツールの利用者の方から「今までに比べてリンクの作成に非常に時間がかかるようになった」とのご報告を頂きました。

今までは遅くても数秒以内に作成できていた物が、早くても10秒以上かかるというのです。

こちらではしばらくプログラムの変更は行っていませんでしたので、単にDMMのサーバーが重くなっているのではと考えていましたが実は完全に私のミスでした。

何が原因だったのか

当サイトのDMMアフィリエイトのリンク作成ツールでは、開発言語としてC#が用いられています。つまりは、.NET Frameworkの機能を利用して実装されているということです。

プログラム中では、ユーザーの問い合わせに応じてDMMのサーバーから実際に商品情報と商品パッケージ画像を取得するのですが、この時に.NET FrameworkのBeginGetResponseメソッドを用いています。実はこのメソッドにちょっとした問題がありました。

このメソッドはインターネットリソースの非同期要求を開始するメソッドであり、通常このメソッドが呼ばれた瞬間に、要求の完了・未完を問わずに一瞬で呼び出し元に制御が返ってきます。

ところが、条件によってはBeginGetResponseメソッドから制御が帰らずにスレッドが長時間ブロックされたままになってしまうことがあります。私のツールがリンクの作成に非常に時間がかかるようになったのもこれが原因でした。

どんな条件の時にスレッドがブロックされるのか

例によって、海外サイトを検索していたら次のサイトを発見しました。

webrequest.begingetresponse is taking too much time when the url is invalid
https://stackoverflow.com/questions/1232139/webrequest-begingetresponse-is-taking-too-much-time-when-the-url-is-invalid

要約するとインターネットからのリソースの取得は非同期的に行われるけどDNSの解決なんかは内部で同期的に実行されるから、無効なURLなんかを指定してDNSの解決に失敗したりするとスレッドがその間ブロックされてしまうとのこと。

ところが。
私のプログラムでは無効なURLは指定していませんし、そもそもDMMの商品URLに通常のブラウザからアクセスするとあっという間に結果が表示されます。

しかし、同時にとある事を思い出しました。

実は数日前にApacheの実行ユーザをWindowsサービスのデフォルトユーザから、セキュリティをガチガチに固めた「Apache」というユーザ変更しました。そして改めて検証してみると、Apacheをデフォルトユーザで起動した場合にはリンク作成ツールは今まで通りの速度で動作するのですが、ユーザを「Apache」に変更すると10秒以上の遅延が発生するのです。

ひょっとして、ユーザ「Apache」のインターネット接続設定がおかしいのでは?と思い、ユーザ「Apache」でログオンしていみたところ・・・。

容疑者発見!

internetoption.png

「インターネットオプション」を開いてみたところなぜか「設定を自動的に検出する」というチェックボックスがオンになっていました。物は試しにこのチェックボックスをオフにして再度リンク作成ツールをテストしてみると、見事に遅延は解消されました。犯人はおまえだったのか。

参考までに、なんでこのような現象が起きるのかを調べてみたのですが、マイクロソフトの英語版公式リファレンス によると、こんな記述がありました。

The BeginGetResponse method requires some synchronous setup tasks to complete (DNS resolution, proxy detection, and TCP socket connection, for example) before this method becomes asynchronous. As a result, this method should never be called on a user interface (UI) thread because it might take some time, typically several seconds. 

要約:このメソッドは非同期状態になる前に、いくつかの同期タスク(例えば、DNS解決、プロキシ検出、TCPソケット接続等)を完了する必要があり、場合によってはそれらの同期タスクには数秒を要するため、このメソッドはUIスレッドから呼び出されるべきではありません!

 なお、日本語版のリファレンスには載っていませんでした・・・。


まとめ

 というわけで、どうやらスレッドをブロックしている要因はDNS解
決だけではなく、プロキシ検出なども含まれるため、「設定を自動的に検出する」オプションにチェックが入っているにもかかわらず設定の検出に失敗したり時間を要した場合には、その間スレッドはブロックされてしまうっぽいです。


 ところで、デフォルトでは「設定を自動的に検出する」はオフになるはずなのですが、なぜオンになっていたのでしょうね。

Windows上のApache 2.2.9以降でFastCGIを動かす方法


 Windows上のApacheでFastCGIを動かそうとして少し手こずったので、備忘録的にエントリを書こうと思います。


はじめに

 このエントリは次のような方を対象としています。

  • Windows上でApache 2.2.9以降を使用している。
  • ActivePerlを使用している。
  • Movable Type 5.1を使用している。
  • Movable TypeをFastCGI化して少しでも動作を速くしたい。


Movable Typeが重すぎる

 事のきっかけは、ブログ更新の時に常に感じていた「Movable Typeがあまりにも重い」という事でした。
私がMovable Typeを運用しているサーバはPhenom II X4 945(3.0GHz)で動いており、私のサイトのようなアクセス数が少ない個人サイトの運営にはまったく困らないスペックなのです。

 ところがMovable Typeだけは別でした。画面上の何かしらのアイテムをクリックしてから次の画面が表示されるまでの時間が長いことこの上なく、まさしく「もっさり」という形容詞がふさわしいという動きの遅さでした。そしてこれがブログ更新の際のストレスにもなっていたのです。

 そこで私はネットを検索していろいろと調べた結果、「Movable TypeをFastCGIで動かすと高速化できる」という事を知りました。早速私はMovable Typeの高速化に挑戦することにしたのですが一筋縄ではいきませんでした。


Apache 2.2.9以降では公式のmod_fastcgiが上手く動かないらしい

 まずはじめに私はいくつかのサイトを検索してMovable TypeをFastCGIで動かす具体的な方法を調べました。大まかな手順は以下の通りです。

  1. 公式サイトからmod_fastcgi-2.4.6-AP22.dllを入手してApacheのmodulesフォルダに配置する。
  2. httpd.confを書き換えてMovable TypeがFastCGIで動くように設定する。

 私も当然この手順を試してみたのですがどうにもうまく動いてくれないのです。

 Movable Typeを試しに動かそうとするとInternal Server Errorが表示され、Apacheのログには次のようなエラーが記録されていました。

(OS 109)パイプは終了しました。  : FastCGI: comm with server (中略) aborted: GetOverlappedResult() failed

 ところが私が検索して出てきたサイトやブログの方々は何の問題もなくMovable TypeのFastCGI化に成功しているのです。

 さらに詳しく海外サイトなども調べてみると、どうやら私と同様の問題に悩まされている方が何人かいらっしゃるようで、結局はApache 2.2.9以降では通常の方法で手に入るmod_fastcgi-2.4.6-AP22.dllはうまく動かないと言うことが分かりました。


非公式版mod_fastcgiを使ってみる。
 

 しかし、世の中は広く、mod_fastcgiのソースを独自にビルドしてApache 2.2.9以降に対応したバイナリを配布してくださっている方がいました。何ともありがたい。

 早速そのバイナリを入手して、Apacheのmodulesフォルダにインストールしてみたところ、一発でMovable Typeが起動しました!


というわけで、Windows版Apache 2.2.9以降でFastCGIを動かす手順

  1. CPANからFCGIモジュールとCGI::Fastモジュールを入手してインストールします。
  2. こちらからApache 2.2.9以降向けにビルドされたmod_fastcgiのバイナリをゲットします。x86版とx64版がありますので、自分のOSのプラットフォームに合った物を選択してください。
  3. 入手したmod_fastcgi.soをApacheのmodulesフォルダにインストールします。
  4. httpd.confを書き換えてMovable TypeがFastCGIで動くように設定します。
    設定例

    LoadModule fastcgi_module modules/mod_fastcgi.so

    <IfModule mod_fastcgi.c>
        FastCGIConfig -initial-env PERL5LIB=C:/Perl/lib;C:/Perl/site/lib -autoUpdate -idle-timeout 120 -killInterval 3600 -maxClassProcesses 3 -maxProcesses 15
        AddHandler fastcgi-script .fcgi
    </IfModule>

    <Directory “Movable Typeがインストールされているディレクトリのパス”>
        <IfModule mod_fastcgi.c>
            AllowOverride None
            <FilesMatch “^mt(?:-(?:comments|search|ftsearch|tb|cp))?.cgi$”>
                SetHandler fastcgi-script
            </FilesMatch>
        </IfModule>
    </Directory>

  5. Enjoy!


Movable TypeはFastCGIにより高速化されたのか

 結果から申し上げますと、ハッキリとわかるぐらいに高速化されました。
まず、アイテムをクリックしてから次の画面が現れるまでの反応速度がかなり向上し、ストレスを感じなくなりました。これならブログ更新のモチベーションも保てそうです。
 次に再構築の時間ですが、1分程かかっていたものが44秒まで短縮されました。私のブログは記事数が少ないため再構築にもそれほど時間がかからないのですが、記事数が多いブログを運営されている方はこの差はもっと大きくなるのではないかと思います。

 というわけで、Movable Typeの重さに悩まされている方には、FastCGIは良い高速化手段の一つであると言えます。ただしPerlのプロセスがしばらくの間常駐してメモリを喰い続けるというデメリットもあるわけですが、それでもこれぐらいの速度向上ならばトレードオフといったところでしょう。

マザーボード修理 ~MSI MS-6797~


 今回のご依頼は、MSIのMS-6797というマザーボードのコンデンサの交換です。
依頼者様によりますと、「コンピュータのパーツの入れ替えを行っていたら、突然通電しなくなりコンデンサを見てみたところ茶色いコゲのような物が付着していた。自身でコンデンサの交換を行おうとしたものの、スルーホールに足やハンダが詰まってしまい手も足も出なくなった」とのことでご依頼を頂きました。

今回交換するコンデンサは以下の11箇所になります。

赤:16V 1800μF φ10 緑:6.3V 1800μF φ8

IMGP1223.jpg

 さて、マザーボードをよく見てみますと確かにスルーホールに足が詰まっています。さらに、一見何も詰まっていないように見えるスルーホールにも切れた足の欠片が入っており、これらを取り出すのはなかなか手間が掛かりそうです。
ここは根気よくスルーホールにジョボジョボとハンダを流し込みながら先の細いコテ先でゆっくりと掻き出すようにして足を取り外すことに成功しました。

IMGP1212.jpg

無事、スルーホールの詰まりを解消したマザーボードです。

IMGP1213.jpg

 こちらのコンデンサは膨張・液漏れ共に起こしておりませんが、電源部に使用される負荷のかかるコンデンサということと、依頼者様のコンピュータの使用年数から考えて交換しておいたほうが良いと判断したためこちらも新品に交換することにしました。

IMGP1215.jpg

 問題の液漏れを起こしているコンデンサ。依頼者様があらかじめ取り外した物を(交換用のコンデンサのスペックを確認するために)送って頂きました。2003年製造の物で、寿命を迎えてもおかしくないと思われます。

IMGP1228.jpg

交換に使用するコンデンサはすべてーサンヨーのWGシリーズになります。

IMGP1232.jpg

無事、コンデンサの交換を終えたところ。

IMGP1233.jpg

この後、マザーボードは依頼者様の元へ返送され、無事に起動したとのご報告を頂きました。

マザーボード修理 ~AOpen AX4GER-N 2枚目~


 久々のご依頼です。今回はAOpenのAX4GER-Nになります。
依頼者様によりますと「業務で使用している古い端末がOSが立ち上がった瞬間に電源が落ちてしまう」とのことで、コンデンサ交換のご依頼をいただきました。

交換するコンデンサは以下の19本になります。
緑:16V 2200μF φ12.5 赤:6.3V 3300μF φ10 黄色:6.3V 1000μF φ8 紫:16V 1500μF φ10 水色:16V 680μF φ8 橙:16V 470μF

IMGP1181.jpg

 一番損傷が激しいのはCPU周辺のコンデンサ。コンデンサ上部からの液漏れが激しいです。

IMGP1187.jpg

メモリスロット付近にある3箇所のコンデンサ(緑)こちらはまだ液漏れを起こしていませんが、液漏れを起こしていないコンデンサも予防処置として交換してほしいとのご依頼をいただきましたので併せて交換します。

IMGP1184.jpg

同様に拡張スロット周辺のコンデンサも予防処置として交換します。

IMGP1186.jpg

 CPU周辺電源回路のコンデンサをすべて交換しました。入力側のコンデンサは元々16V 1800μF×2本だったものを若干強化し16V 2200μF×3本(サンヨーWX)に強化し、出力側コンデンサはサンヨーWGを用いました。

IMGP1189.jpg

 メモリスロット周辺のコンデンサは、元々が6.3V 1500μFでしたが、こちらは耐圧16V品のサンヨーWGを使用し、CPU周辺同様に若干の強化を行いました。

IMGP1192.jpg

 その他、拡張スロット周辺のコンデンサに関しましては元のスペックと同様の6.3V 1000μFを使用。こちらもサンヨーのWGです。

IMGP1191.jpg

 無事にコンデンサの交換が完了し、マザーボードは依頼者様の元へ返送されましたが、今回は症状が全く改善されなかったとのご報告を頂きました。おそらくはマザーボード上のMOS-FETが寿命を迎えているか、電源ユニットの寿命の可能性もあります。

今回はご期待に添えず申し訳ございませんでした。

依頼者様からの素敵なお礼の品物が届きました。


 更新が滞ってしまって申し訳ございません。
およそ1ヶ月半ぶりのの更新になります。実はここ1ヶ月ほどコンピュータから離れ、他の方面の勉強などをしていました。
気づいたらすっかり熱中してしまい、こちらのブログを書く事を忘れてしまっていました。

 そんな中、以前ASUS KFN32-D SLIのコンデンサ交換のご依頼を頂いた方から、お礼として素敵な品物が届きました。

 実は以前コンデンサの交換を行ったマザーボードはスタジオでのレコーディングに用いられていた物であり、当然ハイエンドで高価な物であるのですが、実はコンデンサの交換をしても直らなかった場合にはPC自体の買い換えを考えていらっしゃったという事なのです。

 ところが、こちらでコンデンサの交換を行うことによりマザーボードが復活、結果的にはPCの買い換えを行わずにすみ、故にかなり安い費用での復帰が出来たそうで、非常に喜んで頂けたそうです。そしてそのお礼として依頼者様の運営されている音楽レーベルからリリースされているCDやノベルティグッズなどを送って下さいました。

IMGP1078.jpg

 送って頂いたCDは主にクラブミュージックのCDで、詰まる所、低音をガンガン効かせて聴きたかったわけですが、実は私は3月11日の大震災でスピーカーが落下し、振動板が見事に破損、廃棄せざるを得なくなってからずっとヘッドフォンのみで音楽を聴いていたのです。
 が、これらのCDを頂いてからどうしてもスピーカーで低音を楽しみたくなり、先月とうとう新しいスピーカーを買ってしまいました。改めてスピーカーで頂いたCDを聴いてみて思ったことは、「やっぱりウーハーで低音を響かせて聞くクラブミュージックは最高!」ということです。
 ちなみに私のお気に入りのトラックは、
「HOUSE ANTHEMS:02/LOVE LOUGE」より
Track No.06:UNAJI
 イントロのエレピとアコピの絡みが綺麗で、これを聴きながら夜の高速道路を走ったらとてもピッタリ合うのではないかと思われる曲です。
「Funk Da Session/NEURON ATTACK」より
Track No.05:Fallin Love
Track No.06:Goes Back Around
 2曲とも女性ボーカル曲なのですが、キックの4分打ちに対してベースラインがグネグネと動き回り、その上にベースラインの隙間を縫うようなフレーズのボーカルが見事にハマっている、聴いていて非常に気持ちよい曲です。スピーカーの買い換えを決意した曲でもあります。
「NAKED PASSION / LATINO HEAT」より
Track No.7:Out Of The Blue
 フェリー・コーステン(System F)の超有名な名曲のカヴァーです。2:00~と4:00~からの展開とそれに至るまでの流れが心地よすぎて癖になります。これもちょっと車で聴きたいかもしれない1曲。ただ、私の場合車にウーハーを積んでいなくてノーマルスピーカーのみなので低音がショボいんですな。時間が出来たらハードオフでウーハーの掘り出し物でも見つけにいきますかね。
 これらのCDは私がコンデンサの交換を行ったPCで製作された物だそうです。
 この場を借りて、改めてお礼を申し上げたいと思います。
ありがとうございました。
・・・いやぁ、自分のレーベルもサボってないで頑張らないとイカンな・・・(汗