「PC」カテゴリーアーカイブ

.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のプロセスがしばらくの間常駐してメモリを喰い続けるというデメリットもあるわけですが、それでもこれぐらいの速度向上ならばトレードオフといったところでしょう。

DMMアフィリエイトのリンク作成ツールをバージョンアップしました。


当サイトで公開しております、「DMMアフィリエイトのリンク作成支援ツール」ですが、本日若干の改良を加えました。

従来はテキストリンクかイメージリンクのいずれかしか作成できませんでしたが今回新たに「イメージ+商品説明テキスト」というスタイルでアフィリエイトリンクを作成する機能が追加されました。

dmmlinktool.png

なお生成されるリンクの見た目はスタイルシートでカスタマイズ可能となっております。
外枠の色を変えたい、テキストの大きさや色を変えたい、などの要求にはできるだけ応えられるようになっております。

非AFTなHDDを今更ですが買ってみました。


ご存じの通り、現在HDDは1TBや2TBといった大容量の製品が一万円を切る値段で買えたりしてコンピュータユーザーにはウハウハな状況ですが、実はXPユーザーには罠があります。

現在出回っているHDDの多くは「AFT」(正確にはBigSectorと呼ばれる)という規格でフォーマットされており、このAFTでフォーマットされたHDDをXPでそのまま使うとパフォーマンスが低下するといった現象が発生します。

Windows VistaやWindows 7などはAFTに正式に対応しており、こういったパフォーマンスの低下は無いようですが、残念ながら私はAFTに正式対応したOSを使っておりませんので、今更ですが非AFTのHDDを買ってみました。

なお、AFTで物理フォーマットされたHDDでもジャンパピンを設定したり専用のツールで再アライメントを行うことによりAFT非対応なOSでもパフォーマンスを落とすことなく利用できるそうです。

というわけで、今回購入した物はコレです。HGSTの「HDS5C3020ALA632」現在では貴重な非AFTなHDDです。(それにしても長すぎる型番ですな)

回転数が5940rpmということで、現在出回っている7200rpmよりも回転数は劣りますが、そもそもデータ置き場&バックアップ用に購入したためスピードはあまり重視しないのと、HDDの温度が上がるのは精神的によろしくないためこれで満足です。
IMGP0762.jpg

ベンチマーク

さっそくベンチマークを取ってみました。

HDS5C3020ALA632_Benchmark.png

 シーケンシャルアクセスはデータ倉庫用としては十分過ぎる程速い数値が出ています。問題は極端に低い4Kブロックのランダムアクセス。可動部品を使ったHDDの宿命でしょう。OSの起動時間やアプリの起動時間はこの4Kブロックのランダムアクセスが大いに影響するそうです。これ以上の向上を望むのならSSDを買うしかありません。
今更HDDという気もするけど
 現在はSSDなどの高速な記憶装置が普及し始めていますが、ギガバイト単価で考えるとHDDの安さはやっぱり魅力的です。
おそらくSSDがいまよりもずっと安くなり、容量もそれなりに大きくなったら私もSSDに移行するかと思いますが、今のところはHDDで十分です。

初代iPodのバッテリーを交換しました。


 本日は、今から10年前に購入した初代iPodのバッテリーを大容量の社外品と交換してみました。

壊れたと思った初代iPodが壊れていなかった件

 実は、5年ほど前に私の初代iPodが動かなくなりました。それまでMacで使っていた初代iPodをWindowsで使おうと再フォーマットし、Windowsマシンに接続するもブルースクリーンが多発、そしてついにはiPodを認識しなくなるどころか充電さえできない状態になったのです。これはもうiPodそのものが壊れてしまったんだと思い、そのまま5年ほど放置していました。

 しかし、最近ふとiPodをiMacに繋いで見たところ認識するどころか曲の同期までできるではないですか。どうやらハードウェアは全く壊れていませんでした。

 では何が壊れていたのか。それは、iPodに付属のFirewireケーブルです。これが内部で断線していたらしく、Windows上でiPodを同期する際にブルースクリーンが多発していたのです。

 それにしてもiPod発売当時の衝撃はすさまじいものがありました。なにしろそれまで私は音楽を外に持ち出す際にはポータブルCDプレーヤー+CD-Rという組み合わせでしたから(MDにはいまいち魅力を感じなかったため購入には至りませんでした)、1000曲も入って一瞬で曲を切り替えられる、それに振っても揺らしても音飛びしないiPodの登場に非常に興奮したものです。当然私は発売日に衝動買いしていしまいました。

 しかしさすがに10年前に発売された製品です。バッテリーはへたっており、10分も曲の再生をすればバッテリー切れに。

