Hacktoberfest 2026：维护者为十月标记出来的 issue，仍然开放、适合新手。 浏览 Hacktoberfest issue

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

未关闭 适合新手
  • 哪里不对？
#291 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 6 天内回复

还没有人认领这个 Issue。

评估

难度
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
星标
198
派生
40
平均合并
5 天 13 小时
30 天内合并 PR
8

环境准备

  • 没有 Dockerfile 或 Docker Compose 文件
  • 有 Pull Request 模板
  • 没有贡献指南

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

Sendspin/sendspin-python-cli 的其他 Issue

查看 Sendspin/sendspin-python-cli 的全部 Issue

相似的 Issue

更多 Python Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。