- From: Raymond Toy <rtoy@google.com>
- Date: Fri, 21 May 2021 11:37:38 -0700
- To: "public-audio@w3.org Group" <public-audio@w3.org>, public-audio-comgp@w3.org
- Message-ID: <CAE3TgXH1eGCZD39n2rJWky9GqX6rpcKZ2PS8rvw5PfFyeT9SUw@mail.gmail.com>
May 21Attendees Philippe Milot, Paul Adenot, Raymond Toy, Christoph Guttandin Minutes - 16:00-16:10 UTC (9:00-9:10 am PDT): Set up - 16:10-17:45 UTC (9:10-10:45 am PDT): others <https://github.com/WebAudio/web-audio-api-v2/issues?q=is%3Aissue+is%3Aopen+-label%3Apriority-1+-label%3Apriority-2> - Issue 121: channelCount set at MediaStreamAudioDestinationNode MUST set MediaStreamTrack channelCount <https://github.com/WebAudio/web-audio-api-v2/issues/121> - Paul: I agree generally - [Agreed to do this] - Issue: 118: Raw audio recording not supported <https://github.com/WebAudio/web-audio-api-v2/issues/118> - Raymond: Agrees with Paul’s last comment. - [Paul updates issue] - Issue 111: Request to Expose AudioBuffer to DedicatedWorker <https://github.com/WebAudio/web-audio-api-v2/issues/111> - [Paul updates issue; very similar to context on worker] - Issue 110: Should 'Atomics.wait' be available in AudioWorklets associated with an OfflineAudioContext? <https://github.com/WebAudio/web-audio-api-v2/issues/110> - Paul: I say no. - Raymond: I agree. - Paul: Close this? - Raymond: I’m fine with that. - Issue 107: AnalyserNode: provide access to complex FFT result <https://github.com/WebAudio/web-audio-api-v2/issues/107> - Raymond: We could do this, but doesn’t solve the actuarial use-case. - Philippe: He has a workaround for the issue - Raymond: Yes, using WASM FFT in a worklet - Paul: Shall we close? - Raymond: Yes - Paul: I’ll add some comments about WASM being optimized - Issue 106: AudioOutputContext <https://github.com/WebAudio/web-audio-api-v2/issues/106> - Raymond: What does he want to capture? - Paul: System audio for processing - Raymond: Seems like not a good idea. - Paul: I’ll update the issue. - Issue 112: Units & examples used in DynamicsCompressorNode are ambiguous <https://github.com/WebAudio/web-audio-api-v2/issues/112> - Raymond: Looks like editorial changes to clarify text - Paul: I’ll mark it as such. - Issue 105: Add ability to pause/resume AudioBufferSourceNode <https://github.com/WebAudio/web-audio-api-v2/issues/105> - Raymond: Last comment from the telecon got a thumbs up from the poster. Does that mean he’s ok with the solutions? - Paul: playback zero works with no downsides. - Raymond: That works too. Shall we close this, saying we won’t do this? - Paul: Yeah. - Issue 101: V2 documentation logistics <https://github.com/WebAudio/web-audio-api-v2/issues/101> - Raymond: Can close this - Issue 92: Add detune AudioParam for ConstantSourceNode <https://github.com/WebAudio/web-audio-api-v2/issues/92> - Paul: Looks good for consistency. - Issue 90: No way to set loop to false at a future time for an AudioBufferSourceNode <https://github.com/WebAudio/web-audio-api-v2/issues/90> - Paul: Doesn’t seem currently possible to do what he wants to do. Since we’re improving ABSN anyway, might as well. - Raymond: Not exactly sure how to do it, but we can think of something. - Issue 88: Expose platform-level 3D audio APIs to WebAudio <https://github.com/WebAudio/web-audio-api-v2/issues/88> - Philippe: It’s about exposing 3D audio. And want to map it to the web by exposing this to the web. - Paul: What you want is much more advanced than the PannerNode? - Philippe: I don’t know. - Paul: PannerNode could have user HRTFs so 3D is possible. - Paul: Includes distance attenuation - Philippe: Can we make that optional? - Raymond: That’s easy. :-) - Paul: We can do that easily: add if statement in the implementation to skip attenuation. - Philippe: Might be ok to do PannerNode. Like no distance atten. Is ambisonics good enough? - Raymond: Too bad Hongchan isn’t here to discuss Omnitone. - Philippe; Could this be added to WebAudio natively? - Philippe: Perhaps not using OS stuff would be better and using native nodes? - [Phlippe describes how it Wyze works] - Philippe: I’ll create 2 new issues on the thing we discussed - Issue 87: Channel layout detection for the destination output device <https://github.com/WebAudio/web-audio-api-v2/issues/87> - Philippe: Would be great to extend the supported layouts. - [discussions about channel layout that I didn’t capture] - Philippe: Would like at least 7.1 and 7.1.4 (atmos) since these exist. - Philippe: Could we increase priority? - Paul: We can do that. - Issue 84: Report actual startTime of AudioScheduledSourceNodes <https://github.com/WebAudio/web-audio-api-v2/issues/84> - Raymond: Can you describe the use case Christoph? - Christoph: I asked for it to precisely schedule consecutive nodes. If I schedule the first, I need to know when it was actually started to precisely schedule the next. - Raymond: Can’t schedule it ahead of time? - Christoph: From my experience scheduling ahead of time doesn't always work. There are always some cases when the look ahead wasn't big enough. - Christoph: It could maybe be a started event with the value. - Raymond: Seems like a reasonable request. Don’t know what the API should be. - Christoph: But isn't that the concept of currentTime? Shouldn't it be the value that can be used to schedule something "now"? - Paul: It’s the time of the current render and is incremented at the end. - Christoph: Ah okay, I thought it's conceptually the time of the next frame. - Christoph: It would be nice to have a way to schedule something as fast as possible and then be able to know when it happened. - Paul: start(0) will do that, but you don’t know when that happens. - Christoph: Yes, exactly. - Paul: I’ll update the issue - Raymond: Are your buffers not super short? - Christoph: Maybe a second each. I ran for example into that problem when implementing a streaming player with the Web Audio API. - Raymond: I was asking because if the buffers are really short, you won’t get the promises or events fast enough to start the next. - Issue 83: Input only / muted AudioContext <https://github.com/WebAudio/web-audio-api-v2/issues/83> - Paul: sinkID null should work, right? - Raymond: I think so. - Issue 81: DynamicsCompressorNode release parameter range <https://github.com/WebAudio/web-audio-api-v2/issues/81> - Paul: Let’s just increase it - Raymond: Don’t know how the existing code will handle this, but seems ok to do this, spec-wise - Issue 77: Please make high resolution time available within AudioWorkletGlobalScope. <https://github.com/WebAudio/web-audio-api-v2/issues/77> - Paul: DIdn’t we already say ok? - Issue 62: Extend the `createPeriodicWave` API to accept time-domain arguments <https://github.com/WebAudio/web-audio-api-v2/issues/62> - Paul: Nothing more to add - Raymond: easy enough to add, but I agree. - Issue 55: More options when constructing an OfflineAudioContext <https://github.com/WebAudio/web-audio-api-v2/issues/55> - Paul: We already agreed to do this. - - 17:45-18:00 UTC (10:45-11:00 am PDT): Closing remarks, future plans - V1!!! - We’ll continue with our regular meetings next week, at the usual time. - Thanks to everyone for helping to make this a productive meeting.
Received on Friday, 21 May 2021 18:38:06 UTC