Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

Windows: stream.start() fails with "Unanticipated host error -9999 / WdmSyncIoctl" because the audio executor thread never initializes COM

オープン 初心者向け
  • 何か問題がありますか？
#291 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 6 日以内に返信

まだ誰も着手していません。

評価

難易度
2/5
見積もり時間
1〜3時間
初心者へのやさしさ
62/100
issue の種類
バグ
明瞭さ
明確に書かれている
活発さ
活発
技術スタック
python
領域
audio-video-rtc, cli

調査の方向性

修正は sendspin/audio.py の AudioPlayer.__init__ に入れてください。そこでは _stream_executor が initializer なしで作成されています。start、stop、close がそのexecutorにどのように投入されているかを読み、その後、ワーカースレッド用に Windows 限定の COM 初期化を追加してください。WASAPI デバイスで stream.start() が PaErrorCode -9999 を送出しなくなれば完了です。これは Windows マシンでの確認が必要です。レポート内の再接続ループの注記は別の問題なので、この修正にまとめないでください。

索引モデルが issue の本文から書いたものです。

説明

Environment

Windows 11, Python 3.12.10 (venv), sendspin 7.6.0 (installed from the 7.6.0 tag), aiosendspin 9.1.1, sounddevice 0.5.6
Output device: a Realtek "Speakers" endpoint, host API "Windows WASAPI", 48 kHz
Server: Music Assistant 2.10.6 (Sendspin provider)
What happens sendspin daemon --url ws://:8927/sendspin --audio-device 12 connects and pairs fine, but as soon as playback starts:

INFO:sendspin.audio:Stream STARTED: 3 chunks, 0.29 seconds buffered
ERROR:sendspin.audio:Stream operation start failed
sounddevice.PortAudioError: Error starting stream: Unanticipated host error [PaErrorCode -9999]:
'WdmSyncIoctl: DeviceIoControl GLE = 0x00000490 ...' [Windows WDM-KS error 0]
(The WDM-KS text is the generic "last host error", the device itself is a WASAPI one.) Nothing is heard.

Isolated reproduction (no Sendspin involved) Same device, RawOutputStream(samplerate=48000, channels=2, dtype="int24", blocksize=2048, latency="high"):

create + start + stop in the main thread: works
create in main thread, start() in another thread: fails with the error above
create and start() both inside a secondary thread: fails
same, but calling ctypes.windll.ole32.CoInitializeEx(None, 0) at the beginning of that thread: works
So PortAudio's WASAPI backend needs COM initialized on the thread that opens/starts the stream, and AudioPlayer._stream_executor (a 1-worker ThreadPoolExecutor) never does that; stream.start()/stop()/close() are all submitted to it.

Fix that works for me (sendspin/audio.py, AudioPlayer.init):

def _com_init() -> None:
if sys.platform == "win32":
import ctypes
ctypes.windll.ole32.CoInitializeEx(None, 0) # COINIT_MULTITHREADED

self._stream_executor = concurrent.futures.ThreadPoolExecutor(
max_workers=1, thread_name_prefix="sendspin-audio", initializer=_com_init
)
With this, a 3-beep test file played from Music Assistant through the Sendspin daemon comes out of the speakers correctly.

Happy to open a PR if you prefer.

Also noticed (minor): running two daemons with the same identity makes them kick each other in a tight reconnect loop (thousands of connect/disconnect lines per second). A backoff on "replaced by a new connection" would avoid log floods.

主要言語
Python
スター
195
フォーク
39
平均マージ
5日 13時間
マージ済み PR（30日）
8

環境構築

このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

Sendspin/sendspin-python-cli のほかの issue

Sendspin/sendspin-python-cli の issue をすべて見る

似ている issue

Python の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。