iPad (8th Generation) iOS 15.6 Using https://webrtc.github.io/samples/src/content/devices/multi/ 1) Select Allow to the prompt to Access the Microphone and Camera 2) Click the red video camera in the address bar to disable the Microphone and Camera. 3) Play the audio track on the right hand side under local media files. Adjust volume on device to a medium level. Audio track should repeat in a loop. 4) Click the red video camera in the address bar to re-enable the Microphone and Camera. 5) The volume of the playing audio track increases significantly. Expected behavior: the volume should remain relatively the same when enabling or disabling the microphone & camera. Our actual use case is slightly different, but exhibits the same problem: 1) User clicks to move to the next page/section 2) Video starts auto playing in one element, while the prompt to Access the Microphone and Camera displays so we can display the camera stream in a second video element (which is muted) 3) User clicks Allow and the volume jumps up considerably. 4) User lowers the volume. All subsequent videos play at too low a volume. If the user doesn't lower the volume in step 4, the volume will return to its normal level when a new video source is loaded into the video element. Replaying the existing video without changing the source causes the audio to fluctuate/distort, like its interacting with the microphone or something. Again, changing the source on the video element seems to fix the problem.
Not sure if this is related to https://bugs.webkit.org/show_bug.cgi?id=236219
Probably a duplicate, but I'm not quite sure enough to close it as such.
When capturing microphone, we change the audio session category to PlayAndRecord. This in turns changes the system level. While this behaves as expected, we might want applications to be able to proactively state they are capturing apps so that the audio level does not change when starting to capture.
(In reply to David Mannion from comment #1) > Not sure if this is related to https://bugs.webkit.org/show_bug.cgi?id=236219 This is somehow different. bug 236129 is about microphone capture ducking other audio sources.
<rdar://problem/98772368>