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 回答