2026 年でも E-MU 1616M CardBus を使い続ける

E-MU 1616M CardBus という過去の遺物のために ThinkPad X61 というこれまた過去の遺物を延命し続けてきたんだけど、さすがに CPU が Core2Duo なもんで動かない VST Plugin が出てきてる。 例を挙げると SONiVOX 社の Essential Keyboard Collection ってやつ、ここ会社も潰れサポート消滅したし似たようなプロダクトはいくらでもあるから乗り換えりゃいいんだけどさ。

とはいえ Windows 11 も 24H2 で Core2Duo サポート切ってるのもあるしそろそろ限界といえよう。

CardBus スロットのある令和最新式ノート PC

そんなものは無い、つーか Express Card スロットのある令和最新式ノートだってねえよ多分。

よって平成最新式から探すしかないのである、日本の PC メーカーは法人向けに過剰に後方互換性を重視するから Core i ながらも CardBus スロット付きの機種はわずかながら存在したのだ。

  • Fujitsu LIFEBOOK A572/742,A573/743,A574/744,A576/746,A577/747/748
  • Panasonic Let’s Note CF-S9,CF-S10

この中じゃ A577/747/748 が Core i 第 7/8 世代搭載で、新しめの DAW や VST Plugin が使いだしとる AVX/AVX2 命令も使えかつ Windows 11 の足切りにもギリ引っかからないから最適といえる。 しかし LIFEBOOK は第 3 世代搭載機より後は Cardbus スロットはオプションなので、レア装備過ぎてこれまで一度も現物にお目にかかったことが無いのだ。

となると LIFEBOOK で CardBus 標準装備してるのって第 2 世代の A572/742 一択なのよね、それなら同じ第 2 世代の Let’s Note CF-S10 の方が携帯性やデザイン面でマシなんだわ。 英語キーボードの選択肢が無いしファンクションキー押さんと PrintScreen も PageDown/PageUp もできないクソキーボードなのは一緒だから大して変わらんけどな。

でも CF-S10 は性能のわりに中古の値段そこそこお高くコスパ悪いよなと手が出なかったんだが、去年くらいに近所のジャンク屋で外装もピカピカの CF-S10 黒が 3k で売ってて即買いしてしまったのだ。 安い理由は Cardbus スロットの蓋が欠損してるからジャンク品ということらしい、この機種の持病といえる Cardbus スロット下の底割れもしとらんのにずいぶんと気前がいい。 欠損パーツはオクで色違いのシルバー入手して修理完了、昔シルバーの車に解体屋から拾ってきた黒の右フロントフェンダーとトランクつけてた頃はよく珍走に間違われましたね。

不具合発生

とりあえず E-MU 1616M の無改造のドライバが動く最後のバージョン Windows 10 1809 をインストールし Group Policy で TargetReleaseVersion 指定でこれ以降のバージョンへのアップグレードを禁止。 Pro なら LTSC 2019/Windows Server 2019 のパッチを手動であてときゃ 2029 年まではセキュリティも不安無く使えるんじゃねえかな Windows Update は最新じゃないって文句言うけど。

そんでやっと表題の件になるけど CF-S10 がスリープからの復帰に失敗したりスリープ処理中に死ぬのである、原因はすぐに E-MU 1616M CardBus だと判明。 なにしろ 正式に Windows 7 対応すらしてない製品だからこのくらいの不具合は自力で解決しないとね。

E-MU 1616M のソフトウェアはドライバと PatchMix DSP というパッチベイ/ミキサーで構成されてるのだが、この PatchMix DSP が起動したままスリープすると復帰時にハングアップする。 おそらくドライバが高度な電源管理に対応しておらずスリープ中の電源喪失で再度デバイスの初期化が必要になるのに、その前に PatchMix DSP がデバイス触って死ぬって感じだろうか。

電源オプションの詳細設定を開いても USB とか無線 LAN は違ってスリープ中にも CardBus スロットに刺さったデバイスに給電を続ける設定は無さそうである。 仕方がないのでアドホックな対処法としてスリープの前にデバイスを無効化することを考えた、スリープの前後にこんなスクリプトを実行すればいいだけのはずである。

# スリープ前
Get-PnpDevice -FriendlyName "E-MU E-DSP Audio Processor (WDM)" | Disable-PnpDevice -Confirm:$false -Verbose

# スリープ後
Get-PnpDevice -FriendlyName "E-MU E-DSP Audio Processor (WDM)" | Enable-PnpDevice -Confirm:$false -Verbose

ところがですね Linux なら powerd デーモンが電源状態を監視してイベント発生時に /etc/acpi 以下のスクリプトを実行してくれるけど Windows にはそんなフレームワークは無いのだ。 うーん NT 4.0 発売から 30 年経ってんのにいまだにこれマジ？

いちおうフォロー入れとくとタスクスケジューラーを使ってイベントログを監視し

  • Kernel-Power 42 … 休止状態への移行
  • Kernel-Power 107 … 休止状態からの復帰

を拾って処理を実行することはできなくはない、だがこれログに出力されるタイミングってどっちもスリープから目覚めた後になるのよね。 つまりタスクスケジューラーではスリープ前に何かをすることは不可能なのである。

電源状態をアプリケーションから監視する

ということで自分でアプリ書くしかねえとかマジかよ、俺が Win32 プログラミングなんてやったのもう何十年前だか思い出せないレベルだけどうっすらと WndProc()　でコールバック登録してとかあったよなぁ！？

MSDN 読んだら WM_POWERBROADCAST メッセージで

  • PBT_APMSUSPEND … 休止状態への移行
  • PBT_APMRESUMEAUTOMATIC … 休止状態からの復帰(自動)
  • PBT_APMRESUMESUSPEND … 休止状態からの復帰

というイベント飛んでくるの待てばいい感じか。

なお Windows 8 以降縛り PowerRegisterSuspendResumeNotification() という専用 API もあるみたいだが、まぁそれはどうでもいいや。 やってる事はどうせ一緒だろうし。

気がかりなのはこのメッセージは非同期だろうから PBT_APMSUSPEND イベント飛んできた後デバイスを無効化する時間的余裕があるやなしや。 まあデバイス無効化せずとも PatchMix DSP プロセスが死んでれば問題ないから、間に合わないならこっち殺るのが手っ取り早いか。

E-MU 謹製の監視アプリもいる

デバイスの無効化だけならオレオレ電源監視デーモンでいいけど PatchMix DSP の終了をするならば、そもそもそいつはスタートアップに登録された CtHelper.exe というドライバ付属のアプリが E-MU 1616M デバイスの死活監視しつつやってるんだよな。 そうなるとこいつの挙動も調べておかないと不整合出るよなと。

ということで次回があればそっちの解析をしていく、やる気があれば 1903 以降で動かない原因である ctoss2k.sys にもメス入れたいけどこっちは他機種のドライバ流用で逃げられるから優先度は低い。