Appleのバッテリー交換サービスではもう受けつけてもらえないようだった。

 そこではじめに考えた事はAppleのバッテリー交換サービスを利用するということです。ご存じの通りAppleは古くなったiPodのバッテリー交換サービスを行っています。実はこれ、申し込むとバッテリーどころか本体まで新品になって返ってくるという素敵すぎるサービスなのですが、申し込むには本体のシリアル番号が必要です。

 試しに私のiPodのシリアル番号を打ち込んでみたところ・・・。

iPodSerial.png

 「シリアル番号が見つかりません」出てきました。さすがに発売から10年も経っているとサポート期間も過ぎてしまったようです。

大容量が魅力の社外品バッテリー

この際ですから社外品の大容量バッテリーに換えてみることにしました。

 今回入手したのは「Pod 1G&2G用 互換バッテリー2200mAh」 元々iPodに入っていたバッテリーは1200mAHですから8割近い容量アップです。私はここのショップで購入したのですが現在売り切れてしまっているようです。
IMGP0765.jpg

 このセットにはバッテリーのほかにiPodを分解するための工具が付属しています。
バッテリーは思いの外柔らかかったのでびっくりしました・・・。
IMGP0767.jpg

 付属の工具をiPodの隙間に差し込み、iPodの周りをぐるっと一周させます。すると裏蓋がカパっと外れます。なお工具の差し込みには予想以上に力がいります。
IMGP0768.jpg

 裏蓋を開けたところ。元々もバッテリーはソニー製でした。
IMGP0770.jpg

 バッテリーはハードディスクのすぐ上にゴム版で接着されています。
IMGP0772.jpg

 コネクタの取り外しにはそれほど力は要りませんでした。
IMGP0773.jpg

 新しいバッテリーをセットしたところ。
IMGP0778.jpg

 見事完全復活を遂げた初代iPod。
IMGP0782.jpg

 この機会ですから、iPod touchと比べてみます。
IMGP0797.jpg

厚さの比較

IMGP0799.jpg

 初代iPodを若い人に見せると「ありえないぐらい分厚い!」という反応が返ってきておもしろいです。

 それにしても、改めて初代iPodを使ってみると、フラッシュメモリベースのiPod touchに慣れてしまった身としては、曲を選んでから再生されるまでの「間」がえらく長く感じました。曲を選んで再生ボタンを押すと「キュイーーーン」とハードディスクが回り出してしばらくしてから曲の再生が始まるのです。購入当時はそんなに気にならなかったのですが、慣れとは恐ろしいものですね。

OS X Lionが発売になりました。


mac-os-lion.png

 私もこの日を楽しみにしておりましたが、海外のフォーラムを見ているとLionではDigital Performerが正常に動作しないとう情報を目にしました。起動直後にフリーズして使い物にならないそうです。
