I am working on a Windows Store application that utilize MediaElement control in WinRT (C# language). Everything worked as expected until I start dealing with the PlaybackRate property . I tested my application on Windows Surface RT (ARM based), Eee Slate (x64 based device) and desktop PC running windows 8 (x64 based), and found that while both the x64 devices honor the changes I made on the PlaybackRate propety, the property PlaybackRate (and DefaultPlaybackRate) was totally ignored on Surface RT.
At first I thought I made some coding mistake, so I used the official Windows Store Samples (http://code.msdn.microsoft.com/windowsapps/Basic-Media-Playback-003619be), and the exactly same experience.
So does PlaybackRate (and DefaultPlaybackRate) not supported in ARM based devices? Any workaround?
You can try to remove the attributes [AudioCategory="BackgroundCapableMedia" AudioDeviceType="Multimedia”] from the XAML of the MediaElement, somebody has tried it and the PlaybackRate responds correctly on both ARM and INTEL machines.
Related
I am working on a Kinect application. I am planning on creating an executable for the application. The executable will then be installed on a "Windows Single Board Computers". Currently I am running the application on an i7 Desktop Tower with 3.4GHz and 8GB memory.
I have looked at the system requirements for Kinect SDK:
http://www.microsoft.com/en-us/download/details.aspx?id=44561
I think these specs are only when developing. But what would be the specs when I am only running the executable?
I looked at this question, how to make an executable version of a WPF Kinect Application?
To revise, I am going to program the Kinect on my Desktop tower. Create an executable for the application. Then install the application on the "Windows Single Board Computers" and then connect the connect to this new board and run the application.
What specs do I need for this "Windows Single Board Computer"?
Thank you in advance.
I did a project called Virtual Dressing Room which engage some animations with Kinect data. To run only the Kinect data and play with it just needed 4gb ram with 1.9 Ghz CPU. But when it mixed with XNA animations then it required more ram like above 6GB. So it depends upon your application. If you simply play with kinect and 2D animations then 4GB ram is ok.
Since you are new to SOF I suggest if this answer can be acceptable then mark it. So you will have better responses for your future questions.
So I finally got my two Kinect v2's in the mail, and was looking forward to get some raw data from them and see how much they interfere with each other. I went to go download the SDK, and for some reason I had never noticed the Windows 8 requirements... As in Windows 7 isn't supported.
This feels pretty bogus and unnecessary, but fine I can't do anything about that. Before I waste some money to upgrade my machine to an OS that I really don't want, is there any way to get the Kinect v2s to talk to a Windows 7 machine (or maybe even Ubuntu)? I don't need any of the fancy skeletal detection or anything; I just want raw xyz-rgb data. I was reading about OpenNI (and their new Apple overlords), and I was hoping that by some miracle their last open source distributions would be forwards compatible with the Kinect v2s?
TL;DR: Are there any free SDKs that can interface with a Kinect v2 on Windows 7-64bit?
look at libfreenect2
It looks like its not ready yet but there are people working on it. So you might want help them along.
Update 2014-10-28
The Project is live and kicking and works fine
Just dropping by to say that I successfully 'installed' the Kinect 2 SDK to windows 7 and it is being recognized by driver4vr.
I'm not precisely sure which files where required so I'll just post my process.
Install VirtualBox (and enable CPU virtualization in bios to support 64bit OS)
Install win 8.1 x64 in VirtualBox
Monitor the VirtualBox c-drive for changes (I used spy-the-spy)
Download and install the Kinect 2 SDK in VirtualBox
Check spy-the-spy for all files added, and copy them to your Windows 7 OS on the same location. (It also installs some VC redistributables, so skip the files already there)
Reboot windows 7 and enjoy Kinect 2.0 on the final decent MS OS.
The Windows 8 is MINIMUM requirement to developing kinect v2
you do not need use Skeleton(kinect V1) or Body(Kinect V2) to track body or skeleton .
you need use to MultiFrameSource Class
I have a few programs I'd really like to test on Windows 8 for ARM. I don't have any Windows 8 ARM hardware though. Is it possible to install Windows 8 in some kind of ARM emulator or some such?
Yes, I know that if it compiles on WinRT it is suppose to "just work", but I'd really like to test it not only to see if it works, but also relative performance(as much can be guessed from an emulator)
There is no way, how to start you x86 PC in an "ARM mode", or launch Simulator in ARM mode. WinRT was designed to bridge the differences or these platforms so you don't need to worry about it and you can just develop. All I can think of right now is try to contact local Microsoft representative in your area - if they have any ARM tablet for testing, they might help you in this, but again if your app is not really flawed or computing power demanding, don't worry about the ARM platform :)
This now appears to be sorta possible (haven't tested yet) with the new App Ceritification Kit for WinRT, which appears to include ARM emulation.
EDIT: This isn't an emulator, it will only run on an ARM WinRT device. I guess there is no ARM emulator, despite that page mentioning ARM and emulation
I think this is a common problem for all developers using Windows CE 6.0 operating systems on specific hardware. I have a client that needs a custom operating system for its ICOP PDX-089T PC with Touch panel, that is based on DM&P SoC CPU Vortex86DX-1GHz.
I do not have the hardware with me, so every time I make a change I have to send at least the NK.bin file, or the whole ghost image to the client to make the tests for.
Is there any way to build a custom Windows CE emulator to add it to Visual Studio 2005 for testing or may be a custom virtual machine to launch it through VMWare or Virtual PC?
I tried some guidelines from the internet to build one, but every effort in making one resulted in hanging up my PC.
Does anybody have similar needs and some solution?
Note: The emulator I need is for Vortex86DX processor and ICOP board.
Microsoft abandoned the x86 Emulator some time ago, choosing to support only an ARM emulator (the BSP ships in the box with Platform Builder 6.0). This means that you can't create an emulator for the x86 processor, though I'm hard-pressed to think of a scenario where you'd really need to and where just getting hardware isn't a better solution for anyway.
There is a BSP for doing Virtual PC OS builds that would run on x86. It's not had much activity in some time, and I've never tried it, so YMMV.
Hi!
I have an old plugin (as binary, dll), used by my application. It was build for WM2003. And now it crashes the app, if loaded on Windows Mobile 6.1 (WM5 works fine, WM6 too).
The source code is not available and it's no more supported by developer. So I can't rebuild it for WM6.1.
Is it possible to patch or convert the binary to allow it to work on WM6.1 ? If so, how can I do this ?
Thank you.
Edit: I've found, that the problem is in PE loader, which acts not the same on WM6.1 (comparing with WM6 and earlier).
Does this plug-in use MFC or ATL? Earlier versions of WinMo had a different ATL/MFC version baked in, so MFC or ATL apps written in Studio will not work unless you deploy the newer ATL/MFC libraries along with the app, just as the old apps will not work on new devices unless you deploy the old MFC/ATL libraries.
This problem is rare, but some information can be found.
The common solution is to rebuild a binary in VS2008 (TCPMP new VS2008 builds for WM6.1), but this will not help, if you don't have the source code.
I've found the problem explanation and another solution in cegcc mailing list (arm-wince-cegcc on Windows Mobile 6.1). In Windows Mobile 6.1 Memory Management scheme was changes.
This slot arrangement remained pretty constant from Windows Mobile 2003 to Windows Mobile 6.0. However, with the release of Windows Mobile 6.1, things were changed to reduce the DLL pressure and to help out in the Device Manager process space.
In Windows Mobile 6.1, the stacks for the device manager are no longer allocated in the processes’ slot. Instead, the operating system uses slot 59, at the top of the Large Memory Area, for the device manager thread stacks. ...
And the workaround for this issue is to declare the DLL in registry (to tell the OS not to load it in high memory).
I don't like this workaround, so I try to find some binary patcher. And found it :)
It's not really a patcher, it's UPX - the Ultimate Packer for eXecutables. But it solves the problem perfectly. The DLL, packed with UPX don't crashes the application and runs fine.