I'm trying to re-purpose a code-snippet for a UWP app using Windows.Media.SpeechRecognition's SpeechRecognizer class.
The problem is that it doesn't seem to utilize the timeout that I set for EndSilenceTimeout -- yet both BabbleTimeout and InitialSilenceTimeout appear to be working just fine. Basically, a 1-2 second pause will always end the session, and I'm trying to figure out how to fix or work around this.
I've tried with both RecognizeAsync and RecognizeWithUIAsync but neither made a difference.
private async void StartRecognizing()
{
var speechRecognizer = new SpeechRecognizer();
speechRecognizer.Timeouts.EndSilenceTimeout = TimeSpan.FromSeconds(10);
speechRecognizer.Timeouts.BabbleTimeout = TimeSpan.FromSeconds(10);
speechRecognizer.Timeouts.InitialSilenceTimeout = TimeSpan.FromSeconds(10);
await speechRecognizer.CompileConstraintsAsync();
SpeechRecognitionResult speechRecognitionResult = await speechRecognizer.RecognizeAsync();
var messageDialog = new Windows.UI.Popups.MessageDialog(speechRecognitionResult.Text, "Text spoken");
await messageDialog.ShowAsync();
}
To test this, just make a new UWP app in Visual Studio and grant yourself permission to access the microphone in the package app manifest; additionally you'll need to make sure your OS itself allows for this in the Speech, inking, & typing settings on Windows 10 v1803.
Related
I am using BackgroundDownloader in my UWP app like:
private async void StartDownload()
{
var destinationFile = await KnownFolders.VideosLibrary.CreateFileAsync("temp.zip", CreationCollisionOption.GenerateUniqueName);
var backgroundDownloader = new BackgroundDownloader();
var downloadOperation = backgroundDownloader.CreateDownload(fileUrl, destinationFile);
SendUpdatableToastWithProgress();
var progressCallback = new Progress<DownloadOperation>();
progressCallback.ProgressChanged += ProgressCallback_ProgressChanged;
var opProgress = await downloadOperation.StartAsync().AsTask(progressCallback);
}
private void ProgressCallback_ProgressChanged(object sender, DownloadOperation e)
{
if (e.Progress.TotalBytesToReceive > 0)
{
var br = e.Progress.BytesReceived;
var percent = br * 1.0 / e.Progress.TotalBytesToReceive;
UpdateToastProgress(percent);
}
}
Is there any chance how can I get ProgressChanged fired even the UWP App is closed?
There is currently no reliable option on how to update BackgroundDonwloader progress in Toast notification through Progress<DownloadOperation>.
As per Microsoft documentation, BackgroundTask could be suspended or killed based on the actual system state. That could happen before the BackgroundDownloader finishes its job and your Toast notification will look like it got frozen.
The best approach here is to update your Toast progress bar in the app suspended or exited event with AdaptiveProgressBarValue.Indeterminate with appropriate texting (e.g. Finishing download in background, etc.). Based on comments from #Faywang - MSFT you can still get notifications about successful or failed download even the app is closed or suspended.
Another approach would be to use extendedExecutionUnconstrained to be able to run BackgroundTask indefinitely. In that case, you would be able to update Toast progress with 'live' data and even more, to trigger new download via BackgroundDownloader. The downside of this approach is that your app cannot be listed in Microsoft Store.
I'm developing a WPF application where I'm recording audio data with the Windows.Media.Capture.MediaCapture class. It's working if I initialize with or without parameters:
var mediaCapture = new MediaCapture();
await mediaCapture.InitializeAsync();
or I can add which microphone to use (if there are more than one):
var allAudioDevices = await DeviceInformation.FindAllAsync(DeviceClass.AudioCapture);
DeviceInformation microphone = allAudioDevices.FirstOrDefault();
MediaCaptureInitializationSettings mediaInitSettings = new MediaCaptureInitializationSettings {
AudioDeviceId = microphone.Id,
StreamingCaptureMode = StreamingCaptureMode.Audio
};
await _mediaCapture.InitializeAsync(mediaInitSettings);
The problem comes when I run my app as a UWP application (with desktop bridge). As a UWP app when it calls the InitializeAsync() method, it always throws an exception with the following (verbose :) ) error message: Element not found. The DeviceInformation object of the microphone is found correctly, so something happens during the initialization of the MediaCapture.
The Microphone capability is set in the manifest file of the bridge project.
What am I doing wrong? I'm also open to use other methods to record the voice.
I figured out that if I run the initialization on the UI thread, it works well:
await Application.Current.Dispatcher.InvokeAsync(async () => {
await mediaCapture.InitializeAsync();
});
I'm trying to register a background task and I'm getting some strange behaviour. I appears that the task itself is registering and firing at the right time; however, when it does fire it's closing my program down (with no error).
I suspect that the reason is linked to the fact that the program is not asking me is I want to allow a background task to run when I launch. I have created a declaration for the background task as a system event, and am registering like this from the App.Xaml.cs:
var builder = new BackgroundTaskBuilder();
builder.Name = "NewTask";
builder.TaskEntryPoint = "ConnectionMonitor.CheckInternet";
builder.SetTrigger(new SystemTrigger(SystemTriggerType.InternetAvailable, false));
BackgroundTaskRegistration task = builder.Register();
So, I believe my question is: why would it not ask me for permission to run a background task (which I assume will give me the answer to my main problem of why it is crashing)?
I'm not sure whether it matters, but this is a Windows Universal app (the app.xaml.cs above is in the Shared project.
The task looks like this:
BackgroundTaskDeferral _deferral = taskInstance.GetDeferral();
bool newConnected = IsConnected();
if (connected != newConnected)
{
connected = newConnected;
var notifier = ToastNotificationManager.CreateToastNotifier();
var template = ToastNotificationManager.GetTemplateContent(ToastTemplateType.ToastText02);
var element = template.GetElementsByTagName("text")[0];
element.AppendChild(template.CreateTextNode(connected ? "Connection available" : "Connection lost"));
var toast = new ToastNotification(template);
notifier.Show(toast);
}
_deferral.Complete();
You asked: why would it not ask me for permission to run a background task?
The answer is, unless your background task requires lock screen access, it does not require the user's permission to be registered. There is no user prompt, by design. One of the intents of this design is that it allows you to register a task from another task.
In Windows, you do not need to call BackgroundExecutionManager.RequestAccessAsync() except for lock screen access. Calling it will give you more quota but will require the user to approve the task.
In Windows Phone, calling RequestAccessAsync() is required no matter what, but never prompts the user with a UI. For this reason the logic in your Universal App can be shared but will likely have a #if to handle the registration differently, if relevant.
I'm working on a Windows Store App which will access the device's microphone. However, when I attempt to work with the media devices, execution gets lost in the await somewhere. So far, I've noticed this on the following three scenarios:
var devices = await DeviceInformation.FindAllAsync(DeviceClass.AudioCapture); // never returns
var inputDeviceId = MediaDevice.GetDefaultAudioCaptureId(AudioDeviceRole.Communications);
var device = await DeviceInformation.CreateFromIdAsync(inputDeviceId); // never returns
var mediaCapture = new MediaCapture();
var settings = new MediaCaptureInitializationSettings
{
StreamingCaptureMode = StreamingCaptureMode.Audio,
AudioProcessing = AudioProcessing.Default,
MediaCategory = MediaCategory.Other,
AudioDeviceId = inputDeviceId,
VideoDeviceId = "",
};
try
{
await _mediaCapture.InitializeAsync(settings); // never returns
}
catch (Exception ex)
{
throw new Exception("Microphone is not available.", ex);
}
I am using Visual Studio 2013 Update 2 RC and developing on a Surface Pro 2. I have tried debugging in Local Machine and Simulator modes but both with the same results. I do have the Microphone capability selected in the App's manifest. I expect the OS should be prompting me for access to the microphone device but I am not presented with that dialog.
Any help is greatly appreciated! Thanks in advance.
I suspect that further up your call stack, you are blocking the UI thread by calling Task.Wait or Task<T>.Result. This will cause a deadlock, as I explain on my blog.
The reason this deadlocks is because await captures a "context" (in this case, the UI context) and will use that to resume its async method. However, if the UI thread is blocked, then the async method cannot continue.
I'm trying to launch a uri from my windows 8.1 app but can't get it to launch in UseHalf mode
I researched and found that it should be done like this
LauncherOptions lo = new LauncherOptions();
lo.DesiredRemainingView = ViewSizePreference.UseHalf;
lo.DisplayApplicationPicker = true;
await Windows.System.Launcher.LaunchUriAsync(new Uri("http://www.youtube.com"),lo);
but it keeps launching the web browser in full screen
I read that the launch depends on many variables and it is not insured that these settings will be applied
my question is there a way to insure that my app and the browser will open side by side in half screen mode?
It have to work:
Uri uri = new Uri("http://www.youtube.com");
LauncherOptions options = new LauncherOptions
{
DesiredRemainingView = ViewSizePreference.UseHalf
};
await Launcher.LaunchUriAsync(uri, options);
If not, please try this long code:
ApplicationView currentAppView = ApplicationView.GetForCurrentView();
CoreApplicationView newCoreAppView = CoreApplication.CreateNewView();
newCoreAppView.Dispatcher.RunAsync(
CoreDispatcherPriority.Normal,
async () =>
{
// This executes on the new dispatcher so I assume that Window.Current and so on
// reflects the new Window associated with that dispatcher rather than the original
// dispatcher.
Window newWindow = Window.Current;
ApplicationView newAppView = ApplicationView.GetForCurrentView();
await ApplicationViewSwitcher.TryShowAsStandaloneAsync(
newAppView.Id,
ViewSizePreference.UseHalf,
currentAppView.Id,
ViewSizePreference.UseHalf);
});
from Here.
Well after consulting the msdn developers forum it turns out this is the only way to do it
and there is no way for an app to force this kind of behavior the result of this code depends on the setting of the browser and many other variables