Input only / muted AudioContext

[chrisguttandin]

Describe the feature
I think using the Web Audio API to drive some visualization or to only analyze the incoming audio is a very common use case. I therefore think it makes sense to allow creating an AudioContext without any output. It could reduce the energy consumption because the output device can be turned off and such an AudioContext could be allowed to start without any user interaction.

Is there a prototype?
No.

Describe the feature in more detail
I think of this feature as an equivalent to <video muted/> which allows videos to be played without requiring any user gesture.

Given that #2400 will be added to the spec which will allow to specify the output device by setting the sinkId the API for muting an AudioContext might look like this:

new AudioContext({ sinkId: null });

This is also related to WebAudio/web-audio-api-v2#82 which proposes to add a similar thing for the OfflineAudioContext.

[padenot]

Virtual F2F summary:

• Would be very useful for a variety of use-case, and result in significant battery savings (as measured on Firefox for Android and Chrome for Android)
• Not hard to implement
• { sinkId: null} might already be a way to convey the fact that the default audio output device is needed, so the exact API shape will need to change
• This is a special case of the whole "choose the output device at runtime and also at construction"

[padenot]

TPAC 2020:

• This is useful to monitor incoming audio levels in WebRTC app, or to draw visualization of a media without waking up the audio hardware, without requiring user-gesture.
• Being able to switch to a device should be gated on user-gesture (or any other policy that a UA has), but setSinkId isn't. enumerateDevice or selectAudioOutput are, but the device IDs are supposed to be stable and can be stored accross reloads, so this would allow having a running AudioContext that is not outputing to a device, and then associating it with a device, outputing sounds without consent. This also in turns could be prevented (by suspending the context if the device switch happens in a situation where an AudioContext wouldn't have started), but this feel forced.
• An AudioContext that starts without a device has to pick a sample-rate that might not be the sample-rate that the device prefers, resulting in possible sub-optimal performances in terms of latency, resilience and CPU usage.

[rtoy]

Teleconf Mar 11. Forgot to update this, but I think the conclusion is that the priority should be reduced from priority 1. Removing priority-1 label.

[padenot]

AudioWG virtual F2F:

• new AudioContext({ sinkId: "none" }); would work. We'd need to ensure "none" is not a legal value for a device id, but they are UUID in practice so this is fine.

[chrisguttandin]

I think this can be almost closed as complete now that it is possible to use new AudioContext({ sinkId: { type: "none" } }). Or would it be necessary to mention somewhere that this allows starting an AudioContext without a user gesture?

It looks like Chrome v111 which is the only browser implementing this so far still enforces the autoplay policy on a muted AudioContext.

I created a little demo which only creates a muted AudioContext and prints it's state on the screen. https://stackblitz.com/edit/js-wncv2l?file=index.js

[hoch]

2023 TPAC Audio WG Discussion:
Closing because the described issue has been resolved. To @chrisguttandin's point, I created a new issue to discuss: #2556