See also: IRC log
<scribe> scribenick: ChrisL
ChrisW: would like to have a bit of "structure for v.next" discussion wrt incubation
mdjp: can discuss over lunch
<joe> https://github.com/WebAudio/web-audio-api/issues/10
(we discover that MIT Guest blocks IRC, sigh)
padenot: Wrote some text, see link
<padenot> https://rawgit.com/padenot/web-audio-api/10-dynamicscompressor/index.html
<padenot> https://rawgit.com/padenot/web-audio-api/10-dynamicscompressor/index.html#processing
padenot: describing chrome
compressor, it is before the blink fork
... intent to spec something that is not fully precise but
covers general algorithm with some leeway for the exact shape
of the soft knee
... should not be widely different
... the end blocks also can differ
... missing computation of native gain
... inner loops needs to be finished. rest should be
correct
... it is quite complex, reverse engineering the curves
... lots of magic numbers
joe: we had a call talking about
the best way to do this. Hard to reverse engineer. To what
extent do we wantto frame it as an algorithm rather than one
instance of a compressor that complies with the spec?
... could be a danger in miring in details
padenot: current depth is enough.
Unambiguous - peak detecting not RMS for example
... mostly audio rate inside
... most sub algorithms are sets of constraints
... rather than a polynomial expression for example
https://rawgit.com/padenot/web-audio-api/10-dynamicscompressor/index.html#processing
padenot: after my todos we can
look it over
... should be possible to implement without reading the
code
joe: recognise this is copping
out to some extent, talking about making another pass on
compression for v2
... someone can build a similar compressor. Testable
conformance
padenot: possible to write some
knee tests that pass
... knee, curve continuity, peak vs rms is specced
joe: attack and release time constants calculated in a convoluted way with state in several vars, hard to follow
cwilso: concerned on testability, not truly interoperable
padenot: goal of compressor is to make things not move too much in terms of volume. so impls that do a similar job can be tested
joe: valid criticism
padenot: curve must be continuous
(so it doesn't introduce harmonics)
... adaptive release and attack, and precise knee shape, are
the points of flexibility
cwilso: maybe punt on this for
v1, if it is not interoperable
... like the acid test in IE
... iterative approach to conformance
ChrisL: are you suggesting dropping compressor from v1
cwilso: yes, incubate as a
separate thing, impls can look at it but its outside the spec
for now
... most ppl don't care on the details, just using it to stop
sudden jumps or overload output
padenot: there are other examples of loose algorithms, like boxblur is not necessarily gaussian blur
joe, chris: antialiasing another example
joe: want a loose spec that chris rodgers algo is a conforming impl of. Lets us add that node in the spec.
ChrisL: will we want to add a different, more configurable compressor as well in v2
hoch: it has no sidechain
padenot: it is a bus compressor not a channel strip compressor, effectively
ChrisL: can test with an analyser node, loud sine, check for harmonics
padenot: yes, did some tests like that last week
cwilso: saw a typo and also the
knee and the threashold, don't understand the knee param
... threashold should be to the left where the soft and hard
knees diverge
joe: we should walk through and get input to work with
cwilso: knee is additive right?
joe: lets decide first if we are going to punt
padenot: feels like cheating to me
joe: css has stuff like this all
the time
... drop from the spec, impls can have one, but spec does not
describe it
<scribe> ... new impls will not have one
cwilso: no longer convinced current behaviour is desirable. sad it is interoperable. Changing impls to match spec would change the rendefred rfesult a lot
hoch: if we punt, what happens in vnext?
ChrisL: make simple testable statements and do a much better one in v2
joe: punting gives uncertainty
for v2. If we do not mention existing node then it is net=ither
in v1 or v2, but if we do then there are two evolving
compressors, the legacy and the new
... sidechaining and expansion are clearly missing
cwilso: enough dials make the expander and compressor do averything, but its nothing like what people actually use
joe: lets make a description that is internally consistent, testable, and is in line with current behaviour
so does not necessarily conform to what people expect from a compressor
hoch: so changing knee value affects loudness?
padenot: yes
cwilso: by knee value divided by ratio
(drawings on whiteboard
cwilso: diagram in spec currently
is wrong
... can certainly make it testable
joe: it is c1 continuous
... the polynomial is the release, not the knee
hoch: the knee *has* to be centered
joe: can we start going through
paul's section and decide what we need to change
... propose we keep the loose descriptive node in our spec
(no objections)
padenot: I adresssed your initial comments
joe: need to define curve as a
target output level based on input level
... never says that
... also needs to say first order continuous
... update diagram to have threashold where curves diverge and
indicate the knee width
... internal graph, is that a helpful formalism?
rtoyg: doesn't work
<cwilso> another type: "enveloppe rate"
hoch: the gain node is gain computor, the other part needs to be the envelope follower
padenot: did not want to
respecify the delay
... 6ms hardcoded
hoch: otherwise it looks lije the
compressionprocessor is doing the compression
... so it is two render quantum delay
joe: now we have detector average and compression gain
hoch: attack is one render quantum
cwilso: is inventing a temporary class the right way to do this?
rtoyg: people are going to try to run the pseudo code and get confused
ChrisL: call them blocks not nodes.
hoch: knee param bothers me, it has no units
padenot: knee is in dB relative to threashold
joe: good to do it as a range. it
is an increment not an absolute value
... in step 5 is is product not division
padenot: right
joe: envelope rate?
padenot: is the result of
executing the steps
... env rate tells you the instantaneous slope of the curve for
this sample
... slpe between two samples
joe: ok, time derivative
ChrisL: worried by "It is allowed, for example" make it a complete list
padenot: adaptive release is a
classic thing to do, also auto release, not sure how that is
computed
... attacking, you increase compression level; releasing, you
get a negative number that subtracts from the compression
level
... step 6.4 says to add or subtract it
joe: envelope rate is not fully
spelled out
... controls how much compressor rate is changed
Add the difference between attenuation and detector average to detector average, and clamp detector average to 1.0.
joe: that is a no-op
rtoyg: exponentially smoothed
padenot: yes it is just smoothed a bit
rtoyg: if not releasing, rate is 1
joe: just say it is
smoothed
... do we need makeup gain?
padenot: it is a term of art and
in a lot of products. so result is as loud as before
... power shaped based on gain level
rtoyg: hard to test as you have only input and output, no access to internals
padenot: can sample the reduction parameter
joe: can do measurements to see
what it converges on. and how it responds to spikes to see the
attack and release curves
... soft knee by checking derivatives are close, before and
after the change section
padenot: also test the
lookahead
... can test makeup gain too
rtoyg: that is kind of hard
padenot: can test if it is applied
cwilso: this is what we did with
panner, we greatly simplified the first one which was wildly
complex
... chris's intent was to replicate a high end compressor with
few knobs
... better idea to rip out this complex compressor
... this investigation paul did is super valuable. still have
fixed lookahead, configurable attack and release
joe: will allow too much leeway
to have real interop. lets people build code now
... so should paul continue and incorporate our feedback
padenot: will do
... will work on this from 2 July so expect by 6 July
<joe> https://github.com/WebAudio/web-audio-api/issues/1193
hoch: original proposal to inst a
pair of nodes in blocking way, there is nothing blocking on
main thread
... now we do it in parallel, constuction calls back to main
thread on completion to say it is ready
... if constructor has errors we throw so it fails and your
worklet node is in an odd state. can be connected still
... main difference is step 9, que a control message
joe: message channel is also new
hoch: main concern is block or
not
... we don't block and return the reference
ChrisL: advantage of blocking?
hoch: clear failure and no dangling reference
joe: is running event described?
hoch: yes I need to explain the "running" event
Queue a task the control thread to fire "running" event to the associated AudioWorkletNode.
hoch: maybed that is in a different PR
hoch: previously we did not have
a state proporty. Now we do as they are async
... describes state of associated worklet. Joe said there is an
internal flag, active source
enum AudioWorkletProcessorState {
<scribe> "pending",
"running",
"stopped",
"error"
};
padenot: state is exposed through IDL on main thread. activesource is an internal flag, main thread or worklet
hoch: rendering thread
joe: implicit communication from AWN
padenot: sources can finish on
the rendering thread
... reflect back to main thread
joe: active source exists to
drive lifetime decisions. if true it is an internal reference,
like playing for ABSNs
... only object anyone can have a ref to
... we don't say how it happens
padenot: how we toggle the
flag
... cross thread communication, is a problem with JS memory
model
... add sentence to say queue a message
joe: think we need a local copy
padenot: needs to be a simple task in the main event loop
hoch: que the written value
joe: rendering thread copy
influences if subsequent communications happen.
... what is gthe purpose of state. construction status or also
the active source or not
padenot: need to know if
something will run or not, becausde low level atomics. Need to
know if it will terminate
... we can't rely on the context state
joe: do we want a state reflecting construct status plus a separate flag, or one combined flag
hoch: we can move active flag into rendering thread
joe: spec has ASF. unclear wrt coupling to ASF, state related to flag. 2 ways to fix. Get rid of asf, and say stte of AWN. Or, have state be pending|error|created and a separate ASF
hoch: what is difference from
state of running source
... my preference is to do that
joe: there is handwaving currently
padenot: solves this issue
joe: if me msg ASF, which copy drives GC
padenot: main thread one. GC is on main thread
hoch: found a problem when implementing, creating JS on separate machine in this thread, so someone needs to take care of GC
padenot: no cross refefrences across worklet boundary
hoch: transferable is okay
... ok so no need to mention in the spac
padenot: well defined in ecma spec
joe (types resolution into the GH issue)
joe: stopped does not mean dead
hoch: we have allthe states we need?
joe: yes
<joe> https://github.com/WebAudio/web-audio-api/issues/1089
joe: trouble with a mandated
order
... lack of access to information on canonical channel
ordering. Sometimes it is unknown
... hoch suggested a channel map
padenot: what codec gives this problem
hoch: 8 or 16 channel
padenot: ogg specifies an order
and aac, mp4, wav has wav order
... restricting to formats present on the web, which one has
this issue
... info is lost
... in firefox we always remap to smpte order else facebook
would not be able to do VR
... found two public orderings, the windows order and the smpte
order (9which is less public)
... wanted well known and widely adopted order. these 2 are the
same up to a large numbert of channels. but also want discrete
, used for 360 audio
... channels separate from speakers
... chrome, ff and safarfi all implemented non mapped
channels
... jerry asked what happens if we lose the ordering info
... like an 8 channel file
... smpte is the same as wav extensible ordering
matt: they are different for 5.1
(we compare specs, for those who bought copies)
there are changes from 10 and above
hoch: wav does not support 8.2
ChrisL: if one is free and one is not, we should pick the freely available one
padenot: aac is patent encumbered
pad (checks ffmpeg)
<rtoyg> https://www.ffmpeg.org/doxygen/3.0/group__channel__mask__c.html
padenot: (checks ffmpeg)
<padenot> https://trac.ffmpeg.org/wiki/AudioChannelManipulation
padenot: my link has the standard layout
hoch: ffmpeg follows wav, not smpte
joe: we need ordering, not flag bits
ChrisL: I want the ordering in our spec
padenot: and say it is the same order as wav extensible and ffmpeg, in an informative note
<joe> https://github.com/WebAudio/web-audio-api/issues/1135
joe: oh the PR was merged. Closing
<joe> https://github.com/WebAudio/web-audio-api/issues/1162
padenot: you have both behaviours available depending on what you want
rtoyg: spec is clear, chrome is wrong here
padenot: adapt behaviour of suspend (well defined) into close (not well defined)
rtoyg: I will send a PR
... by 1 July
This is scribe.perl Revision: 1.152 of Date: 2017/02/06 11:04:15 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00) Succeeded: s/serral/several/ Succeeded: s/cop/copy/ Succeeded: s/satde/state/ Succeeded: s/the spec/our spec/ Succeeded: s/smte/smpte/ Succeeded: s/in an appendix/in our spec/ Present: Hongchan Ray Paul ChrisW Joe Matt ChrisL Found ScribeNick: ChrisL Inferring Scribes: ChrisL WARNING: No meeting title found! You should specify the meeting title like this: <dbooth> Meeting: Weekly Baking Club Meeting Agenda: https://www.w3.org/2011/audio/wiki/F2F_June_2017 Got date from IRC log name: 20 Jun 2017 Guessing minutes URL: http://www.w3.org/2017/06/20-audio-minutes.html People with action items:[End of scribe.perl diagnostic output]