Docbeamz Posted July 16, 2018 Share Posted July 16, 2018 Hi, Our developers have informed us of an issue with the version of Android used by the Focus that has stalled our project. The Vive Focus (Android) is missing a library, libwvm.so, which is used by our software. We're investigating a workaround. Can you explain why this is missing from Focus Android, if it will be added, and any suggestions you would have for fixing this ASAP. Thx Doc Link to comment Share on other sites More sharing options...
dario Posted July 17, 2018 Share Posted July 17, 2018 Was it related to using android.media.MediaExtractor.setDataSource ? Link to comment Share on other sites More sharing options...
Docbeamz Posted July 17, 2018 Author Share Posted July 17, 2018 Hi , Thanks for the fast response. Here's the full error: E/WVMExtractor: Failed to open libwvm.so: dlopen failed: library "libwvm.so" not found. Developer : …………….. "did some digging and found that the issue was with the container format." It involves .mp3 decompression. If they convert the .mp3's into .wav's the problem doesn't show up. Link to comment Share on other sites More sharing options...
dario Posted July 18, 2018 Share Posted July 18, 2018 For anyone else seeing this error, it can also be due to using the Android MediaExtractor with assets or raw resources (or if you're using a library that calls that). This would require changing the android call to setDataSource to more than just a path, something like: AssetFileDescriptor afd = getResources().getAssets().openFd("sample.mp4"); mediaExtractor.setDataSource(afd.getFileDescriptor(), afd.getStartOffset(), afd.getLength()); Link to comment Share on other sites More sharing options...
Docbeamz Posted July 18, 2018 Author Share Posted July 18, 2018 Hi Dario, Thanks for the reply. This is from our programmer: no, that's not the issueit's not using assets or raw resourcesbut I suppose they can try loading the files differently Thanks Link to comment Share on other sites More sharing options...
Docbeamz Posted July 19, 2018 Author Share Posted July 19, 2018 Hi Dario, Well, we're still stalled on this problem. We're experiencing this issue with our Android music engine. The previous programmer observations I mentioned came from our UI team. Our engine team spent a couple hours investigating and weighed in on this. This is what they sent to me today: -------------------- Hi, Doc. Here is my current thoughts: BeamzEngine is not using MediaExtractor. We decoding MP3 in native C++ code by using minimp3 library. minimp3 is provided in source code and it is platform independent, so I don't think that it uses MediaExtractor (at least I don't see it in minimp3 sources). To work with mp3 files we using simple fopen/fclose/mmap/munmap functions, they are definitelly exists on any Android system. So I think problem in another place, mp3 decoding is not the reason of this problem. Java part of BeamzEngine uses android.media.AudioManager to query system audio params. Here is its usage: // "_context" here is activity, passed to BeamzEngineFactory.createEngine or BeamzEngineFactory.createEngine2 Object audManObj = _context.getSystemService(Context.AUDIO_SERVICE); AudioManager audMan = (AudioManager) audManObj; String fpb = audMan.getProperty(AudioManager.PROPERTY_OUTPUT_FRAMES_PER_BUFFER); String sr = audMan.getProperty(AudioManager.PROPERTY_OUTPUT_SAMPLE_RATE); Another possible place: for mp3 recording we are using OpenSL ES. Maybe it is uses MediaExtractor in its implementation. But you are saying that changing of song files from mp3 to wav fixes the problem, so it is doent't looks like what file recording or quering of system audio params is the reason. But maybe I am wrong. -------------- To recap, Our Android engine runs perfectly on other Android systems. This issue only shows up on the Focus Android device, so it's something unique to the Focus. Our engine programmers will continue to debug this but, we will also be relying on your assistance. Thanks Doc Link to comment Share on other sites More sharing options...
Docbeamz Posted July 23, 2018 Author Share Posted July 23, 2018 Hi Dario, Our Engine programmer made some progress last night but we’re still singing the Android blues. He was able to intermittently verify that mediaextractor is referenced somewhere in the engine code. He will isolate the offending code tonight so we just have to hang in there a bit longer. Here’s what he logged: Here is current results: It took some time to run beamz sample app on my Huawei Honor 8 (android build environment was updated since last builds) but looks like I saw creation of MediaExtractor on launching of app. But it is not always creates. In device logs I see lines like: 07-23 15:04:26.947 1579-1737/? W/MediaExtractor: creating media extractor in calling process 07-23 15:04:26.955 1579-1737/? I/MediaExtractor: extractor created in uid: 10028 (u0_a28) It appears in two cases: Android device startup First launch of beamz sample app after device reboot. Second, third and so on launches of beamz app are not produces logs with creation of MediaExtractor. But when I reboot device and run beamz sample app at first time then I always saw these logs. Maybe there is some system cache of MediaExtractor object and new instance of beamz app could reuse MediaExtractor from previous app instance? I am going to cut pieces of code to determine which code will produce logs with MediaExtractor. First I will try with clean app (without beamz library), next I will cut all OpenSL ES initialization and finally will cut AudioManager object. Hope this will be enough to found why system creates MediaExtractor. It appears that your initial hunch was right. There IS some problem with MediaExtractor on the Focus device. Although we do not use this directly, apparently, some included libs do – coding workarounds may not be possible. Can HTC fix this? Thx Doc Beamz Link to comment Share on other sites More sharing options...
dario Posted July 23, 2018 Share Posted July 23, 2018 Hi Docbeamz, Well unless it's really missing a lib from the required list of.libs for a AOSP based build of Android there's not much we could do as it would require adding (and clearing) this lib for what seems like a side case. I would recommend looking into submitting this as an issue on AOSP (unless it's been fixed in a later version). Sine I've see this reported against other Android OEMs online I would guess it's an AOSP issue but we can look into a patch for our builds if there's an official fix, but the thrid party libs making the call could also be patched with the work around I found to avoid calling this lib. best, Dario Link to comment Share on other sites More sharing options...
Docbeamz Posted July 25, 2018 Author Share Posted July 25, 2018 Hi Dario, We eliminated the MediaExtrator problem by eliminating OpenSL ES which we used for mp3 decompressing. - It calls MediaExtractor. We now use minimp3 for decompression. Thanks for the help Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.