從 USB 拓樸到 Race Condition：Arturia MiniFuse 1 喚醒失效的深度除錯

前言：當工程師遇到「重開機才能解決」的問題

對於一般使用者來說，遇到硬體問題的標準流程是「拔掉重插」或「重開機」。It's works! 但對IT人員來說，這種解決方案是不可接受的。

最近我的 Arturia MiniFuse 1 音訊介面在 MacBook Pro (Apple Silicon) 喚醒後頻繁失效。症狀很詭異：裝置通電燈號沒亮，系統找不到它，但也沒有完全斷線。更慘的是，因為系統找不到外接介面，macOS 自動 Failover 切回內建麥克風與喇叭，導致 Input Monitor 產生刺耳的高頻 Audio Feedback。

這篇文章記錄了我如何從 Physical Layer (物理層) 一路排查到 Application Layer (應用層)，最終發現這是一場發生在 User Space 的 Race Condition (競爭條件) 慘案。

Phase 1: 初步診斷與軟體重啟

一開始，我直覺認為是 macOS 的 Core Audio Daemon 在喚醒時掛掉了。這是 Mac 音訊問題最常見的解法。

# 嘗試重啟 Core Audio 服務
sudo killall coreaudiod

結果：無效。 這代表問題不在 User Space 的音訊伺服器層級，而在更底層的 Kernel Space (驅動層) 或是硬體本身已經死當 (Hang)。

Phase 2: 深入 USB 拓樸 (Topology) 與描述符

既然軟體重啟無效，我使用 system_profiler 來查看 USB Bus 的狀態，試圖釐清到底是「裝置消失」還是「裝置活著但沒回應」。

system_profiler SPUSBDataType

得到的 Log 讓我發現了兩個驚人的事實：

1. 巢狀結構 (Daisy-Chain Hell)

Log 顯示我的連接路徑異常複雜： Host -> VIA Hub (Dock) -> VIA Hub (Internal) -> Terminus Hub (MiniFuse) -> MiniFuse 1

原來 MiniFuse 1 為了提供背後的 USB Hub 功能，內部整合了一顆 Terminus Technology 的 Hub 晶片。訊號經過了 4 層跳轉 (Hops)，這在 USB 協定中對時序敏感的 Isochronous Transfer (等時傳輸) 是極大的挑戰。

2. 荒謬的電源回報 (The 0mA Bug)

MiniFuse 1:
  Product ID: 0xaf80
  Current Available (mA): 500
  Current Required (mA): 0  <-- 這裡有問題

MiniFuse 是一個 Bus-Powered (靠 USB 供電) 的裝置，但當接上 Macbook Pro USB 孔後，但它的 Firmware 竟然向 OS 回報它需要 0 mA 電流。這是一個嚴重的 Firmware Bug，會誤導 macOS 的電源管理策略 (Power Management)，導致喚醒時供電優先級被降級，甚至延後供電。

物理層嘗試： 我試著繞過所有 Hub 直接將 MiniFuse 連接 MacBook Pro。雖然拓樸層級減少了，Log 變得乾淨，但喚醒失效的問題依然存在。這證明了雖然硬體設計有瑕疵，但不是導致「喚醒死鎖」的直接兇手。

Phase 3: 關鍵線索——部分列舉 (Partial Enumeration)

在一次失敗的喚醒後，我發現了一個極度矛盾的現象：

1. macOS 系統設定 (Audio MIDI Setup)：完全看不到 MiniFuse 1。
2. Arturia Control Center (原廠軟體)：顯示「已連線 (Connected)」。

這是一個 Aha! Moment。這意味著裝置的 USB 通訊其實是通的，但是處於一種「半死不活」的狀態。

USB Endpoints 的分離

USB 音訊裝置通常有兩條平行的溝通管道：

• Control Pipe (控制通道)：傳輸指令、韌體狀態（Arturia 軟體走這條）。
• Audio Stream Pipe (音訊通道)：傳輸聲音訊號（macOS Core Audio 走這條）。

現狀是：控制通道活著，但音訊通道死了。

Phase 4: 真兇現身——競爭條件 (Race Condition)

結合上述線索，以及 sudo kmutil (Kernel Management Utility) 無法卸載驅動的狀況，兇手指向了 Exclusive Mode Conflict (獨佔模式衝突)。

我推導出的故障流程如下：

1. System Wake：電腦喚醒，USB VBUS 恢復供電。
2. Race Start：

• 參賽者 A：macOS Kernel (Core Audio) 試圖掛載音訊驅動。
• 參賽者 B：Arturia 背景程式 (MiniFuse Control Center Agent) 偵測到裝置插入。

3. The Lock：Arturia 背景程式因為寫得太「勤勞」，在喚醒瞬間搶先取得了 USB 裝置的 Handle，並以獨佔模式 (Exclusive Lock) 鎖住了它。
4. Deadlock：當 Core Audio 隨後試圖掛載 Audio Stream 時，收到了 Device Busy 或握手失敗的訊號。系統判定裝置不可用，放棄掛載。
5. Result：軟體看得到（因為是它鎖的），但系統不能用（因為被鎖住了）。

驗證假設

我嘗試在問題發生時，強制殺死 Arturia 的背景程序：

# 殺死所有 Arturia 相關的 Process
sudo pkill -9 -f "MiniFuse"
sudo pkill -9 -f "Arturia"
 
# 再次重啟 Core Audio 讓系統重掃
sudo killall coreaudiod

Bingo！ 硬體燈號瞬間亮起，聲音恢復了。假設成立。

解決方案

既然知道是 User Space 的軟體在作怪，解決方案就很簡單：閹割它。

MiniFuse 本身有 NVRAM 記憶設定，根本不需要常駐背景程式。

1. 移除登入項目：在 macOS 系統設定 -> 一般 -> 登入項目 中，移除 MiniFuse Control Center。
2. 禁止背景執行：在同一頁面關閉 Arturia 的背景執行權限。
3. 自動化腳本 (Alias)：為了以防萬一，我在 .zshrc 加入了快速修復指令：

alias fixaudio='sudo pkill -9 -f "MiniFuse"; sudo pkill -9 -f "Arturia"; sudo killall coreaudiod; echo "🔪 Killed Arturia Agent & Restarted Audio."'

總結 (Takeaway)

這次除錯再次驗證了 First Principle (第一性原理) 的重要性。如果我只是盲目地重灌驅動或重開機，我永遠不會知道問題出在那個不起眼的背景程式。

給開發者的啟示： 如果你正在開發硬體相關的 Companion App，請務必處理好 Power State Management。在系統喚醒的關鍵時刻 (Critical Path)，不要去跟 OS Kernel 搶資源，否則你的軟體就會變成使用者的惡夢。

這不是硬體的錯（雖然 0mA Bug 還是很扯），這是軟體工程師在實作 USB Handshake 時的傲慢。