views:

258

answers:

3

Hello,

We are developping 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 developper 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 the 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 success to play the sound during the right duration.

Do you have already met this problem before ? (Maybe it is specific to the Symbol Developper kit, and some of you may have already used id).

Do you know a way to 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.

Thanks for your answers, it helped me a lot.

A: 

i have a feeling that it is because such small intervals of time can't be measured precisely especially via .net. try use more low level functions like this:

[DllImport("kernel32.dll")]
public static extern bool Beep(int freq,int duration);
Andrey
Not true in Windows CE.
ctacke
what exactly is not true? please explain
Andrey
That small intervals can't be measured precisely in .NET. While true on the desktop (due to the NT scheduler architecture) you can get sub-ms accuracy doing measurements in CE - even with managed code.
ctacke
Also, it's worth noting that Beep doesn't exist in CE, which is why he's trying to use the Symbol API in the first place.
ctacke
ok, i was wrong :) so there may be a bug in Symbol API.
Andrey
A: 

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.

ctacke
It sounds good, I'll try it.
OutOfBound
A: 

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

tomlog
I am using the v2.1 and no related bug is marked as resolved in the newer versions. But ask them for support should be a good idea for me.
OutOfBound