W3C

- DRAFT -

Audio Working Group Teleconference

28 Jan 2016

See also: IRC log

Attendees

Present
BillHofmann, mdjp, joe, rtoyg_m, hongchan, cwilso, padenot
Regrets
Chair
SV_MEETING_CHAIR
Scribe
BillHofmann

Contents


<joe> Is anyone on the WebEx? I cannot join

<joe> I have asked Bill if he can help

<mdjp> joe - trying now

<padenot> ahhhh

<mdjp> joe - I get a page telling me the meeting is cancelled or ended

<joe> Bill is out of the country and I got an autoanswer

<joe> This is crazy.

<mdjp> What url are you using Joe?

<joe> https://mit.webex.com/mit/j.php?MTID=mdd4a87761b7e4da123d9213197cad084

<joe> If anyone has access to a telcon number we can use, that would help tremendously

<padenot> hrm still not fixed

<joe> Bill, can we use the telcon solution you gave us last week/

does the webex client work?

<joe> no

oh.

ummm. Yes, you can. Please don't email to the public list this time, though.... Jas...

<joe> I will not -- I am sorry about that

np

<joe> ChrisL, let's follow up next week to figure out how we can get WebEx back up, it died the previous meeting also

<ChrisL> oh

ummm. lets see.

Please join my meeting by computer or smartphone: https://my.webjoin.com/dolby/?passcode=70339799 If this is your first time joining, you may be prompted to download the BT MeetMe with Dolby Voice plugin. Use your stereo headset for the best sound quality. Or join by phone with these dial-in numbers and passcode Participant passcode: then # International direct: +1 857 350.1927 US Toll free: 1 866 777.5715 More dial-in numbers f[CUT]

<joe> OK hope we can excise this from the minutes

<ChrisL> died at the start of the meeting or part way through?

web client is plugin based. ah yes. :)

<joe> Thank you Bill

<hongchan> music!

<rtoyg_m> Hurry up chariperson!

<rtoyg_m> chairperson

<padenot> so catchy

<joe> We are waiting for a chairperson to join the call I guess

<joe> Although I didn't break WebEx I failed to follow up after the last breakage -- my apologies to everyone.

<joe> https://github.com/WebAudio/web-audio-api/pull/677

Discuss PR 677

<scribe> scribenick: BillHofmann

<joe> https://github.com/WebAudio/web-audio-api/issues/12

joe: issue about describing performance time and latency
... when will a signal be heard, but a new use case has popped up - when will will the next render occur?
... this is an issue of "scope creep". Issue 12 adds a new attribute "outputPerformanceTime", time the next scheduled block of audio would be heard

<hongchan> *just muted our mic - does it help?*

joe: PR adds two attributes: currentPerformanceTime and latency - how long after render to reach the useragent output

<ChrisL> yes, thanks!

yes, sounds less like someone being hit with a bat :)

joe: since blocks aren't necessarily rendered continuously and evenly, one or two of these is insufficient. probably need all 3

cwilso: you're right - the currentTime is non-uniform, for a bunch of purposes (most interactive ones), you need to know real *now*
... you don't really have latency, you have average latency
... need "what is really now" in AudioContext time, can calculate latency if you need to

joe: nice to have

cwilso: somewhere, we need to know what time it is now in AudioContext time and in performance time.
... latency is helpful on destination node, but not really useful for calculations

joe: basically for user experience time (e.g. Noteflight)

cwilso: what we have as currentTime is the least useful thing we could have. The current PR adds a timestamp on currentTime, adds latency.
... seems like it'd be better to add the currentTime in AudioContext time that proceeds monotonically

joe: like "outputTime"

mdjp: would be good to clearly explain these time values, regardless with what we end up with

all: yes. agree - we haven't expressed this really clearly.

<ChrisL> +1 to clear explanation with several good examples

BillHofmann: do we have a sense of what the right answer is

<hongchan> "currentTime in AudioContext time that proceeds monotonically" - I agree with what Chris said.

<hongchan> I think this should be 'currentPeroformanceTime'.

joe: we know we need more things, but unclear which exactly we *need*. outputTime is clearly needed, what is unclear is whether we need currentPerformanceTime, etc.

mdjp: since no-one has come forward with a currentPerformanceTime, should we split into v1 and v2 features?

joe: will try to capture a clear proposal in Issue 12, conversation keeps drifting...

hongchan: currently, currentTime proceeds in "batches", there should be a way to have a property that updates monotonically (evenly)

cwilso: to be clear, this isn't an attribute, it's a method call
... you don't want to be updating the attr constantly if not needed

joe: how is this different from outputTime
... if you schedule something to be played at time T, outputTime when you hear that, it'll be at time T

