Thanks for the review, Yoav. My responses are inline: On Sun, Nov 14, 2021 at 10:48 PM Yoav Weiss <yoavwe...@chromium.org> wrote:
> > > On Fri, Nov 12, 2021 at 5:33 PM 'Ajay Rahatekar' via blink-dev < > blink-dev@chromium.org> wrote: > >> Contact emails >> >> hongc...@chromium.org, ajayrahate...@google.com >> >> Explainer >> >> N/A - the specification (W3C Recommendation) is already published. >> > > Regardless, could you add a few sentences explaining what use cases the > feature targets and how developers are expected to use it? > This feature can be useful when you need to synchronize a video stream (or any kind of visual generated by the system) and an audio stream produced by Web Audio API. For example, WebCodecs can be used to decode a MediaStream into raw video and audio data, and then an app can apply processing only on audio data via Web Audio API. This will break the original synchronization, but this can be fixed by taking the hardware audio latency into account. > > >> >> Specification >> >> https://www.w3.org/TR/webaudio/#dom-audiocontext-outputlatency >> >> Summary >> >> AudioContext.outputLatency property is the estimation in seconds of audio >> output latency. >> >> Technically, this is the interval between the time the UA requests the >> host system to play a buffer and the time at which the first sample in the >> buffer is actually processed by the audio output device. For devices such >> as speakers or headphones that produce an acoustic signal, this latter time >> refers to the time when a sample’s sound is produced. >> >> >> Blink component >> >> Blink>WebAudio >> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EWebAudio> >> >> TAG review >> >> Completed: Web Audio API specification is W3C Recommendation. >> > > Link to the TAG review? > https://github.com/w3ctag/design-reviews/issues/212 This was a blanket review for the entire API surface. No issues were raised against the `outputLatency` property. > > >> >> TAG review status >> >> Completed: Web Audio API specification is W3C Recommendation. >> >> Risks >> >> There is a risk of the feature being used for fingerprinting. However >> outputLatency >> is the buffer size of the platform-provided audio callback, so the value is >> inherently platform-specific. That said, the majority of the platform audio >> buffer size is widely known. (MacOS = 128 frames, Windows = 10ms, Android = >> 96 frames, etc) >> >> This feature does not expose more than what you can query/infer from the >> UA string. >> > > Would that exposure map cleanly to UA-Platform > <https://wicg.github.io/ua-client-hints/#sec-ch-ua-platform>, which is > considered low-entropy and exposed by default? Or would it add more than > that? > > /cc +Mike Taylor <miketa...@chromium.org> > I'll do some more investigation and follow up. > >> Interoperability and Compatibility >> >> Gecko: Shipped/Shipping >> > > Link? > https://bugzilla.mozilla.org/show_bug.cgi?id=1324552 > > >> >> WebKit: No signal >> > > Have we reached out? https://bit.ly/blink-signals > We have not reached out, and did not see any comments in the spec discussion. > > >> >> Web developers: Positive ( >> https://github.com/WebAudio/web-audio-api/issues/12) >> >> Other signals: A WebCodecs demo application needs this feature. >> >> >> Is this feature fully tested by web-platform-tests >> <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md> >> ? >> >> No - this property represents a platform-provided output latency value of >> a selected audio device. It does not work properly without an actual audio >> device. >> > > I'm guessing it is tested using browser tests or unit tests without an > audio device, right? > Have y'all filed bugs against WPT to enable testing it similarly? > Currently we only have an IDL test: https://wpt.fyi/results/webaudio/idlharness.https.window.html?label=experimental&label=master&aligned No. We have not filed a bug for the new type of testing. I am not aware if we have that kind of testing infrastructure on WPT. Please correct me if I am mistaken. > > >> Flag name >> >> N/A >> >> Requires code in //chrome? >> >> False >> >> Tracking bug >> >> http://crbug.com/785409 >> >> Launch bug >> >> http://crbug.com/1258109 >> >> Estimated milestones >> >> 98 >> >> >> Link to entry on the Chrome Platform Status >> >> https://chromestatus.com/feature/5682265146261504 >> >> This intent message was generated by Chrome Platform Status >> <https://www.chromestatus.com/>. >> >> >> -- >> Ajay Rahatekar | Technical Program Manager | ajayrahate...@google.com | >> 650-797-1279 <(650)%20650-797-1279> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "blink-dev" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to blink-dev+unsubscr...@chromium.org. >> To view this discussion on the web visit >> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAHB%2BDAgeEo86rN4TrL4n8DutRczgXAogTwYLTo%2BPZco84aMq%3Dg%40mail.gmail.com >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAHB%2BDAgeEo86rN4TrL4n8DutRczgXAogTwYLTo%2BPZco84aMq%3Dg%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> > -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGJqXNv9r4hew4pknp-7iLHjP5hUY2mh1EkrHLFaeQaBzQf5VA%40mail.gmail.com.
