使用 C# 中的符号开发工具包播放声音

发布于 2024-08-23 18:20:19 字数 1086 浏览 3 评论 0原文

我们正在开发一款针对 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 繁忙,因此无法成功播放正确的持续时间的声音。

也许这个问题是符号开发工具包特有的?

如何避免如此长的蜂鸣声?

编辑

我实现了 ctacke 解决方案:我在一个单独的线程中以高优先级播放蜂鸣声。另外,我增加了声音的持续时间(我设置了 30 毫秒而不是 15 毫秒:也许持续时间越长,系统在正确的时间内播放声音的效果就越好)。

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

We are developing a mobile application, which targets devices manufactured by Symbol. On these devices, Windows Mobile is the system.

Our application play sounds (simple beeps in fact) : we use the developer kit provided by Symbol to access the device sound card in order to play sounds.

Here is the code we use:

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);

With duration in milliseconds and frequency in Hertz.

Almost always, the sound is correctly played (I mean the sounds is played with the right duration).

But sometimes, the sound is played much longer (it is played during about one second).

We would like to avoid such a thing, because it is quite disturbing for users' ears.

I have no idea why this behavior exists: nothing change in the application between a short sound and a long sound. The application data is the same, no other task and no background task is executed by the application.

This beep is played when a particular screen is displayed to the user (I mean a Form object is created, and during its initialization, the beep is played). So I think that, maybe, the sound is played when the device cpu is strongly used. And because the cpu is busy, it does not succeed to play the sound for the right duration.

Maybe this problem is specific to the Symbol Developer kit?

How can I avoid such longer beeps?

Edit

I implemented the ctacke solution: I play the beep in a separate thread with high priority. Also, I increased the duration of the sound (I put 30 milliseconds instead of 15: maybe the longer the duration is, the better the system achieve to play the sound during the correct amount of time).

I don't know yet whether this implementation solve this problem or does not; because of the indeterminism of the bug, it will take some time to ensure the problem is solved.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

獨角戲 2024-08-30 18:20:19

我的猜测是,当音频正在播放时,您会收到 GC,这对开/关造成了严重破坏(尽管不知道 Symbol 是如何实现调用的,很难说)。

作为第一次尝试,我将把正在播放的声音扔到一个单独的线程中,并使用 P/Invoke to CeSetThreadPriority(不仅仅是托管的 Thread.Priority 属性)将其优先级调高。这将排除您因驾驶员或其他原因而丢失量子的情况,尽管暂停的时间长度表明这不是量子问题,而更可能是应用程序问题。

如果事实证明它与 GC 有关(RPM 可能会帮助您确定这一点),那么我会创建一个本地库来处理音频并 P/Invoke 它。 GC 不能干扰本机线程,因此您可以保持确定性。

My guess is that you're getting a GC while the audio is playing and that is playing havoc with the on/off (though without knowing exactly how Symbol implemented the call it's hard to say).

As a first stab, I'd toss the sound playing into a separate thread and crank it's priority way up using a P/Invoke to CeSetThreadPriority (not just the managed Thread.Priority property). THis would rule out you losing quantum to a driver or something, though the length of the pause suggests that it's not a quantum issue, but more likely an app issue.

If it turns out that it is related to GC (RPM would probably help you determine that), then I'd create a native library that does the audio and P/Invoke it. The GC can't mess with nati8ve threads, so you'd keep your determinism.

骄兵必败 2024-08-30 18:20:19

确保您使用的是最新的 SDK。您可能已经知道,Symbol 现在是 Motorola 的一部分,并且他们的 Symbol 开发人员套件现已重命名为企业移动开发人员套件。 EMDK 的最新版本是 v2.3 并于一月份发布。

如果您遇到的问题是 SDK 中的错误,则可能已经得到解决(您可以在其 支持网站)。

Make sure you're using the latest SDK. As you might already know Symbol is now part of Motorola and their Symbol Developer Kit is now renamed to Enterprise Mobility Developer Kit. The latest version of the EMDK is v2.3 and was released in January.

Maybe the problem you're experiencing has already been fixed if it was a bug in their SDK (you find release notes of all SDKs on their support website).

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文