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.
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.
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).
Related
How can I avoid user from being able to record app's audio in C#?
It's due to some copyright issues and must be done in my project.
In general, this isn't possible. If you can hear something, you can record it. Obviously that process would be lossy, but there is absolutely nothing you can do to prevent it (the laws of physics say so).
I should clarify that it appears not to be possible to prevent digital recording via WASAPI on windows machines, either. Even if this was possible, it would not be possible to prevent someone plugging in their own sound card which supports digital recording (and some do).
I'm having a problem with timing in XNA 4.0, writing in C# and using Visual Studio 2010 express.
I'm not writing a game exactly, but I'm trying to use XNA for it's simplified content pipeline, drawing, and timing. What I'm trying to do is write a program that can time a user's response to onscreen stimuli at very fine resolutions - less than 5 ms, ideally.
To do this, I need to call the update routine (so I can poll the keyboard) no less than once every 5 ms. Even in variable step timing, I can't get the timing below about 16 ms per call. This doesn't appear to have anything to do with the amount of processing that I do in my update and draw routines. I can comment out everything in both routines and the program still spends roughly 16.66 ms on each iteration.
In fixed step timing, I can set the target to about 60 iterations per second (16.66 ms between updates), but if I try to go any faster than that, the IsRunningSlowly flag is tripped, and the game seems to try to compensate - several iterations will run faster than 60 iterations per second, and then 1 iteration will run slower.
So I guess my question is this: is the 60 iterations per second the upper limit for XNA? Is it possible to circumvent it? Should I just ditch XNA altogether?
I really appreciate your time and knowledge. Thanks in advance.
The problem you are having is due to VSync. Disable it in XNA by adding this line to your game's constructor (assuming you have the default GraphicsDeviceManager graphics):
graphics.SynchronizeWithVerticalRetrace = false;
This will allow your game to run "fast as possible". This should be "good enough" for your purposes.
See this blog post for a description of timing in XNA.
If you wanted to get more fancy: For XNA on Windows I would consider using the Windows event loop and a high resolution timer directly. Note that Game in XNA (on Windows and Xbox 360) is entirely optional.
You'd want to move as many slow operations (eg: update and draw) and blocking operations (eg: vsync) off the main thread. Note that input in XNA can only be handled on the main thread. I think you can create the graphics device on a separate thread - although I have never tried it.
You should note that, if you are measuring reaction times, there is lag in between sending a "present" command to the GPU, and that content actually appearing on screen.
I'm not expert to XNA development, but, I know I have already similar "problem" in windows phone. (slowly problem).
When you have a lot of treatment, use multithreading programming,,
msdn : "Applications that use multithreading are more responsive to user input because the user interface stays active as processor-intensive tasks execute on separate threads. Multithreading is also useful when you create scalable applications, because you can add threads as the workload increases. "
Hope I help you...
We are creating a display system which we will be running on top of Windows 7 embedded.
The computers will not have keyboard or mouse, thus will have no direct user interaction.
Since these computers will only be used during certain times we would like to define schedules for them and make them power off (including their screens), and automatically power on again at specific times.
For this, we need to be able to set the bios WakeOnRTC timer from code. It is not sufficient to wake from hibernate or sleep, as referred to at Schedule machine to wake up.
I know from others that MythBuntu can do this, but that is Linux-based.
I've also heard this is easier to achieve with UEFI-bioses that are emerging.
At this point we are open to select any bios if anyone has a solution.
I'm not going to put too much because this question has already been answered, see the following links.
C#: How to wake up system which has been shutdown?
http://www.codeproject.com/Articles/49798/Wake-the-PC-from-standby-or-hibernation
In short the solution revolves around the following two Win32 API functions:
CreateWaitableTimer
SetWaitableTimer
We are developing a platform with Windows CE 5 (soon to be upgraded to 6) in .Net CF 2 C#.
What we have recently discovered is that if we are touching the touchscreen while using our peripheral, the peripheral data trafic times out and our application crashes. So it seems like the touchscreen is blocking it. As a quick fix we would like to disable the touchscreen while using the peripheral, and the reenabling it.
So our question is, how do we do it?
Do we need some extra packages in the OS build or can we do it manually. We have had a look at touchpaneldisable() and touchpanelenable(...). But the enable method requires a handle to the callback function. So I have no idea on how to fix this.
From an application perspective tehre really isn't a fix. Touchpanel ddrivers a re alittle different than otehrs becasue they get loaded by (and into) GWES, rather than device.exe. They are not designed to be disabled and enabled, though some OEMs do provide the capability (typically by just masking the touch panel interrupt).
It sounds like the touchpanel sampling rate is really high and the device is saturating the processor when it startes sampling. It's something that the OEM probably needs to fix. Some OEMs do provide registry entries to adjust the driver behavior, so check with them to see if this might be available to you. In that case you may be able to fix the issue yourself.
If you have the BSP you might want to go through this blog post as it suggest possible bottle necks for the touch driver.
I'm looking for an audio library that works with .NET that allows for smooth looping. I've tried DirectX AudioVideoPlayback and Mentalis. Both are easy to use, but the looping skips a bit. I'm wondering if that's my fault or theirs. I have sound samples that I know can loop cleanly (WinAmp can do it fine) but I can't get my C# app to do the same. What library could I use, or what could I fix in my app to get it to loop cleanly with the libraries I have?
UPDATE: FMOD has been able to loop my audio, but the problem is that the .net wrapper I have only loads files one way. I can't play a sound effect more than once because they get disposed when playback finishes, and sometimes it hangs whenever a sound is supposed to be played. I know I could just reload the sound to play it again, but I don't want to hit the disk every time a gunshot is fired. Should I just reach into the C++ layer myself and skip the .NET wrappers?
You could try FMOD which is free for non-commercial use.
I would double-check that the sound really loops cleanly - specifically, that the first sample and the last sample are close (or equal), otherwise you'll hear a click. WinAMP could conceivably do some special processing to eliminate the click.
UPDATE: FMOD comes with a whole bunch of samples in C# that show the right way to do stuff. The example called "3d" shows, among other things, a cleanly looping sound. You should be able to rip out the code that handles the looping without utilising the 3D features.