December 22, 2014 
< | 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 | 29 | 30 | 31 | >
December 22, 2014 [01:39:59] *** rdb_ has joined #openal[01:40:13] *** rdb_ has joined #openal[01:40:13] *** ChanServ sets mode: +v rdb_[01:41:01] *** rdb has quit IRC[01:48:09] *** rdb_ is now known as rdb[02:31:23] *** Smirftsch has joined #openal[02:31:24] *** ChanServ sets mode: +v Smirftsch[02:33:17] *** Smirftsch3 has quit IRC[02:59:24] *** D0pamine has quit IRC[03:42:31] <KittyCat> this jack backend feels very precarious. and I'm not sure it'll actually be very useful[03:53:58] <KittyCat> since openal soft's mixer isn't thread-safe (it requires a lock on the device), it requires a lockless ringbuffer to pass data in between the mixer thread and jack's processing callback[04:23:27] <KittyCat> doesn't help that jack's lockless ringbuffer only supports power-of-two buffer sizes (measured in bytes)[04:31:13] <KittyCat> that basically makes 5.1 and 6.1 not doable (without incurring extra overhead to split a sample frame, and then reconstruct it)[04:41:26] *** mat^2 has quit IRC[04:46:03] *** mat^2 has joined #openal[04:46:03] *** ChanServ sets mode: +v mat^2[05:11:47] *** mat^2 has quit IRC[06:11:07] *** yosafbridge has quit IRC[06:13:24] *** yosafbridge has joined #openal[06:13:24] *** ChanServ sets mode: +v yosafbridge[07:40:46] *** marynate has joined #openal[07:40:46] *** ChanServ sets mode: +v marynate[07:45:30] *** neXyon has quit IRC[08:52:00] *** marynate has quit IRC[08:52:28] *** marynate has joined #openal[08:52:28] *** ChanServ sets mode: +v marynate[08:54:53] *** marynate has quit IRC[08:55:54] *** marynate has joined #openal[08:55:54] *** ChanServ sets mode: +v marynate[11:25:12] *** marynate has quit IRC[11:25:55] *** marynate has joined #openal[11:25:55] *** ChanServ sets mode: +v marynate[11:27:19] *** marynate has quit IRC[12:05:45] *** echelog has joined #openal[12:05:46] *** ChanServ sets mode: +v echelog[12:21:30] *** echelog has joined #openal[12:21:31] *** ChanServ sets mode: +v echelog[12:23:57] *** marynate has joined #openal[12:23:57] *** ChanServ sets mode: +v marynate[13:05:35] *** losh has joined #openal[13:05:35] *** ChanServ sets mode: +v losh[14:09:00] *** maxfx has joined #openal[14:09:00] *** ChanServ sets mode: +v maxfx[14:18:43] *** lritter has joined #openal[14:18:44] *** ChanServ sets mode: +v lritter[14:21:12] *** maxfx has quit IRC[14:25:17] *** lritter has quit IRC[14:26:22] *** lritter has joined #openal[14:26:22] *** ChanServ sets mode: +v lritter[15:41:25] *** maxfx has joined #openal[15:41:25] *** ChanServ sets mode: +v maxfx[16:48:33] *** maxfx has quit IRC[17:21:18] <KittyCat> how do I make JACK not so noisy?[17:25:04] <KittyCat> it keeps printing things like[17:25:08] <KittyCat> Jack: jack_client_open alsoft[17:25:09] <KittyCat> Jack: JackLibGlobals Init 0[17:25:11] <KittyCat> Jack: JackLibGlobals[17:25:21] <KittyCat> whenever a new device gets opened[17:26:36] <KittyCat> I don't see any logging verbosity options anywhere[17:42:25] <KittyCat> there's a lot of latency with the JACK backend, too[18:07:24] *** marynate has quit IRC[18:10:24] <caedes__> kinda defeating the whole "jack has super low latency" thing[18:16:52] <KittyCat> yeah. I believe I should somehow account for the number of periods the jack server is using (otherwise openal's period count is just adding to it), but I'm not sure how to get that info[19:11:24] <KittyCat> latency does go way down if I just ignore openal soft's requested buffer metrics and only keep one jack-sized buffer ready for when it's requested[19:59:01] *** mat^2 has joined #openal[19:59:01] *** ChanServ sets mode: +v mat^2[20:11:03] <KittyCat> does jack have a way to check the current "cycle" in both real-time processing thread and non-real-time user threads? assuming "cycle" means a client update cycle, where the process callback is called.[20:15:37] <KittyCat> actually measuring the total latency between openal soft's mixer and jack's output seems quite complicated[20:19:26] <KittyCat> I need to take the readable size of the ringbuffer that the mixer writes into (and which the process thread reads from) and add the device/hardware latency reported by jack[20:22:26] <KittyCat> trouble is, the readable size of the ringbuffer is changed non-atomically with regards to jack's latency measurements (i.e. the readable size can change before jack updates its internal latency measurements from the read data)[20:46:11] *** neXyon has joined #openal[20:46:11] *** ChanServ sets mode: +v neXyon[21:41:47] *** maxfx_ has joined #openal[21:41:47] *** maxfx has joined #openal[21:41:47] *** ChanServ sets mode: +v maxfx_[21:41:47] *** ChanServ sets mode: +v maxfx[21:41:57] *** maxfx has quit IRC[21:46:44] *** neXyon has quit IRC[22:11:57] *** bjz_ has quit IRC[22:16:21] *** maxfx_ has quit IRC[23:04:14] *** maxfx has joined #openal[23:04:14] *** ChanServ sets mode: +v maxfx[23:49:39] *** losh has quit IRC