[00:09:44] * KittyCat is back.
[00:21:35] *** prophile has quit IRC
[03:02:51] *** crashovrd has joined #openal
[03:04:10] <crashovrd> anyone successfully compiled OpenAL Soft under FreeBSD?
[03:04:31] <crashovrd> or rather, anyone succesfully run it under FreeBSD
[03:04:34] <crashovrd> it does compile
[03:04:47] <crashovrd> but fails an ASSERT
[03:04:54] <KittyCat> not sure if I've heard of someone using freebsd specificly. but it should
[03:04:57] <KittyCat> what's the assert?
[03:05:21] <crashovrd> :) i was gonna get to that part. but need some time to reset up for it
[03:11:34] <crashovrd> Assertion failed: (ret == 0), function InitializeCriticalSection, file /data/Downloads/openal-soft-1.3.253/OpenAL32/Include/alMain.h, line 45.
[03:12:04] <KittyCat> hmm..
[03:12:09] <crashovrd> on FreeBSD 7-RELEASE
[03:12:41] <crashovrd> the test has 2 lines of code
[03:12:43] <crashovrd>   device = alcOpenDevice(NULL);
[03:12:43] <crashovrd>   context = alcCreateContext(device, NULL);
[03:13:27] <KittyCat> seems it's failing on pthread_mutexattr_init(&attrib);
[03:13:31] <KittyCat> which is quite odd
[03:13:34] <crashovrd> btw, if you are the author.... THANKS FOR MAKING IT!!
[03:13:41] <crashovrd> my god it was badly needed
[03:13:58] <crashovrd> the SI is a piece of crap
[03:14:08] <KittyCat> heh, yes I am, and you're welcome
[03:14:25] <KittyCat> yes, Linux/Unix needed something a bit better than what the SI was offering
[03:15:25] <crashovrd> i really know nothing about posix threads, so i am of no help there i am afraid
[03:15:46] <KittyCat> my man pages say that can fail with:
[03:15:49] <KittyCat> ENOMEM Insufficient memory exists to initialize the mutex attributes object.
[03:17:13] <KittyCat> if you could print out what the functions return, it would be helpful (printf("%d\n", ret);)
[03:21:23] <crashovrd> you mean the 'device' and 'context' variables?
[03:21:51] <crashovrd> actually since its an assert, my printf probably wont get called
[03:21:59] <KittyCat> no, sorry, in OpenAL Soft
[03:22:20] <KittyCat> in the InitializeCriticalSection function, after the pthread_ calls and before the corresponding assert()
[03:22:36] <KittyCat> it's in OpenAL32/Include/alMain.h
[03:30:51] <crashovrd> i am adding it but its taking me a bit to do it using vi
[03:34:29] <crashovrd> InitializeCriticalSection: pthread_mutexattr_init(&attrib) ret=0
[03:34:29] <crashovrd> pthread_mutexattr_settype(&attrib, PTHREAD_MUTEX_RECURSIVE) ret=-1
[03:34:29] <crashovrd> Assertion failed: (ret == 0), function InitializeCriticalSection, file /data/Downloads/openal-soft-1.3.253/OpenAL32/Include/alMain.h, line 47.
[03:34:29] <crashovrd> Abort (core dumped)
[03:43:16] <crashovrd> dont know if this is relevant, but i will try it
[03:43:18] <crashovrd> http://64.233.169.104/search?q=cache:r_7vC-DW150J:www.codase.com/search/display%3Ffile%3DL2dlbnRvbzIvdmFyL3RtcC9yZXBvcy9jb2Rhc2UuYy9nbnVuZXQtMC42LjJiL3dvcmsvR05VbmV0LTAuNi4yYi9zcmMvdXRpbC9zZW1hcGhvcmUuYw%3D%3D%26lang%3Dc+freebsd+pthread_mutexattr_settype+PTHREAD_MUTEX_RECURSIVE&hl=en&ct=clnk&cd=11&gl=us
[03:43:33] <crashovrd> oid create_recursive_mutex_(Mutex * mutex)
[03:43:48] <crashovrd> they use a different function for BSD
[03:44:00] <crashovrd> pthread_mutexattr_setkind_np(&attr,
[03:44:00] <crashovrd> 			       PTHREAD_MUTEX_RECURSIVE);
[03:46:44] <crashovrd> yup, that seemed to work
[03:46:49] <crashovrd> or rather, it didnt fault
[03:47:20] <crashovrd> my test program wrote
[03:47:21] <crashovrd> device: 676368448
[03:47:21] <crashovrd> context: 676386816
[03:47:21] <crashovrd> AL lib: ALc.c:1253: exit() 1 device(s) and 1 context(s) NOT deleted
[03:47:21] <crashovrd> bsd7#
[03:49:49] <crashovrd> it also required a # include <pthread_np.h>
[03:51:18] <crashovrd> my only other change was ...
[03:51:19] <crashovrd>     //ret = pthread_mutexattr_settype(&attrib, PTHREAD_MUTEX_RECURSIVE);
[03:51:19] <crashovrd>     ret = pthread_mutexattr_setkind_np(&attr, PTHREAD_MUTEX_RECURSIVE);
[03:51:30] <KittyCat> _np means non-portable
[03:52:13] <KittyCat> hmm
[03:53:38] <KittyCat> are there any updates available?
[03:53:55] <KittyCat> for freebsd
[03:54:24] <crashovrd> i am on 7.0 which was released in Feb of this year
[04:09:37] <crashovrd> as a feature request, i would like to see the EFX-Util library included.
[04:10:04] <KittyCat> unfortunately the sources for that aren't available
[04:10:05] <crashovrd> the reason being that i am porting windows code where it is supplied. i dont need it to actually work, but i do need to bind with it
[04:10:27] <crashovrd> because i cant determine EFX support at compile time
[04:11:00] <KittyCat> can't you just not link with it if it's not available?
[04:11:38] <crashovrd> ideally that would be the proper solution
[04:11:56] <KittyCat> autotools and cmake allows you to check if a given library is available, and add it to the main list of libs to link with if available
[04:12:02] <crashovrd> but like i said, its a windows app. so it is assumed to be always there
[04:13:07] <crashovrd> a stub only lib would do the trick in the interim, since the extension is checked and its never called if there is no support for it
[04:13:24] <crashovrd> i am sure that would help others port their stuff.
[04:14:16] <KittyCat> I'd have to know what functions and variables are exported by the lib
[04:14:26] <crashovrd> EFX-Util.h
[04:14:32] <crashovrd> in the OpenAL 1.1 SDK
[04:14:41] <crashovrd> there are only 4 functions i think
[04:14:54] <crashovrd> yup
[04:14:55] <crashovrd> just 4
[04:16:08] <KittyCat> problem is, openal soft does support the efx extension, so it'd probably try to call those functions
[04:16:22] <crashovrd> oh wow, i didnt know that
[04:16:30] <crashovrd> yeah, that would be a problem
[04:17:50] <KittyCat> and the eax->efx conversion routines are closely gaurded by creative
[04:19:41] <crashovrd> :(
[04:19:41] <KittyCat> and openal soft doesn't support the eaxreverb effect (it only supports the generic reverb effect), so the produced effects might not be fully useable anyway
[04:19:55] <crashovrd> i only use 1 function : ConvertReverbParameters
[04:20:18] <crashovrd> and i only pass it the presets they define.
[04:21:12] <KittyCat> creative's said you can run those routines on a windows app, and store the results
[04:21:23] <KittyCat> so you can convert the eax presets, and make your own efx presets
[04:22:05] <crashovrd> lol, i kind of figured that was the reply i would get. i was just now considering doing that
[04:22:53] <crashovrd> the first thing that comes to mind though, is disabling it on non windows
[04:23:02] <crashovrd> so that is probably what others will do too
[04:23:46] <KittyCat> you can probably just completely skip using the efxutils for your app
[04:24:30] <KittyCat> make a small, windows-only app that takes the eax presets, and writes out efx presets into a custom header that you use in your main app
[04:38:45] *** juanmabc has quit IRC
[05:00:46] <crashovrd> hmm
[05:01:07] <crashovrd> well, my converted program was reporting openal errors
[05:01:18] <crashovrd> so i added alGetError to the test program
[05:01:23] <crashovrd> and it reports
[05:01:24] <crashovrd> device: 676368448, error 40964
[05:01:24] <crashovrd> context: 676386816, error 40964
[05:05:42] <crashovrd> fwiw, i do have sound
[05:06:08] <crashovrd> and FreeBSD only has OSS, no ALSA
[05:06:40] <crashovrd> enumerating with  ALC_ENUMERATE_ALL_EXT
[05:06:50] <KittyCat> figured as much (about no ALSA)
[05:06:54] <crashovrd> OSS Software
[05:07:05] <crashovrd> Wave File Writer
[05:07:08] <crashovrd> and thats it
[05:07:13] <KittyCat> yeah. I'm not sure if it's possible to enumerate devices using OSS
[05:09:25] <KittyCat> most I could probably do it try opening /dev/dsp1, /dev/dsp2, etc in order until I get a file-not-found error, and use /dev/dsp as a default
[05:09:25] <crashovrd> is there a way to get more diagnostic info as to why alcOpenDevice or alcCreateContext is failing?
[05:09:32] <KittyCat> I don't know if ythat's standard OSS, though
[05:09:44] <KittyCat> not really, unfortunately
[05:09:55] <KittyCat> if it's not returning null, it's not failing, though
[05:10:38] <crashovrd>   device = alcOpenDevice(NULL);
[05:10:39] <crashovrd>   error = alGetError();
[05:10:39] <crashovrd>   printf("device: %d, error %d\n", device, error);
[05:10:46] <crashovrd> thats the code that output the results
[05:10:51] <crashovrd> it doesnt do anything else
[05:11:05] <KittyCat> alGetError gets the error for the current context
[05:11:29] <KittyCat> there isn't a current context before you call alcMakeContextCurrent with a valid context
[05:12:07] <crashovrd> oic, so its a behavior issue
[05:12:08] <KittyCat> you'd use alcGetError (which returns an ALC_ enumerant) to get an error from a specific device
[05:15:01] <crashovrd> indeed, if does work
[05:15:10] <crashovrd> rather, it does work
[05:15:15] <crashovrd> i got sound
[05:16:00] <KittyCat> :)
[05:16:51] <crashovrd> i see it does report EFX support too
[05:16:54] <crashovrd> nice
[05:17:23] <crashovrd> 1 effect slot and 1 auxilary send
[05:18:22] <crashovrd> so what are your thoughts about adding an #ifdef and the 2 changes i mentioned
[05:18:46] <crashovrd> because so far it works, i have to rework the efx stuff to actually test that.
[05:18:50] <crashovrd> right now its just commented out
[05:19:44] <crashovrd> and again thank you for replacing that piece of crap SI version
[05:19:52] <crashovrd> i couldnt even compile against it
[05:20:30] <KittyCat> for the pthread stuff? I may, but I'd honestly prefer to get freebsd to support the stndard method of setting the recursive flag
[05:20:43] <KittyCat> the _np stuff is a bit ugly, so I'd try to avoid it if possible
[05:21:21] <crashovrd> what about as an interim solution then
[05:21:48] <crashovrd> i would rather not maintain the patch pending freebsd pthread resolution
[05:23:02] <crashovrd> FreeBSD has what they call 'ports'
[05:23:25] <crashovrd> they have a maintainer that takes the original code and apply patches against it
[05:23:52] <crashovrd> and these ports are paged and installed rather than the original
[05:24:24] <KittyCat> I suppose I can put in a patch for it, if you know the proper way to handle it (something that would work on any freebsd system that it'd need to care about)
[05:25:17] <crashovrd> that i cant answer, i dont know what the other BSD's do
[05:25:30] <crashovrd> i would suggest posting to their mailing list
[05:26:50] <KittyCat> for the most part, it's not a problem to just check if the setattr call fails, and tries the _np call after that. the main issue is whether I can gaurantee the _np header being there with the right function
[05:28:25] <crashovrd> i am the wrong person to ask on that one. i have zero knowledge of posix threads much less how they vary across unix versions.
[05:29:15] <crashovrd> your first instinct is probably the best resolution...
[05:29:34] <crashovrd> post to the FreeBSD mailing list with the failure and ask about them supporting it
[05:29:54] <crashovrd> depending on their response, you may have to #ifdef it to support it
[05:30:29] <crashovrd> http://www.freebsd.org/community/mailinglists.html
[05:46:31] <KittyCat> mind testing a patch?
[05:46:39] <crashovrd> sure
[05:47:41] <KittyCat> revert your change, and apply it with patch -p1 < pthread.patch
[05:47:50] <KittyCat> then rerun cmake, and make and make install
[05:48:10] <crashovrd> k, may take me a bit
[05:54:10] <crashovrd> http://pastebin.com/d33994b89
[05:54:22] <crashovrd> Assertion failed: (ret == 0), function InitializeCriticalSection, file /data/Downloads/openal-soft-1.3.253/OpenAL32/Include/alMain.h, line 52.
[05:55:40] <KittyCat> pthread_np.h wasn't found..
[05:55:42] <KittyCat> hmm
[05:56:34] <KittyCat> can you paste the generated CMakeFiles/CMakeError.log file?
[05:56:59] <crashovrd> /usr/include/pthread_np.h
[05:57:04] <crashovrd> thats where it is on this system
[05:57:33] <KittyCat> I'd imagine it should work, then. CMakeError.log should say why the check failed
[05:58:44] <crashovrd> http://pastebin.com/d2751e95
[05:59:37] <KittyCat> weird. seems something else needs ot be included before it
[05:59:41] <KittyCat> *to
[06:01:26] <crashovrd> this is what it contains
[06:01:28] <crashovrd> http://pastebin.com/d6ccad772
[06:02:01] <KittyCat> okay, so it needs pthread.h included first
[06:05:22] <KittyCat> this patch should work then (revert the last patch before applying this one)
[06:12:04] <crashovrd> http://pastebin.com/d14e20e61
[06:12:19] <crashovrd> Assertion failed: (ret == 0), function InitializeCriticalSection, file /data/Downloads/openal-soft-1.3.253/OpenAL32/Include/alMain.h, line 52.
[06:12:49] <KittyCat> okay, it didn't recheck for pthread_np.h.
[06:13:03] <KittyCat> delete CMakeCache.txt and rerun cmake/etc
[06:14:41] <crashovrd> http://pastebin.com/d566a729a
[06:15:38] <crashovrd> it seems its still not finding it
[06:15:47] <KittyCat> what's CMakeError.log say?
[06:17:08] <crashovrd> http://pastebin.com/d86cc19d
[06:17:58] <KittyCat> hmm, still failing..
[06:18:04] <KittyCat> sure you applied the new patch?
[06:18:27] <crashovrd> the output said
[06:18:35] <crashovrd> that wasnt in the first one, right?
[06:18:49] <KittyCat> it was
[06:19:04] <crashovrd> k, let me delete the patch files and try again
[06:19:34] <crashovrd> k, resend it
[06:19:34] <KittyCat> check CMakeLists.txt for pthread_np. it should have: CHECK_INCLUDE_FILES("pthread.h;pthread_np.h" HAVE_PTHREAD_NP_H)
[06:21:55] <crashovrd> yup, same thing with that file
[06:22:16] <crashovrd> i am doing tar -xf openal-soft-1.3.253.tar
[06:22:19] <crashovrd> to revert it
[06:22:37] <KittyCat> make sure to delete CMakeCache.txt so it'll recheck it
[06:25:14] <crashovrd> http://pastebin.com/d55373073
[06:25:18] <crashovrd> make failed
[06:26:08] <crashovrd> 'PTHREAD_MUTEX_RECURSIVE_NP
[06:26:11] <KittyCat> bleh. okay, change the PTHREAD_MUTEX_RECURSIVE_NP to PTHREAD_MUTEX_RECURSIVE
[06:26:12] <crashovrd> i used 'PTHREAD_MUTEX_RECURSIVE
[06:26:33] <KittyCat> I'm quite sure I've seen PTHREAD_MUTEX_RECURSIVE_NP before, though..
[06:27:45] <crashovrd> yes, with that change it works
[06:27:56] <crashovrd> i got sound again
[06:28:30] <KittyCat> okay, good
[06:29:01] <crashovrd> you are now my most favorite person in the world
[06:29:09] <crashovrd> ... atleast until i find bugs
[06:29:10] <crashovrd> ;)
[06:29:18] <KittyCat> heh :)
[08:05:39] *** KittyCat has quit IRC
[08:05:52] *** KittyCat has joined #openal
[08:05:52] *** ChanServ sets mode: +v KittyCat
[08:42:20] *** crashovrd has quit IRC
[10:00:48] *** Alam_Debian has quit IRC
[10:03:49] *** Walt has quit IRC
[10:28:58] *** Alam_Debian has joined #openal
[10:28:58] *** ChanServ sets mode: +v Alam_Debian
[10:40:48] *** Alam_Debian has quit IRC
[10:41:59] *** Alam_Debian has joined #openal
[10:41:59] *** ChanServ sets mode: +v Alam_Debian
[11:10:04] * KittyCat is away: sleep
[11:15:37] *** ChanServ has quit IRC
[11:18:22] *** ChanServ has joined #openal
[11:18:22] *** irc.freenode.net sets mode: +o ChanServ
[11:18:34] *** ChanServ has quit IRC
[11:19:39] *** ChanServ has joined #OpenAL
[11:19:39] *** irc.freenode.net sets mode: +o ChanServ
[12:50:19] *** prophile has joined #openal
[12:50:20] *** ChanServ sets mode: +v prophile
[14:07:36] *** Walt has joined #openal
[14:59:20] *** predaeus has joined #openal
[14:59:20] *** ChanServ sets mode: +v predaeus
[16:26:32] *** predaeus has quit IRC
[18:44:17] *** Alam_Debian has quit IRC
[18:44:18] *** D0pamine has quit IRC
[18:45:00] *** Alam_Debian has joined #openal
[18:45:00] *** D0pamine has joined #openal
[18:45:00] *** irc.freenode.net sets mode: +vv Alam_Debian D0pamine
[18:59:16] *** D0pamine has quit IRC
[18:59:16] *** Alam_Debian has quit IRC
[18:59:31] *** Alam_Debian has joined #openal
[18:59:31] *** D0pamine has joined #openal
[18:59:31] *** irc.freenode.net sets mode: +vv Alam_Debian D0pamine
[19:27:47] *** predaeus has joined #openal
[19:27:47] *** ChanServ sets mode: +v predaeus
[20:21:16] *** predaeus has quit IRC
[20:22:01] *** juanmabc has joined #openal
[20:22:01] *** ChanServ sets mode: +v juanmabc
[21:48:49] *** juanmabc has quit IRC
[22:11:39] *** juanmabc has joined #openal
[22:11:39] *** ChanServ sets mode: +v juanmabc
[23:06:27] *** crashovrd has joined #openal
[23:07:37] <crashovrd> got a non-critical bug in OpenAL Soft
[23:07:41] <crashovrd> Assertion failed: (ret == 0), function DeleteCriticalSection, file /data/Downloads/openal-soft-1.3.253/OpenAL32/Include/alMain.h, line 63.
[23:08:02] <crashovrd> if i am bound to the library, but never create a device or context. i get that on program exit
[23:08:42] <KittyCat> hm, that shouldn't happen
[23:08:58] <KittyCat> can you run it in a debugger and get a backtrace?
[23:09:15] <crashovrd> sure! if you can tell me how
[23:09:17] <crashovrd> ;)
[23:09:39] <KittyCat> run: gdb myapp
[23:09:53] <KittyCat> then 'r' to run it
[23:10:13] <KittyCat> , when it asserts, gdb will catch it. then run 'bt' to get the backtrace
[23:11:45] <crashovrd> http://pastebin.com/d20d16f7f
[23:13:06] <KittyCat> hmm
[23:18:39] <KittyCat> you can get around it by calling something silly. like, alcGetString(NULL, ALC_NO_ERROR); and ignoring the return value
[23:19:08] <KittyCat> I forgot to make sure openal is initialized before deleting the global mutex
[23:20:16] <KittyCat> or if you don't mind using GIT, I can put in a patch for it soon
[23:20:48] <crashovrd> i actually like tars betters
[23:21:31] <crashovrd> its not a critical issue for me, i just happened upon it by accident and thought i should report it
[23:21:53] <crashovrd> since it is plausible that i would encounter it in the future
[23:22:33] <crashovrd> and it would piss off anyone running automated tests
[23:23:42] <crashovrd> speaking of tests, a test suit would be nice for OpenAL Soft
[23:24:22] <crashovrd> as a minimum, it should enumerate devices and play a sound
[23:25:15] <KittyCat> the svn repo, where the old windows code and SI are, has some test programs
[23:26:57] <crashovrd> well, the use i see is that when you ship an app and someone runs it, this minimal test could provide a diagnostic on whether OpenAL works on their platform
[23:27:28] <KittyCat> yeah
[23:27:50] <crashovrd> i dont recall if OpenAL has vendor strings, but it would be nice to know which OpenAL your using as part of the diag
[23:29:20] <crashovrd> since distros are shipping the SI, i see that as a major issue on the horizon
[23:29:30] <crashovrd> as i said, i cant even run against the SI
[23:30:24] <crashovrd> so the diag would also say "Hey! your build from source/package/whatever installed correctly and works."
[23:31:22] <crashovrd> or your openal is out of date, see www.whatever.com for info on obtaining a current version.
[23:55:57] * KittyCat is back.





top