[00:04:52] *** barra_away has quit IRC
[00:20:23] *** barra_away has joined #openal
[00:20:23] *** ChanServ sets mode: +v barra_away
[00:22:01] *** barra_away is now known as barra_
[00:52:48] *** Proteus has joined #openal
[00:52:48] *** ChanServ sets mode: +v Proteus
[01:15:21] *** Walt_ has quit IRC
[01:21:02] *** Walt_ has joined #openal
[01:21:02] *** ChanServ sets mode: +v Walt_
[02:22:18] *** ASau` has joined #openal
[02:22:19] *** ChanServ sets mode: +v ASau`
[02:22:59] <ASau`> Hello!
[02:23:19] <ASau`> Can anyone answer on some questions?
[02:23:40] <ASau`> 1. Is recording supported cross-platform?
[02:23:52] <ASau`> 2. Is it supported on NetBSD either?
[02:24:01] <ASau`> 3. Is NetBSD supported at all?
[02:24:38] <ASau`> 4. What I have to provide to get the lacking support?
[02:40:54] <wild13> hi
[02:41:09] <wild13> yes yes yes and umm  yes
[02:46:52] *** barra_ has quit IRC
[02:51:30] *** wild13 has quit IRC
[03:11:54] *** Walt_ has quit IRC
[03:43:56] <KittyCat> lgp-michael, cool :)
[03:44:35] <KittyCat> ASau`, OpenAL Soft should compile on NetBSD, but I'm not sure if anyone's tried it
[03:44:49] <KittyCat> does it use OSS (or ALSA)?
[03:46:14] * KittyCat is back.
[03:51:44] <ASau`> Ha!
[03:52:01] <ASau`> It compiles after I patched bug in it.
[03:52:22] <ASau`> Of course, it doesn't use alsa.
[03:56:38] <KittyCat> what's the bug?
[03:59:49] <ASau`> Now there're lots of them.
[04:00:04] <ASau`> OpenAL is extremely portable and well-documented library.
[04:07:31] <KittyCat> I'd like to think so
[04:07:56] <ASau`> You may continue.
[04:09:48] <KittyCat> did you get OpenAL Soft built? or are you using a different one?
[04:10:16] <ASau`> I don't intend to use non-free software.
[04:10:27] <KittyCat> OpenAL Soft is LGPL..
[04:10:44] <ASau`> It states otherwise.
[04:10:52] <KittyCat> where?
[04:11:05] <ASau`> In its COPYING file.
[04:11:21] <ASau`> Anyway, I'm not going to use non-free software.
[04:11:27] <KittyCat> GNU LIBRARY GENERAL PUBLIC LICENSE, Version 2
[04:16:48] <KittyCat> well, it is free software, under the LGPL v2.
[04:17:06] <ASau`> Anything with word GNU isn't free software.
[04:17:21] <ASau`> I don't use Stallman's redefinitions.
[04:17:41] <KittyCat> what do you consider to be free software, then?
[04:18:06] <KittyCat> (not looking to debate, just curious..)
[04:18:12] <ASau`> From BSD to public domain.
[04:20:56] <KittyCat> I'd like to think LGPL is a nice middle-ground. not as restricting/viral as the GPL (eg. you don't have to make your app LGPL just by linking to libs using it and you don't need to supply sources for unmodified binaries), while making sure the code stays open and free of closed, proprietary changes
[04:24:18] *** juanmabc has quit IRC
[04:54:38] <ASau`> Ha!
[04:54:44] <ASau`> ALSA-only solution.
[04:56:23] <KittyCat> hm?
[05:13:00] *** Proteus has quit IRC
[05:13:07] *** Proteus_ has joined #openal
[05:13:07] *** ChanServ sets mode: +v Proteus_
[05:37:36] *** pabs3 has joined #openal
[05:37:36] *** ChanServ sets mode: +v pabs3
[05:40:20] <angasule> KittyCat: does building a static library work?
[05:56:27] <KittyCat> theoretically. the cmake script won't do it by default, though
[05:57:18] *** Proteus_ has quit IRC
[05:57:27] *** Proteus_ has joined #openal
[05:57:27] *** ChanServ sets mode: +v Proteus_
[06:10:51] *** wild13 has joined #openal
[06:10:51] *** ChanServ sets mode: +v wild13
[06:13:51] *** angasule has quit IRC
[07:03:29] *** wild13 has quit IRC
[07:32:48] <lgp-michael> angasule: yes it does, change SHARED to STATIC in CMakeLists.txt
[07:33:38] <lgp-michael> tho be aware that it dlopens libraries it needs so even if you make it static some of its functionality wont be
[07:41:24] *** Rain|code has quit IRC
[07:48:01] <KittyCat> OSS (the sound backend) is always "dynamic"
[07:49:10] <KittyCat> for any app
[07:53:38] * lgp-michael nods
[09:48:50] *** pabs3 has left #openal
[13:05:52] *** predaeus has joined #openal
[13:05:52] *** ChanServ sets mode: +v predaeus
[13:07:27] <predaeus> Hey! Does by chance anybody know what creative's license for deploying OpenAL on the XBox360 looks like? I can't find licensing information on Creative's site, only that they are the license holders when deployed on certain platforms.
[13:09:25] <predaeus> checking svn now for licensing info...
[13:11:37] *** Walt_ has joined #openal
[13:11:37] *** ChanServ sets mode: +v Walt_
[13:13:14] *** barra_away has joined #openal
[13:13:14] *** ChanServ sets mode: +v barra_away
[13:13:26] *** barra_away is now known as barra_
[13:15:15] *** angasule has joined #openal
[13:15:15] *** ChanServ sets mode: +v angasule
[13:42:06] <angasule> KittyCat: around, by any chance?
[13:49:53] <predaeus> looks like the license is free of charge at least, but will contact creative
[13:51:32] <angasule> predaeus: license for what?
[13:52:02] <predaeus> angasule, OpenAL SDK for Xbox 360, creative holds a separate license for that
[13:52:21] *** Walt_ has quit IRC
[13:52:37] <angasule> probably there is an NDA involved
[13:52:40] <angasule> they love NDAs
[13:53:00] *** Walt_ has joined #openal
[13:53:00] *** ChanServ sets mode: +v Walt_
[13:53:26] <predaeus> :-D
[13:53:45] <angasule> not kidding, creative is freaky like that :P
[13:56:42] <KittyCat> angasule, I'm here
[13:57:35] <angasule> KittyCat: ever compiled openal-soft statically?
[13:58:57] <angasule> I've been reading some mails and talking with the debian-games people
[14:01:12] <KittyCat> once
[14:01:55] <angasule> did it work? :)
[14:02:24] <angasule> btw, not sure the current CMakeLists.txt allows for it? the debian people seem to have some sort of patch, but I had a power failure while talking to them...
[14:06:00] <angasule> another issue,
[14:08:31] <angasule> is that I'm not sure they have a fake package for openal (like there is a libgl1 for OpenGL)
[14:10:48] <angasule> they seem to have one for libopenal0 (what the SI provided)
[14:12:32] <KittyCat> I believe it worked without an issue. just had to change SHARED to STATIC. I needed to do it to try and profile the lib
[14:13:52] <angasule> hmm, openal-soft is marked with "replaces openal0", which should be 'conflicts', I think
[14:14:01] <angasule> or it doesn't conflict? :?
[14:14:33] <KittyCat> it conflicts with the headers
[14:14:34] <angasule> is it possible to install the OpenAL SI and -soft? they have different sonames, etc, right?
[14:14:56] <angasule> headers are a different package
[14:15:43] <KittyCat> yeah, but it's pretty dangerous to have both installed, still
[14:16:11] <angasule> why?
[14:17:15] <KittyCat> eg. if alut uses libopenal.so.0 and the app uses .1
[14:17:40] <lgp-michael> angasule: I'd say for one that the dynamic loader is a hit and miss affair at best, (kernel issue) and ifyou have 2 different sonames fora library you'll have to toss a coin as to which one it uses
[14:17:41] <angasule> hmm
[14:18:06] <angasule> uh? I was quite sure that the version would set them apart
[14:18:43] <angasule> I haven't used alut much, but there were some issue in the SI? it was integrated? now it's separate?
[14:21:45] <KittyCat> basically the issue is if alut links with openal.so.0 and the app links with .1, then at run time both libs will try to be loaded
[14:22:05] <angasule> well
[14:22:11] <KittyCat> so alutInit will use a different lib than your al* calls
[14:22:25] <KittyCat> or there'll be problems resolving symbols
[14:22:31] <KittyCat> or other fun things
[14:22:32] <angasule> isn't alut soname versioned?
[14:22:43] <KittyCat> yes
[14:23:06] <KittyCat> and the al lib it links to is version, too
[14:24:32] <angasule> and the -dev package can only link to the latest openal, so it's not possible to break it that way without putting some work into it
[14:24:42] <angasule> I can't find an alut package other than freealut
[14:24:57] <angasule> alut was included in the SI, I guess? gah
[14:25:04] <KittyCat> the ideal way to handle it for binary distros is to add a symlink from .0 to .1
[14:25:12] <KittyCat> alut isn't part of the SI anymore
[14:25:18] <KittyCat> it's been a seperate package for a while
[14:25:57] <angasule> but the SI package was based on 0.0.8, which still had alut, right?
[14:26:15] <angasule> they shouldn't have named it alut0, but alut1, I think
[14:26:26] <KittyCat> no, 0.0.8 doesn't have alut in it
[14:26:43] <KittyCat> though it did have extensions that had alut functions.. it was a mess :P
[14:26:44] <angasule> weird
[14:26:46] <angasule> ah
[14:28:28] <angasule> freealut is synched in some way to openal-soft?
[14:29:26] <KittyCat> (free)alut just uses openal. openal soft, being a compliant implementation, can be used with freealut as is
[14:29:39] <KittyCat> freealut doesn't do anything special and just makes normal AL calls
[14:30:06] <angasule> hmm, ok
[14:30:28] <angasule> I'm not sure if to propose to make freealut provide alut0 or alut1 (openal-soft should provide libopenal1)
[14:30:57] <KittyCat> no reason to bump freaalut's abi number, unless the abi breaks.
[14:31:18] <angasule> what's freealut's soname?
[14:31:43] <KittyCat> libalut.so.0
[14:31:45] <angasule> alut has a specification, right?
[14:31:48] <KittyCat> yeah
[14:32:11] <angasule> ok, sorry about the questioning, but I have to be 100% sure about these things if I'm going to explain them to the debian devs
[14:32:25] <KittyCat> heh
[14:32:26] <angasule> some of them don't even seem to be coders, which makes it a bit hard to talk to them
[14:32:56] <angasule> one of them argued against having an openal1 package as with libgl1
[14:32:59] <KittyCat> the only change that needs to be done is, anything linking to openal needs to be relinked, so it'll look for openal's new .so name
[14:33:36] <KittyCat> having openal0 and openal1 installed simultaniously will just break things
[14:33:46] <angasule> why?
[14:33:50] <angasule> different sonames
[14:34:01] <angasule> when linking new stuff, the highest soname will be used
[14:34:13] <angasule> and old stuff linked against .0 will work fine
[14:34:32] <KittyCat> yeah, but like I said wi th alut. if alut uses one version of openal, and the app uses another, both will be pulled in
[14:34:49] <KittyCat> and what happens with that is anyones guess.. but it doesn't work well
[14:35:34] <angasule> but that's not possible
[14:35:43] <KittyCat> yes it is
[14:35:54] * lgp-michael nods
[14:35:54] <angasule> well, packages are compiled against freealut
[14:36:09] <KittyCat> when you link with -l, it'll link against a specific abi version
[14:36:10] <angasule> you have to mess up yourself, that's what I mean :)
[14:36:28] <KittyCat> so if you use -lopenal, you'll get either libopenal.so.0 or libopenal.so.1
[14:36:34] <angasule> it'll only affect devs who aren't careful
[14:37:09] <angasule> but debian users in general should be able to install both without worries
[14:37:19] <angasule> it's only if you compile your own code that it can break
[14:37:41] <KittyCat> only if packages were carefully split so as not to have dual dependancies
[14:37:46] <angasule> if you install oldalut, SI and Soft and then compile a program that something could go wrong
[14:38:03] <KittyCat> but its more work for much less gain to maintain packages against openal0, when they'll work fine with openal1 after a relink
[14:38:05] <angasule> bad grammar, sorry
[14:38:24] <angasule> yes, all packages have already been recompiled against openal1
[14:38:50] <KittyCat> then there's no need for openal0 because nothing should depend on it anymore
[14:38:55] <KittyCat> old packages should be upgraded
[14:39:36] <angasule> openal-dev depends on openal1 and alut-dev on alut0 (freealut)
[14:39:42] <angasule> so actually it's impossible to link wrong
[14:40:09] <angasule> there is no -dev package for openal0 and alut-1 that I can see
[14:41:50] <KittyCat> if both libs are there, then anyone manually linking can have issues
[14:42:02] <angasule> how?
[14:42:18] <angasule> you need the -dev to compile, and the -dev will bring in the latest .so
[14:42:26] <angasule> and the linker will link with the latest .so
[14:43:01] <angasule> unless you manually download the SI headers and then compile without freealut installed, it seems safe
[14:43:09] <angasule> and if you do that, then you deserve the pain :)
[14:43:10] <KittyCat> which lib will alut use?
[14:43:22] <KittyCat> if an app uses openal0 and alut, it'll need alut to use openal0 as well
[14:43:33] <KittyCat> if an app uses openal1 and alut, it'll need alut to use openal1
[14:43:55] <KittyCat> and alut itself doesn't break.. just the lib it links to. so upping the abi version is wrong
[14:44:32] <angasule> but does openal0 provide a libalut.so.0 ?
[14:44:48] <KittyCat> no
[14:45:41] <angasule> freealut will ALWAYS have openal1 (soft) available
[14:45:57] <angasule> and if anyone tries to link against alut, they will install alut-dev
[14:46:10] <KittyCat> then what about apps that use alut and openal0?
[14:46:30] <KittyCat> alut will use openal1, and the app will use openal0. then you get clashing libs
[14:46:51] <angasule> uh, weird, now I see an alut0 with openal0 o_O
[14:47:20] <angasule> how old is freealut?
[14:47:37] <angasule> how pooperous
[14:48:05] <KittyCat> besides, openal soft is supposed to improve the situation with openal. it is a fully compatible openal implementation. if existing apps continue to use 0.0.8, it really defeats part of the purpose
[14:48:35] <angasule> no new packages will be compiled against 0.0.8
[14:48:40] <KittyCat> those apps won't get an improvement in sound, despite an improved openal being installed
[14:49:16] <KittyCat> it's like not linking apps against a gl 2.0 lib because they're already compiled agianst 1.5
[14:49:35] <KittyCat> the only mistake (which I fully take as my fault) is that openal soft uses .1
[14:49:45] <KittyCat> it *should've* used .0, but I didn't realize that in time
[14:49:55] <angasule> poop, I see now, I thought there was no freealut for 0.0.8, but there was
[14:50:19] <angasule> so now that freealut works with openal1 any app has to be compiled against those two
[14:50:38] <angasule> hmm
[14:50:48] <angasule> but -soft isn't fully binary compatible, is it?
[14:50:53] <KittyCat> yes it is
[14:51:01] <KittyCat> unless the app is using unofficial exports
[14:51:04] <angasule> doesn't it have quite a few missing functions?
[14:51:23] <angasule> from loki extensions and stuff
[14:51:35] <angasule> but those should be dynamically loaded, I guess
[14:51:46] <KittyCat> it has a few missing extensions, and by extension not those functions. but those functions shouldn't be exported or linked against by the app directly
[14:52:31] <KittyCat> the only way to get extension functions is via alcGetProcAddress
[14:52:49] <KittyCat> any app that uses them explicitly is broken
[14:52:58] <KittyCat> and I'm not sure I ran into any that have..
[14:53:29] <angasule> thanks for all the info, I think now I can write a mail
[14:53:37] <angasule> mostly to ask for an openal1 fake package
[14:53:54] <angasule> so that, say, creative can provide a different implementation
[14:54:17] <KittyCat> you mean like a virtual/ package in gentoo?
[14:54:23] <angasule> I guess
[14:54:30] <angasule> a sort of 'provides'
[14:54:38] <angasule> so openal-soft would provide libopenal1
[14:55:19] <KittyCat> in gentoo, a package would depend on, for example, virtual/opengl
[14:55:42] <angasule> on debian it would depend on a non-existant package called libopenal1
[14:55:52] <angasule> and openal-soft has a field that says "replaces: libopenal1"
[14:56:07] <angasule> 'replaces' isn't the best choice of word, but it's there
[14:57:07] <KittyCat> any number of different packages (eg. nvidia's drivers, ati's) would "provide" virtual/opengl, so other packages would just depend on that and not worry about the exact package
[14:57:19] <angasule> yeap
[14:57:24] <angasule> I want the same for openal
[14:57:32] <angasule> right now there is only Zuul, I mean, openal-soft
[14:57:51] <angasule> but others might come
[15:04:06] <KittyCat> the SI would need to be a part of that package group too. unless it's just dropped completely
[15:05:27] <angasule> well, the difference in soname might be an issue
[15:06:15] <angasule> anyway, the SI would only be kept for backwards compatibility
[15:06:47] <KittyCat> which is why openal-soft would probably provide a .0 -> .1 symlink for binary distros
[15:07:14] <KittyCat> unless it wants to relink all against .1 and provide a .1 -> .0 for the SI
[15:20:48] *** Gigs has quit IRC
[15:20:58] *** Gigs has joined #openal
[15:20:58] *** ChanServ sets mode: +v Gigs
[16:13:06] <angasule> apparently binary compatibility is really friggin' hard
[16:13:40] <KittyCat> not for the lib itself
[16:13:55] <KittyCat> just don't remove functions, or change the parameters/return type
[16:14:03] <KittyCat> or their calling convention
[16:15:23] <angasule> well
[16:16:00] <angasule> apparently it wouldn't be easy for creative labs to build a replacement libopenal.so.1 that would be compatible
[16:16:09] <angasule> it would require relinking to the games, etc in debian
[16:17:41] <angasule> <angasule> persia: I don't know how much the C ABI changes between gcc versions, if at all? I know C++ is a mess
[16:17:41] <angasule> [10:46:56] <persia> angasule: Not necessarily at all.  It depends on which gcc they used.  By example, some libraries in Debian and Ubuntu (using the same version of gcc, often prepared by the same person) may not be binary compatible.
[16:18:03] <angasule> [10:48:38] <persia> angasule: Well, there's a few factors.  In the case I mentioned above, I believe the main difference is that Debian compiles against an i486 target, and Ubuntu against an i586 target, but I may be incorrectl.
[16:18:04] <angasule> [10:49:45] <persia> Typically, when each package is compiled, it is compiled against some known good version of a library.  As long as that library has the same set of exposed symbols, with the same definitions, in the same order, it remains safe.
[16:20:23] *** juanmabc has joined #openal
[16:20:23] *** ChanServ sets mode: +v juanmabc
[16:20:38] <KittyCat> it wouldn't be hard for creative to make their own
[16:20:58] <KittyCat> openal is C, not C++, so C++'s ABI (which has been messy until recently) isn't an issue
[16:22:13] <angasule> well
[16:22:14] <KittyCat> .so's don't have an issue with symbol ordering
[16:22:44] <angasule> they said some do
[16:23:05] <KittyCat> linux doesn't
[16:23:27] <angasule> I think the debian-games team doesn't have the best debian devs :P
[16:23:31] <KittyCat> can't speak for other systems, but I don't think ELF binaries have that problem
[16:24:00] <angasule> yeap
[16:24:12] <KittyCat> it would just need the same symbol names with the same function definitions. and since the openal API is explicitly defined, you couldn't break from that anyway and still be called 'openal'
[16:24:30] <angasule> exactly
[16:24:46] <angasule> and the C ABI is very well defined, AFAIK
[16:25:11] <angasule> the only problem would be extra symbols
[16:25:16] <angasule> I'm starving
[16:25:23] <KittyCat> only difference in the C ABI is if there's a _ prefix. but I only Windows/COFF uses that, and no Unix systems
[16:25:46] <KittyCat> COFF/PE/whatever
[16:25:47] <angasule> plus creative would be using gcc or at least gcc's ABI
[16:25:57] <angasule> yeah, PE, portable executable ;)
[17:35:33] *** juanmabc has quit IRC
[17:41:59] * KittyCat is away: sleep
[17:50:53] *** angasule has quit IRC
[17:52:11] *** angasule has joined #openal
[17:52:11] *** ChanServ sets mode: +v angasule
[18:12:17] *** predaeus has quit IRC
[19:18:53] *** wild13 has joined #openal
[19:18:53] *** ChanServ sets mode: +v wild13
[19:21:35] *** Rivorus has joined #openal
[19:21:35] *** ChanServ sets mode: +v Rivorus
[22:04:51] *** angasule has quit IRC
[22:48:47] *** juanmabc has joined #openal
[22:48:47] *** ChanServ sets mode: +v juanmabc
[23:50:42] *** angasule has joined #openal
[23:50:42] *** ChanServ sets mode: +v angasule





top