So I ran into the dreaded 'unfortunately....has stopped working' issue where art loads 2 classes and the debugger promptly tanks out - see this
So, in utter desperation, I switched from ART to Dalvik, half dreading a long session with ADB if the tablet got sour about the switch. Seemed to work. Tango works, albeit with a whole new set of head scratchers (flakier about getting XyzIj, flash is running, surface binding working, hell I can see the camera flashes in the surface showing the camera view - and if I try again and again, I do get tango point data :-)
Can I assume all the tango issues are of my own doing and keep using Dalvik, or must I switch back to ART and try to do all of my debugging through logcat ?
The answer to the question in title: Can we use Dalvik with Tango?
You should always use ART instead of Delvik on Tango, Delvik will work but NOT stable on Tango device, it might cause the issue you experienced like depth out-of-sync.
Same problem here,
What helps is switching to Dalvik for debugging non tango-related issues, but this really slows development process down, as all apps have to be optimized for each switch between debugging and testing session.
Related
It appears that a large fraction of Tango users are experiencing issues since Leibniz was pushed out. I found this post in another thread and thought it might be why I am seeing so much instability in my app after the update:
This is from: TangoService_connectOnFrameAvailable() gets stuck or crashes using Google Tango Leibniz Release 1.10
"Apologies, that you are experiencing problems. Is this still happening? I am asking this because, there was a bit of leeway in timing between when the TangoCore was updated on PlayStore and when the OTA went out (which can potentially cause this issue, if OTA and TangoCore are mismatched). I just want to make sure that you are are updated on both TangoCore and OTA before diagnosing it. Also, make sure you have permissions for camera in the android manifestl." – r4ravi2008
I am pretty sure that the reason I am having problems is because I do have the mismatch described above. I have Tango Core updated through Google Play, but if I got to "About Tablet" I see:
Build number: KOT49H.150320
Also, my Kernel version has an updated date of Friday March 20th.
This build number is exactly the build number referenced here: https://developers.google.com/project-tango/hardware/depth-test
However, on this page it says that this build is for Kalman (not Leibniz). When I try the suggested step of going to "System Updates" and clicking "Check for Update" the system says that it is up to date (even though apparently it did not receive the latest OTA).
Two questions:
Am I correct in that Kernel (OTA) and project tango core are mismatched?
If so, how do I fix this?
Thanks in advance...
Apologies in advance as this is rather a comment than an answer to Voxel Scanner Voxxlr's post... But as I don't have 50 reputation points I cannot leave comments...
Well, like Mark I reset the device to factory settings and carefully updated everything (PlayStore, System Update)... Then, I made super sure that the correct tango_client_api.h/.so is used in my project... Et voila, suddenly it worked... Generally, it seems to be a good idea to spend as little time in the callbacks as possible... Otherwise you can observe these "hiccups" Mark is reporting... After considerable rearrangements in my code everything runs smoothly again... I can also confirm that the color frames are OK... If you are interested in my converter code: I posted it here link
My solution was to use a blunt instrument - force the Tango to do a full factory reset and let it start all over again- I can say that Explorer seems to work fine and the unity pointcloud and tracking samples work, but I'm just getting started and absolutely nothing in this statement should be misconstrued as an endorsement - remember, YMMV :-)
Yeah, no. The Unity Point Cloud sample hiccups all the time with respect to displaying point clouds, and crashes after a minute or two :-(
I believe so, I had similar problems where point cloud and motion tracking would get lost every couple seconds and eventually the app would crash. But just yesterday, my device said there was an update, while previous manual system checks kept saying it was up to date. After updating, the build number lists KOT49H.150414 (Kernel date is April 14, 2015), so that seems to be the actual Leibniz release on the device (not just the Core and SDK), and things are much more stable now.
Also just got the color data and displaying it like an AR image, but it's still in YUV format so everything is red. Working on converting it to RGB, but things seem to be working much better now.
Not sure if this technically qualifies as an answer, but I received this message from Google tango support:
Hi there,
What you are experiencing is a known bug that we have found fix too. Please stay tuned to our next OTA update that will fix this issue. We hope to push this update as soon as possible and thanks for your patience.
Best,
Monty
Project Tango Support
I am honestly not quite sure how to interpret this. What exactly is the bug? That my device won't download the latest OTA? Based on Brian's post, it really does seem that I have a mismatch between Tango Core and the kernel that needs to be remedied to get acceptable performance.
See Google+ Tango Page for info on the issue - there was an OTA update issue - it is being corrected
(Wow did SO just select a lot of nonsequitor questions - joy of being on the edge :-)
I find that often when I'm trying to run this app multiple times from Android Studio, subsequent invocations that cause a resume, instead of a cold start (real cold, as in camera permission needed again), the app can no longer acquire pose data - it does get attitude and position data, but it never gets any point clouds because the onPoseAvailable callback in setTangoListeners never gets called again - often I have to reboot the device, sometimes googles app makes everything better, and other times I have to reboot.
I'm pretty sure this is because the proper actions vis connecting to and disconnecting from tango in the Pause and Resume logic is not quite right - however, even when the app is completely rebuilt and installed due to code changes, this irritating behavior remains (irritating) - Anyone have any experience with this ?
I think there are two possible reasons causing this issue, one is the above you mentioned(connect disconnect life cycles), the other one could be the IR frame out of sync issue, as mentioned in Project Tango known issues, as it says:
"Occasionally, or when under high CPU load, the depth flash may appear in the color image, or no depth points are returned. Let the device cool down and/or reboot"
One way to diagnose the problem is to observe the device's IR projector(see Project Tango Tablet Development Kit hardware section). First, launch a depth application, if everything works correctly, you will be able to see a sequence of really dim red flash coming from the IR projector, the red flash pulses around 3Hz. If the problem is connect fails, the IR projector won't give the red pulses. If it is depth out of sync, then you will see the red pulses, but no depth coming out (no callbacks).
Hope it helps.
I am experiencing the exact same issue as this fellow, and cant seem to find any real solutions to the issue. The only solution I've been able to find so far that works it not maximizing VS. Keeping VS in windowed mode fixes the problem completely, but as soon as it returns to maximized state UI elements no longer redraw unless the stale area is put under new active focus. This makes it impossible to develop and I'm forced to return to windowed mode. I've tried disabling hardware acceleration with no luck. Any Ideas?
There are a handful of feedback reports at connect.microsoft.com that describe a similar problem. But none that ever evolved to a solution, most typically the programmer that filed the report stopped responding when asked to provide additional diagnostics.
Clearly this is an environmental problem, something is wrong with your machine. VS2012 uses WPF for rendering, it puts non-trivial demands on the machine. You do need a solid video driver and a functional DirectX stack to make it work without problems. This tends to be an issue in general, video drivers are by far the most problematic kind of driver. Problems are roughly correlated with the age of the machine and how old the operating system is.
So a good starting point is to look for a video driver update first, visit the web site of the company that made your adapter to look for the latest. Reinstall DirectX on the machine next. If you were considering a clean update of your machine before, like updating the Windows version, now would be a good time to start with a clean slate.
We have used Google Map API V3 in our application and seemed to have found a strange problem, which is not reproducible on all machines.
The following is the configuration of the machine where we could reproduce it :
OS : Windows7
Graphic Card : 128MB (I guess this should be enough, because I feel the issue is related to these parameters.)
When Zooming out from Google maps in our application we get the following error from Firefox 19 and it crashes completely:l
AdapterVendorID: 0x8086, AdapterDeviceID: 0x 166GL Context? GL Context+ GL Layers? GL Layers+ xpcom_runtime_abort(###!!! ABORT: Framebuffer not complete – error 0x8cd6, mFBOTextureTarget 0xde1, aRect.width 4736, aRect.height 1967: file /builds/slave/rel-m-rel-osx64_bld-0000000000/build/gfx/layers/opengl/LayerManagerOGL.cpp, line 1446)
ProductID: {ec8030f7-c20a-464f-9b0e-13a3a9e97384}
After looking out for a similar issue on Google we found that on turning off the hardware acceleration, the maps no more crash.
However this is not a viable solution in our case, since we have a website and we cannot ask every user to turn hardware acceleration off.
Can anybody think of some possible reasons as to why Firefox crashes while zooming out from Google maps in our application? What does hardware acceleration exactly try to do?
Please let me know if any further information is required.
Any suggestions would be highly appreciated.
It's just started crashing for me, but it seems to only happen if I'm using Open GL. If I turn it off, it works fine ... so far!
I have a WinForms application that uses XNA to animate 3D models in a control. The app have been doing just fine for months but recently I've started to experience periodic pauses in the animation. Setting out to investigate what is going on I have established these facts:
It happens on my machine only, other machines works fine
Removing everything from my render loop does not improve the problem
In 2. I didn't actually remove everything, I limited my loop to set the viewport on my GraphicsDevice and then do a GraphicsDevice.Present.
Trying to dig further I fired up PIX to capture some statistics. Screenshots of two PIX runs can be viewed here (Run6) and here (Run14). Run6 is using my original render loop and Run14 is using the bare-bones Present loop.
PIX tells me that the GPU is periodically doing something, and I assume this is causing the pauses. What could be the cause of this? Or how do I go about finding out what the GPU is actually doing?
Update: since I usually trust my code to be perfect (who's laughing?) I started a new XNA project from scratch to see if it exhibit the same behavior. So starting a new XNA 3.1 Windows Game project and running PIX I get this timeline. The same periodic pauses. So the problem must be lower in the stack, in XNA or Direct3D.
So PIX shows that the GPU is working on something, I can see the list of DX calls made within each frame and the timing calculations shows that the pause occurs during (or after) the IDirect3DDevice9::Present call.
Update 2: I had previously installed and uninstalled XNA 4.0 CTP on the problematic machine. I cannot be certain that this is related but I thought that perhaps a reinstall of the XNA Game Studio 3.1 bits could make a difference. Turns out it did.
The underlying question remains the same (and the bounty is still up): what could affect XNA 3.1 (or DirectX) to make it behave like this and is there any logging/tracing power tool for the DirectX and/or GPU level out there that could shed some light on what is going on?
Note: I'm using XNA 3.1 on a Windows 7 x64 dual-core machine with 8GB RAM.
Note2: also posted this question on the XNA Creators forums here.
You could try to see if you can find something with Xperf that is close to your periodically problem, do not run your application but keep the programs open that would normally run besides your application. You could also try to do it again with the application running but it could give a cluttered view.
Start the tracing, do this in an elevated prompt.
xperf -on BASE+LATENCY -stackWalk Profile
Wait for a fair amount of time to be sure that the problem is traced.
Stop the tracing and open it like this.
xperf -d trace.etl
xperfview trace.etl
Analyze by looking at the graphs and consulting tables of specific intervals and see if you can find something that is related to the problem, the highest chance on finding it would be in the DPC and Interrupts section. But it might as well be something odd at the CPU or I/O section. Good luck!
Also more information on Xperf and how to obtain it, hopefully this delivers results.
If not, you can alternatively try GPUView which has been used for improvements in DWM,
this is also included next to Xperf with the Windows Performance Toolkit so you can easily try both!
log v
... wait for a fair amount of time to be sure that the problem is traced ...
log
gpuview merged.etl
In the case that gpuview gets out of memory you can try to add "/limit 3" or remove the v.
Read the documentation of the tools if you are stuck somewhere.
Hmm ... this seems to be occurring on the GPU, however it sounds like a CPU garbage collection issue. Can you run the CLR profiler and see if you can see any spikes in GC activity that you can correlate to the slowdowns?
I agree that it sounds unlikely since you can clearly see it in PIX, but it might offer a clue as to the cause.
If it's only happening on your own machine, then could it be drivers? Forgive me for being skeptical, but it's a 64 bit machine after all :D
This looks like either a vsync issue or GPU in its last throes. Since going back to a different version fixed it, and the "bottleneck" is in IDirect3DDevice9::Present lets go with the former option.
I'm not familiar with XNA so I don't know how much of the workings of D3D are exposed, but do you know what your PresentationParameters are set to?
Specifically try setting the swap effect set to Discard.