While experimenting with Toast Notifications, I have run into an annoying little problem. If I attempt to set the audio to looping, the notification will not play any sound at all. Using non looped sound will work just fine. I am using the code from the MSDN site like so:
...
IXmlNode toastNode = toastDoc.SelectSingleNode("/toast");
((XmlElement)toastNode).SetAttribute("duration", "long");
XmlElement audio = toastDoc.CreateElement("audio");
audio.SetAttribute("src", "ms-winsoundevent:Notification.Looping.Alarm2");
audio.SetAttribute("loop", "true");
toastNode.AppendChild(audio);
...
And it simply will not play sound if I set the 'loop' attribute to true. I have tried manually setting 'silent' to 'false' as well as picking from different sound options listed here: http://msdn.microsoft.com/en-us/library/windows/apps/hh761492.aspx
I have confirmed that the toast are lasting for 25 seconds (as specified by the long duration) and I have tried reordering the audio attributes, all to no avail. Can anyone tell me what the heck is going on here?
So it turns out that the toast audio is working just fine. The actual problem is admittedly odd. After digging around a lot, I found that the alarm / call / files that get used in the loops are all silent on my machine, i.e. they have no audio in them. This seemed really weird since they came from the OS installer. After more investigation, I found that each of my machines (I have two) that have an N Edition of Windows 8 installed has these silent files. My other machines, which have the normal editions have files that actually produce audio. So far I have solved the problem by changing the permissions to the "c:\windows\media" directory (something I don't like doing) and copying the real files over by hand. I plan on submitting a report to Connect, and I will post new material if I discover a less painful way to fix the issue.
UPDATE:
Installing the Media Features Pack from MS will fix the issue. The Alarm*.wav and Call*.wav audio files in C:\windows\media will have audible content. This kind of bites in my opinion because I didn't install media player for a reason, and now my N-Edition customers may experience what seems to be a bug.
Related
I considered cross posting to the Super User site or similar but don't know how. As you will see this is not just a programming question.
I developed some C# code to communicate with an Onset InTemp thermometer via Bluetooth Low Energy (BLE). It works fine for a long time. I'm able to get beacons (which have the thermometer data) and also connect, get services and characteristics in case I need to get missed data or set parameters on the thermometer. However, after about 8 hours (can be as much as 24 hours) of continuously receiving beacons and connecting, getting historical data, etc., my app hangs on this line:
var gatt = await device.GetGattServicesAsync();
I put lines before and after this line and verified it's clearly hanging on this line. Again, it can be after 8 hours or 24 hours of use. It certainly chugs along just fine for quite a time. Killing and restarting the program is of no help. It hangs on the first call to:
device = await BluetoothLEDevice.FromBluetoothAddressAsync(args.BluetoothAddress);
Only rebooting the PC fixes the problem. This is not surprising given the messages in the Windows Event Logs before it hangs:
The Bluetooth driver expected an HCI event with a certain size but did not receive it.
It's for this reason that I stated that this might be a SuperUser board question. No matter how badly I programmed my code :), killing the program should get BLE working again. FWIW, I did try disabling/re-enabling BLE through settings before rebooting.
I have found some links to this problem, but nothing very definitive.
I'm also working on writing a smaller, complete program to show the problem. So far, I can't get example program to fail from which I conclude that either (1) I haven't let it run long enough, or (2) I'm not fully duplicating what is going on with my full program. Perhaps I'm not putting as much pressure on the BLE drivers or I'm not listening for beacons and attempting to connect in the same ratios or with the same timing.
I should say that I see a lot of gripes about Windows implementation of the BLE Host layer and BLE drivers. Unfortunately, I'm stuck with Windows. Nordic also suggested that everything I'm reporting is a "known problem" and using their Nordic dongle will solve the problem. See for example: https://devzone.nordicsemi.com/f/nordic-q-a/65516/using-nrf52840-dongle-as-receiver-client-for-onset-thermometer.
That may well be true, but it would be a lot of work as they have libraries in C++ and Node.JS but not C#.
Any help is greatly appreciated.
Thank you!
I have an asp.net application that runs on an MC9090 scan gun running Windows CE 5.0. I'm trying to play a sound on the scanner through the website. I used the code below to play the sound on the scanner, but it sounds like a crackle instead of the sound.
<embed id ="MyAudio" src="/External/MySound.mp3" type="audio/mpeg" autostart="true" loop="false" />
Doing my research I found out that even when I play sounds directly on the scan gun, it doesn't play the sound instead it just plays the short crackle sound. So I thought the speakers were not working, but all the system sounds work fine. scan beeps and error beeps.
This is happening on two different scan guns. Does anyone have any ideas why even when I click on a wav file in the explorer on the scan gun it still doesn't play the sound correctly. Any help would be great.
EDIT: Also to clarify the system sounds are working on the scanner but nothing plays when called in the website, example:
System.Media.SystemSounds.Asterisk.Play();
Not all 9090s have working sound cards. Some need to have their core updated, which would involve contacting Motorola. You will still hear the scan and error beeps because all the 9090 devices have a built in beeper, that will take over if the speaker is not functioning properly.
The best way to test this would be to use OTL:
Go to the Application directory and launch OTL.exe
Click the "Test Apps" option.
Click the 'SelfTest" option.
Select "Speaker" and then click the "Start" button.
Select any wav file from the drop down and then listen. If it fails, you will see an error on the bottom of the form. Even on an error, you should still hear something because the device will attempt to use the Beeper instead.
If you don't have OTL, you could attempt to compare the wav files with another device that is known to have working sound.
If it is in fact an issue with the Speaker, you should contact Zebra because the device needs an update.
Also, to my understanding, the procedure you are calling will only attempt to play the wav file and not use the Beeper on failure. Which would cause the error of no sound to be played.
I have a problem with playing audio tracks with the AudioPlaybackAgent on devices running WP8. It works perfectly on WP7, but not on WP8. It only works sometimes for WP8, so there is no clear steps on how to reproduce it either. What seems to be the problem is that when a new track is about to play and I have set the BackgroundAudioPlayer.Instance.Track to the new AudioTrack, it don't receive onPlaystateChanged.TrackReady.
Why is this? I don't receive onError either.
Is there a known bug with playing audio on WP8 devices? It happens about 50% of the time, and the same track can both work and not work. What can be the problem here? Please help. Any from Microsoft that can help on this? That would be highly appreciated.
The fact this occurs 50% of the time makes me suspect this could be a race condition which didn't occur on WP7.
Are you doing any thread-locking (using Mutex, lock() etc) from your background agent when changing tracks? I had something similar for a WP8 background audio app that was previously working on WP7 and traced it back to a deadlock in my code.
Don't forget that WP8 now has dual-core processors and is more likely to hit such issues. See this post from someone on the Windows Phone team about back-compat between WP8 and 7. Especially interesting is the section named "Runtime behavior changes" in that post.
I have a working program that could load and play a video file. It has a canvas over the video on which an interrupt draws events loaded from a separate text or csv file. It was all working marvelously and I have been using it for weeks, but I wanted to add fft and video analysis functionality. I added Exocortex to the project and now loaded videos don't play and loaded events don't display on the canvas.
I can't think of why this would have any effect, and it's the only change that's been made. The rest of the program appears to work normally. Does Exocortex have anything about it that might interfere with MediaElements or Canvases?
EDIT: Further investigation suggests the problem is not with Exocortex, but with the mediaelement and a recent Windows 7 Update. The solution is still evading me.
A reformatting my computer with a new install of windows 7 has fixed the problem. In other words, I have absolutely no idea what was broken and what wasn't working. Windows Media player was experiencing the same problem.
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).