また、私がシンセサイザの音色エディットに使用しているXV EditorはPower PCバイナリで、Rosettaが廃止されたLionでは動かないことが確定。さらにXV Editorは2007年から開発が止まっており、アップデートされる気配も無い事から絶望的です。とはいえXVユーザー数は世界的にも少なくないでしょうから、ローランドも何かしらの対策を行ってくれる事を期待しています。

 しかしながら現段階ではDAW系のアプリは軒並み全滅らしく、メーカーのアップデートパッチを待つか、お金を払ってアップグレードするしかなさそうな様子です。ただ、Digital Performerに関しては開発元であるMOTUが「Digital Performer 7はLionとの互換性はありませんが、我々はパッチの開発に全力を注いでおりますので、ユーザーの皆様はバージョン7.24アップデーターが出るまでLionへのアップグレードは待ってて下さい」とのアナウンスを出していました。(情報元:https://www.motu.com/newsitems/motu-products-and-mac-os-x-10-7-lion)

 一方で、Lionの発売と同時に新しいMacBook airとMac miniが発売されました。
私はMac miniのほうが非常に気になっています。光学ドライブを廃した事は賛否両論ありそうですが、私は光学ドライブはアプリケーションやOSのインストールにしか使っていないのでこの決定は大歓迎です。

 というわけでローランドさん、XV Editorのintel対応をよろしくおながいします。

Phenom IIのCPUクーラーを交換


Phenom IIのリテールクーラーがうるさい件

去年の6月にCPUをそれまで使っていたAthlon 64 3800+からPhenom II X4 945に変更して以来、付属するリテールクーラーの騒音に悩まされていました。冬の時期には回転数の上昇も穏やかだったためあまり気にならなかったのですが、今年の7月から気温が上昇、それに伴い付属のリテールクーラーは甲高い回転音を出すようになり、またCPUの温度も高負荷時にはかなり高めに出ることもあり、CPUクーラーを社外品に交換しました。結果的には大満足でした。

CPUクーラーの選定

社外品のCPUクーラーには大小様々な製品があり、冷却性能や静粛性も異なるようですが、あまり大きくて重い製品はいくら冷却性能が高くても避けようと思っていました。なぜなら重さでマザーボードがたわんでしまうかもしれないからです。実は今までにコンデンサの交換の依頼を受けた際、いくつかたわんで元に戻らなくなってしまっているマザーボードを見て以来重いCPUクーラーには恐怖心を抱いていました。

そこで今回はCOOLER MASTERのVortex Plusに決定しました。この製品は見た目こそ若干大きいですが、重さは445gとそれほど重くなく、これならたわみの心配もなさそうです。

VortexPlus.jpg

ヒートパイプってすごい

Vortex Plusには4本のヒートパイプがCPUに直接接触する形で配置されています。この機会ですからヒートパイプについて調べてみると、とてもすごい技術なのだということがわかりました。

IMGP0619.jpg

まず、CPUの冷却効率を上げようと思ったら、ヒートシンクをどんどん大きくすれば良いと思っていましたが、それだけではCPUの熱がヒートシンクの一部に集中してしまっていくら大きくしてもダメなんだそうです。つまり、大きなヒートシンクを効率よく使うには熱をヒートシンクの隅々まできちんと運んでやる必要がある、その為にヒートパイプが使われる、とのこと。

ヒートパイプの中は真空になっていて、中に液体が入っているそうです。次に、ヒートパイプの片方に熱が加えられると中の液体が蒸発して気化します。(中は真空になっているため、液体は簡単に蒸発するそうです) このときに発熱源から熱を奪います(気化熱)

そうすると今度はその熱を持った蒸気がヒートシンク側まで運ばれ、冷却されます。そこで気化していた蒸気が冷やされて気体から液体に再び戻ります。こうして冷やされた液体は再び発熱源の所まで戻り、また発熱源から熱を奪い、気化し・・・という事を繰り返して熱をどんどん効率よく運ぶ事ができる、ということ。

なるほど、だからiMacとかノートパソコンとかにも積極的に採用されているわけですね。

ヒートパイプすごいよヒートパイプ

参考サイト:https://www.heatpipe.co.jp/heatpipe.html


Socket AM3プラットフォームへの取り付けは至って簡単

クーラーの付属品には様々な金具やピンが付属しますが、Socket AM3プラットフォームに至ってはたった二つの金具だけで取り付けられ、難易度も高くありません。マザーボードの取り外しも必要ありませんでした。
また、シリコングリスも付属しています。(私はそれを知らずにわざわざグリスを別に買ってしまいました・・・)

たくさんのパーツが付属しているが・・・

IMGP0620.jpg

AM3マザーへの取り付けはこの二つのパーツだけで良い

IMGP0621.jpg

早速マザーボードに取り付けてみたところ。残念ながらメモリとヒートシンクが干渉してしまったため、メモリの位置を変えることによって回避した。IMGP0625.jpg

テスト結果

テストはエアコンが効いていない真昼の暑い時間帯(室温32度)に行いました。エアコンが効いていない、というより去年の秋にエアコンが壊れてそのまま放置してあるのです(汗)ですからアイドル時とはいえリテールクーラーの回転数はかなり高いことにご留意ください。

リテールクーラー

  • アイドル時 Cool’n’Quiet ON
    ファン回転数4299RPM CPU温度40度
  • アイドル時 Cool’n’Quiet OFF
    ファン回転数4470RPM CPU温度42度
  • 高負荷時
    ファン回転数5921RPM CPU温度60度
Vortex Plus
  • アイドル時 Cool’n’Quiet ON
    ファン回転数1819RPM CPU温度38度(リテール比-2度)
  • アイドル時 Cool’n’Quiet OFF
    ファン回転数1985RPM CPU温度40度(リテール比-2度)
  • 高負荷時
    ファン回転数2836RPM CPU温度51度(リテール比-9度)

結果を見て頂くと解るとおり、ファンの回転数がリテールクーラーの約半分であるにもかかわらず、高負荷時においての温度上昇がリテールクーラーと比べてかなり低くなっています。また、ファンの口径が大きく風量が多いため、CPUのみならずCPU周辺にあるVRMやチップセットなども冷却されるようです。さらに、高負荷時からアイドル時へ戻った際にリテールクーラーの時には温度が下がるまでにある程度の時間を要していましたが、Vortex Plusの場合にはすぐに温度が元に戻ります。これはすごい。

結果は大満足です

 こんな事ならCPUを買うときに一緒にこの製品を買っておけばよかったと思いました。
現在AMDのリテールクーラーがうるさいと感じている方には間違いなくおすすめできる製品だと思います。

DMMアフィリエイトのリンクを簡単に作成できるツールを公開しました。


このツールはDMMで販売されている商品ページのURLを最大20件まで入力でき、一括でアフィリエイトリンクを作成する事ができるツールです。

ツールはこちらのページで公開しております。

早速使い方を説明致します。

dmmlinktool.png

アフィリエイトIDを入力
まず、あなたのアフィリエイトIDを入力します。
enteraffid.png

商品のURLを入力(複数入力可)
続いて、アフィリエイトのリンクを作成したい商品のURLを入力します。
複数のURLがある場合には改行で区切って入力します。最大20件まで入力できます。
enterproductsurl.png

オプション選択
次に、リンクの作成オプションを選択します。テキストリンクか画像リンクかを選択できるほか、サムネイルイメージのリサイズも行えます。
options.png

結果の確認
最後に、送信ボタンを押しますと、生成されたリンクタグや実際にブラウザでどう見えるかがプレビューに表示されます。
preview.png

おまけ
なお、画像リンクを作成した場合、画像の上にマウスを載せると商品の説明がポップアップするように出来ています。
popup.png

技術的な事

このツールはCGIとして動作するツールですが、ほぼすべてのプログラムがC#で記述されており、.NET Frameworkの機能を活用して作られています。従って、Windows版を作るのはとても簡単、というより、実は既にWindows版も存在します。Web版のURL20件制限はサーバーの能力が乏しいために存在しますが、Windows版には制限はございません。ただし、Windows版はまだコア部分に適当なGUIをかぶせただけで、とてもじゃないけど公開できる代物ではないためまだ公開はしておりません。

なお、DMMからデータを取得する際、一度取得したデータはこちらにキャッシュされますので、必要以上にDMMのサーバに負荷をかけるという事はありません。

Socket 939マザーがまだ新品で手に入るようです


自分用備忘録も兼ねて。
939A790GMH(m).jpg
ASRockの939A790GMHというマザーなのですが、まだ新品で手に入るそうです。
しかも、CPU周辺は固体コンデンサで固められていて良い感じ。
https://www.asrock.com/mb/overview.jp.asp?Model=939A790GMH

サーバ用にAtom搭載マザーを買おうかと思ったけど、手元にSocket 939なAthlon 64が余っているので、こちらを買うという選択肢もありかもしれませんな。

ICON DIGITAL社のCUBE Gの不具合について


G4からIntel iMacにDAW環境を移行するにあたって、3月11日の地震が発生する直前にサウンドハウスにオーディオインターフェースを発注しました。G4では PCIスロットにオーディオインターフェースを挿して使用していたのですがiMacにはPCIスロットがありませんのでUSBかFireWireのオーディオインターフェースを用意する必要があります。そこでいくつかの製品の中から私の条件に合う中で安価でコストパフォーマンスが高い物を選び発注しました。

そしてこれが今回発注したiCON DIGITAL社のCUBE Gです。Mac miniに似たデザインですが、実際にはMac miniよりも一回りほどサイズが小さく、本体上部の白い通電ランプがなかなかイカすデザインであります。

CubeG_Top.jpgCubeG_Front.jpg

私の制作環境で必要最低限の条件が、

  • 24ビット/96KHzで録音・再生が行える。
  • アナログ4入力、もしくはアナログ2入力+S/PDIFを1入力備えている。

ですので、この条件を満たすオーディオインターフェースでなるべく安価な物を検討し、その結果iCON DIGITAL社製のCUBE Gを購入したのですが、このインターフェース、ただの音楽鑑賞には使えますし、音質も値段以上なのですが、DAWに使用しようとするとブチブチと音切れを起こし、使い物になりませんでした。

具体的には、

  1. Digital Performerで24bit/48KHzとか、24bit/96KHzなどでプロジェクトを作成する
  2. モノラルトラックを作成し、ギターを録音する
  3. Live Room Gでキャビネットをシミュレートする。
  4. ProVerbでリバーブをかける

たったこれだけで、不規則に「プチ・プチ」という音の途切れが発生し、さらに同様のトラックを5本も作れば、「ブチブチブチブチ」とすさまじい音切れを起こして実際の音楽制作にはまったく使い物にならなくなるという状況です。サンプリングレートを減らしてみたりバッファサイズを大きくしてみても改善しません。(むしろバッファサイズを大きくすることによりもっと不安定になることもある)

 

実際に不具合が発生するプロジェクト。バッファサイズは2048サンプルと大きめ。
トラックの本数は画面に表示されている分だけで、CPU負荷も高くない。

trouble_project.png

実際の音楽制作ではもっとたくさんのトラックを使いますし、プラグインももっとかけます。
これだけで音切れが発生するということは、DAW目的には全くといっていいほど使えないという事です。

確かにUSBオーディオインターフェースはCPUに負荷がかかると不安定になるという話は聞きますが、今回の場合、ほとんど負荷はかかっていません。また、オーディオインターフェースをBEHRINGERのUCA222(V-AMP3を購入したときのおまけについてきたもの)に変更してみますといくら負荷をかけようがバッファサイズを小さくしようが安定して動作することから、やはりこれはCUBE G自体の問題である可能性が高いです。

Digital Performer以外のソフトではどうか、と試しにGarage Bandで使ってみました。すると、ソフトシンセで手弾きをした際に微妙なタイミングで「プチ、プチ」と音が途切れることがあります(泣)

では・・・MacではなくWindowsではどうか、ということでWindowsマシンに接続してギターを適当に弾いて録音してみたところ、録音の段階で微妙に音を取りこぼしている感じです(涙)

そこで、サウンドハウスのサポートにダメ元で連絡を取ってみました。実はこの製品を受け取ったのは地震発生数十分前、箱を開封する前に地震が来てしまったため、1週間以上動作確認どころか中身を確認することすらできませんでした。通常なら返品期間も過ぎている筈なのですがサウンドハウスのサポートの人は親身になってサポートしてくださいました。

とりあえずは一度日本での販売代理店であるフックアップと連絡を取ってみるように言われたため、現在フックアップと交渉している段階です。

音質は値段以上に素晴らしい

では、不具合が発生したからこの製品はまったくだめなのかというとそうではありません。

iTunes で音楽を再生する分にはまったく不具合が発生しません。また、本体にモニター用のヘッドフォン端子が装備されているため、音質劣化の原因となる外部のアンプなどを通さずに直接ヘッドフォンでモニターできます。この状態でiTunesで音楽を鑑賞するとこの製品の良さが分かります。

Macの内蔵オーディオで聴く音楽はヘッドフォンに楽器がへばりついているような平べったい印象を受けるのに対し、このCUBE Gで聴くときちんと奥行きが再現されるのです。

ただし、値段相応に削られている機能もある。

ダイレクトモニタリングができない

まず、ダイレクトモニタリングができません。ソフトウェアモニタリングのみです。

たとえば、入力端子にギターを接続し演奏したとします。そうするとその信号はいったんコンピュータに取り込まれてなんらかの処理をされてから再びオーディオインターフェースに戻ってきて、やっとモニタできる状態になるのです。つまり入力から出力までの遅れがあります。そして、なぜかバッファサイズをいくら小さくしても改善しません。(他のオーディオインターフェースならバッファサイズを小さくすると負荷が上昇する物の実用レベルまで改善します)

従って、ダイレクトモニタリングをしたい場合にはミキサーを別途用意し、ソフトウェアモニタリングをOFFにした上で、ミキサーでモニターしつつ、AUX SENDなどで録音したい信号をオーディオインターフェースに送ってやるという処置が必要です。

しかし、この製品をUSBポートに接続したり、Macがスリープから復帰した場合、問答無用でソフトウェアモニタリングが毎回有効になってしまいます。ですから、普段からミキサーでモニターをしている方は毎回音楽制作の開始に先立って、手動で「iCON Control Panel」なるものを開き、ソフトウェアモニタリングを切ってやらなければなりません。

Icon Control Panel
私の場合はこれを毎回音楽制作に先立ち起動して
ソフトウェアモニタリングを無効にする必要がある。

iconcpl.png

本体からUSBケーブルに放出されるノイズがハンパない

この製品の動作中は、Macの内蔵オーディオにすさまじいノイズが混入します。
CUBE Gで発生したノイズがUSBケーブルを伝ってMacに戻り、Macのオーディオアウトから出てくるという感じです。まるで嫌がらせかなにかのように・・・。

製品自体はとても素晴らしいので

しかしながら冒頭で申し上げた不具合が発生しなければまったくもって素晴らしくコストパフォーマンスが高い製品であるため、フックアップ社のサポートと交渉しつつ不具合が解消された場合には改めてレビューをさせていただきます。

同様の不具合を抱えている方のコメントをお待ちしております。

iMac+Digital Performerでこの製品を現役で使用されている方で、「俺も不具合が発生した!」という方、もしくは「俺は全然平気で使えているぜ!」なんて方からのコメントもお待ちしております。私は本気で困っています・・・。