上个月的连载中，我介绍了如何利用ChatGPT和OpenAI的代码生成AI“Codex”，在短短30分钟内开发出支持ASIO的音乐播放器“DAL Player”。该播放器基于C#/.NET 10/WPF/NAudio构建，初版（Ver0.1）实现了最基本的播放功能，随后在Ver0.2中增加了ASIO控制面板按钮。然而，切换不同采样率的WAV文件时，应用程序会崩溃，这个bug被留作下一步的修复目标。
这次是该项目的后续报道。我们不仅修复了bug，还发现了意想不到的根本原因，最终将源代码和可执行文件一并发布到了GitHub。
与AI协作开发的过程充满了意外和趣味，接下来我将分享约3小时内与AI互动的详细经历。
从环境恢复开始
准备开始第二阶段开发时，首先需要恢复开发环境。作为经常使用各种软硬件进行实验的我，至少每月一次，甚至有时几乎每天都会格式化电脑，恢复到全新状态。
实际上，我是通过Acronis TrueImage备份恢复环境，但由于在开发DAL Player Ver0.2后进行了电脑初始化，所有开发环境都被清空，甚至忘记了之前如何安装Codex。
幸好项目的[source]文件夹完整备份了，我在ChatGPT的帮助下重新安装了新的ChatGPT桌面应用（现已集成Codex）和Visual Studio Community 2026，并将备份文件还原到原位置，重新开始工作。
特别注意的是，Codex之前创建了一个稍显特殊的Git结构。
.git目录并非普通文件夹，而是指向名为[repo-ultimate]的指针文件。为了确认其完整性，我让Codex以只读方式检查该结构。
结果非常理想。源代码、Git提交历史、main分支和Ver0.2标签均完好无损。唯一缺失的是NuGet的NAudio包，但这可以在恢复时自动重新下载。
实际执行NuGet恢复和Debug构建，零警告零错误顺利完成。启动重新构建的DAL Player Ver0.2，确认其功能正常，成功回到上次开发结束的状态。
当然，这一切并非我完全理解后独立完成，而是依赖ChatGPT的指导。每一步都是询问ChatGPT“接下来怎么办？”，它会告诉我向Codex发送什么提示，我照做即可。
感觉上几乎不需要思考，完全按照AI的指示操作，AI在这段合作中处于主导地位。
确定三大开发目标
环境准备就绪后，我与ChatGPT讨论了接下来的开发重点，主要有三项：
- 修复上次发现的采样率切换导致崩溃的问题
- 在GitHub上公开源代码
- 支持除WAV外的MP3和FLAC等其他音频格式
此外，还有一些使用体验上的改进和播放器功能的提升需求。
ChatGPT建议按顺序先修复崩溃，再发布GitHub，最后扩展格式支持，这样发布给用户的版本更稳定可靠。我采纳了这一建议。
崩溃原因并非采样率切换
首先着手修复崩溃。
Codex分析Ver0.2代码后指出，调用AsioOut.Stop()后立即调用Dispose()可能导致问题。
根据NAudio设计规范，Stop()完成应通过PlaybackStopped事件确认，若未等待事件完成就创建新的ASIO实例，可能与驱动的重设操作冲突。
因此，我让Codex将Stop()改为StopAsync()，并等待PlaybackStopped事件后再销毁对象。
Debug构建成功后，在实际设备上测试44.1kHz→48kHz→96kHz切换，初步无崩溃。
然而，进一步测试多种WAV文件时发现，有些文件能正常播放，有些则不能。
分析后发现，问题多集中在24bit音频文件上，但并非所有24bit文件都出错。
我将测试结果整理给ChatGPT：
- 44.1kHz/16bit：正常
- 48kHz/24bit（Pro Tools导出）：异常
- 96kHz/32bit：正常
- 96kHz/24bit：无响应且后续文件无法播放
- 各种录音设备生成的24bit文件：均异常
由此可见，最初认为采样率切换导致崩溃的判断是错误的。
SOUND FORGE实验揭示关键
将测试结果反馈给Codex后，它怀疑WAV头结构差异（如是否为Extensible格式、有效位数处理）可能是原因，但不建议盲目修改。
我决定亲自验证：用波形编辑软件SOUND FORGE Pro打开无法播放的24bit WAV文件，不改变采样率，只将位深改为32bit后导出，再用DAL Player播放。
结果非常明确：转换为32bit后，之前无法播放的文件均能正常播放。
同一音源、采样率不变，仅改变位深即可切换播放状态。
这强烈表明问题出在24bit PCM数据传递给ASIO的路径上，而非采样率。
Codex进一步分析了Pro Tools和SOUND FORGE导出的WAV头，确认文件格式正确无损。
结论是，DAL Player直接将24bit PCM（每样本3字节packed格式）从WaveFileReader传给AsioOut的方式存在缺陷。
通过24bit转32bit浮点数解决问题
修复方案是：在传给ASIO前，将WAV读取的音频数据转换为32bit IEEE浮点格式的IWaveProvider，保持采样率、声道数和播放时长不变，仅改变样本表示形式。
统一16bit、24bit、32bit WAV的处理路径，消除位深差异带来的兼容问题。
Codex完成实现后，Debug构建无警告无错误。实机测试包括Pro Tools导出的48kHz/24bit、SOUND FORGE导出的96kHz/24bit、各种录音设备的24bit文件，以及16bit和32bit文件，全部正常播放，采样率切换也无异常。
这次修复过程从“采样率切换导致崩溃”到“24bit PCM处理问题”的转变，体现了与AI协作调试的独特体验。
修复后的DAL Player Ver0.3完成，我更新了CHANGELOG和README，并以“Fix ASIO playback and 24-bit WAV support”为提交信息，保留Ver0.2标签，新建v0.3标签。
正式发布到GitHub
Ver0.3稳定后，下一步是将项目公开到GitHub。
虽然我早有GitHub账号，但这是首次自己发布项目，依然依赖ChatGPT指导。
按照ChatGPT指示，我登录GitHub，创建空的公共仓库“dal-player”，将main分支及v0.2、v0.3标签推送上去。认证通过Git Credential Manager的浏览器认证，过程顺利。
需要注意的是，推送到GitHub的是源代码、README、LICENSE、CHANGELOG等文件，构建好的可执行文件未包含在内。
这是因为.gitignore排除了bin和obj目录，这符合GitHub的常规做法。若要发布可执行文件，应使用GitHub Releases功能。
体积庞大的“极简播放器”
制作发布版时，我希望用户无需安装Visual Studio或.NET Runtime即可运行，于是选择了“self-contained”版本，包含完整.NET 10 Windows Desktop Runtime。
但生成的文件夹包含465个文件，解压后约165MB。对于只支持ASIO和播放WAV的简单播放器来说，体积过于庞大。
为比较，我测试了另外两种发布方式：
| 发布方式 | 文件数 | ZIP大小 | 需要.NET Runtime |
|---|---|---|---|
| Framework-dependent | 11 | 约0.31MB | 需要用户预装 |
| Self-contained | 465 | 约72.5MB | 不需要 |
| Self-contained Single-file | 1 | 约68.2MB | 不需要 |
Framework-dependent版本体积小，但依赖用户预先安装.NET 10 Desktop Runtime；Self-contained Single-file版本将所有内容打包成一个约165MB的可执行文件，文件数量最少，用户体验最好。
最终我选择Single-file版本作为正式发布版。
我还在另一台未安装Visual Studio和.NET Runtime的电脑上测试，确认能正常启动、识别ASIO驱动、播放24bit WAV及显示ASIO控制面板。
这也反映出现代.NET应用发布的现状：即使是极简播放器，包含完整运行时后体积也会大幅膨胀。
通过GitHub Releases正式发布
最后，我在GitHub的Releases页面手动创建了v0.3版本发布，标题为“DAL Player v0.3”，说明了支持ASIO播放、16/24/32bit PCM兼容、Single-file版本等信息，并附上SHA-256校验值和经过验证的ZIP文件。
至此，DAL Player不仅有了源代码仓库，也成为了任何人都能下载并直接试用的软件。
项目主页：https://github.com/kenfujimoto/dal-player
v0.3下载页：https://github.com/kenfujimoto/dal-player/releases/tag/v0.3
下一步计划：支持更多格式
这次从环境恢复开始，经历了“采样率切换崩溃”误判为“24bit PCM处理问题”的过程，最终实现了GitHub公开发布。
与ChatGPT的协作、Codex的代码实现和实际设备测试相结合，体现了人机合作的开发模式——虽然主导权似乎在AI手中。
接下来计划支持除WAV外的MP3、FLAC等格式，提升使用体验，并扩展支持WASAPI Exclusive等Windows音频接口。
我会继续将DAL Player作为实验工具，逐步推进这个项目，期待大家继续关注。
