February 7, 2017 
< | 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 | >
February 7, 2017 [00:20:17] *** Murii <Murii!~Murii@79.113.234.223> has quit IRC ()[00:25:52] *** Smirftsch1 <Smirftsch1!~Smirftsch@p2003007A0D055800C8604041EB21B02E.dip0.t-ipconnect.de> has joined #openal[00:25:52] *** ChanServ sets mode: +v Smirftsch1[00:26:36] *** kenzierocks_ <kenzierocks_!~kenzieroc@yes.quite.indeed.old.chap.it.is.kenzierocks.me> has joined #openal[00:26:36] *** ChanServ sets mode: +v kenzierocks_[00:27:47] *** caedes_ <caedes_!~caedes@ip1f11b658.dynamic.kabel-deutschland.de> has joined #openal[00:27:47] *** ChanServ sets mode: +v caedes_[00:32:17] *** lilmike_ <lilmike_!server@mtserver.mwtd.net> has joined #openal[00:32:17] *** ChanServ sets mode: +v lilmike_[00:33:17] *** jpernst_ <jpernst_!~jameson@162.243.131.93> has joined #openal[00:33:17] *** ChanServ sets mode: +v jpernst_[00:34:26] *** Smirftsch <Smirftsch!~Smirftsch@p2003007A0D055800C8604041EB21B02E.dip0.t-ipconnect.de> has quit IRC (*.net *.split)[00:34:27] *** kenzierocks <kenzierocks!~kenzieroc@yes.quite.indeed.old.chap.it.is.kenzierocks.me> has quit IRC (*.net *.split)[00:34:28] *** caedes <caedes!~caedes@ip1f11b658.dynamic.kabel-deutschland.de> has quit IRC (*.net *.split)[00:34:29] *** weltall <weltall!~weltall@planeshift/developer/weltall> has quit IRC (*.net *.split)[00:34:30] *** jpernst <jpernst!~jameson@162.243.131.93> has quit IRC (*.net *.split)[00:34:30] *** lilmike <lilmike!server@mtserver.mwtd.net> has quit IRC (*.net *.split)[00:34:32] *** kenzierocks_ is now known as kenzierocks[00:34:32] *** lilmike_ is now known as lilmike[00:34:33] *** weltall2 <weltall2!~weltall@planeshift/developer/weltall> has joined #openal[00:34:33] *** ChanServ sets mode: +v weltall2[00:35:28] *** weltall2 is now known as weltall[02:55:07] *** Smirftsch2 <Smirftsch2!~Smirftsch@p2003007A0D078600C8604041EB21B02E.dip0.t-ipconnect.de> has joined #openal[02:55:07] *** ChanServ sets mode: +v Smirftsch2[02:55:43] *** Smirftsch1 <Smirftsch1!~Smirftsch@p2003007A0D055800C8604041EB21B02E.dip0.t-ipconnect.de> has quit IRC (Ping timeout: 245 seconds)[03:04:17] <Emcy> What does "emulate EAX reverb" do in the openal soft configurator?[03:05:29] <KittyCat> it uses the lower quality standard reverb effect when the app uses the eax reverb effect[03:06:25] <Emcy> do you mean efx? how does eax apply, that was creatives old thing[03:07:17] <KittyCat> "eax reverb" is what the reverb type is called in efx[03:07:57] <KittyCat> standard reverb follows the I3DL2 reverb standard. "eax reverb" is an updated version with more parameters[03:09:11] <Emcy> i understand[03:10:43] <Emcy> should be no rason to enable that i guess[03:12:44] <KittyCat> not usually, unless you have a rather weak cpu[03:26:27] <Emcy> sounds like brutal doom64 uses EFX throughout all the maps in version 2[03:26:31] <Emcy> nice[03:26:51] <Emcy> seems like he only used one preset for the whole game though[05:50:24] *** irungentoo <irungentoo!~irungento@unaffiliated/irungentoo> has quit IRC (Remote host closed the connection)[08:49:08] *** vrlx <vrlx!~vrlx@79.113.234.223> has joined #openal[08:49:08] *** ChanServ sets mode: +v vrlx[08:50:25] *** vrlx <vrlx!~vrlx@79.113.234.223> has quit IRC (Client Quit)[11:30:31] *** vmuresan_ <vmuresan_!~vmuresan@gw1.computervoice.ro> has joined #openal[11:30:31] *** ChanServ sets mode: +v vmuresan_[11:35:01] *** vmuresan_ is now known as Murii[15:47:10] *** irungentoo <irungentoo!~irungento@unaffiliated/irungentoo> has joined #openal[15:47:10] *** ChanServ sets mode: +v irungentoo[15:51:52] *** Murii_ <Murii_!~Murii@79.113.234.223> has joined #openal[15:51:52] *** ChanServ sets mode: +v Murii_[17:34:13] *** irungentoo <irungentoo!~irungento@unaffiliated/irungentoo> has quit IRC (Remote host closed the connection)[17:37:18] *** ybalrid <ybalrid!~ybalrid__@2a01:e35:139b:3d00:41fc:9d19:a8c9:7b48> has joined #openal[17:37:18] *** ChanServ sets mode: +v ybalrid[20:08:03] *** maxfx <maxfx!~maxfx@2a00:1028:8b40:c6d6:c5ab:3f96:8116:b7af> has joined #openal[20:08:03] *** ChanServ sets mode: +v maxfx[21:11:53] <KittyCat> I'm interested in opinions on some of the defaults openal-soft uses for certain things[21:12:45] <KittyCat> like the buffering metrics. current default is 1024 samples per buffer, with 4 buffers[21:13:45] <KittyCat> that's a bit on the high side, although the intention is to ensure it's large enough to not underrun on low-end hardware[21:17:10] <KittyCat> and the resampler. currently it defaults to using linear resampling. although there are options for 4-point sinc, 8-point sinc, and a 12- to 24-point anti-aliased sinc[21:20:03] <KittyCat> those sinc options use some sizeable lookup tables though, which could have cache problems. I haven't noticed any playback issues on my machine, but I don't know if they should be the default just because my cpu can handle it[21:33:36] <grim001> are there API options available to change these settings?[21:36:07] <KittyCat> no, only in the config file/alsoft-config gui[21:37:40] <caedes_> maybe API (at least at a "low/medium/high quality" granularity) would be useful[21:38:07] <caedes_> so people can configure it in games audio settings, per game, for games that are CPU intensive[21:38:09] <jpernst_> yeah, some kind of ALC_SOFT_config extension could be useful[21:39:37] *** jpernst_ is now known as jpernst[21:39:42] <caedes_> and regarding the original question: I don't know really - I never heard complaints about latency (which too big buffers could cause, right?)[21:40:18] <caedes_> better quality by default sounds nice, but I haven't tried how noticable it even is and how the tradeoff with CPU usage is[21:42:02] <KittyCat> yeah. I've not heard any real complaints about latency either (aside from an issue on android, but I don't think that's related to the configured buffer metrics), but it's currently set to be close to 90ms total[21:43:25] <KittyCat> almost a tenth of a second between openal soft mixing something, and it finally getting played by the device (assuming there's not any more buffering going on somewhere)[21:44:18] <jpernst> i'd be in favor of lowering that, but latency is a pet peeve of mine[21:44:25] <caedes_> ok, that's >5 frames at 60fps, I'm surprised it's not noticable[21:45:33] <caedes_> but apparently it isn't, at least to me in the games I usually play[21:47:12] <jpernst> my concern i that i suspect many people, even devs, won't know about the config file at all and the defaults will almost always be used[21:47:16] <jpernst> i didh't know about it until hearing about it here[21:47:26] <KittyCat> I've personally been using 512 samples per buffer, and 6 buffers, at 48khz. so closer to 60~64ms[21:47:56] <caedes_> well, if the devs don't know about the config they won't know about openal-soft extensions either[21:48:09] <KittyCat> generally speaking, the config options are for user/system settings, rather than app-specific settings[21:48:23] <jpernst> that's true, i had a hard time finding solid docs for binding the extensions[21:48:37] <jpernst> that github repo filled with the extensions helped a lot[21:48:43] <KittyCat> ones that are useful to expose to apps, and which can be done safely, I do try to expose via extensions[21:50:52] <jpernst> setting the interpolation mode feels similar to setting the AA/AF settings in gl, which is something you want to be able to control in the application[21:52:37] <KittyCat> yeah, being able to control the resampler from the app does make some sense. though I'm not quite sure how to expose such an option that maintains compatibility (if not consistency) going forward[21:54:44] <KittyCat> 'linear' is a pretty staple method, as is 'point', but the other ones may go through changes[21:56:08] <jpernst> even having a single "sinc" setting would be a marked improvement[21:56:22] <jpernst> you can keep it vague until you're more comfortable comitting to a specific implementation[21:56:45] <KittyCat> for instance, at one point there was a cubic resampler which applied a matrix to a collection of 4 samples to derive the new samples. that was changed to a 4-point FIR basically, which is now derived using a windowed sinc response[21:57:02] <KittyCat> and because it was easy, I added an 8-point variation of that[21:57:30] <jpernst> or have an ALC_RESAMPLER_SPEC_SOFT query thing or something[21:59:46] <jpernst> alcGetStringiSOFT is already a thing from the HRTF extension, could just add to that[22:02:04] <jpernst> even if it requires resetting the device to change it, i think that's acceptable[22:02:20] <KittyCat> the app should probably be able to know what the resampler methods are, rather than leaving them as opaque selections[22:02:58] <jpernst> perhaps they could be sorted in order of increasing cpu load[23:16:20] *** Murii_ <Murii_!~Murii@79.113.234.223> has quit IRC ()[23:35:46] *** maxfx <maxfx!~maxfx@2a00:1028:8b40:c6d6:c5ab:3f96:8116:b7af> has quit IRC (Ping timeout: 264 seconds)