Tech Update: Bluetooth & MacOS, Safari autoplay, Webkit commits, PowerPoint sharing

daginge
daginge Dailynista
edited August 2022 in Tech Updates 📢

👋 Hello!  In this post, we review the following updates that have the potential to impact WebRTC applications:

  • 🎚️ Auto gain control causing issue for people with certain bluetooth headsets on MacOS
  • ▶️ The saga of Safari and autoplay in WebRTC continues
  • Safari/Webkit commits can finally be traced back to iOS/MacOS releases in Github
  • 💻 Sharing full screen Powerpoint presentations on MacOS is fixed (maybe)

If you have questions, please ask in the comments!


🎚️ Auto gain control causing issue for people with certain bluetooth headsets on MacOS

For some users with bluetooth headsets that have the capability to hardware mute, we are seeing issues across MacOS, where auto gain control, a method of automatically adjusting input volume, causes users not to be heard.

This can typically be observed by end users in a scenario where their microphone works, but they are quiet for some time. Auto gain control may then adjust input volume all the way down on MacOS, which causes MacOS to send a mute signal to the bluetooth headset, which hardware mutes. In some cases, an audible alert is sent to the user, but this might not happen. The end result is that the user can no longer be heard when they try to talk again, as the bluetooth headset itself is now muted.

Unfortunately there are no easy ways to detect this issue. The best course of action is to allow the option to disable auto gain control in advanced settings, and ask users if they contact you with this issue if they are using a bluetooth headset, and to try disabling auto gain control next time.

In Daily, you can disable this behaviour by passing “autoGainControl: false” in userMediaAudioConstraints.

Chrome reports that this is a known issue, and will be fixed in M107. They also suggest some advanced workarounds for users affected. As far as we know, the same issue affects all browsers on MacOS, and we expect other browser vendors to follow suit.


▶️ The saga of Safari and autoplay in WebRTC continues

Over the years, we have seen multiple cases of the now infamous autoplay policy cause issues for WebRTC. For end users, this would cause audio to be muted when it shouldn’t. From WebRTC’s side of things, audio data is transferred from sender to receiver, but cannot be played on the receiver side because of autoplay. This has caused a lot of hard to debug issues as everything appears to be normal from WebRTC’s side of things, but actually aren’t.

While autoplay restrictions should be disabled when capturing a microphone, this isn’t always the case, and recently, Safari has pushed some fixes to autoplay we expect to land in the initial release of iOS 16.

  • Safari 149 introduces an autoplay fix that correctly handles autoplay if a video element is added when the page is in an interrupted state.
  • A not yet released fix that will correctly play the video when the srcObject was added while the element was hidden (display: none, or not added to DOM). Until this fix is released, it’s a good idea to verify that the video element is visible before adding the srcObject.

As a general rule, we recommend tracking errors from the video and audio element.play() in something like Sentry or Bugsnag, or use Daily Prebuilt which handles these cases for you.


Safari/Webkit commits can finally be traced back to iOS/MacOS releases in Github

For years we had no way of telling what fixes/changes were included between each Safari release, which was a source of frustration especially for WebRTC engineers as we couldn’t track when a bug we reported was actually released. 

I’m happy to report this is no longer the case, as with Webkit’s release on Github, we can now diff changes between two releases quite easily. While the commits are a bit hard to read currently, it’s possible to extract full release logs for commits to WebKit between major releases of iOS and MacOS.

If you use Daily, we’ll keep up to date on all these releases for you, and note the most important ones for you here in the community. However, we mention it anyway as you might be tracking other bugs or features in Safari, and now have an easy way to check what’s actually being shipped.


💻 Sharing full screen Powerpoint presentations on MacOS is fixed (maybe)

Previously, if your end users tried to share a Powerpoint presentation in full screen, the editor view would remain shared and the slides wouldn’t update as the presentation went along, which made sharing presentations difficult.

A fix has landed in Chrome, but the fix relies on detecting the presentation mode window, which might not always work, or at the very least be flaky to unexpected updates to Powerpoint. Nevertheless, we can consider this long standing bug fixed for now, which has been with us since screen sharing landed in Chrome!

This tech update is based on information from WebRTC Insights, a biweekly newsletter that provides information on things happening in the WebRTC ecosystem. Learn more about WebRTC Insights.


We hope these updates are useful for you! Is there anything in particular you would like to see us talk about next time, or do you have any questions? Let us know in the comments below!

Comments

  • karl
    karl Dailynista
    edited September 2022

    Great post, @daginge!

    Re: the autoplay bug in Safari, have you figured out any kind of automated testing framework or approach for keeping tabs on it (apologies if this is in your WebrtcHacks post--I've bookmarked that to read later)? When Safari 15 came out last year, I found weird combinations of things on both iOS and macOS (like setting the muted and poster attributes on a <video> element for showing the local camera on a WebRTC call). But I resorted to manually checking my little suite of pages, https://karlstolley.github.io/safari-15-autoplay/, with each Safari Preview and Safari 15 point-release.

  • daginge
    daginge Dailynista

    Thank you!

    In Confrere we most often tested on iOS which I never found a good test strategy on. Instead we followed the betas and did manual QA to hunt bugs, which worked quite well.

    Robot testing iOS devices would be game changing I think!

  • karl
    karl Dailynista

    @daginge very cool. macOS Safari has begun to play somewhat nicer with the WebDriver API. I'm making an item on my almost-goofing-off to-do list to see the state of things on iOS, including Appium's support for iOS via its remote debugger: https://appium.io/docs/en/drivers/safari/