MIDI 데드락의 본격적 원인 규명 및 최종 해결

  • 발단: RME 컨텐션 의심 → AMD/온보드 오디오 디바이스 정리 작업 진행 중 MIDI 무한 로딩 재발
  • 서비스 자체 데드락 확인: MidiSrv 서비스가 중지 요청에도 응답 없음 (services.msc, PowerShell Stop-Service, taskkill 전부 실패) → GitHub Issue #939의 순환 락(circular lock) 데드락 버그와 정확히 일치하는 패턴으로 확인
  • 임시 해결책: sc config midisrv start= disabled로 서비스 자체 비활성화 → 레거시 경로 전환으로 안정적 재실행 확보
  • 부작용 발견: MidiSrv를 끄니 ChoiSauce 100 페이더가 인식 자체가 안 됨 (범용 USB Audio Class 기반 KS 드라이버라 새 스택이 열거를 전담하는 구조 때문)
  • 트레이드오프 확정: MidiSrv 켜면 ChoiSauce 인식되지만 재실행 시 데드락 / 끄면 안정적이지만 ChoiSauce 인식 불가
  • 임시 운영: 건반 내장 페이더로 대체
  • 최종 해결: Discord에서 동일 증상(Cubase + Choisauce) 사례 발견 → 원인은 Nuendo가 ChoiSauce를 DirectMusic(레거시)과 Windows MIDI(신규) 두 API 경로로 동시에 열거하려다 핸들 경합을 일으킨 것으로 확인
    https://discord.com/channels/980245825202552942/1487641314223980595/1528283395514171495
 

Discord - Group Chat That’s All Fun & Games

Discord is great for playing games and chilling with friends, or even building a worldwide community. Customize your own space to talk, play, and hang out.

discord.com

하아.... 진짜... 삽질의 대장정은 이분 덕분에 잘 마무리 되었다.

  • 해결 설정: MIDI Port Setup에서 "Use Device WinRT MIDI", "Use Device DirectMusic" 체크 해제 → Windows MIDI 단일 경로로 통일 → ChoiSauce 정상 인식 + 재실행 안정성 확보로 완전 해결

전체를 관통하는 핵심 교훈:

  1. 새 Windows MIDI Services 스택 환경에서는 하나의 디바이스가 여러 API 경로에 동시에 걸치지 않도록 단일 경로로 통일하는 것이 핵심 원칙
  2. 오디오/MIDI 디바이스의 PnP 상태 변경은 반드시 Nuendo 종료 상태에서 진행
  3. 인박스(Windows 내장) 드라이버는 pnputil로 삭제 불가하며, Disable 상태도 재부팅 시 되돌아갈 수 있어 BIOS 레벨 차단이 가장 확실한 근본 대응

 

+ Recent posts