2

我们正在开发一款针对 Symbol 制造的设备的移动应用程序。在这些设备上，Windows Mobile 就是系统。

我们的应用程序播放声音（实际上是简单的哔声）：我们使用 Symbol 提供的开发工具包来访问设备声卡以播放声音。

这是我们使用的代码：

Symbol.Audio.Device MyDevice = (Symbol.Audio.Device)Symbol.StandardForms.SelectDevice.Select(
      Symbol.Audio.Controller.Title,
      Symbol.Audio.Device.AvailableDevices);

Symbol.Audio.Controller sound_card = new Symbol.Audio.StandardAudio(MyDevice);

int Duration = 15;
int Frequency = 3000;
sound_card.PlayAudio(Duration, Frequency);

持续时间以毫秒为单位，频率以赫兹为单位。

几乎总是正确播放声音（我的意思是声音以正确的持续时间播放）。

但有时，声音播放的时间要长得多（播放大约一秒钟）。

我们想避免这样的事情，因为它对用户的耳朵来说是相当令人不安的。

我不知道为什么会存在这种行为：短音和长音之间的应用程序没有任何变化。应用程序数据相同，应用程序不执行其他任务和后台任务。

当向用户显示特定屏幕时会播放此哔声（我的意思是创建了一个 Form 对象，并在其初始化期间播放哔声）。所以我认为，也许，当设备cpu被强烈使用时会播放声音。并且由于 cpu 很忙，它无法在正确的时间内成功播放声音。

也许这个问题是 Symbol Developer 工具包特有的？

我怎样才能避免这么长的哔哔声？

编辑

我实现了 ctacke 解决方案：我在具有高优先级的单独线程中播放哔哔声。此外，我增加了声音的持续时间（我设置了 30 毫秒而不是 15：也许持续时间越长，系统在正确的时间内播放声音的效果就越好）。

我还不知道这个实现是否解决了这个问题；由于 bug 的不确定性，需要一些时间才能确保问题得到解决。

4

2 回答 2

1

我的猜测是，您在播放音频时得到了 GC，并且对开/关造成了严重破坏（尽管很难确切知道 Symbol 是如何实现调用的）。

作为第一次尝试，我会将播放的声音扔到一个单独的线程中，并使用 P/Invoke 将其优先级提高到 CeSetThreadPriority（不仅仅是托管的 Thread.Priority 属性）。这将排除您对驱动程序或其他东西的影响，尽管暂停的长度表明这不是一个量子问题，而更有可能是一个应用程序问题。

如果事实证明它与 GC 相关（RPM 可能会帮助您确定这一点），那么我将创建一个本地库来处理音频并 P/Invoke 它。GC 不能与原生线程混淆，所以你会保持你的确定性。

于 2010-03-04T15:11:05.920 回答
0

确保您使用的是最新的 SDK。您可能已经知道，Symbol 现在是摩托罗拉的一部分，他们的 Symbol Developer Kit 现在更名为 Enterprise Mobility Developer Kit。EMDK 的最新版本是v2.3，于 1 月发布。

如果是他们的 SDK 中的错误，您遇到的问题可能已经修复（您可以在他们的支持网站上找到所有 SDK 的发行说明）。

于 2010-03-04T17:38:24.640 回答