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.