Related
Hello !
SUMMARY: How to run pocketsphinx_continuous on mobile phone with Android, and how to do it with simulator of mobile phone with Android. PocketSphinx can be downloaded for free here, for both Linux and Windows: http://cmusphinx.sourceforge.net/html/download.php .
Click to expand...
Click to collapse
------------------------------------------------------------------------------------------------------------
SHORT EXPLANATION
I'd like to create application for mobile phone and server such that:
1. User runs application on mobile phone with Android, this application uses PocketSphinx. It is Automatic Speech Recognition software for devices like mobile phones, written in C. Somebody told me that "Pocketsphinx is used successfully on Symbian with minimal effort". (However I think Android may be better choice). My knowledge about Android is limited but I know something about CMU Sphinx. Can you help me, please, to run this PocketSphinx on Android? I also need to find simulator of mobile phone with Android. I have already found Wireless Toolkit and I tried to use this emulator, however I think it doesn't allow to run simulation of mobile phones with Android. (By the way I am limited in my project to mobile phone of the price up to about 160 euro; which Android version would be best for my application?).
2. This application communicates with the user. The users speaks digits and some other words (dictionary is about fifteen words, I can create language and acoustic models, as well as formal grammar in CMU Sphinx, with the use of SphinxTrain). The application recognizes those digits.
3. Based on this talk, mobile phone sends information about results of recognition to the server. I can do it in Java for CLDC/MIDP with httpconnection, POST method on the mobile phone side and with Tomcat on server. I think this httpconnection must be possible not only in Java ME, but also in Android C. But this is thing which will bother me later, now I'd like to run pocketsphinx_continuous on Android and try to modify it according to my needs.
Summing up, what I'd like to know is how to run demo pocketsphinx_continuous on mobile phone with Android, and how to do it with simulator of mobile phone with Android. (I've got Wireless Toolkit but I think it is not capable of running Android). PocketSphinx can be downloaded for free here, for both Linux and Windows: http://cmusphinx.sourceforge.net/html/download.php . There are two ways of installing it in Ubuntu. First is to unpack it (it is tar.gz), enter its directory and type "./configure", "make", "sudo make install". The other, different, is written in README file, i.e. run autogen.sh, "./configure", "make clean all", "make test", "make install". The result should be, among many other files, javadoc in doc directory.
------------------------------------------------------------------------------------------------------------
LONG EXPLANATION
What is required to give me some advices is written above. So if you don't want / don't have time to read the whole text, just above explanation is enough. But let me say about other possible approaches which I try to do. Those are worse than what I explained above, but I also tried them.
CMU Sphinx contains SphinxTrain to create acoustic model. It has got some different recognizers (also called decoders), those are PocketSphinx, Sphinx4 and some other. PocketSphinx is written in C and is for devices like mobile phones. Sphinx4 is Java application for PCs because it requires better hardware. There is good tutorial about using SphinxTrain with Sphinx4. It is here: http://www.speech.cs.cmu.edu/sphinx/tutorial.html . There is no similar tutorial for PocketSphinx. However with some knowledge about Android and C it is possible to run it on Android. The other approach than PocketSphinx, is using this Sphinx4. However it requires connection between mobile phone and server, sending audio data from cellular phone to server. It can be done with Skype, but there is still problem on server side with redirecting sound from Skype to Sphinx4. So you see there are two different approaches. One is to run speech recognition on mobile phone with PocketSphinx and Android. The other is speech recognition on server with Sphinx4. There are some ways to follow this second option. One is Skype on both server and mobile phone. (But there is problem with redirecting speech from Skype to Sphinx4). The other is too expensive Digium card. The third one is IVR, but I still look for good open-source IVR software. All of those three ways of second option involve Sphinx4. It was much easier to create application with Sphinx4. It is for PCs, not embedded devices, because it requires better device, extensive floating point math and some other things. But it has much better documentation than PocketSphinx. But I want to use PocketSphinx because I don't need to pay to anybody for access to mobile internet in order to send data through internet for application like Skype. The access to internet is required only for short time to send little text data with httpconnection, POST method. This is why I'd like you to help me, please, with running pocketsphinx_continuous on simulator of PocketSphinx on mobile phone with Android. (By the way, I see I've got installed S60 Developer Tools -> 3rd Edition FP1 SDK -> MIDP -> Emulator).
Summing up in a list, those are in CMU Sphinx:
I. SphinxTrain, which I can use to create files needed for speech recognition
II. decoders which use speech input and some files which I create with SphinxTrain, to follow speech recognition (input speech + files from SphinxTrain = are used by decoder)
II-1. PocketSphinx, written in C, for devices like mobile phones
II-2. Sphinx3, written in C, for PCs, actually the best developed
II-3. Sphinx4, written in Java, for PCs, with the best documentation
II-4. Some other, older versions
Those are possible approaches of solving my task:
I. Speech recognition on mobile phone with PocketSphinx. This is much better way than [II].
Problems: 1. running PocketSphinx on mobile phone with Android. 2. simulating mobile phone with Android on PC. I also thought that maybe I should consider Meamo, what do you think about it? Or use things different than CMU Sphinx, e.g. Simon, HTK, Julius. I looked at those other ASR engines and I think PocketSphinx may be best choice.
II. Speech recognition on server with Sphinx4. There are some different ways of establishing voice connection between mobile phone and server.
II-1. ordinary call from mobile phone to server; server has got Digium card. Disadvantage: Digium card is expensive.
II-2. to use Skype on both mobile phone and server. Problem: redirecting of sound from Skype to Sphinx4 and vice versa.
II-3. can you think about any other ways? I found that Asterisk may be useful.
Greetings !
Summing up, what I'd like to know is how to run demo pocketsphinx_continuous on mobile phone with Android
Click to expand...
Click to collapse
First step would be to setup a toolchain and compile the prog for android
or statically linked with uClibc.
Then push it onto your device and test if it works as expected.
You can also push it onto the android emulator that comes with the sdk.
Just my 2 cents...
Thank you very much!
Can you give me any links to tutorials which can be useful for me?
By the way I know how to create my own application in Sphinx4 and I know how to run demo in PocketSphinx, but I've got some difficulties with creating my own application for PocketSphinx. So if you can have a look at PocketSphinx http://cmusphinx.sourceforge.net/html/download.php and tell me which files I need to have to create new project for PocketSphinx, I would be greatful. I mean that for Sphinx4 the only what I need to do is to enter S:\tutorial\sphinx4-1.0beta3-src\src\apps\edu\cmu\sphinx\demo\helloworld and create my own ...\demo\my_application, and inside it analogically to what is here ...\demo\helloworld. In the case of PocketSphinx, to run the application, I need to enter S:\tutorial\pocketsphinx\doc and run pocketsphinx_continuous. So I check what I've got in this file and I cannot see what files and where I need to have in order to create new project. I uploaded directory doc with pocketsphinx_continuous here: http://www.speedyshare.com/files/19429494/doc.7z
Greetings and thanks once more !
Rough outline: You'll need the Android SDK and NDK, both of which are available from http://developer.android.com/. The NDK will allow you to compile C code. You'll need to wrap the C core in a Java layer to make it accessible to the rest of the Android system. The SDK also includes an emulator, which I believe you've asked for if I understand you right.
I haven't actually attempted this, so that's about all the help I can be, but there is sample code included with the NDK that should get you started.
Thanks for your answer !
I check the google and see that NDK is term of Android, because I knew only SDK abbreviation. I assume NDK is especially for porting (like porting PocketSphinx for Android). So am I right that with this NDK I don't need to change code of PocketSphinx? I think it would be too easy .
There also other question which I've got. It is not strictly connected with Symbian but there wouldn't be any need for porting if I won't solve this problem. I've got my application in Sphinx4. There are also examplary appications for Sphinx4 and PocketSphinx. I can run demos from PocketSphinx (as explained in first post), as well as demos from Sphinx4. I can change source code of demos from Sphinx4 to perform my task. I'd like to do similar thing with PocketSphinx, but even if it should be easy task, I cannot do it. In Sphinx4 it is much simpler because all source files are in one directory. In PocketSphinx it is done in somehow different way. (http://cmusphinx.sourceforge.net/html/download.php). Without ability to move my application from Sphinx4 there is no need for me to port this PocketSphinx to Symbian.
Greetings !
johnyjj2 said:
I assume NDK is especially for porting (like porting PocketSphinx for Android). So am I right that with this NDK I don't need to change code of PocketSphinx? I think it would be too easy .
Click to expand...
Click to collapse
NDK is used to write software for Android devices that are compiled natively to the platform -- for now, this usually means ARM. Java as you probably realize is a bytecode intermediate language that the java virtual machine converts to native calls at runtime. This means that Java is generally platform independent whereas your C code is not.
JNI as used with the NDK is the Java Native Interface (or something to that effect). It allows you to call code that has been compiled for a specific processor from Java. This means that you could put heavily optimized super fast calculations in a native library and call them from your Java app.
It could also mean, that you've more or less written your entire application in some native code, and then you have written a java shim that has enough code to initiate and start your native software. Beware, there be dragons here.
The fact that you CAN do this, doesn't mean you SHOULD. There are a lot of benefits to using the android platform and specifically using the android way of writing applications. Concepts like views, activities, intents, etc., greatly simplify how an Android device interacts with other Android devices and provides a consistent and powerful framework.
For something like SCUMMVM, it is a game (platform) that is very linear in design; you are either actively playing it, or it is on pause. How other applications are running while using SCUMMVM is inconsequential. It sounds like you have very different requirements.
Thanks for answer!
Isn't that link (http://cmusphinx.svn.sourceforge.net/viewvc/cmusphinx?view=rev&revision=9470) simply trying to copy engine library to Symbian, without effect? Only enginge won't help, there is also need to write from zero code which will use this library. So it looks like there is still long way to have it working. Do I understand it properly?
Greetings!
Hi guys,
I'm currently using an iPhone as my primary phone and android as a secondary one. I want to shift to windows phone (mango) but there are a few apps on the android not available on winmo which I can't live without. Is there any way to run android apps on the windows mobile the same way(or ANY way) its done on the blackberry play book?
Thanks
I don't think there's any. But there are alternate apps.
Android apps on WP7 would be incredibly difficult, though theoretically it could be done with enough effort.
Most Android apps use Dalvik (a dialect of Java). This is totally incompatible with the Silverlight/C# that WP7 apps use, but there are enough similarities between them that it might be possible to build a tool that either translates the Dalvik instructions to MSIL (the binary that compiling C# produces) at launch, or dynamically interprets it (the latter would be very slow, though).
However, even with purely Dalvik apps, there are other problems. WP7 apps are limited to a very restrictive sandbox, with no access to the vast majority of the filesystem (for example). Android apps, by comparison, have a great deal of access to the device they run on, so even a very simple app may expect to have permissions that wouldn't be available on WP7. Instead, attempts to access restricted parts of the filesystem would have to be "virtually" redirected within the sandbox. This is possible in many cases, but a *lot* of work to code and has all kinds of weird edge cases.
Additionally, Android apps have a very different runtime model from WP7 apps. The biggest change is in how they handle leaving the foreground; WP7 apps are either suspended or dehydrated, while Android apps often just keep running (they can elect to suspend, but aren't required to). WP7 does support background tasks (with strict limitations, at least if you stick to the official APIs), but moving the Android app runtime into those background tasks would be quite difficult.
Finally, there's the issue of hybrid apps (apps that use native code in addition to managed runtimes like Sliverlight or Dalvik). These are much more common on Android than on WP7 (at least, than on WP7 outside this webite). Android runs on a Linux kernel, using POSIX system calls and APIs. WP7 runs on a CE kernel, using win32 system calls and APIs. There's a very loose mapping from one to the other (see the Wine project for running Win32 apps on desktop Linux) but it adds a lot of overhead and would be another layer, at least as tricky as the managed part, to the difficulty of this project.
Short version: nope, sorry.
GoodDayToDie said:
Android apps on WP7 would be incredibly difficult, though theoretically it could be done with enough effort.
Most Android apps use Dalvik (a dialect of Java). This is totally incompatible with the Silverlight/C# that WP7 apps use, but there are enough similarities between them that it might be possible to build a tool that either translates the Dalvik instructions to MSIL (the binary that compiling C# produces) at launch, or dynamically interprets it (the latter would be very slow, though).
However, even with purely Dalvik apps, there are other problems. WP7 apps are limited to a very restrictive sandbox, with no access to the vast majority of the filesystem (for example). Android apps, by comparison, have a great deal of access to the device they run on, so even a very simple app may expect to have permissions that wouldn't be available on WP7. Instead, attempts to access restricted parts of the filesystem would have to be "virtually" redirected within the sandbox. This is possible in many cases, but a *lot* of work to code and has all kinds of weird edge cases.
Additionally, Android apps have a very different runtime model from WP7 apps. The biggest change is in how they handle leaving the foreground; WP7 apps are either suspended or dehydrated, while Android apps often just keep running (they can elect to suspend, but aren't required to). WP7 does support background tasks (with strict limitations, at least if you stick to the official APIs), but moving the Android app runtime into those background tasks would be quite difficult.
Finally, there's the issue of hybrid apps (apps that use native code in addition to managed runtimes like Sliverlight or Dalvik). These are much more common on Android than on WP7 (at least, than on WP7 outside this webite). Android runs on a Linux kernel, using POSIX system calls and APIs. WP7 runs on a CE kernel, using win32 system calls and APIs. There's a very loose mapping from one to the other (see the Wine project for running Win32 apps on desktop Linux) but it adds a lot of overhead and would be another layer, at least as tricky as the managed part, to the difficulty of this project.
Short version: nope, sorry.
Click to expand...
Click to collapse
That was quite disheartening for the OP
But I liked the thorough explanation.
for curiosity, which apps are you looking for?
Thanks a million for the detailed reply. I can give up on this now otherwise would have gone crazy searching. As for the apps I wanted to use Rako which basically controls the lighting in my house and creston media which controls my theatre. These I can't live without.
Additional ones would be anonymous email and sms bomb.( to bug my friends)
as for the lighting you got me..
but for media the xbox (if you have one) companion controls my whole xbox media experience from audio (zune), movies (integrated movie player streaming from my pc)..
What about this - http://wp7mapping.interoperabilitybridges.com/Library?source=Android
Can't this be used?!
buffalosolja42 said:
but for media the xbox (if you have one) companion controls my whole xbox media experience from audio (zune), movies (integrated movie player streaming from my pc)..
Click to expand...
Click to collapse
Crestron controls my theater as a whole i.e lights, projector, blu ray etc. I just need to press 1 button and lights dim, screen comes down, blurry starts playing and so on. For the xbox controller its only for the xbox
buffalosolja42 said:
but for media the xbox (if you have one) companion controls my whole xbox media experience from audio (zune), movies (integrated movie player streaming from my pc)..
Click to expand...
Click to collapse
drupad2drupad said:
What about this - http://wp7mapping.interoperabilitybridges.com/Library?source=Android
Can't this be used?!
Click to expand...
Click to collapse
Okay im a noob and i have noooo idea what that is
drupad2drupad said:
What about this - http://wp7mapping.interoperabilitybridges.com/Library?source=Android
Can't this be used?!
Click to expand...
Click to collapse
That is just for developers who want to port their app.
jessenic said:
That is just for developers who want to port their app.
Click to expand...
Click to collapse
Exactly! So yes, Android app can come to WP, only if developers are hard working to port it.
However, I haven't done more than making ROMs for WM, Themes for Android, but I am currently porting 2 apps from Android to WP. Honestly, all porting is made so dead easy that a little bit of English and Bing at hand, and you are off to a great start! It's slow process but anyone can port if they want to.
Hi Guys,
I would like to create simple app with NATIVE code which run in emulator.
It is not possible to use solution in http://forum.xda-developers.com/showthread.php?t=1299134&highlight=developer+guide because it's use some ARM code.
Do you have any idea how make things work?
Thank you,
Ch.
You actually could (msotly) use that guide, but you would need to recompile the ARM portion for x86. My guess as to the best way to do this would be to use the "Platform Builder" for CE6 or CE7, instead of using the WinMo 6.5 platform as your target. WinMo only shipped on ARM devices, so far as I know, but the underlying OS, Windows CE, is very portable and the tools for it support building on a wide variety of architectures. WP7 is built on a version of CE somewhere between CE6 and CE7.
Otherwise, the stuff about using ATL, making a COM library, using ComBridge from the WP7 app, etc. all still applies.
That all said... why would you want to do this? Do you not have an actual phone to test on? Porting between ARM and x86 isn't *that* hard, but you shouldn't just assume that it'll work in all cases, so it makes a lot more sense, if you're building native code, to build and test for the same architecture you're planning to release on.
Additionally, the emulator may be missing some of the libraries that are present on the phone.
Thanks a lot. I will try it.
This is very beginning of my school project. I want only demonstrate that is possible to run some native code on WP7. Next phase of project will be on real device which I don't have right now..
Well, good luck, but I'd tend to say you're setting yourself up for a risk of failure. I don't know what it will take to use the CE Platform Builder for something like this; I have it installed but have never tried using it.
There may also be a way to compile for x86 using the WinMo build tools; I think some of the old "emulators" for WinMo were also x86 virtual machines (much like the WP7 emulator is). I never tried, though.
Risk of failure? I don't see how. The hardest part of this is finding a way to get his .exe on the emulator device and unlocking it. If he isn't using ARM ASM in his project, "porting" to x86 (or any other processor WinCE supports) should be trivial as long as a sufficiently complete SDK is available. The main issue with x86 on newer Pocket PC-like targets is that there are no Pocket PC SDKs targeting it newer than the Pocket PC 2003 one. If you want to use newer WM5 only features like GPSAPI, you'd probably need to use a CE 6.0 SDK instead.
If he doesn't want to do real time debugging, any of the Windows CE development tools or even 3rd party tools like Bloodshed DevC++, CE gcc/MinGW or FreePascal should all suffice. Windows CE is a very backward compatible OS so even an application targeting the CE 2.11 platform/SDK should still run on WP7 when you are careful to use supported APIs.
If you don't want to install Platform Builder and generate your own custom OS to base an SDK on, there are plenty of SDKs to choose from. Of course, some are worse than others. If you are using the CE 4.2 or 5.0 STANDARD_SDKs, you might become a bit frustrated when you realize they are missing many basic things like the Windows CE SIP APIs. (something that has been available for CE since 1.01 in 1997). But if you don't care about using the latest native CE kernel features and still want to use a newer IDE like VS2005/VS2008, the CE 5.0 STANDARD_SDK should be enough if you are careful. Though, I usually install things like eMbedded Visual C++ 3.0 and 4.0 along with all the Pocket PC and Handheld PC SDKs just in case I need a header or lib file that one or the other is missing.
The following MS SDKs can target x86:
-eVC3
Pocket PC 2002
Smartphone 2002
Handheld PC 2000
-eVC4
Pocket PC 2003
Smartphone 2003
STANDARDSDK_400
STANDARDSDK_401
STANDARDSDK_420
STANDARDSDK_500
-VS2005/2008
STANDARDSDK_500
Another useful x86 SDK I've found is the one for the Allegro CE/DOS Field PC:
http://www.junipersys.com/Juniper-Systems/support/Developers/Allegro-Field-PC/Allegro-CX
Here are some download links to many of the CE SDKs and compilers that were released over the years:
Here are some links to download some of the tools I've mentioned:
http://www.hpcfactor.com/developer/
http://www.microsoft.com/download/en/search.aspx?q=embedded visual tools
You will need SP4 for eMbedded Visual C++ 4.0 if you wish to use newer SDKs with it.
http://www.microsoft.com/download/en/search.aspx?q=pocket pc sdk
Ummm... maybe you missed the part where this is WP7 forum, and the OP is trying to run native code on the WP7 emulator... I can tell from your post that you're not terribly familiar with WP7 development, so here's a few salient points:
Compiling to a .exe is a waste of time. WP7 won't run foreign EXEs, at all, unless you make some pretty low-level changes that aren't possible on the emulator (see "full-unlock" custom ROMs). You have to write a managed app (which compiles to a DLL hosted inside a low-privilege EXE that's built into the system) and a COM library and use the InteropServices ComBridge API. So far we haven't even gotten P/Invoke to work.
WP7, especially Mango, uses a limited set of native APIs and the APIs have changed somewhat in the last decade or so. They aren't supposed to be available to third-party devs at all, so any backward compatibility is basically a convenient accident. Targeting Smartphone 2003 *might* work, but then, it might not. Even a number of WinMo 6.5 APIs aren't available or don't work.
Since it appears that the OP is just going for a demo project, he or she probably is a lot less interested in getting the most powerful APIs, and is probably hoping for something closer to invoking a MessageBox from native code.
All that said, however, it's true that there are WinCE SDKs which can build native x86 code. I'd tend to suggest using the CE6 or CE7 Platform Builders, since they're the most recent (WP7 is somewhere between the two), but there are other options. You probably want to follow the guide as much as possible, including things like using ATL, as it makes writing a COM library a lot easier and that's the best way we currently know for executing native code in WP7.
Hi everyone.
Could anybody compile BlueStacks App Player for Windows RT?
It would be great to use this app on our tablet with Win RT
I use on my laptop (win7) and wish o use on my Surface RT
Official site
Thanx a lot
It would be a great app to have, but seeing that it's not open-source there is about zero chance of it ever getting ported by the community.
Your best bet is to just hope that they (the actual makers of the app) decide to bring it over to RT, which is possible but unlikely.
Search next time; the devs here are up to their ears in requests for closed-source applications and are pretty fed up with it. Sorry.
They've actually already stated that it's coming...
Not explicitly. They hinted at it in a Help forum post, but never confirmed or denied it. And that was months ago.
jtg007 said:
Not explicitly. They hinted at it in a Help forum post, but never confirmed or denied it. And that was months ago.
Click to expand...
Click to collapse
Actually they had listed on their site that they were working on an ARM version.but not sure if they still are. Seems unlikely MS would allow it in the store due to direct competition with the windows store.
guitar1969 said:
Actually they had listed on their site that they were working on an ARM version.but not sure if they still are. Seems unlikely MS would allow it in the store due to direct competition with the windows store.
Click to expand...
Click to collapse
MS doesn't have a whole lot of control of things outside the Store. They could side-load an app pretty easily.
The vast majority of RT devices aren't "jailbroken" for sideloading arbitrary ARM binaries. Also, remember that RT doesn't (currently) support OpenGL, which means any Android apps/games that use advanced graphics won't work unless BlueStacks write and include an openGL-via-DirectX compatibility layer.
GoodDayToDie said:
The vast majority of RT devices aren't "jailbroken" for sideloading arbitrary ARM binaries. Also, remember that RT doesn't (currently) support OpenGL, which means any Android apps/games that use advanced graphics won't work unless BlueStacks write and include an openGL-via-DirectX compatibility layer.
Click to expand...
Click to collapse
I meant side-loading a Metro app, which can be done by just about everybody.
Cant sideload metro apps without a developers certificate
Derp. Yes, of course sideloading is the obvious way to go about it. Getting the dev license is easy, and yeah BS would have to sign their app, but that's not exactly difficult and their cert doesn't have to be signed by anybody else; it just requires that the end user install the cert before the app if it doesn't already chain to a trusted authority. The appx installer script automates all of that, though.
That said, the OpenGL issue is still there. Don't count on 3D games, at a minimum, working.
Don't forget however, that all of this is pretty much irrelevant right now. The Surface lacks the power to run Bluestacks. On my 6-core 2.3 ghz 6 gigs of ram computer with a great graphics unit, Bluestacks is still relatively slow. Just imagine it on the quad-core 1.4 with 2 gigs of ram that the Surface has. Not to mention it's on ARM, which is considerably less powerful than x86 or x64.
C-Lang said:
Don't forget however, that all of this is pretty much irrelevant right now. The Surface lacks the power to run Bluestacks. On my 6-core 2.3 ghz 6 gigs of ram computer with a great graphics unit, Bluestacks is still relatively slow. Just imagine it on the quad-core 1.4 with 2 gigs of ram that the Surface has. Not to mention it's on ARM, which is considerably less powerful than x86 or x64.
Click to expand...
Click to collapse
I dont think bluestacks is a multithreaded application in which case your 6 cores would be irrelevant and it would be purely down to your 2.3ghz clockspeed, which is not high at all. 6gb of RAM would also be irrelevant as no android app requires that much RAM so it simply wont be needed. GPU, not so sure what happens there, most of the apps I try running dont seem to enable my GPU at all so I am not sure if bluestacks is using software or hardware OpenGL, but then I havent tried any 3d games or anything. It runs ok on my 3.5ghz AMD athlon 2 but its not always as perfect as lets say a nexus 7 tablet running android natively.
I'm admittedly not 100% sure on how BlueStacks works (is it a native x86 DalvikVM, or is it emulating a full ARM system?), but it should be, at least in theory, possible to get it to run as naively as it does on Android by just porting the DalvikVM to Windows RT. That should result in speeds at least similar to a lower end Android tablet (Windows is bigger and has more cruft than the linux kernel that's running the DVM). With some sort of reverse WINE scenario it should also be possible to get a degree of binary compatibility for native libraries/addons.
SixSixSevenSeven said:
I dont think bluestacks is a multithreaded application in which case your 6 cores would be irrelevant and it would be purely down to your 2.3ghz clockspeed, which is not high at all. 6gb of RAM would also be irrelevant as no android app requires that much RAM so it simply wont be needed. GPU, not so sure what happens there, most of the apps I try running dont seem to enable my GPU at all so I am not sure if bluestacks is using software or hardware OpenGL, but then I havent tried any 3d games or anything. It runs ok on my 3.5ghz AMD athlon 2 but its not always as perfect as lets say a nexus 7 tablet running android natively.
Click to expand...
Click to collapse
Sort of, yes. But still, that means the Surface would be way less powerful. Also, my RAM is EATEN by Bluestacks because it's not apps that are the problem to run, it's Android. You're basically loading an entire virtual machine onto your RAM to run, in a program shell, then running Android apps on top of that. So the power of the device does matter... however:
netham45 said:
I'm admittedly not 100% sure on how BlueStacks works (is it a native x86 DalvikVM, or is it emulating a full ARM system?), but it should be, at least in theory, possible to get it to run as naively as it does on Android by just porting the DalvikVM to Windows RT. That should result in speeds at least similar to a lower end Android tablet (Windows is bigger and has more cruft than the linux kernel that's running the DVM). With some sort of reverse WINE scenario it should also be possible to get a degree of binary compatibility for native libraries/addons.
Click to expand...
Click to collapse
Bluestacks would have to run a full emulation of ARM in order to run all apps, right? Because when you install native x86 Android, it runs very few apps from the store, because they aren't compiled for ARM.
Netham45 could be right though that we could kind of make Android run natively, though I'm highly dubious about it happening through Bluestacks. Bluestacks most likely won't make an ARM port (especially cause I doubt Microsoft would allow it in the store) and if we did have access to source code, it's still built around running on Intel processors, and would probably have to go through all sorts of unnatural emulation... So making a totally separate Android program from scratch (which would require inordinate amounts of work) would probably be the best bet.
No. I think bluestacks is actually "just" a port of the dalvik VM to run on windows.
Android apps are not compiled for a specific CPU type. They are compiled for the dalvik virtual machine which is in a way similar to the java virtual machine, in fact a dalvik applications source code is java source code hense why many people say android apps are java, in reality the dalvik VM is very different from the java VM and the 2 are not compatible.
The vast majority of apps do actually work on x86 just fine.
The main problem is that google restricts apps based on your device and often it doesn't recognise x86 devices so doesn't show results, the default app manifest files don't actually restrict platform but many devs set them to arm for some reason. With various tools to spoof what device you appear as you can still gain access to thses other apps.
The problem apps are those that use the NDK (a small minority). NDK apps do have native code, but not just for ARM. The NDK default settings are to generate binaries for ARMv7, but it can be set to x86, ARMv6, MIPS or to compile multiple binaries for a mixture of the above (causes its own issue as it includes the binaries for all platforms in one APK which loads the relevant binary at runtime, good for compatibility as one APK covers all devices but makes the final APK massive). x86 devices of course cannot run ARM compiled apps which does include a few big name apps.
I don't know if bluestacks has left it as pure dalvik VM on x86 or if it does include an ARM emulator for the NDK but it certainly isn't just running an ARM emulator and tyen android atop of it.
I don't experience the ram eating effects you mention either.
SixSixSevenSeven said:
No. I think bluestacks is actually "just" a port of the dalvik VM to run on windows.
Click to expand...
Click to collapse
That's exactly what my understanding was as well, although what I'm about to say somewhat contradicts that.
Interestingly, http://www.bluestacks.com/technology.html says that BlueStacks is "fully configurable" and that it "supports" Windows on ARM as well as x86 Chrome, even though neither of those are actually available today. So, not sure if that page is before or ahead of its time.
"BlueStacks employs a lightweight, optimized, soft hypervisor with deep enhancements to support "embedded virtualization". End consumers can enjoy the full Android environment through BlueStacks, or just install Android app icons directly on the Windows desktop."
What the page basically says is that the core virtualization that BS uses is very easily configurable to different combinations or permutations of OSs; that the technology can just as easily run Windows on Android or Android on Chrome as it can Android on Windows, which is the only current release. It also implies that BS can do BOTH a mere dalvik vm (just install apps to the Desktop) as well as a complete system emulation (full Android experience).
There may be hope for RT yet.
As far as I remember, Bluestacks is using QEMU as there base platform. So it's probably still running ARM code in emulator.
I am looking at if we can port the Dalvik VM over to Windows RT. Anybody want to join the explorations?
So far I can see the Dalvik VM has lots of generated ARM assembly code and have huge dependencies on linux.
Porting would need quite a bit of effort.
Developers from Windroy has done it for the Windows X86 platform. If they can do it for Windows RT, it'll be much easier.
HAVE you ever thought how an app is used and how it is installed ???
Well now you can cause I am here..:victory:
Many of you have probably heard, that Android uses Java. But have you ever heard anyone saying that Minecraft (The Linux .Jar) works on Android? No, you haven’t. And you most likely never will. This is because Android uses the so-called ‘Dalvik-VM’, VM meaning Virtual Machine. Yes, you got that: Virtual machine. Java doesn’t work natively on a computer. It runs in its own little cosy-cub. That’s why many people see such a potential in Java – That’s also one of the reasons the Android team chose to use Java. But because Android (usually) runs on ARM-based devices, one cannot simply install Java to the system and expect everything to work. So instead, they decided to use Dalvik.
Dalvik is the process virtual machine (VM) in Google’s Android operating system. It is the software that runs the apps on Android devices. Dalvik is thus an integral part of Android, which is typically used on mobile devices such as mobile phones and tablet computers as well as more recently on embedded devices such as smart TVs and media streamers. Programs are commonly written in Java and compiled to bytecode. They are then converted from Java Virtual Machine-compatible .class files to Dalvik-compatible .dex (Dalvik Executable) files before installation on a device. The compact Dalvik Executable format is designed to be suitable for systems that are constrained in terms of memory and processor speed. – Wikipedia.
Click to expand...
Click to collapse
Just from reading that, most of you will get a brief idea, of what Dalvik really is. But let’s ask a different question. Why are the apps installed using a Java virtual machine?
This question is actually quite simple to answer. We have all had this problem: We use a program on our beloved computer and all of a sudden, the whole system crashes and requires a reboot. This can have multiple causes, but the main one, however, is that the process had an internal error, while trying to attach to a specific piece of memory. But this can only happen in natively-running apps. Apps that run in a virtual machine can also crash, that’s not what I’m trying to say at all, but when the apps crash in a virtual machine, it’s virtual. It does not affect the system – Only the virtual computer. But as good as a virtual machine can be at some times, it also has many pros. One of the… how can I put this? Superior arguments for not using a virtual machine is speed. Sure, if you’ve got a computer with a bucket-load of power, it should get easy tasks done, right? Not necessarily. A virtual machine still runs as a program which has to request access to different memory locations which then allow the virtually-running program to request access to memory from the virtual machine which then asks the host OS for the needed space. Even though this usually only takes a second or two, per operation that is, it can be really annoying when different requests are pending for an answer. That’s where native code is much better. Native code only has to request for a memory location once, and then never again. That means less queuing and more speed – Ultimately resulting in more responsiveness.
Here comes a question to you, the readers: If you were a program, with the choice to choose whether it gets run in a virtual machine or natively on the OS, which would you choose. To make the decision a bit harder, you are approx. 50MB in size, your main task is IO (In-out) and you process large files (Pictures, renders, archives, videos, etc. …) and you’ve just gone into beta.