23:52:47 RRSAgent has joined #audio 23:52:47 logging to http://www.w3.org/2015/10/26-audio-irc 23:52:49 RRSAgent, make logs world 23:52:49 Zakim has joined #audio 23:52:51 Zakim, this will be 28346 23:52:51 I do not see a conference matching that name scheduled within the next hour, trackbot 23:52:52 Meeting: Audio Working Group Teleconference 23:52:52 Date: 26 October 2015 23:53:05 kawai has joined #audio 23:53:23 mhakkinen has joined #audio 23:53:35 rrsagent, this meeting spans midnight 23:54:23 olivier has joined #audio 23:54:42 present+ rtoyg_m 23:54:45 present+ mdjp 23:56:27 hongchan has joined #audio 00:03:39 mhakkinen has joined #audio 00:07:03 jdsmith has joined #audio 00:07:05 Kaki has joined #audio 00:07:13 present+ jdsmith 00:08:11 BillHofmann has joined #audio 00:08:19 mdjp - discussion on closure for v1 00:08:39 padenot implementation is following quickly on from spec changes 00:09:24 padenot testing is improving but not there yet, miozilla trying to contribute to web platform tests 00:11:10 cwilso biggest bits are processing model audio worker - detail around how compression works but all captured as issues. TAG review very productive, feel strongly that we need to get the low level bedrock apis defined. 00:11:25 joe review issues and current status 00:11:53 ToddG has joined #audio 00:12:38 joe 23 open issues (unassigned) 60 ready for editing in total (v1) 00:12:51 joe v1 7 issues that are not ready for editing 00:14:40 droh_ has joined #audio 00:15:17 joe what can we do to speed up the resolution of the issues? Most are straight forward to resolve. There are a lot of issues assigned to people that are not moving. They should be unassigned if assignees are unable to work on them. 00:17:52 oonishi has joined #audio 00:18:58 Kaki_ has joined #audio 00:20:30 mhakkinen has joined #audio 00:20:37 Kaki_ has joined #audio 00:24:16 cwilso looknig forward to charter suggest that forking the work into specific areas (low level, processing etc) rather than a single monolithic would be a better approach rather than concentrating on V2 as a single spec 00:28:17 billHomann: Can we adopt an agile approach to moving forward? Review issues as they are raised and not adopt set goals. 00:28:40 joeb: We've pretty much adopted a sprint model in the last few months and it's worked well. 00:30:15 mdjp: Need to get the issues to the point where we have a working draft that is in good shape, where we are happy with the feature set and status of the spec. 00:31:19 BillHofmann: Beyond the spec, what about tests? What's the full scope of work that we need to complete? 00:32:11 joeb: Recommend we start discussion on other remaining issues, and then revisit status of V1 later in the day. 00:34:07 jdsmith: Tempting to say that there are a handfull of larger issues and an editing push to close "ready for editng" issues and be very close to V1 completion. 00:34:13 https://github.com/WebAudio/web-audio-api/issues/118 00:34:26 joeb: Let's start with issues not marked "ready for edting". 00:35:41 joeb: On issue 118, Paul recommends we leave resampling open for diferent UA implementations. Is it acceptable to do that and let diferent UA's compete? 00:35:59 padenot: I've never heard of anyone complain about resampling behavior. 00:36:50 mdjp: It can be good to have that kind of competition in the absence of compelling reasons to standardize. 00:37:27 [web-audio-api] cwilso pushed 1 new commit to 372-StereoPanner: https://github.com/WebAudio/web-audio-api/commit/ebe890de4006e4aea9dc8da5fdbacd9b1eb1ab78 00:37:27 web-audio-api/372-StereoPanner ebe890d Chris Wilson: Clamp loopStart, loopEnd and offset... 00:37:37 rtoyg: I don't object to that. 00:37:46 joeb: Then we shoudl close the issue. 00:38:32 Issue 118 is now closed. 00:39:22 https://github.com/WebAudio/web-audio-api/issues/348 00:41:12 joeb: jernoble proposed providing categories of buffering 00:41:56 jdsmith: We've had requests from companies to help get this issue resolved. There are applications that are real time, and they could set smaller buffers and use more power. 00:42:30 cwilso: Not sure last discussion on this was going the right way. It would be good to expose some kind of knob to tune buffering/power. 00:43:31 rtoyg: Knob can be set to play music, with longer buffers and latency. Or may want RTC, which short buffers and limited latency. Could be so short that stream would drop out frequently. Need some way to balance. 00:44:24 joeb: Are general categories not sufficient? If so, what do we need? 00:45:32 joeb: Proposal had "interactive", "non-interactive" and "media". Is "media" like RTC? 00:46:02 cwilso: Media would be like streaming from Pandora. Could be long buffering, longer latency, minimized battery. 00:46:55 mdjp: How do we know what the diferent values mean? 00:48:15 cwilso: "interactive" is lowest latency, "non-interactive" is somewhat higher and useful for RTC, and "media" is the longest latency. 00:48:59 watanabe has joined #audio 00:49:15 joeb: What about using actual numbers? 00:49:33 jdsmith: Those vary by device and are hard to quantify. 00:49:46 padenot: And sample rate as well. 00:51:24 cwilso: Interactive, normal and playback? 00:51:59 [web-audio-api] cwilso pushed 1 new commit to gh-pages: https://github.com/WebAudio/web-audio-api/commit/0a0111a03051ae4857e17b5937744e69f53429ca 00:51:59 web-audio-api/gh-pages 0a0111a Chris Wilson: Clamp loopStart, loopEnd and offset.... 00:53:50 apau has joined #audio 00:55:11 joeb: Define the terms: Intereractive: loest latency without glitching, Normal: balance latency and stability/power consumption, Playback: latency not important, sustained playback without interruption is priority. Lowest power consumption. 00:55:32 joeb: Normal would be the default. 00:56:26 padenot: Should put this on the constructor, when we have that. 00:56:40 joeb: Not done yet, but should do that or we'll have a mess. 00:59:01 Jdsmith: Correction, interactive should be the default, and should be like current implementations. 01:01:49 joeb: "Normal" does sound like it's the default though. 01:02:01 [web-audio-api] cwilso pushed 1 new commit to gh-pages: https://github.com/WebAudio/web-audio-api/commit/44ebce6044882da08c41f30a835b3564c922a407 01:02:01 web-audio-api/gh-pages 44ebce6 Chris Wilson: Return destination node from connect()... 01:03:35 joeb: Reorder to balanced, interactive, playback. 01:04:31 https://github.com/WebAudio/web-audio-api/issues/532 01:05:31 "Impedance mismatch between the Web Worker text and what is possible/needed for the AudioWorker" 01:06:45 cwilso: Need to remove all remaining references to WebWorker and keep this bug open until that's done. 01:06:53 joeb: Assigned to cwilso. 01:06:53 mathieucitrix has joined #audio 01:07:41 https://github.com/WebAudio/web-audio-api/issues/628 01:07:57 "Specify the processing model for the Web Audio API" 01:08:06 joeb: This was discussed yesterday. 01:08:16 [web-audio-api] cwilso deleted 372-StereoPanner at ebe890d: https://github.com/WebAudio/web-audio-api/commit/ebe890d 01:08:27 joeb: Can close it when the Pull Requests for AudioWorker are completed. 01:10:48 joeb: Will now look at issues that aren't marked "needs review", but also are not "ready for editing". 01:10:51 https://github.com/WebAudio/web-audio-api/issues/13 01:11:17 Kaki has joined #audio 01:11:33 "A NoiseGate/Expander node would be a good addition to the API." 01:11:53 cwilso: There is a proposal attached to the issue on the new node type. 01:12:09 joeb: jer pushed back on it. 01:12:49 cwilso: We discussed this in the working group. In the absence of someone reviewing the proposal, I'm reluctant to do the commit. 01:13:13 cwilso: I feel strongly we need this node type in the spec. 01:13:49 joeb: What do the other editors want to do with this? Is it spec'd sufficiently to roll into the spec? If not, it may have missed the window. 01:14:38 padenot: I'd rather add the spec for the dynamics compressor. It's in the spec, but the details of it are not. 01:15:37 cwilso: The only two problems with DynamicsCompressorNode are that it's not spec'd. It also has no side-chaining output. 01:19:32 cwilso: Noisegate is important. You'll want to put one on every mic stream. 01:20:51 joeb: It feels weird to me to add a new node that's similar to another one that's not yet already spec'd. If we work them together, the one might fall out of the work for the other. 01:21:10 cwilso: Not clear how that helps one fall out of the other. 01:22:19 joeb: I think there will be more comfort accepting the commit once DynamicsCompressorNode fully spec'd. 01:23:55 joeb: Next up is the bug on accessing different output devices (https://github.com/WebAudio/web-audio-api/issues/445). To be discussed later today. 01:24:22 https://github.com/WebAudio/web-audio-api/issues/631 01:24:46 rtoyg: This one is ready to implement. 01:24:53 joeb: Marked that way. 01:25:25 Now working uncommitted issues. 01:26:19 https://github.com/WebAudio/web-audio-api/issues/606 01:26:38 "Valid rolloff factors for Panner?" 01:27:04 joeb: Is this something we can resolve here, or does it require some deep diving? 01:29:28 joeb: Suggest we move on and come back to this later. 01:30:27 https://webaudio.github.io/web-audio-api/#the-pannernode-interface 01:43:27 oonishi_ has joined #audio 01:57:47 hongchan has joined #audio 01:59:43 Kaki has joined #audio 02:06:02 BillHofmann has joined #audio 02:06:25 https://github.com/WebAudio/web-audio-api/issues/611 02:06:52 "Distance models: maxDistance vs refDistance" 02:07:00 kawai has joined #audio 02:08:26 joeb: Throwing errors works great if you have a method call. 02:09:05 rtoyg: So we'll just let people set these any values, whether they make sense or not? That's probably okay with me. 02:09:58 Panner formulas: https://webaudio.github.io/web-audio-api/#the-pannernode-interface 02:13:37 joeb: Could update formulas to clamp dref to the min of dref and dmax. 02:14:42 joeb: I'd prefer to solve this in the formula definitions rather that throw errors. 02:15:04 [web-audio-api] cwilso pushed 1 new commit to gh-pages: https://github.com/WebAudio/web-audio-api/commit/2677a0f777fc180dc30d21fddec072eb255b679d 02:15:04 web-audio-api/gh-pages 2677a0f Chris Wilson: Remove references to Web Workers.... 02:19:00 https://github.com/WebAudio/web-audio-api/issues/612 02:19:28 "Behavior of exponentialRampToValue when the previous event is less than equal to 0" 02:20:27 [web-audio-api] cwilso pushed 1 new commit to gh-pages: https://github.com/WebAudio/web-audio-api/commit/078b15f29fd7cd4ccb357a88d2133354c9fc73f6 02:20:27 web-audio-api/gh-pages 078b15f Chris Wilson: loop modification mixup.... 02:22:29 Kaki_ has joined #audio 02:23:44 rtoyg: Have a proposed behavior that seems okay (hold the value from the end of the previous event) if V0 is negative. 02:25:56 roytg: Can do the same if either V0 or V1 are negative. If both are negative, the equation is valid. 02:26:54 joeb: Can redefine the formula for the cae when V0 and V1 have opposite signs to evaluate to V0. 02:27:22 [web-audio-api] cwilso pushed 1 new commit to gh-pages: https://github.com/WebAudio/web-audio-api/commit/013e6ad482af195e8844c083a365171d11871c59 02:27:22 web-audio-api/gh-pages 013e6ad Chris Wilson: Rearrange description of "currentTime"... 02:27:45 joeb: i.e. preserve the previous value. 02:27:56 Zakim has left #audio 02:29:38 https://github.com/WebAudio/web-audio-api/issues/640 02:30:02 tidoust has joined #audio 02:30:09 "Specify the nominal range for SpatialPannerNode's AudioParam" 02:32:10 paul: AudioParam's generally need nominal values. 02:32:29 joeb: So do we just need to say vectors can be -infinity to +infinity? 02:32:37 padenot: Yes. 02:33:25 https://github.com/WebAudio/web-audio-api/issues/642 02:33:53 "Conflict on resuming context" 02:34:20 joeb: Resume and suspend do feel pretty different. Should we just close this issue? 02:35:47 ChrisLilley has joined #audio 02:37:03 joeb: Suggest we change the behavior of the OfflineAudioContext to match the online one - resolve the promise if the context is in the running state, and eject only if it is closed. 02:38:54 Next topic: Testing 02:45:58 jdsmith_ has joined #audio 02:46:28 rtoyg: All of our tests are running in a Chrome test harness as well. 02:46:48 joeb: Had an intern that got existing tests running on different browsers. 02:48:20 joeb: My take after that work was that it wouldn't be that hard to get all the tests running on every browser. 02:48:42 joeb: That would give us another positive piece for finishing V1. 02:49:00 mhakkinen has joined #audio 02:49:32 joeb: How many of Mozilla's old tests aren't in the W3C format? 02:49:35 padenot: Most of them. 02:50:10 https://github.com/w3c/web-platform-tests 02:50:27 https://github.com/DanielShaar/web-platform-tests 02:50:36 joe_ has joined #audio 02:50:49 https://github.com/DanielShaar/web-platform-tests 02:51:03 amy has joined #audio 02:51:45 amy has left #audio 02:52:00 mhakkinen has joined #audio 02:54:33 watanabe has joined #audio 02:55:01 joeb: It sounds like testing work might be characterized as migrating tests into the w3c test harness. 02:56:56 mdjp: That wraps up the testing discussion. 02:57:59 ToddG has joined #audio 03:00:03 Kaki has joined #audio 03:51:50 joe has joined #audio 03:58:34 BillHofmann has joined #audio 04:04:29 ChrisLilley has joined #audio 04:04:43 mhakkinen has joined #audio 04:04:56 Chris_Lilley has joined #audio 04:05:01 hongchan has joined #audio 04:06:59 rrsagent, here 04:06:59 See http://www.w3.org/2015/10/26-audio-irc#T04-06-59 04:07:46 Present+ Chris_Lilley 04:08:04 rtoyg_m has joined #audio 04:12:17 [web-audio-api] cwilso pushed 1 new commit to gh-pages: https://github.com/WebAudio/web-audio-api/commit/938cf2bf8f81a4febb0228eae03c9d0af5103cbc 04:12:17 web-audio-api/gh-pages 938cf2b Chris Wilson: connect() typo, and tidy cleanup. 04:12:33 jdsmith has joined #audio 04:12:40 paging shepazu 04:13:17 zakiim, pick a victim 04:13:31 ToddG has joined #audio 04:13:34 zakim, pick a victim 04:14:54 Zakim has joined #audio 04:15:04 zakim, pick a victim 04:15:04 I don't who is present, Chris_Lilley 04:15:12 pjeong has joined #audio 04:15:18 oh zakim, get a grip 04:15:31 scribenick: Chris_Lilley 04:15:53 topic: v1 04:16:11 joe: all the issues have equal weight so far 04:16:25 kawai has joined #audio 04:16:40 ... unprioritised backlog. Leyts decide the most pressing issues. even idf some things are not done. 04:16:51 s/Leys/Lets 04:17:03 ... what things are essential? 04:17:33 joe: audio worked, dynamic compressor, automation cleanup are clearly needed 04:17:54 ... other things are clarifications and we could leave thm as is for now. Gives focus. 04:18:13 s/dynamic/dynamics/ 04:18:27 BillHofmann: just 2 buckets? 04:18:43 joe: loking for showstoppers, things we can't ship without 04:19:32 BillHofmann: what about 251? 04:19:43 cwilso: nothing much needed, could be v1 04:20:18 BillHofmann: just tagged as v1. looking at the milestone, 65 of them 04:21:45 mdjp: need to think of timescale, if we can get to that point. All on my list was covered already, so where can we get to 04:22:23 jdsmith: reassess when you have all the top issues donew. does not stop them being implemented 04:22:51 joe: prefer to identify key things we will focus on 04:23:32 mdjp: in a months time, review where we are and so on 04:23:34 yukio has joined #audio 04:24:25 mdjp: make sure no one person has all the issues 04:24:41 joe: rebalance if necessary 04:25:22 ... metric is the ones that are really needed to get v1 out the door 04:25:53 BillHofmann: question, open pull requests - there are a lot, what is happening? done means merged? 04:25:57 joe: yes 04:26:10 padenot: editors will merge them 04:26:24 joe: 20 open PR 04:26:45 BillHofmann: longer they sit, more likely they will not cleanly merge 04:27:04 joe: so balance work away from spec editors to compensate 04:27:18 padenot: we just need to get on and do it 04:27:31 rtoyg: some PR have significant amouts of stuff 04:27:57 padenot: yes, authors need to address comments and send new PR that address them 04:28:29 BillHofmann: a week is a reasonable timeframe 04:28:41 ... okay, understood 04:29:56 joe: lets pick important v1-required issues 04:30:29 https://github.com/WebAudio/web-audio-api/issues?q=is%3Aopen+is%3Aissue+milestone%3A%22Web+Audio+V1%22+sort%3Acreated-asc 04:31:06 joe: 10 https://github.com/WebAudio/web-audio-api/issues/10 04:31:12 cwilso: requirement 04:31:43 joe: 12 is being worked on by mozilla 04:31:43 https://github.com/WebAudio/web-audio-api/issues/12 04:32:13 joe: 30 https://github.com/WebAudio/web-audio-api/issues/30 04:32:21 cwilso: this is editorial 04:33:04 31 https://github.com/WebAudio/web-audio-api/issues/31 04:33:28 rtoyg: must be done 04:33:52 Chris_Lilley: its trivial except all the must and MUST need to be checked and perhaps reworded 04:34:44 joe: do last in case language changes and it needs to be redone 04:35:12 34 https://github.com/WebAudio/web-audio-api/issues/34 04:35:23 (not critical) 04:36:00 45 https://github.com/WebAudio/web-audio-api/issues/45 04:36:10 mdjp: do later, in case of changes 04:36:35 52 https://github.com/WebAudio/web-audio-api/issues/52 04:36:44 joe: I have a PR on that 04:37:10 85 https://github.com/WebAudio/web-audio-api/issues/85 04:37:18 joe: there is a PR on this from me 04:37:52 cwilso: conflicts with one I just checked in, definition of current time 04:38:23 86 https://github.com/WebAudio/web-audio-api/issues/86 04:38:39 mdjp: has PR 04:39:06 95 https://github.com/WebAudio/web-audio-api/issues/95 04:39:13 joe: padenot this is yours 04:39:32 padenot: okay 04:39:40 zqzhang_ has joined #audio 04:39:42 jdsmith: not in first bucket 04:39:54 padenot: okay, postpone 04:40:14 97 https://github.com/WebAudio/web-audio-api/issues/97 04:40:23 joe: sure I have a PR on that 04:41:54 110 https://github.com/WebAudio/web-audio-api/issues/110 04:42:09 joe: PR on that too 04:43:10 130 https://github.com/WebAudio/web-audio-api/issues/130 04:43:24 joe: is this adressed by what we discussed yesterday? 04:43:28 rtoyg: yes, mostly 04:44:08 cwilso: no initial schedule point, this confuses people. ramp with endpoint has no start oint and so jumps, no defined begin. Can't directly solve it 04:44:23 ... could saythere is a magic initial point, but goofy. 04:44:46 ... interleaved points, carl said this is goofy, diagram changes. but that is how a scheduler works 04:44:50 joe: close it? 04:45:33 cwilso: implemnenbtations are consistent but it is not described 04:45:37 joe: should be 04:46:07 132 https://github.com/WebAudio/web-audio-api/issues/132 04:46:10 kaki has joined #audio 04:46:13 (no takers) 04:46:57 BillHofmann: weresolved a year ago, cwilso had a comment. 04:47:05 joe: feel we can leave this as-is 04:47:31 246 https://github.com/WebAudio/web-audio-api/issues/246 04:47:40 joe: is this the same as the noisegate one? 04:47:59 cwilso: its on dynamic compressor, straightforward. Thought I had done this already 04:48:26 mdjp: speccing the compressor is essential 04:49:24 cwilso: (thinks) grave mistake to have a dynamic compressor with no sidechain. its trivial to input, just taking a control from a different input. and incredibly useful 04:49:33 ... no easy way to fake it 04:49:49 ... also good to have the envelope follower output 04:50:02 joe: we resolved to add a second input 04:50:12 cwilso: from f2f last year 04:50:35 joe: roll into dynamics compressor? 04:50:42 cwilso: not blocking on it 04:51:03 ... different from noise gate where you rely on attack and decay controls 04:51:24 Chris_Lilley: very easy and widely used 04:51:52 247 https://github.com/WebAudio/web-audio-api/issues/247 04:52:03 padenot: fixed by a PR in flight 04:53:22 264 https://github.com/WebAudio/web-audio-api/issues/264 04:53:37 joe: I can take it 04:53:53 300 https://github.com/WebAudio/web-audio-api/issues/300 04:54:02 joe: this is a nice to have. 04:55:17 cwilso: important because so many mobile devices have high sample rates; otherwise 8bit audi in games comes out at 48k. we have no access to the resample bit 04:55:46 ... streaming rate not under control; else we could make a contwext at stream SRand align samples. Can't do that so clicks 04:56:03 ... its a reasonable solution. we could cut it but 04:56:23 cwilso: not convinced we should drop it for v1 04:57:51 322 https://github.com/WebAudio/web-audio-api/issues/322 04:57:56 padenot: PR in flight 04:58:25 324 https://github.com/WebAudio/web-audio-api/issues/324 04:58:30 not current sprint 04:58:52 330 https://github.com/WebAudio/web-audio-api/issues/330 04:59:26 rtoyg: trivial 04:59:31 BillHofmann: not in sprint 05:00:03 cwilso: resolved a year ago. not done yet 05:00:21 335 https://github.com/WebAudio/web-audio-api/issues/335 05:00:34 joe: third optional argument 05:01:13 jdsmith: doesn't block anything 05:01:24 336 https://github.com/WebAudio/web-audio-api/issues/336 05:01:28 joe: put this off 05:01:45 344 https://github.com/WebAudio/web-audio-api/issues/344 05:01:52 BillHofmann: we did this yesterday 05:01:59 cwilso: yes but we got complaints 05:02:10 ... not responded yet 05:02:27 cwilso: adda cancel-and-hold with no time on it 05:03:23 346 https://github.com/WebAudio/web-audio-api/issues/346 05:03:57 joe: spec already clear (they can't) 05:04:14 cwilso: not specifically stated though 05:04:39 348 https://github.com/WebAudio/web-audio-api/issues/348 05:04:49 rtoyg: think we should do this 05:04:58 cwilso: IN CURRENT SPRINT? 05:05:23 rtoyg: yes 05:05:59 cwilso: OMGG (flips table) 05:06:51 joe: think its not going to happen in current sprint 05:08:33 joe: OK we have 10, and 5 assigned to cwilso 05:08:45 cwilso: node composition is no change 05:08:52 joe: will take the tag ones 05:09:05 cwilso: constructability is a lot of work and not fundamental 05:09:16 joe: straightforward but annoying 05:09:50 cwilso: 12, someone is working on, who? not clear 05:10:49 cwilso: https://github.com/WebAudio/web-audio-api/issues/12 05:10:58 padenot: in gecko but not exposed yet 05:11:42 cwilso: think (lots of proposals, all over the place in this thread) 05:12:39 cwilso: we need a way to understand when current time is played in performance now time 05:12:45 padenot: that is hard 05:12:55 cwilso: independent of destination node latency 05:13:10 joe: many ways to map back and forth 05:13:39 cwilso: need latency of output device, timestamp accounts for chunking 05:14:12 cwilso: need to work out where they are. output node latency is a different issue 05:14:24 joe: is that 340? no 05:14:42 ... oh because 12 takes that on 05:15:34 joe: this is one of the big remaining defects for v1. we need solutons to both. or can't tell when something is heard 05:15:42 cwilso: needs input latency too 05:16:56 joe: this gives latency cleanly, and another number to solve issue 12 05:17:19 cwilso: one edit to that michael said, 05:17:41 ... context performance timestamp, when that cuirrent time represents 05:18:05 ... performance.now +x = when it comes out the speakers 05:18:46 cwilso: sometimes destination node latency is unknowable and can't be done automatically 05:19:07 ... when current time on the audoio context is, in terms of performance time 05:19:33 ... its when we send those bits to the destination. plus dest latency on top 05:20:30 joe: how can we say that is spec prose? 05:20:48 cwilso: context.performsanceOutputTime 05:22:26 cwilso: when is current time going to hit the speakers. alweays in the future. buffer + latency. monotonically increases but jumps in blocks 05:22:35 joe: leave what he had in there? 05:22:59 cwilso: not useful as it stands. expose dest not output latency separately or not 05:23:07 joe: very important for app tuning 05:23:13 ... people ask this a lot 05:23:19 cwilso: yes, I agree 05:24:06 ... smooth out buffered chunking. exposing that is fine. but one number or two 05:24:16 ... two sources of latency 05:25:17 cwilso: do you want that on average or right now 05:25:23 joe: on average 05:25:35 cwilso: one number is current time in performance time 05:25:58 ... but current time chunks forward, so it is not uniform. depends when you are in the buffer 05:26:17 ... don't need the average, you can calculate it 05:27:03 padenot: they are not clocked together 05:27:12 ... so they drift 05:27:30 cwilso: but as an average latency it does not matter 05:27:41 padenot: if they drift apart the average will move 05:27:58 rtoyg: yes as not on same clock 05:28:25 padenot: so you re-add each time 05:28:27 cwilso: yes 05:29:07 ... never schedule minutes or hours in a buffer. goal is to get enough info to estimate when to do things. not asmple accurate across two clock sources 05:29:32 kaki_ has joined #Audio 05:30:05 cwilso: to a reasonable degree. not phase synch for example. but enough for drum hits ie ams or so 05:30:32 cwilso: gets in the ballpark with opne number. can smooth over time if you really want 05:31:24 cwilso: input and output latency, eventally, I hope 05:31:30 mhakkinen has joined #audio 05:31:53 https://github.com/WebAudio/web-audio-api/issues/12 05:32:53 mdjp: we have other issues related. use consistent language for them 05:33:09 cwilso: this should still represent when it hits the speakers, as an estimate 05:34:14 cwilso: output node latency is included in that 05:34:50 joe: ok so we addressed 340 in effect, and bailed on it 05:34:58 cwilso: yes, lets you solve 340 05:36:01 cwilso: you don't have a smoothed estimate but you do have one. 05:37:02 rtoyg: will do audio param scheduling 05:37:12 cwilso: this is the "no initial point" one 05:37:27 joe: so lets get these done in a month. actually, much sooner 05:37:34 mhakkinen has joined #audio 05:37:36 BillHofmann: when are the next meetings? 05:37:53 joe: 2-3 weeks from thurs, so 12 Nov 05:38:02 cwilso: doubnt i can do that 05:38:16 joe: lets defer telcon schedule until the end of the meeting 05:39:20 break 05:49:17 joe has joined #audio 05:57:23 mhakkinen has joined #audio 05:57:28 ToddG has joined #audio 05:57:38 hongchan has joined #audio 05:59:35 rtoyg_m has joined #audio 06:01:24 olivier has joined #audio 06:06:35