NateRickard / Xamarin.Cognitive.Speech

A client library that makes it easy to work with the Microsoft Cognitive Services Speech Services Speech to Text API on Xamarin.iOS, Xamarin.Android, UWP, and Xamarin.Forms/.NET Standard libraries used by those platforms
MIT License
59 stars 18 forks source link

Cannot Access File Path Returned From Plugin.AudioRecorder #1

Closed FlammableFork closed 7 years ago

FlammableFork commented 7 years ago

I am using both of your plugins for Bing Speech (Xamarin.Cognitive.BingSpeech and Plugin.AudioRecorder). They have been working very well. I have just gotten around to testing this plugin (Xamarin.Cognitive.BingSpeech) with UWP, and I have run into a bit of a problem (or mismatch) between this plugin and Plugin.AudioRecorder.

The result from Plugin.AudioRecorder's StartRecording method is the full path to the recorded file. This works well, and recording has no issues. However, when I try to pass that same path to the SpeechToTextSimple method of this plugin, I run into a problem. Plugin.AudioRecorder records to a temporary directory, which for UWP is the TempState folder. however, after looking through the code for this plugin, I can see that things are configured to use LocalStorage, which for UWP is LocalState. This results in an exception being thrown by SpeechToTextSimple in the form of PCLStorage.Exceptions.FileNotFoundException.

The lines of code to which I am referring are lines 222 & 223 in BingSpeechApiClient.cs

var root = FileSystem.Current.LocalStorage;
var file = await root.GetFileAsync (audioFilePath);

This problem doesn't affect iOS or Android, but I am assuming that the temporary storage used by Plugin.AudioRecorder and LocalStorage actually end up being the same directory (I haven't looked into it).

Would it be possible to modify this code to accept a full path using PCLStorage's GetFileFromPathAsync method instead of simply looking for the filename in LocalStorage? The only other option I can see would be to get the file in TempState using PCLStorage and move it to LocalState before sending the request to SpeechToTextSimple. Am I seeing things correctly? Thanks.

EDIT: Or, perhaps even an overload that takes an optional boolean specifying we are sending a full path (to keep the existing API intact)?

NateRickard commented 7 years ago

@FlammableFork I knew not creating the UWP sample would come back to haunt me. Fixed the issue and added a UWP sample to the repo. Thanks for reporting & investigating.