November 15, 2014 
< | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | >
November 15, 2014 [00:37:09] *** Kaetemi has quit IRC[03:06:25] *** tristanseifert has joined #openal[03:06:25] *** ChanServ sets mode: +v tristanseifert[03:48:30] *** lritter_ has joined #openal[03:48:30] *** ChanServ sets mode: +v lritter_[04:04:27] *** lritter_ has quit IRC[04:04:51] *** lritter_ has joined #openal[04:04:51] *** ChanServ sets mode: +v lritter_[04:17:56] *** bjz has quit IRC[04:18:21] *** bjz has joined #openal[04:18:21] *** ChanServ sets mode: +v bjz[05:18:20] *** DrBenway has joined #openal[05:18:20] *** ChanServ sets mode: +v DrBenway[05:18:51] <DrBenway> im about to try to run openal soft for android[05:18:56] <DrBenway> anything i should look out for?[05:20:14] <DrBenway> at first run, it just fails loading the .so[05:37:15] *** bjz_ has joined #openal[05:37:15] *** ChanServ sets mode: +v bjz_[05:37:46] *** bjz has quit IRC[05:41:31] <KittyCat> DrBenway, what's the error?[05:41:58] <DrBenway> java.lang.IllegalArgumentException: Unable to load native library: /data/app-lib/com.kinevox.hello_android-1/libhello_android.so[05:42:14] <DrBenway> it's weird, i some point i saw it failing to find openal.so[05:42:34] <DrBenway> it starts failing as soon as i hook the dependency to my sound engine which links against openal soft[05:42:48] <DrBenway> built with cmake and the android toolchain from opencv (slightly modified)[05:43:07] <DrBenway> any issue with linking openal statically on android?[05:43:20] <DrBenway> i saw a comment in the build script about IDs and static linking[05:43:25] <DrBenway> i didn't really understand what they meant[05:43:54] <DrBenway> PS: hello_android is the name of my application[05:45:43] <DrBenway> how does openal soft handles the sound on android? does it fallsback on full on software or does it wrap android's native sound api?[05:45:56] <DrBenway> (open sl or something)[05:46:45] <KittyCat> openal soft always mixes in software (hence the 'soft' in its name), and uses opensl for output on android[05:47:08] *** bjz_ has quit IRC[05:47:25] <KittyCat> I'm not familiar with linking/running android apps. I've been able to cross-compile libopenal and openal-info for android, but I've not been able to get an emulator to cooperate to try running it[05:49:04] <DrBenway> yeah i got it compiling fine[05:49:18] <DrBenway> most people seems to load the lib manually from java[05:49:38] <DrBenway> for me it's a native activity and it's supposed to load right when my .so loads[05:49:48] <DrBenway> but something's failing and i can't get info on why[05:50:20] <DrBenway> i should probably get myself together and figure out how their debuger works[05:50:22] *** bjz has joined #openal[05:50:22] *** ChanServ sets mode: +v bjz[05:50:32] <DrBenway> (this is on the device, not on the emulator)[05:53:37] <DrBenway> i think it's too late. will give it a crack some other time[07:06:54] *** kornerr1 has joined #openal[07:06:54] *** ChanServ sets mode: +v kornerr1[07:52:36] *** bjz has quit IRC[07:55:44] *** bjz has joined #openal[07:55:44] *** ChanServ sets mode: +v bjz[08:16:17] *** zeroclouds has quit IRC[10:28:29] *** neXyon has joined #openal[10:28:29] *** ChanServ sets mode: +v neXyon[11:05:11] *** neXyon has quit IRC[11:07:31] *** neXyon has joined #openal[11:07:31] *** ChanServ sets mode: +v neXyon[11:21:23] *** neXyon has quit IRC[11:37:58] *** lritter_ has quit IRC[12:07:05] *** tristanseifert has quit IRC[12:47:24] *** CapsAdmin has joined #openal[12:47:24] *** ChanServ sets mode: +v CapsAdmin[12:57:29] *** take_cheeze has joined #openal[12:57:30] *** ChanServ sets mode: +v take_cheeze[13:47:46] *** tristanseifert has joined #openal[13:47:47] *** ChanServ sets mode: +v tristanseifert[13:53:38] *** Stratege__ has joined #openal[13:53:38] *** ChanServ sets mode: +v Stratege__[13:54:15] *** bjz_ has joined #openal[13:54:15] *** ChanServ sets mode: +v bjz_[13:55:40] *** Stratege has quit IRC[13:56:54] *** bjz has quit IRC[14:02:37] <rdb> DrBenway, keep in mind that Android's library loader does not load dependencies[14:02:49] <DrBenway> that must be it[14:03:00] <rdb> If libhello_android.so depends on, say, libopenal.so, you need to first dynamically load libopenal.so[14:03:04] <DrBenway> so i have to load the so manually and fetch the function pointers by name?[14:03:19] <DrBenway> shrug, that sucks[14:03:22] <rdb> You just have to make sure the dependency libraries are loaded[14:03:27] <rdb> No need to manually fetch function pointers[14:03:39] <DrBenway> thats kind of weird[14:03:48] <DrBenway> if i link against the .so, it'll try to load it automatically[14:03:54] <DrBenway> and fail loading my .so[14:04:09] <rdb> Yes, Android's native environment is really bad[14:04:16] <rdb> Developing C/C++ apps for Android is such a pain[14:04:18] <DrBenway> so what you're saying is that i'll have to find a different way to link (delay load or something?) and then call something that loads the .so?[14:04:36] <rdb> One easy way to get around this is by linking everything statically[14:04:49] <DrBenway> yeah, thats what i normally do[14:05:03] <DrBenway> but openal's build script doesn't look too friendly for static linking. and it's lgpl...[14:05:20] <DrBenway> im starting to consider just re-writing my sound code in opensl[14:05:23] <rdb> If your libhello_android.so depends on libopenal.so, though, you can simply call System.loadLibrary("openal"); before loading hello_android[14:05:27] <DrBenway> i would probably be done by now[14:05:37] <DrBenway> that's from java though[14:05:41] <DrBenway> i created a native activity[14:05:52] <DrBenway> im guessing there's another function to do it[14:05:55] <rdb> Yes, you will need to call that from the Java counterpart of your native activity.[14:05:59] <DrBenway> every web example do it from java[14:06:06] <DrBenway> i have no java code so far[14:06:14] <DrBenway> (kind of happy about that part)[14:06:15] <rdb> You will probably end up having some glue code in Java.[14:06:19] <rdb> Sad as it is.[14:06:26] <rdb> If you don't need 3D audio and all the fancy features that OpenAL has, OpenSL ES may be the way to go, though.[14:06:29] <DrBenway> i looked it up and apparently not that much[14:06:41] <DrBenway> nah i'll eventuallyu need 3d audio[14:06:51] <rdb> Right, you will probably want to extend NativeActivity so that you can put in a few loadLibrary calls, etc.[14:07:04] <rdb> You *can* do this using JNI instead, if you insist.[14:07:32] <rdb> But in my opinion, Java code written in C is at least as bad as having Java code written in Java. :-p[14:08:27] <rdb> Actually, you may be able to get away with using regular dlopen() in this case[14:08:29] <rdb> I haven't tried it though[14:08:32] <DrBenway> well they have a nice app_glue piece of code that allows me to keep most of my code the same as before[14:08:49] <DrBenway> i'll probably end up re-writing the glue code but for now, it gets me going[14:08:54] <rdb> Their native C API is so, so, limited[14:08:58] <rdb> But it's a start, I guess[14:09:21] <rdb> You'll soon find yourself using JNI a lot, I guess[14:09:28] <DrBenway> i'm still in the porting stage. haven't really hit the hard pain[14:09:34] <DrBenway> for what im curious?[14:10:06] <rdb> Image loading, for one[14:10:33] <DrBenway> im loading pngs fine[14:10:39] <rdb> I guess you're using libpng?[14:10:41] <DrBenway> i got my whole render pipeline ported without too many problems[14:10:42] <DrBenway> yeah[14:11:02] <DrBenway> i think the sound is the last thing and then it "should" be all sweet[14:11:03] <rdb> For my porting cases I decided to keep it lightweight by using Android's image loading APIs, meaning I can kick out libpng, libtiff, libjpeg, etc. etc.[14:11:36] <DrBenway> i might eventually swap for android's image loading if i can see that there's better perf[14:11:43] <DrBenway> but that should be relatively trivial[14:12:04] <DrBenway> i'll probably end up loading more their 4x4 compressed format than anything else[14:12:05] <rdb> If you ever have a need, hit me up on IRC and I can share some code[14:12:07] <DrBenway> png for now[14:12:16] <DrBenway> sure[14:12:22] <DrBenway> i always like looking at code[14:12:41] <DrBenway> https://github.com/fcoulombe/kinevox <-- i'm here[14:12:50] <DrBenway> not sure if it'll build for someone else[14:13:43] <rdb> https://github.com/panda3d/incremental/blob/master/panda/src/android/pnmFileTypeAndroidReader.cxx[14:13:58] <rdb> The actual pixel data reading is done with native code[14:14:17] <rdb> But you need to use JNI to actually call the BitmapFactory.readBitmap function[14:14:20] <rdb> Which is Java.[14:14:44] <rdb> The most annoying part of that all is having to pass around the JNIEnv and JavaVM objects[14:14:53] <DrBenway> i kind of like the idea of not having to do interops[14:14:58] <DrBenway> im guessing it's not "free"[14:15:40] <rdb> I dreaded the idea of having to compile all our thirdparty packages for Android and having it all work somehow, and still have reasonable size[14:16:59] <DrBenway> heh, if you check my 3rd party repo, i hooked up something that is not too bad with cmake[14:17:34] <rdb> I always worried about CMake+Android, does tha work well?[14:17:50] <DrBenway> i fork their repo to my own github and pull them down via submodules. and then have my own cmake file that builds them as external project using whatever config and outputs to binaries/<platform|arch|/usr/local/lib[14:17:57] *** lritter has joined #openal[14:17:57] *** ChanServ sets mode: +v lritter[14:18:10] <DrBenway> im not gonna say it was a walk in the park... or that it's fully polished but it's working so far[14:18:39] <DrBenway> opencv has a pretty heavy toolchain that needs a bit of adaptation (or they should finish what they started)[14:19:05] <rdb> Btw, the loading was for us extra complicated because we have a virtual file system, so I had to extend InputStream and OutputStream in Java to call into our C++ code. So when we load a bitmap, the call graph looks like Java -> C++ -> Java -> C++. Not sure if you have anything like that to deal with[14:19:11] <DrBenway> im still just building for arm7 but i'm guessing it won't be a huge amount of work to generate code for all archs[14:19:28] <DrBenway> ouch[14:19:46] <DrBenway> so far im using just the normal filesystem[14:19:53] <DrBenway> asset manager[14:20:18] <DrBenway> unless something that i'm calling is hitting java and im not away... it's all native[14:20:33] <rdb> Yeah, I use the asset manager whenever I can. I implemented the asset manager as a back-end for our virtual filesystem, I should probably set up some way to make it short-circuit our VFS when we load from the asset store[14:20:37] <DrBenway> s/away/aware[14:20:49] <DrBenway> i'll eventually probably implement some kind fo pack file[14:21:01] <DrBenway> it just hasnt been necessary yet[14:21:07] <rdb> That's why we have the virtual file system[14:21:14] <rdb> I'm not sure if android's asset manager is actually implemented in C++, actually, or if it calls into Java[14:21:39] <DrBenway> anyway... the least amount of back and forward between C++ and java[14:22:13] <rdb> Yeah, minimising the amount of JNI back-forth is usually a good thing[14:23:23] <rdb> The asset manager is a bit limited, though, I'm thinking of just making a .zip loader for the apk and reading from the apk zip directly[14:38:22] <DrBenway> linking openal statically seems to help... havent tested to see if the sound plays[16:48:24] *** bjz_ has quit IRC[16:50:24] *** bjz has joined #openal[16:50:24] *** ChanServ sets mode: +v bjz[17:06:43] *** kornerr1 has quit IRC[18:26:20] *** KittyCat has quit IRC[19:06:49] *** KittyCat has joined #openal[19:06:49] *** KittyCat has joined #openal[19:06:49] *** ChanServ sets mode: +v KittyCat[19:22:35] *** BrainDamage has joined #openal[19:22:35] *** ChanServ sets mode: +v BrainDamage[19:54:48] *** letoram has quit IRC[19:54:55] *** monokrome has quit IRC[19:55:01] *** letoram has joined #openal[19:55:02] *** ChanServ sets mode: +v letoram[19:56:21] *** Stratege___ has joined #openal[19:56:21] *** ChanServ sets mode: +v Stratege___[19:59:31] *** rmk0_ has joined #openal[19:59:32] *** ChanServ sets mode: +v rmk0_[20:00:20] *** Stratege__ has quit IRC[20:00:38] *** Amadiro has quit IRC[20:00:57] *** rmk0 has quit IRC[20:03:36] *** lritter has quit IRC[20:08:32] *** Amadiro has joined #openal[20:08:32] *** ChanServ sets mode: +v Amadiro[20:21:20] *** KCat has joined #openal[20:21:21] *** ChanServ sets mode: +v KCat[20:22:07] *** KittyCat has quit IRC[20:32:56] *** KCat is now known as KittyCat[20:36:26] *** mmozeiko has quit IRC[20:44:25] *** zeroclouds has joined #openal[20:44:25] *** ChanServ sets mode: +v zeroclouds[20:47:40] *** letoram has quit IRC[20:47:43] *** Impyy has quit IRC[20:48:25] *** Impyy has joined #openal[20:48:25] *** Impyy has joined #openal[20:48:25] *** ChanServ sets mode: +v Impyy[20:51:16] *** letoram has joined #openal[20:51:16] *** ChanServ sets mode: +v letoram[21:01:41] *** echelog has joined #openal[21:01:42] *** ChanServ sets mode: +v echelog[21:06:52] *** echelog has joined #openal[21:06:53] *** ChanServ sets mode: +v echelog[21:07:22] *** CapsAdmine has joined #openal[21:07:27] *** ChanServ sets mode: +v CapsAdmine[21:08:22] *** Amadiro has joined #openal[21:08:23] *** ermau has joined #openal[21:08:23] *** tepper.freenode.net sets mode: +vv Amadiro ermau[21:08:56] *** weltall has quit IRC[21:09:44] *** rdb_ has joined #openal[21:09:44] *** ChanServ sets mode: +v rdb_[21:09:57] *** CapsAdmin has quit IRC[21:10:21] *** Jonas__ has quit IRC[21:11:07] *** rdb has quit IRC[21:11:49] *** weltall has joined #openal[21:11:49] *** ChanServ sets mode: +v weltall[21:13:03] *** rude has quit IRC[21:14:12] *** rude has joined #openal[21:14:12] *** ChanServ sets mode: +v rude[21:18:44] *** Jonas___ has joined #openal[21:18:44] *** ChanServ sets mode: +v Jonas___[21:18:58] *** Jonas___ is now known as Jonas__[21:37:03] *** rdb_ is now known as rdb[21:50:19] *** monokrome has joined #openal[21:50:19] *** ChanServ sets mode: +v monokrome