SV_MEETING_TITLE -- 05 Dec 2012

<chrislowis> Bad connection.

<tmichel> could we start the agenda with issue about adding code for conformance requirement and testing ??

<tmichel> zami, who is here ?

<gmandyam> Giri Mandyam, Qualcomm Innovation Center, joining the call

testing

<jussi> Zakim: ??P66 is me

<chrislowis> tmichel: added some code to track requirements in the spec as per RFC keywords.

tmichel: added spec updates to hilight RFC2119 MUST MAY etc

<chrislowis> ChrisLilley: thanks!

tmichel: and then XSLT it to find the testable assertions
... won't be all the tests we need, just a subset

<scribe> scribenick: chrislilley

tmichel: did a search and replace, so there are false positives
... asked chris rodgers to clean up the result as the author knows which ones are really required

chris: will get keywords in but don't want to start from the auto search and replaced version

tmichel: just wanted to show what is possible
... plh will present some testing guidelines in two weeks

chris: ok but will take more time than we have til the next deadline

<scribe> ... continued review of them as i proceed

tmichel: use uppercase MAY for 2119 and lowercase may for general English

chris: some places the test may have to be a manual test, because it may be a high level aspect which can't be done with an automatic test

chrislowis: priority at the moment is to make testing and conformance easy for implementors

tmichel: agree we don't have a direct mapping between keywords and number of tests

chris: agree it has value

tmichel: (garbled)
... styling will not remain in the final spec, the code will but won't trigger visible styling change

chris: ok that covers everything, did not like the styling, and its better to pick out the keywords manually

ChrisLilley: good to link tested assertion styling with :target so it hilights when you link to it

<ehsan> https://github.com/alankligman/webaudio-conformance

<chrislowis> ChrisLilley: Alan.

ehsan: have checked stuff into github and will maintain it

??: looking for feedback on test and how to submit them

chris: in webkit we use an offline context. set up a rendering graph and give it a callback, which gives n audio buffer
... the javascript can check that and send a pass/fail message
... important to have that in the spec, for testing

ack: ys we need that for any sort of useful testing, not just high level API testing

chrislowis: need that to test in an implementation independent way

chris: manual tests can be error prone and time consuming
... a dozen or so manual tests is fine

ack: also want to discuss test submission process

ChrisLilley: can use incoming directories. Shepherd is a way to manage tests

tmichel: each WG does it differently

ack: want submission process as easy as possible so we get lots of submissions. Need a large number of tests to get implementor attention
... currently its not easy to see if something is in the spec or not

chrislowis: important to get tests early

ehsan: any problems with the test framework? can it be announced on the public list?

(yes)

tmichel: we should dedicate a full telcon to testing
... on 19 Dec

<ChrisWilson> https://www.w3.org/Bugs/Public/show_bug.cgi?id=19803

discuss two remaining contentious issues in the MIDI spec

mIDI fingerprint

cwilso: fingerprint does not guarantee uniqueness
... need a fallback, as windows gives no way to associate a physical midi port gets the same unique identifier
... generally the case for any hardware. each one can be further queried, can identify by manuf and type, but they can get switched
... or plugged in a different order

shepazu: if this a windows limitation or a midi one?

cwilso: its not related to the midi spec, its how the system enumerates devices

shepazu: could there be some unique ID that a device sends out?

cwilso: yes, but distinguish between devices and midi adapters. same thing over usb, but not over DIN midi
... MIDI protocol only talks about communication with endpoints
... using sysex it can be improved a bit
... don't want to reorganise the interfaces each time you start a DAW
... soec says SHOULD because we can't guarantee uniqueness
... index is simply a list of ports
... in chromeOS we have not got those problems
... think it has unique identifiers, not sure if they are portable across machines

ChrisLilley: sounds OK as a SHOULD if some platforms can't provide it

cwilso: made unique identifiers by concatenating manuf, model and index
... reasonable thing to do but can't be relied upon
... have other ways to ask about the device, maintain a MIDI port reference but they are not saveable

zz: but they would persist across a session

shepazu: can it be relied upon on other platforms

cwilso: maybe but not universally

xx: APIs can give a huge amoubt of info, like persistent tegistry information, device descriptors API
... big pool for generating a unuique ID

cwilso: need to document what happens to fallback if it fails
... session stores IDs but also do index and name storage
... so session can be restored later
... not ideal, but better than total failure
... looking for guidance, good feature but unreliable so needs well specified failure behaviour
... jussi seems to think its usefull enough right now

jussi: case where you check if you have a certain name at the same index as previously, may have enough info to create a unique ID
... create fingerprint from data plus how many devices you have with the same information

cwilso: so two interfaces of the same type show up named the same and you store MOTU1 and MOTU2 for example

jussi: yes

shepazu: keep it in, mark at risk, ask for feedback
... can drop it later
... and we can document why we dropped it, if we do

<ChrisWilson> https://www.w3.org/Bugs/Public/show_bug.cgi?id=19975

MIDI timestamps and message queues

cwilso: when restructuring, looked at making onMessage be a single message, so we dont neeed a midi message at all
... long thread, some good discussion. different is the callback represents a single midi messages rather than a bunch at once
... not that crazy, event firing overhead is ok and its how windows midi api works also
... can simplify now and add event handler for multiple messages later if needed

ChrisLilley: can timestamt two messages that form a 14-bit message?

cwilso: yes, get two callbacks for MSB and LSB, may not have same the same timestamp
... still undefined what you do if one of the messages is missing. same for sysex, osx core midi api lets you have a midi packet with a partial sysex
... usbmidi and windows midi does not give partial messages
... on js processing end its much easier to only get complete messages
... correct way is to buffer one message until the rest appears

ChrisLilley: seems like a good simplification

jussi: I agree
... no proven cases where it is better to have only multiple messages

cwilso: found some scenarios where slow processing gives a buffer issue. but it does make it easier to write basic software

jussi: yes, solve the harder problem when we have it

chrislowis: summarise these discussions in the bugs, please

cwilso: will do, and hiope to publishbefore year end
... other bug outstanding is to state everywhere we throw exceptions
... and add lots of examples

call time

telcon time

shepazu: two issues, one is that kames from intel can't join at this time, second is that this slot is taken up by two other huge groups and the bridge gets full
... so people end up unable to join
... working on more capacity, but this slot is overbooked

chrislowis: change next year, then

ChrisLilley: great to avoid the clash with CSS

shepazu: will make a poll on the new times

<scribe> ACTION: shepazu to make a call time poll [recorded in http://www.w3.org/2012/12/05-audio-minutes.html#action01]

<trackbot> Created ACTION-53 - Make a call time poll [on Doug Schepers - due 2012-12-12].

shepazu: difficult to organise a time due to global scope
... some groups alternate early and late calls, for example

<chrislowis> ChrisLilley: thanks so much for scribing, much appreciated!

<chrislowis> ChrisLilley: great job!

chris lowis will you send out the minutes?

<chrislowis> ChrisLilley: I think I can do that tomorrow, yes.

- DRAFT -

SV_MEETING_TITLE

05 Dec 2012

Attendees

Contents