February 10, 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 10, 2017 [00:05:52] *** friedrich <friedrich!~friedrich@aextron.de> has quit IRC (Ping timeout: 240 seconds)[00:34:34] *** maxfx <maxfx!~maxfx@2a00:1028:8b40:c6d6:c5ab:3f96:8116:b7af> has quit IRC (Ping timeout: 264 seconds)[00:43:25] *** friedrich <friedrich!~friedrich@aextron.de> has joined #openal[00:43:25] *** ChanServ sets mode: +v friedrich[01:38:42] *** irungentoo <irungentoo!~irungento@unaffiliated/irungentoo> has quit IRC (Read error: Connection reset by peer)[01:44:34] *** irungentoo <irungentoo!~irungento@unaffiliated/irungentoo> has joined #openal[01:44:34] *** ChanServ sets mode: +v irungentoo[02:06:08] <Emcy_> 5ms for the hrtf processing seems really good.[02:06:30] <Emcy_> considering that sort of thing required an ASIC not long ago[02:07:01] <Emcy_> 100ms latency seems about right with what i can hear in game[02:07:22] <Emcy_> CS GOs processing seems slightly more latent even[02:07:44] <Emcy_> i wonder if there is room or scope to reduce it below 100ms though[02:13:55] <KittyCat> you can try changing it for your system. in alsoft-config, you can change the buffer metrics to create less latency (though it puts more weight on the CPU, as it's less time to process the same amount)[02:15:11] <Emcy_> i might try that[02:15:47] <Emcy_> i suspect most people who would run oalsoft have cpu power to spare these days. Even entire cores going spare probably.[02:15:47] <KittyCat> or edit .alsoftrc/alsoft.ini with the period_size and periods settings (see alsoftrc.sample with the source)[02:16:15] <KittyCat> yeah, I've been considering lowering the default buffer metrics[02:17:15] <Emcy_> i could do some testing to see the point at which sound processing becomes transparent to which way youre looking in a game[02:17:29] <Emcy_> its not very far off right now[02:18:17] <jpernst> can the location of the config file be changed with an env var?[02:20:09] <KittyCat> you can specify a custom/extra config file by setting ALSOFT_CONF to the full path+file. needs to be set before the library is initialized (best before running the app, or at least before loading the lib)[02:20:28] <jpernst> yeah, my bindings load the dylib dynamically so i could set it before that[02:21:06] <jpernst> perhaps even allowing hot reload to change the params[02:21:11] <jpernst> in the absence of a config extension[02:22:35] <KittyCat> just be aware that the config options are highly version dependent[02:23:37] <jpernst> yeah, i'd emphasize the fact that they're "configuration hints" and are not guaranteed to work[02:23:38] <KittyCat> I try to maintain backwards compatibility, but sometimes some options are outright dropped, and others can have had settings that don't make sense anymore[02:24:08] <jpernst> i'm mainly interested in the latency and resampler settings[02:35:26] *** friedrich <friedrich!~friedrich@aextron.de> has quit IRC (Quit: No Ping reply in 180 seconds.)[02:50:45] *** Smirftsch1 <Smirftsch1!~Smirftsch@p2003007A0D0616009C832801D4217919.dip0.t-ipconnect.de> has joined #openal[02:50:45] *** ChanServ sets mode: +v Smirftsch1[02:53:11] *** Smirftsch2 <Smirftsch2!~Smirftsch@p2003007A0D062900AD20D29407CC9C17.dip0.t-ipconnect.de> has quit IRC (Ping timeout: 276 seconds)[02:53:36] *** friedrich <friedrich!~friedrich@aextron.de> has joined #openal[02:53:36] *** ChanServ sets mode: +v friedrich[05:46:29] *** irungentoo <irungentoo!~irungento@unaffiliated/irungentoo> has quit IRC (Remote host closed the connection)[06:07:05] *** Murii <Murii!~vmuresan@gw1.computervoice.ro> has quit IRC (Read error: Connection reset by peer)[06:07:22] *** Murii <Murii!~vmuresan@mail.computervoice.ro> has joined #openal[06:07:22] *** ChanServ sets mode: +v Murii[06:11:28] *** Murii <Murii!~vmuresan@mail.computervoice.ro> has quit IRC (Ping timeout: 240 seconds)[06:21:44] *** Emcy_ <Emcy_!~MC@unaffiliated/mc1984> has quit IRC (Read error: Connection reset by peer)[06:49:03] *** Emcy <Emcy!~MC@unaffiliated/mc1984> has joined #openal[06:49:03] *** ChanServ sets mode: +v Emcy[08:04:30] *** Smirftsch1 <Smirftsch1!~Smirftsch@p2003007A0D0616009C832801D4217919.dip0.t-ipconnect.de> has quit IRC (Ping timeout: 258 seconds)[08:21:00] *** Smirftsch <Smirftsch!~Smirftsch@p549D75B0.dip0.t-ipconnect.de> has joined #openal[08:21:00] *** ChanServ sets mode: +v Smirftsch[08:33:55] *** Smirftsch1 <Smirftsch1!~Smirftsch@p200300D7A3CB90009C832801D4217919.dip0.t-ipconnect.de> has joined #openal[08:33:55] *** ChanServ sets mode: +v Smirftsch1[08:34:59] *** Smirftsch <Smirftsch!~Smirftsch@p549D75B0.dip0.t-ipconnect.de> has quit IRC (Ping timeout: 240 seconds)[08:40:07] *** friedrich <friedrich!~friedrich@aextron.de> has quit IRC (Quit: No Ping reply in 180 seconds.)[08:56:16] *** friedrich <friedrich!~friedrich@aextron.de> has joined #openal[08:56:16] *** ChanServ sets mode: +v friedrich[10:30:11] *** Emcy <Emcy!~MC@unaffiliated/mc1984> has quit IRC (Read error: Connection reset by peer)[10:41:12] *** Emcy <Emcy!~MC@cpc93884-swan4-2-0-cust190.7-3.cable.virginm.net> has joined #openal[10:41:12] *** Emcy <Emcy!~MC@cpc93884-swan4-2-0-cust190.7-3.cable.virginm.net> has quit IRC (Changing host)[10:41:12] *** Emcy <Emcy!~MC@unaffiliated/mc1984> has joined #openal[10:41:12] *** ChanServ sets mode: +v Emcy[10:41:21] *** Emcy <Emcy!~MC@unaffiliated/mc1984> has quit IRC (Remote host closed the connection)[10:42:26] *** Emcy <Emcy!~MC@cpc93884-swan4-2-0-cust190.7-3.cable.virginm.net> has joined #openal[10:42:26] *** Emcy <Emcy!~MC@cpc93884-swan4-2-0-cust190.7-3.cable.virginm.net> has quit IRC (Changing host)[10:42:26] *** Emcy <Emcy!~MC@unaffiliated/mc1984> has joined #openal[10:42:26] *** ChanServ sets mode: +v Emcy[10:45:46] *** vmuresan_ <vmuresan_!~vmuresan@mail.computervoice.ro> has joined #openal[10:45:46] *** ChanServ sets mode: +v vmuresan_[10:58:09] *** Emcy <Emcy!~MC@unaffiliated/mc1984> has quit IRC (Quit: Leaving)[10:58:31] *** Emcy <Emcy!~MC@cpc93884-swan4-2-0-cust190.7-3.cable.virginm.net> has joined #openal[10:58:31] *** Emcy <Emcy!~MC@cpc93884-swan4-2-0-cust190.7-3.cable.virginm.net> has quit IRC (Changing host)[10:58:31] *** Emcy <Emcy!~MC@unaffiliated/mc1984> has joined #openal[10:58:31] *** ChanServ sets mode: +v Emcy[11:10:10] *** Emcy <Emcy!~MC@unaffiliated/mc1984> has quit IRC (Read error: Connection reset by peer)[11:18:08] *** Emcy <Emcy!~MC@unaffiliated/mc1984> has joined #openal[11:18:08] *** ChanServ sets mode: +v Emcy[14:44:42] *** friedrich <friedrich!~friedrich@aextron.de> has quit IRC (Quit: No Ping reply in 180 seconds.)[14:46:52] *** friedrich <friedrich!~friedrich@aextron.de> has joined #openal[14:46:52] *** ChanServ sets mode: +v friedrich[15:33:06] *** irungentoo <irungentoo!~irungento@unaffiliated/irungentoo> has joined #openal[15:33:06] *** ChanServ sets mode: +v irungentoo[15:34:24] *** Murii <Murii!~Murii@79.113.234.223> has joined #openal[15:34:24] *** ChanServ sets mode: +v Murii[16:58:34] *** grim001 <grim001!~grim001@ip24-253-45-21.lv.lv.cox.net> has quit IRC (Read error: Connection reset by peer)[16:59:00] *** grim001 <grim001!~grim001@ip24-253-45-21.lv.lv.cox.net> has joined #openal[16:59:00] *** ChanServ sets mode: +v grim001[17:29:46] *** friedrich <friedrich!~friedrich@aextron.de> has quit IRC (Ping timeout: 255 seconds)[17:40:26] *** friedrich <friedrich!~friedrich@aextron.de> has joined #openal[17:40:26] *** ChanServ sets mode: +v friedrich[19:47:55] *** friedrich <friedrich!~friedrich@aextron.de> has quit IRC (Ping timeout: 255 seconds)[20:38:03] *** irungentoo <irungentoo!~irungento@unaffiliated/irungentoo> has quit IRC (Remote host closed the connection)[21:03:22] *** Smirftsch2 <Smirftsch2!~Smirftsch@p200300D7A3D05100907352F9525561B1.dip0.t-ipconnect.de> has joined #openal[21:03:22] *** ChanServ sets mode: +v Smirftsch2[21:04:04] *** Smirftsch1 <Smirftsch1!~Smirftsch@p200300D7A3CB90009C832801D4217919.dip0.t-ipconnect.de> has quit IRC (Ping timeout: 245 seconds)[21:13:47] *** Smirftsch2 <Smirftsch2!~Smirftsch@p200300D7A3D05100907352F9525561B1.dip0.t-ipconnect.de> has quit IRC (Ping timeout: 258 seconds)[21:14:41] *** Smirftsch <Smirftsch!~Smirftsch@p549D7C49.dip0.t-ipconnect.de> has joined #openal[21:14:41] *** ChanServ sets mode: +v Smirftsch[21:14:48] *** friedrich <friedrich!~friedrich@aextron.de> has joined #openal[21:14:48] *** ChanServ sets mode: +v friedrich[21:57:53] *** maxfx <maxfx!~maxfx@2a00:1028:8b40:c6d6:c5ab:3f96:8116:b7af> has joined #openal[21:57:53] *** ChanServ sets mode: +v maxfx[22:20:55] *** friedrich <friedrich!~friedrich@aextron.de> has quit IRC (Ping timeout: 255 seconds)[22:33:32] *** friedrich <friedrich!~friedrich@aextron.de> has joined #openal[22:33:32] *** ChanServ sets mode: +v friedrich[22:50:05] *** Murii <Murii!~Murii@79.113.234.223> has quit IRC ()[22:50:34] <CCHyper> evening, is anybody online? :)[22:54:42] <KittyCat> hi[22:55:37] <CCHyper> Hi KittyCat, how are you?[22:56:06] <CCHyper> Not sure if you remember me, we spoke quite some months ago, you helped with out OpenAL implimention[22:57:44] <KittyCat> I'm alright[23:00:33] <CCHyper> We are trying to handle focus loss and gain and when we process gain after loss, it sounds like its playing back random data[23:01:05] <CCHyper> And I am unable to pin point it to where the issue is coming from[23:01:29] <CCHyper> playback is fine, works as intended, but as soon as we do focus loss then gain, its broke[23:02:20] <CCHyper> alSourcePlay and alSourcePause are both in use respectively[23:03:23] <CCHyper> though one of our testers did notice that alSourceQueueBuffers is returning and error and alBufferData is also[23:04:41] <KittyCat> can't really say without knowing the code. do you do anything with the current context once it's set?[23:05:49] <CCHyper> after we have done the init, nope[23:06:05] <CCHyper> we create on startup, destory on shutdown[23:06:34] <KittyCat> can you pinpoint what's causing the errors in the AL calls?[23:07:12] <CCHyper> I can't, and the coder who worked on this has since become AWOL[23:08:05] <CCHyper> we dont get a crash, just reported errors. and the errors we get are...[23:08:32] <CCHyper> AL_INVALID_OPERATION from alBufferData[23:08:55] <CCHyper> and from alSourceQueueBufffers[23:09:53] <CCHyper> the audio buffers we parse into these are ALuint AudioBuffers[20], acting as a ring buffer[23:10:12] <CCHyper> alBufferData(AudioBuffers[GetBuffer], Format, data, size, Frequency);[23:10:17] <CCHyper> alSourceQueueBuffers(Source, 1, &AudioBuffers[GetBuffer]);[23:10:23] <CCHyper> GetBuffer is the ring index[23:11:03] <KittyCat> alBufferData may generate an AL_INVALID_OPERATION error if it's still queued on a source[23:13:03] <CCHyper> sorry, I dont quite follow, do you mean we have to unqueue all on "stop"?[23:13:19] <CCHyper> I wish to have the audio "pause" until focus restore[23:14:52] <KittyCat> you don't have to unqueue all on stop. but you need to make sure the buffer you're filling is unqueued[23:17:20] <CCHyper> do you mind if i show you a copy of the openal interface again?[23:17:59] <KittyCat> sure[23:20:49] <CCHyper> just PM'd links[23:32:00] <KittyCat> do you stop calling Queue_Audio while it's paused?[23:35:19] <CCHyper> Let me check[23:36:20] <CCHyper> I dont think we do...[23:36:55] <CCHyper> should Queue_Audio check for Stopped?[23:38:12] <CCHyper> oh, they are part of a different class[23:38:14] <CCHyper> hm[23:39:19] <CCHyper> can I fetch the current OpenAL status after it has been issued alSourcePause(Source);?[23:41:50] <KittyCat> whatever's calling Queue_Audio needs to be aware that it shouldn't be forwarding more audio[23:43:42] <CCHyper> ok, let me try something[23:45:30] <CCHyper> so i should handle this outside of Queue_Audio?[23:46:39] <KittyCat> yeah. presumably you've read audio from some place and moved the read pointer ahead before calling Queue_Audio[23:46:57] <CCHyper> we have a audio maintence function[23:47:10] <CCHyper> two places call Queue_Audio[23:47:19] <CCHyper> the initial play sample function[23:47:30] <CCHyper> and the maintenance callback[23:47:39] <KittyCat> so nothing you can do in Queue_Audio will tell the reader that the audio can't be used yet[23:49:56] <CCHyper> so our sound thread needs to skip the call to the callback function?[23:50:05] <CCHyper> in we are in a loss state?[23:51:04] <CCHyper> logically, the game does not pause on focus loss, so I want the OpenAL interface to pickup where ever the game currently is[23:51:21] <CCHyper> not resume from after it paused[23:51:37] <CCHyper> the game will continue to issue new sounds while its out of focus[23:51:44] <CCHyper> deos that make sense/[23:52:06] <CCHyper> does*[23:52:56] <KittyCat> I guess it depends on what exactly you want to happen on focus loss/gain[23:53:11] <CCHyper> pickup where ever the game is[23:53:46] <CCHyper> so i suppose it should be issuing new data to play, but OpenAL needs to not be accepting it until focus gain?[23:55:18] <KittyCat> you could just set the listener gain to 0 then, and keep sources playing/queueing audio[23:55:33] <CCHyper> oh we can?[23:56:52] <CCHyper> ok, so i guess all I need to do is update the calls in OpenALInterfaceClass::Start/Stop yes?[23:57:12] <CCHyper> Play to Set_Volume(1.0f) and Stop to Set_Volume(0.0f)[23:57:17] <CCHyper> is that right?[23:58:44] <KittyCat> Start/Stop would be a misnomer then since audio is still being processed, it's just silent[23:58:57] <KittyCat> but it sounds like that's the behavior you want[23:59:15] <CCHyper> ok, so a call to alSourcef() allows this?[23:59:22] <CCHyper> with AL_GAIN