<ChrisL> when the sound *leaves* the speakers, presumably

rtoy_g: when it leaves the computer...

<ChrisL> (we all agree bluetooth sucks)

BillHofmann: Bluetooth, for instance, has high latency

<ChrisL> high and variable

joe: in some cases, you know for sure that the system has a nominally fixed (near constant) latency

<padenot> you can know the output latency on all platforms

joe: perhaps it's when the UA calls "play" to the audio subsystem

cwilso: there's no way today to carefully sync audio, midi, and the screen - particularly, audio

padenot: we know the time it hits the speakers, it works just fine, even with BT

joe: will attempt to write this issue up and add to Issue 12
... is the PR author affiliated with a WG member?

cwilso: he doesn't work for google, but could be a chromium contributor.

joe: will write up the issue, won't try to solve who does the PR.

<ChrisL> "I think it is better to split this issue to three seperated issues:

<ChrisL> 1) latency issue

<ChrisL> 2) time drift issue (currentTime and currentSystemTime)

<ChrisL> 3) granularity issue. "

<ChrisL> Olivier Thereaux,, 11 Sep 2013

BillHofmann: should we have a graph/explain each of these?

joe: yes. The IRCAM commenter has been doing that, it's helpful.

Review of new issues

<mdjp> https://github.com/WebAudio/web-audio-api/issues?q=is%3Aopen+is%3Aissue+no%3Amilestone

<mdjp> https://github.com/WebAudio/web-audio-api/issues/708

hongchan: already specified, not sure what else can be done here...

mdjp: does anyone agree this is a valid issue?

rtoy_g: agree with Hongchan

<mdjp> https://github.com/WebAudio/web-audio-api/issues/707

https://github.com/WebAudio/web-audio-api/issues/707

rtoy_g: elaborates thinking on issue...

mdjp: move to "ready for editing" for v1

<mdjp> https://github.com/WebAudio/web-audio-api/issues/705

rtoy_g: this has come up just this week - we've never discussed...

BillHofmann: see the value, but is this a "must have" or "handy"

ChrisL: lots of people are doing this by hand, we think, probably useful

joe: this is a job for "Super Audio Worker"

all: discussion on what the criteria should be for new "everyone uses them" nodes

mdjp: could go either way on this

BillHofmann: raises issue on lots of different variants being discussed

joe: people aren't beating us up on noise nodes, they're beating us up on AudioWorker

mdjp: anyone object to v.next?

<mdjp> https://github.com/WebAudio/web-audio-api/issues/703

rtoy_g: these all follow on from joe's constructor PR
... all of these related issues are adding the parameters to the constructors

BillHofmann: do they line up to the factory method arguments?

rtoy_g: pretty much. most are pretty obvious, ones called out here are not so obvious.

billhofmann: so these are "best practice" questions?
... and who can share a best practices position?

mdjp: shall we set a task for the next call on commenting on them to propose solution?

<mdjp> https://github.com/WebAudio/web-audio-api/issues/695

mdjp: assume these are v1, we'll comment over the next 2 weeks

rtoy_g: notes that default == 360, which if we do modulo, forces no output, should remove that and let >360 angles produce result as documented
... should be 0 <= angle <= 360, outside values are undefined

mdjp: happy with that proposal.
... any other pressing issues?

rtoy_g: can we get reviewers on the open PRs?

padenot: will look at them

Update on Houdini worklet timelines and impact on Audio Worker.

mdjp: homework: review PRs and Roy's issues

<rtoyg_m> Ray, not Ray.

(sorry)

<rtoyg_m> People make that mistake all the time. I have no idea why. :-)

mdjp: any update on the issue?

padenot: yes, some action having sent the email

joe: he was inviting us to submit PRs

padenot: yes, I will review the text and note what we should address

Next F2F

mdjp: question is whether we should do a plenary session at WAC#2

Date of next meeting

mdjp: sent out google poll for F2F, really only date was the Thurs/Fri before; will send out email confirming
... next meeting 2 weeks.

Summary of Action Items

Summary of Resolutions

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.144 (CVS log)
$Date: 2016/01/28 18:01:00 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.144  of Date: 2015/11/17 08:39:34  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/70339799//
Succeeded: s/aka/e.g./
Succeeded: s/Roy/Ray/
Found ScribeNick: BillHofmann
Inferring Scribes: BillHofmann
Present: BillHofmann mdjp joe rtoyg_m hongchan cwilso padenot

WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth

Found Date: 28 Jan 2016
Guessing minutes URL: http://www.w3.org/2016/01/28-audio-minutes.html
People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.


[End of scribe.perl diagnostic output]