In WinRT, files are better identified by a StorageFile object rather than a path string. This is due to the reasons that 1. non-conventional file systems (such as cloud drives) are supported and 2. file access rights are much more restrictive compared to desktop applications. E.g. trying to open an arbitrary file on the file system usually causes a UnauthorizedAccessException. However, if that same file was obtained by a FileOpenPicker control, it is possible to open that file - but only by using the obtained StorageFile object.
It would be great if the MediaFoundationReader supports that, too. I.e. just supply a StorageFile instead of a path to its constructor. A viable alternative would be to open the file in the App and to supply some IRandomAccessStream instead,
Comments: Yes, would be a good addition. you may find the AudioGraph API in UWP already gives you what you need.
It would be great if the MediaFoundationReader supports that, too. I.e. just supply a StorageFile instead of a path to its constructor. A viable alternative would be to open the file in the App and to supply some IRandomAccessStream instead,
Comments: Yes, would be a good addition. you may find the AudioGraph API in UWP already gives you what you need.