23:47:44 RRSAgent has joined #audio 23:47:44 logging to http://www.w3.org/2015/10/25-audio-irc 23:47:46 RRSAgent, make logs world 23:47:46 Zakim has joined #audio 23:47:48 Zakim, this will be 28346 23:47:48 I do not see a conference matching that name scheduled within the next hour, trackbot 23:47:49 Meeting: Audio Working Group Teleconference 23:47:49 Date: 25 October 2015 23:48:05 rrsagent, this meeting spans midnight 23:54:48 shepazu has joined #audio 00:02:23 present+ cwilso 00:02:25 present+ padenot 00:02:28 rtoyg_m has joined #audio 00:02:28 haa 00:02:31 kawai has joined #audio 00:02:32 present+ mdjp 00:02:33 joe has joined #audio 00:02:37 present+ joe 00:02:39 BillHofmann has joined #audio 00:02:43 jdsmith has joined #audio 00:02:46 present+ jdsmith 00:02:50 present+ 00:02:55 present+ rtoyg_m 00:03:03 hongchan_ has joined #audio 00:03:09 present+ BillHofmann 00:03:17 Guest has joined #audio 00:05:03 yasuraoka has joined #audio 00:07:49 kaki has joined #audio 00:08:39 https://github.com/WebAudio/web-audio-api/issues?utf8=%E2%9C%93&q=is%3Aopen+is%3Aissue+milestone%3A%22Web+Audio+V1%22+sort%3Acreated-asc+label%3A%22Needs+WG+review%22 00:10:11 zakim, pick a victim 00:10:12 Not knowing who is chairing or who scribed recently, I propose cwilso 00:10:55 scribenick: cwilso 00:10:58 watanabe has joined #audio 00:12:49 topic: processing model 00:13:29 00:14:01 http://padenot.github.io/web-audio-api/#processing-model 00:14:26 https://drafts.css-houdini.org/isolated-workers/#examples 00:14:41 padenot: the Houdini description of running processes on different threads seems helpful in describing our model 00:14:44 I find this is relevant for us. 00:14:58 (what paul just pointed out) 00:16:23 Joe: what changes do you see coming out of the Houdini draft that will affect us? 00:17:30 padenot: Houdini thread says you don't parse script on houdini thread (?) 00:18:42 joe: do you think the interfaces described for nodes would be affected by this? 00:18:52 paul: yes, I don't think that would change. 00:19:11 paul: I don't see incompatibilities between those apis and isolatedworker 00:19:42 bill: are they proposing this (in Houdini) as a general interface? 00:20:03 paul: that's the intent. 00:20:16 jun has joined #audio 00:21:06 hongchan/cwilso/paul agree it's intended to be a general concept. 00:21:25 joe: where are we relative to implementability? 00:21:52 paul: speaking as an implementer, I'm gonna wait a bit. :) 00:22:27 ...I've spoken with the person who would likely end up implementing, and they're not sure exactly how script is intended to be run, etc. 00:23:57 hongchan: ian kilpatrick has a prototype of the underlying bits; once that settles in, I'll be looking at implementing 00:24:02 https://github.com/w3c/css-houdini-drafts/issues/ 00:24:12 https://github.com/w3c/css-houdini-drafts/labels/Isolated%20Workers 00:24:47 paul: issues 54 and 56 are directly related to audio 00:25:27 joe: processing model is the biggest new thing introduced, and I haven't seen a lot of comments on the group. Is it good, is it complete... 00:25:35 paul: I can tell you it's not complete (yet) 00:26:23 bill: if I understand, the processing model affects the developer of audioworker, but not the user? 00:26:46 paul: well, sort of - the user of audioworker may have their code break due to the processing model. 00:26:55 s/developer/implementer/ 00:28:56 joe: small question about processing model: on currentTime. Are you going to merge these changes (annotating sync/async) soon? 00:29:26 olivier1 has joined #audio 00:29:27 paul: blink uses an atomic to update currentTime, we use a stable state. We think the latter is more correct, but open to discussion. 00:30:24 joe: is there something the group needs to discuss in this area? I have a PR that redefines how currentTime is updated. IS that still appropriate? 00:31:42 paul: if you while(1) console.log(context.currentTime), does it ever update? We think no... 00:34:28 joe: would it make sense for the update of currentTime to take effect while the main loop is busy? 00:34:53 ...the new semantic of currentTime reflects work done by the audio thread... 00:35:15 Yukio has joined #audio 00:37:02 cwilso: I think currentTime should be advancing... 00:37:41 joe: also, we're going to be adding mapping between currentTime and DOM time. 00:37:50 cwilso: yeah, we'd end up with more jitter in the timing then. 00:37:55 paul: I think I agree. 00:38:25 joe: processing model needs a step 6 to reflect this. 00:39:29 paul: we should look at how performance time gets updated, maybe? 00:41:40 cwilso: This is blasphemy! This is madness! THIS IS AUDIO! 00:42:06 paul: I'll follow up on this. 00:43:13 https://www.w3.org/community/webtiming/ 00:43:20 paul: also somewhat related: on time-domain mapping, there's another person working on syncing multiple devices' time clocks. (See url above) 00:44:34 ...it's clear we can't just have a number of milliseconds of latency 00:46:26 cwilso: or can we? :) 00:48:43 joe: with chair hat off, there's a glaring need for even a bad representation of latency. 00:48:51 joe: to come back to audioworker...any more to discuss here? 00:49:52 kawai has joined #audio 00:53:18 cwilso:naming? 00:53:35 bhofmann: if we step back, we're letting people write audio nodes 00:53:36 cwilso: we're letting them write custom audio processing 00:53:58 bhofmann: should we call them "custom audio processors"? 00:54:37 cwilso: if we have CustomAudioProcessor we'll have CustomAudioProcessorNode too 00:55:00 bhofmann: trying to avoid getting caught up in worker 00:55:20 bhoffman: obviously names matter a lot or we wouldn't have this discussion 00:55:53 cwilso: we're not trying to harmonize with houdini 00:56:42 hongchan has joined #audio 00:58:53 cwilso: I'll come up with some names 01:03:29 watanabe has joined #audio 01:03:33 matt: people should come up with names during the next two days and write them on the board. 01:04:52 https://github.com/WebAudio/web-audio-api/issues/573 01:05:10 topic: interaction of automation methods is unclear 01:05:50 mdjp - cwilso will be judged to be the voice of reason in taking our naming suggestings further. 01:08:57 joe: ray, can you summarize? 01:09:32 rtoy: this is a mashup of 1) scheduling two things at the same time, and 2) interlacing between schedule calls 01:13:43 rtoy: the model is relatively clear in the spec (other than the initial value point). 01:18:24 rtoy: if you have automation going on, and you schedule a new event that ends before the one you currently have running 01:19:46 ...what happens? 01:25:40 01:39:59 resolutions: 1) #344 should remain the POR, 2) we should remove the automation events of the same type overriding each other, but the rest is fine. 01:48:05 iank has joined #audio 01:54:26 ToddG has joined #audio 02:10:27 yasuraoka has joined #audio 02:12:56 02:13:03 02:13:49 iankilpatrick: visiting from CSS Workers 02:14:14 ian: IsolatedWorkers piece of infrastructure that we need for CSS extensibility in the rendering engine 02:14:31 ian: for example, define your own custom layout. CSS Paint API spec coming soon to create callbacks 02:14:38 ChrisL has joined #audio 02:15:12 ian: concerns on running user's script in the main thread. what happens if you call setInterval() in this context? 02:15:22 https://drafts.css-houdini.org/isolated-workers/ 02:15:22 ian: the first thing we needed is a stripped down JS worker concept 02:15:49 ian: IsolatedWorkerGlobalSCope is basically empty except for Base64 fns which are convenient to have 02:16:09 ian: we wanted to start from a clean slate with no dangerous APIs that someone can call from the middle of a rendering engine 02:16:13 Yukio has joined #audio 02:16:31 ian: then we came to the next thing we needed: the ability to be able to run on multiple threads and not be tied to main thread at all. 02:16:42 ian: in the future we'd like to be able to run painting on separate thread 02:17:22 ian: this is why we wanted the ability to spin up multiple local scopes that are tied to one worker and be able to arbitrarily call into any of them. User can define all of this. 02:17:43 ian: for purposes of Houdini we'll probably run two IsolatedWorker global scopes and randomly assign calls to each of them 02:18:27 ian: concerns about devs depending on order of allocation of calls to these global scopes 02:18:38 ian: s/multiple local/multiple global/ 02:18:51 watanabe has joined #audio 02:19:10 ian: there isn't the ambiguity of an event callback while you're doing someithing synchronously. see CSS Paint spec 02:20:13 ian: on the order of 20 Kb per context. doesn't make sense for layouts with 100s of nodes to all have their own context 02:21:12 ian: other things in spec that try to reinforce this. for example when script is loaded, it's forced into a strict JS parsing mode and wrapped in an anon. function 02:21:30 ian: goal is to make it really hard for script scopes to communicate accidentally 02:29:38 mhakkinen has joined #audio 02:37:31 Zakim has left #audio 02:39:13 shepazu has joined #audio 02:41:58 ToddG has joined #audio 02:46:37 shepazu has joined #audio 02:48:07 shepazu has joined #audio 02:49:39 (unminuted fast discussion on cancelling automation without holding onto future scheduled values, and the precise meanings of "now" and "as soon as possible") 02:59:29 Zakim has joined #audio 02:59:47 zakim, remind us in 6 hours to go home 02:59:47 ok, ChrisL 03:21:34 yasuraoka has joined #audio 04:17:19 joe has joined #audio 04:17:33 olivier has joined #audio 04:23:44 ToddG has joined #audio 04:27:10 BillHofmann has joined #audio 04:33:15 kawai has joined #audio 04:36:35 mhakkinen has joined #audio 04:37:29 droh_ has joined #audio 04:38:39 https://github.com/WebAudio/web-audio-api/issues?utf8=%E2%9C%93&q=is%3Aopen+label%3A%22Needs+WG+review%22++%22TAG+issue%3A%22+ 04:39:29 ChrisL has joined #audio 04:39:49 BillHofmann_ has joined #audio 04:40:31 watanabe has joined #audio 04:40:39 jdsmith has joined #audio 04:41:03 hongchan has joined #audio 04:42:55 shepazu has joined #audio 04:44:29 Yukio has joined #audio 04:47:28 TAG: what is the problem with making audio params constructable? 04:49:37 cwilso no ability to create an audio param which does not have its values accessed as they are not updated 04:49:57 joe current audio worker audio params are created indirectly from global scope 04:50:14 cwilso they can be created on main thread or within AW script 04:51:20 TAG: if we can not find a way to make progress on this quickly it would not be an issue 04:56:19 joe new audio param and pass in node as frrst argument 04:56:38 TAG is there a param which is gobal and referenced by each node? 04:57:13 cwilso audio worker is not a node - its a factory for type of audio processor - returns a node with audio params attached 04:57:36 cwilso only loads code once in the audio thread - creates objects with their own audio params 04:59:17 cwilso audio params created on instance not on generic audio worker - audio prarams not created until a node is instances 04:59:59 padenot audio params not marshalled, only values which are represented on the audio thread 05:01:21 cwilso we dont have the ability to create an audio param on one node. 05:01:41 joe audio worker param descriptor could be constructed 05:02:04 TAG process of constructing a node causes a parameter to be allocated on the node? 05:02:15 TAG creating audio param on a node is meaningless? 05:02:33 padenot not been thought about as they only appear on node creation 05:02:53 cwilso 121 relationship can be thought of as a read only attribute on nodes 05:04:13 TAG: set up a restriction on audio param constuctor to be inert if not allocated a node 05:05:01 cwilso - need to be careful that you don;t have the expectation of being able to attach an audio param to a worker instance and marshal to the audio thresd 05:07:07 cwilso audio worker can change its param descriptor changing how it looks in the main thread 05:09:40 cwilso if audio param is constuctable there is nothing useful you can do with it 05:09:59 TAG this is fine - its an open question which can be documented and answered in the future 05:12:58 cwilso - proposal desugar all context created nodes adding constructors with context as initial parameter 05:13:28 related https://github.com/WebAudio/web-audio-api/issues/255 05:17:10 TAG: audio worker provides a path to resolve this issue - should not necessarily hold up v1 05:17:35 padenot: some nodes not defined and shoul dbe defined before providing the descriptions 05:18:20 cwilso - move to v2 05:18:42 https://github.com/WebAudio/web-audio-api/issues/251 05:19:04 cwilso fine to subclass nodes but not able to do anyting to their audio processing 05:19:54 cwilso having a custom compositor node would be useful eg - create a chorus node 05:20:08 padenot have you found problems with a connect method 05:20:19 padenot not found issues 05:21:42 cwilso other challenge - forwarding of audio params - may not be achivable in V1 05:21:45 joe may be ok 05:22:39 TAG sounds relitively complete - very difficult to package a library of nodes and make them portable. Hard to come up with useful grouping. 05:22:56 cwilso not tried this to see if it worked and presumed if didn't - will try it 05:23:21 joe are we doing anything to rule out a compositor node approach in the future? We could solve the problem and ook into it later 05:24:53 RESOLUTION: Deferring tfor cwilso to verify behaviour and will close on verification if sucessful 05:25:04 https://github.com/WebAudio/web-audio-api/issues/257 05:27:17 cwilso we should be able to define the html 5 audio elemnt in terms of web audio - we don't have lower level output access 05:27:26 mhakkinen has joined #audio 05:27:29 padenot we dont expose anything past the destination 05:28:29 padenot important to address this, good use case to not use the web audio api - companies using script processor or scheduling audio buffer source node. 05:29:30 cwilso what is a media stream - how do we get bits in and out? 05:30:25 jeff has joined #audio 05:30:40 olivier has joined #audio 05:32:51 joe we are trying to reconsile uncertain areas with media capture and rtc 05:34:29 olivier has joined #audio 05:43:11 cwilso what is the appitite to define i/o apis and implement them. 05:43:53 TAF this should not hold up shipping of the api - but commiting to a lower level api or task force would also be valid 05:44:20 joe how much responsability will media capture take on with respect to abstractions of devices 05:45:21 TAG question for tag to take up with the group and something to come back to. Knowing more about media streams would be interesting 05:45:54 joe we are meeting with some of the RTC group tomorrow to talk through a proposal for output devices. 05:47:14 BillHofmann_can we do useful things with the spec as it stands (yes) - TAG: there ar opportunities that we have yet to enable 05:47:50 RESOLUTION - we should describe this in more detail and be a priority for charter post V1 as a task force or cross working group. 06:00:22 https://github.com/WebAudio/web-audio-api/issues/344 06:02:31 cwilso - should not add additional method (assumeCurrentValue) clarify spec to point out possible discontinuities, current value in the future will rever to the last schedule point 06:06:19 https://github.com/WebAudio/web-audio-api/issues/436 06:10:51 cwilso - through acceptingt his proposal does this mean we would look to make ABSNs reuseable - this is a consistant request from users. 06:13:12 joe - should resolve 436 and then investigate reuseable ABSN question 06:14:13 some conversation happens in the bottom corner of the room 06:15:59 joe - proposed resolution, convolver waveshaper and ABSN all output silence once buffer or curve is set to null. Node becomes inactive and can be GC'd new buffer or curve throws error 06:19:31 olivier has joined #audio 06:38:08 joe has joined #audio 06:38:24 mhakkinen has joined #audio 06:49:14 BillHofmann has joined #audio 06:52:51 hongchan has joined #audio 06:55:28 rtoyg_m has joined #audio 06:59:28 Hello, everyone! 06:59:51 Hi, Bill! 07:00:14 https://github.com/WebAudio/web-audio-api/issues/535 07:00:36 The order in which Promises are returned, rejected, or resolved is ambiguous 07:02:02 joe: this is similar to questions jernoble raised about processing model 07:02:04 jdsmith has joined #audio 07:03:10 padenot: my branch has explicit description in async vs sync cases 07:03:24 joe: this issue goes away... 07:04:09 padenot: what's important is to describe how you queue the events back and when you resolve the process 07:04:18 rtoygm: not sure we have this done correctly 07:05:26 billhofmann: is the spec language specific enough? 07:05:55 joe: jernoble suggests that he's ok with language if explicitly indeterminate 07:07:03 rtoyg: note the worker spec isn't specific 07:08:41 joe: https://github.com/WebAudio/web-audio-api/commit/6d93bdaa763e71379516ccb6d4d987993108fad9 07:09:12 padenot: can close this once padenot's commit referenced above is merged 07:09:33 padenot: #647 is the key one 07:09:46 ToddG has joined #audio 07:11:52 https://html.spec.whatwg.org/multipage/webappapis.html#processing-model-8 07:12:43 padenot: note this is the processing model in HTML ("what is a microtask"?) 07:13:21 ChrisLilley has joined #audio 07:13:55 Next up: WebMIDI 07:14:18 https://github.com/WebAudio/web-midi-api/labels/needs%20WG%20review 07:14:33 cwilso: three issues that need WG review 07:16:19 cwilso: Issue #110... determine if hardware supports general MIDI... 07:17:12 pauljeong_ has joined #audio 07:17:42 cwilso: lack of consistent support means that you'll get lots of false negatives 07:19:48 kawai: no devices expose this 07:20:20 cwilso: however, USBMidi specs it... 07:21:11 07:21:23 joe: James wants it 07:21:37 cwilso: not sure if it's worth supporting - could go either way 07:22:36 kawai: what about DAW systems? 07:22:52 cwilso: no, in that case you're going to set everything up by hand 07:23:46 joe: I don't think general midi is a very interesting thing to expose 07:23:56 cwilso: inclined to not support, or at least not support in v1 07:25:00 kawai: almost no devices support, so we don't think it's valuable 07:25:59 jdsmith: indicator isn't reliable, not sure how useful it is 07:26:34 cwilso: seems like you'd need to set it up anyway 07:27:15 cwilso: will leave in v2, see if it rises from the near-dead 07:27:27 https://github.com/WebAudio/web-midi-api/issues/150 07:28:59 cwilso: have this issue with software synths in general, need to ask permission for software devices 07:29:19 cwilso: takashi notes that we'd need to also prompt re BT devices 07:30:48 cwilso: recommendation is that midi options should have a software type, would rather not have separate BT types, even though that means we'd prompt for them. 07:31:27 takashi: no strong opinion, that's ok 07:34:10 cwilso: note BT MIDI devices just show up on Mac and Windows, but mobile platforms require request 07:36:02 07:37:52 cwilso: should ignore BT problem, if we end up prompting everytime on Android, that's fine 07:38:06 cwilso: so, proposal: just flag software 07:38:15 https://github.com/WebAudio/web-midi-api/issues/148 07:39:59 cwilso: hard to consistently get correct information; propose punt. 07:44:33 cwilso: these were the only issues I wanted review on 07:44:38 https://github.com/WebAudio/web-midi-api/milestones/V1 07:46:57 cwilso: two vendors shipping webmidi-dependent products: Yamaha and Peavey 07:48:03 cwilso: Mozilla impl is in development... 07:48:36 padenot: it's working on OS/X, padenot has offered help on Win/Linux 07:51:14 mdjp: last item on the agenda! 07:51:39 olivier has joined #audio 07:51:59 joe: should perhaps cover Audio Output stuff 07:52:45 https://docs.google.com/document/d/1jRVexJ6yM6gJggOZjMFejXUApTByD5aoYRGzAJTsQzM/edit# 07:54:15 joe: existing audio output devices API takes either device IDs, magic strings, use them to set the Sink on various objects 07:55:16 joe: could use this to set the sink for either HTMLMediaElement or Web Audio to this 07:55:25 joe: however, there are some problems with this 07:56:00 joe: 1. enumerating devices doesn't really tell you anything of value, and 07:56:17 joe: 2. can't get access to characteristics of output devices and 07:56:24 joe: 3: they don't really have the info you need 07:57:27 joe: 4. sink ids also don't allow any control of output device (e.g. mute) 07:57:55 joe: proposal is to have a getUserMediaOutput that works similar to getUserMedia 07:58:53 billhofmann: also note use of constrainable pattern 08:02:44 padenot: wasn't there an API to select output devices for video? 08:02:48 joe: not aware on one... 08:04:20 cwilso: need to be able to know the native clock rates 08:04:49 joe: we had a comprehensive list of these items - just not in the spec 08:13:47 kawai: are multiple inputs supported? 08:13:53 padenot: yes, I think!?! 08:16:25 standing motion to adjourn 08:17:57 rrsagent, make minutes 08:17:57 I have made the request to generate http://www.w3.org/2015/10/25-audio-minutes.html mdjp 08:18:16 trackbot, end meeting 08:18:16 Zakim, list attendees 08:18:16 As of this point the attendees have been (no one) 08:18:24 RRSAgent, please draft minutes 08:18:24 I have made the request to generate http://www.w3.org/2015/10/25-audio-minutes.html trackbot 08:18:25 RRSAgent, bye 08:18:25 I see no action items