HTC DriverGate – 音频版

好吧，在 Windows Mobile 感觉良好的一两天之后，我们又回到了一些不必要地困扰我们设备的问题。

似乎该驱动程序再次影响了选定的 HTC 设备，包括所有当前的高端设备，如 HTC Touch Diamond、Touch Pro、HD 和 Xperia。 当声音通过耳机或扬声器定期播放（通常每 5 分钟一次）时，您会听到音频中出现短暂的“跳跃”。 声音被描述为滞后/跳过/打嗝/滴答声/昙花一现。 问题似乎在 Wave 设备驱动程序或硬件 Wave 设备本身的深处（Qualcomm 再次行动？） A2DP 中似乎不存在问题。

该问题主要影响第三方玩家，因为 HTC 似乎已经解决了该问题，但仅针对他们自己，通过构建自定义波驱动程序。

Conduits 袖珍播放器团队一直在调查这个问题，但已经灰心丧气。 这就是在这个问题上不得不说的。

我们对 HTC 音频跳过问题进行了广泛的测试，并得出结论，这不是 Conduits 可以解决的问题。 在分析了 HTC Audio Manager 程序和其他几个文件（例如 HTC 的 DirectShow Audio Renderer HTCRenderFlt2.dll 和 HTCADXRenderer4.dll）后，我们发现它们都对 WaveOut 驱动程序进行了一些非常特殊的系统调用。

以下是我们发现的一些技术细节。 首先，我们认为线程或进程优先级与问题无关。 普通的音频应用程序使用一个循环的“waveOut 缓冲区”来保持音频输出“满”，以便系统从中提取和播放音频数据。 应用程序使用标准 waveOutWrite 函数来填充这些缓冲区。 从 Pocket Player 的角度来看，这些缓冲区总是满的，调整优先级不会影响这一点。 改善音频跳过（影响 HTC TyTN）的一种方法是通过编辑 HKLM\Drivers\Builtin\WaveOut 下的注册表值来提高 WaveOut 驱动程序的线程优先级。 这种方法在这里不起作用。 有趣的是，这些跳过问题发生在台式 PC 上。 那里的问题与实时驱动程序的处理时间“太长”有关，这会阻止音频驱动程序处理下一批声音。 这发生在带有一些 MacBook 驱动程序的 Vista 中。

音频管理器使用与标准 waveOut 调用不同的输出机制——它使用 DirectShow 音频渲染器过滤器，这是另一种发送音频的方式。 查看其工作原理的内部结构，它使用的是完全不同的机制。 它使用专有的 waveOutMessage 调用来打开一个新的消息队列，然后通过该队列“流式传输”音频。

Pocket Player（和其他应用程序）可能会通过使用 HTC Audio Renderer 而不是他们自己的 waveOut 例程来解决这个问题，但是我们会失去交叉淡入淡出和其他 Pocket Player 的特定功能。 我们做了一些创建 DirectShow 过滤器图的初始测试（使用他们的音频渲染器完成），但仍然遇到了跳过，所以必须有额外的步骤。

因此，Conduits 现在将此视为制造商有义务解决的特定于设备的问题。 或者，如果 HTC 想要为他们的音频输出驱动程序记录他们特殊的“流媒体模式”，我们可以考虑适应这种模式。

如果您从 ROM 中提取 Wavedev.dll，您将看到无数关于“MP3 Streams”之类的调试消息，表明来自他们的软件的音乐的完全独立的音频路径。 如果需要，我们将重写使用 DirectShow 输出的 WaveOut 输出插件（我们的输出例程使用私有插件架构，就像我们的其他插件类型一样）。

HTC 拒绝记录他们是如何解决这个问题的，称他们不支持第三方软件。

当然，XDA-Developers 绝不会让这种情况撒谎。 Thx1200 开始为能够为这个问题提供开源解决方案并将其提供给社区的开发人员提供奖励。 目前，赏金只有 30 美元，但我相信我们可以筹集更多捐款来解决任何使用 3rd 方音频软件的人的棘手问题。

在此处阅读 XDA-Developers 的完整主题，并且如果您觉得这是需要纠正的情况，也不要忘记添加您的承诺。