See also: IRC log
<olivier> trackbot, start meeting
<trackbot> Date: 30 May 2012
<philipj> we're really not sure if we're in or not
<philipj> nothing happens after entering 28346#
<olivier> try again - I've had to do it twice
<jussi> me too
<philipj> Are you using the US bridge?
<olivier> I am using zakim@voip.w3.org
<olivier> from my sip software (x-lite 4)
<olivier> the European bridge has been flaky
<philipj> we started by trying the US one (since the Europe ones have never worked for me)
<jussi> try waiting until it's told you the instructions, that seems to help sometimes
<olivier> passcode recognition can be bad. I suggest trying a few times.
<olivier> +1 to jussi's suggestion too
<gcardoso> couldn't reach the european bridge neither
<philipj> the conference code is 28346, right?
<olivier> yes
<philipj> this time it beeped a few times and then silence
<philipj> different, but still wrong :)
<shepazu> http://www.w3.org/2011/audio/charter/2012/charter-proposed.html
<olivier> ACTION: Olivier to send prose on UCR and MIDI for the scope of the proposed charter [recorded in http://www.w3.org/2012/05/30-audio-minutes.html#action01]
<trackbot> Sorry, amibiguous username (more than one match) - Olivier
<trackbot> Try using a different identifier, such as family name or username (eg. ot, folivier3)
<olivier> ACTION: ot to send prose on UCR and MIDI for the scope of the proposed charter [recorded in http://www.w3.org/2012/05/30-audio-minutes.html#action02]
<trackbot> Created ACTION-48 - Send prose on UCR and MIDI for the scope of the proposed charter [on Olivier Thereaux - due 2012-06-06].
zakim P81 is Alistair
<olivier> http://lists.w3.org/Archives/Public/public-audio/2012AprJun/0452.html
<olivier> Scribe: Alistair
<olivier> http://lists.w3.org/Archives/Public/public-audio/2012AprJun/0360.html
Olivier: Marcus or Philip, would you like to spend a couple of minutes giving an overview of the issues you added to the tracker?
Philip: We read the spec from
beginning to end, imagining how we would try to implement it.
We noted things that were hard or impossible to implement +
some editorial issues where we thing things need to be brought
closer to normal web development.
... Some issues are consitency re: string ENUMs. The tickets
that we put under "architecture" are things that we thing will
make a big difference to starting implementation.
Olivier: Chris Rogers, I think you have started tackling these architecture tickets. Could you speak to this?
<olivier> Issues pending review -> http://www.w3.org/2011/audio/track/issues/pendingreview
Chris Rogers: I have started on these. We have had some good discussions on the list aout circular routing.
<olivier> ISSUE-24?
<trackbot> ISSUE-24 -- Undefined behavior for circular graphs -- pending review
<trackbot> http://www.w3.org/2011/audio/track/issues/24
<olivier> ISSUE-24 changeset -> https://dvcs.w3.org/hg/audio/rev/74bd0f9f2fb6
Olivier: The solution proposed in the link above has not been comented on yet. When I read the pros, that you can create a circular graph with an exception, this raises questions.
Chris Rogers: You could create a circular graph with one node, this was just meant as an example. I can change the documentation to make this clearer.
Philip: The change propposed does not define what a 'cycle' is, or what it should sound like when you create one, or when to throw an exception. We don't quite agree with the solution proposed. The solution we were thinking of was to generate silence or NaN in those cycles.
Chris Rogers: So you are saying, if there is no delay node in the cycle, then generate silence.
<olivier> (marcus speaking)
Marcus: I suggest writing a
pseudo-code example to further explain the desired
behavior.
... Another thing proposed was to stall the graph, though this
API does not contain the idea of stalling, so generating
silence seems sane.
<olivier> my bad, thought Marcus was speaking above, it was Philip
Marcus: One thing that is not covered here, is if you have loops that involve audio params, what should happen then? If you take output from one node and connect to the audio param itself, which would be a loop.
Chris Rogers: Well we could adopt a similar approach that we use in normal audio, where we require a delay.
Marcus: Yes, I think we should document this desired behavior.
Chris Rogers: OK I can do that.
Philip: The spec says that delay
nodes are required, but you also have the issue of JavaScript
processing nodes. It's not quite clear about the delay in
JavaScript nodes, and it is unclear if that delay is reflecting
in the timestamps. Are these timestamps shifted?
... it is relevant for loops because you can implement delays
with javaScript or passthroughs with JavaScript.
Chris Rogers: The JS Audio node is going to have latency. If there are any loops, that latency is going to be part of the effect. That is going to be true of any element that have latency. Most do not have latency. The dynamics processer has a small look-ahead latency.
Philip: Does that mean it would be OK to have a loop with the dynamics node?
Chris Rogers: That's a good question. We can let cycles exist without any delay nodes at all and accept that there is an implicit delay (a minimum delay) associated with the node.
Chris Rogers: That is one approach we can take is not require delay nodes at all, with the understanding that there would be a minimum delay asc. with the block processing size.
Philip: Is it acceptable to have a min. delay of the block size in a loop. Say you want to have a 1-2 sample delay, then that would not be doable.
Chris Rogers: That's right, if we are assuming that there would be a min. delay doing cycles, then we wouldnt be able to have feedback loops that small in samples.
Chris Rogers: We have a 128 sample min block size. I could see us reducing that down to 64 / 32.
Philip: It becomes kind of
propblematic to have the behavior to depend on this block size.
Because if everyone uses different samples settings it could
become unmanageable.
... To have compatability, wouldnt we have to have the exact
same size? It seems like it could be problematic to specify the
exact block size that you would have to use.
Olivier: I think the suggestion is not to standardize the min block size use but to standardize a min. delay which would be farly small regardless of what block size the implementation uses.
Chris Rogers: I think we should set this by milliseconds, not samples. I think this will give us better accuracy across different machines.
Philip: Should we be using a
multiple of the framesize to specify in milliseconds?
... If we say it is 3 milliseconds, calculated from 48khz. But
if you have 3ms. at 88khz then that would leave it smaller than
you block size.
Chris Rogers: If the sample rate goes low, then it would require that the block size be smaller.
Philip: Is it worth it define it in ms instead of smaples?
Chris Rogers: We couldm but we will then come across the issue of two machines with different processing power sounding slightly different.
Philip: What would happen if the spec said we should support arbitarty block sizes?
Chris Rogers: It's not that it is impossible, but it's tricky. When you create delays that are tweaked, say down to 1 sample, then you have to be prepared to construct the graph on low sample size, or reconstruct on the fly, which adds complications.
<Zakim> shepazu, you wanted to talk about the priority of constituencies (later)
Doug: The highest level of priority should be the user experience. We should err on the side of making the user experience as good as possible first, then the developer experience.
Chris Rogers: I tend to agree with that, but we have not discussed there being a huge performance difficulty bringing the graph size down to a smple size of 1. There is a huge performance cost going down to those block sizes. Users would have to be aware of this.
Doug: If that would hurt the user experience, that is something we should try and aviod where possible, even if it means the implementors have to follow the spec more stringently.
Olivier: Can we leave it to the implementation to decide how to handle the delay being to small?
Chris Rogers: I think we can do something like that, but I would not output silence, but I would clamp the delay to the min. that the implementation can support.
Philip: Things that are undefined will be depended on by people, who will end up haivng to reverse engineer things, and end up having to use the same block size. I dont agree with leaving this undefined.
Chris Rogers: So if it is defined, do you want to defined it in ms. or samples?
Philip: It seems that if fixed
size buffers are required in this spec, then it seems we should
outline that in the spec. I think using "samples" is going to
be a clearer path towards implementation.
... The same graph at the same sample rate will sound the same,
but using the native sampling rate of the system you might get
different results.
Chris Rogers: We do that currently. I am fine with that. We could define this at 128 or 64 samples and perhaps add an attribute in the future where this could be settable by the developer.
Philip: That sounds reasonable. I
think the API will look strange from the outset, but would be
implementable.
... I think if we all agree, we can just specify this and make
the decision if/when someone says "this is not good enough to
meet x/y/ use cases."
... Clamping delays to block size could be risky because people
will depend on the behavior.
Chris Rogers: OK.
Philip: We should pick wisely on this blocksize as we will likely have it for a long time.
Chris Rogers: We could go down to 64 to (like PureData etc). But 128 seems to work.
<olivier> Resolved: it is OK to have a circular graph so long as there is a delay. The minimum delay should be 128 samples.
<Zakim> shepazu, you wanted to suggest that any proposed solutions to issues be added to the issue
Doug: As a note, there are no binding resolutions until we finish the spec., but anyone who goes against the resolution should only do so respectfuly, for a very good reason and with caution.
<shepazu> Resolution: it is OK to have a circular graph so long as there is a delay. The minimum delay should be 128 samples.
Doug: The reason for the solution is to provide clarity for those watching the process, and for us to go back and be able to see why and how we made a decision.
<olivier> (regarding resolutions, /me points everyone to http://www.w3.org/2011/audio/wiki/Main_Page#Meeting_Minutes_and_Resolutions if you don't know it already)
Doug: If you have a proposed solution, even if you are not sure if it is the right way to go forward, you should add it. If you have suggestions on how to resolve it, please include them to you issues.
<philipj> me too, not just marcus
Olivier: I will add the
resolution to the issue and leave it Open review until Chris R.
has had a chance to work with the spec.
... Thank you all for attending. Talk soon.
This is scribe.perl Revision: 1.136 of Date: 2011/05/12 12:01:43 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Found Scribe: Alistair Inferring ScribeNick: Alistair WARNING: No "Present: ... " found! Possibly Present: Alistair Doug Doug_Schepers FILT3R Olivier P55 P58 P8 P81 P86 P87 Philip aaaa aabb aacc crogers gcardoso inserted jussi marcus philipj shepazu tmichel trackbot You can indicate people for the Present list like this: <dbooth> Present: dbooth jonathan mary <dbooth> Present+ amy Agenda: http://lists.w3.org/Archives/Public/public-audio/2012AprJun/0452.html WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth Found Date: 30 May 2012 Guessing minutes URL: http://www.w3.org/2012/05/30-audio-minutes.html People with action items: olivier ot WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]