[00:02:30] *** prophile has quit IRC
[00:15:13] *** Walt has quit IRC
[00:29:06] *** Walt has joined #openal
[00:29:06] *** ChanServ sets mode: +v Walt
[00:58:24] *** Alam_Linux has joined #openal
[00:58:26] *** ChanServ sets mode: +v Alam_Linux
[01:01:27] *** Alam_Linux has quit IRC
[01:37:18] * KittyCat is back.
[01:38:40] <Alam_Debian> so, is OpenAl-Soft development moving to the SVN server or staying on GIT?
[01:40:33] <barra> git seems superior to SVN but for win32 users SVN would be the better option because the lack of good GUI git clients
[01:41:04] <KittyCat> main development will be in git, but I'll keep svn up-to-date with all the patches too
[01:42:34] <KittyCat> I'm still debating whether I should try to update svn per patch, or just push in a lump of changes when I update git
[01:42:42] <KittyCat> depends on how easy it'd be
[01:59:55] *** barra has quit IRC
[04:43:43] *** juanmabc has quit IRC
[05:02:45] *** jvalenzu has quit IRC
[06:45:34] *** jvalenzu has joined #openal
[06:45:34] *** ChanServ sets mode: +v jvalenzu
[07:26:04] *** predaeus has joined #openal
[07:26:04] *** ChanServ sets mode: +v predaeus
[08:13:45] *** Walt has quit IRC
[08:32:26] *** predaeus has quit IRC
[10:24:31] *** juanmabc has joined #openal
[10:24:31] *** ChanServ sets mode: +v juanmabc
[10:28:13] *** Walt has joined #openal
[10:28:13] *** ChanServ sets mode: +v Walt
[10:36:37] * KittyCat is away: sleep
[14:42:23] *** Walt has quit IRC
[15:31:18] *** prophile has joined #openal
[15:31:18] *** ChanServ sets mode: +v prophile
[17:18:13] *** juanmabc has quit IRC
[18:07:48] *** kb1ooo has joined #openal
[18:07:48] *** ChanServ sets mode: +v kb1ooo
[18:27:29] <kb1ooo> does anyone know what the response time is of an alSourcePause()?  and a subsequent resume with alSourcePlay()?
[18:32:45] *** juanmabc has joined #openal
[18:32:47] *** ChanServ sets mode: +v juanmabc
[18:59:40] *** predaeus has joined #openal
[18:59:40] *** ChanServ sets mode: +v predaeus
[19:01:46] *** prophile has quit IRC
[19:04:51] <kb1ooo> bbl
[19:04:57] *** kb1ooo has quit IRC
[20:08:28] *** prophile has joined #openal
[20:08:28] *** ChanServ sets mode: +v prophile
[20:22:01] *** predaeus has quit IRC
[21:24:55] *** juanmabc has quit IRC
[22:08:11] *** juanmabc has joined #openal
[22:08:13] *** ChanServ sets mode: +v juanmabc
[22:54:30] *** kb1ooo has joined #openal
[22:54:30] *** ChanServ sets mode: +v kb1ooo
[23:23:49] * KittyCat is back.
[23:25:46] <KittyCat> kb1ooo, I think the response time ultimately depends on the refresh.
[23:26:06] <KittyCat> and the delay before you hear it depends on the output buffer size
[23:33:53] <KittyCat> if you're thinking about doing alSourcePause(); do something quickly with source; alSourcePlay(); to do something without making it sound like it stopped, it won't work reliably
[23:36:28] <kb1ooo> KittyCat, tnx.  Actually what I really want to do is modulate using AL_GAIN.
[23:36:50] <kb1ooo> I have a simple application where I need to modulate a single freq tone on and off.
[23:37:23] <KittyCat> you can change most properties of a source while it's playing
[23:37:33] <kb1ooo> this generates clicks unless you use something like a gaussian rise and fall times
[23:38:01] <KittyCat> ah, hmm..
[23:39:23] <kb1ooo> so what I really need is to maybe make several alSourcef (_source, AL_GAIN,     val); calls
[23:39:48] <kb1ooo> where val follows a gaussian envelope.
[23:40:14] <kb1ooo> this is similar to the envelope wish list I saw on the openal site
[23:40:19] <KittyCat> you can do that while it's playing, no problem
[23:41:13] <kb1ooo> yah, i just need to figure out the reponse time of the alSourcef call.
[23:41:30] <kb1ooo> I suppose I can record and look at the signal.
[23:41:36] <KittyCat> funny you should mention that, though. I've been recently thinking about coming up with an extension to do just that (the envelope buffer/properties)
[23:43:07] <KittyCat> but the response time is no set value. different implementations can have bigger or smaller update sizes
[23:43:17] <KittyCat> some can even do it dynamicly
[23:49:56] <kb1ooo> hmm, ok.  Is there anything configurable like internal streaming buffer size that affects it?
[23:50:45] <KittyCat> there's the ALC_REFRESH context attribute, but that's only a hint
[23:52:47] <KittyCat> particularly for software, changing the refresh length can have some pretty bad consequences (higher latency, or more skipping), thus OpenAL Soft ignores it and lets the user pick themselves via a config file
[23:55:46] <KittyCat> what I can do, though, is fix openal soft so that drastic volume changes are applied overtime to reduce/remove skipping
[23:56:02] <KittyCat> afaik, the windows drivers already have it fixed
[23:59:27] <kb1ooo> ok, I'm on os x and planning to use the app on iphone as well.
[23:59:40] <KittyCat> to do it properly I'd probably have to store all 8 channel volumes per source, and when the target volumes are figured out, modify the source volumes so that they're closer to the target (and not letting them change beyond a certain amount per update)





top