WebRTC Community Update: iOS 16, Chrome screensharing media picker & more.

daginge
daginge Moderator, Daily Alumni

Hello, and welcome to a new edition of our WebRTC Community update!

In this post, we’ll dig into the latest iOS release, as well as bugs and updates from the WebRTC community!

If you have questions, please ask in the comments!


iOS 16 / Safari 16 is released!

It’s here! iOS 16 was released last week without much fanfare, together with some interesting new dynamic islands. So far it’s looking like the most calm iOS major release in years, with bugs far and few in between. I would like to claim that the improved Beta experience and quick turnaround time from Apple on bugs during the beta phase has been a huge part of this, as well as WebRTC in general maturing on iOS after 5 years.

In terms of features there really aren’t many in terms of WebRTC. Sadly Apple hasn’t published a tag for Safari 16 yet on Github, so we are flying blind as to which commits actually made it into Safari 16, but the Technical release points to some important bugs being squashed, such as the by now infamous chipmunk effect. Jury is still out on this being fixed on iOS 16, we’ll let you know!

New Screensharing Media Picker

Chrome is currently testing a new Screensharing Media Picker, where tab selection will be the default view rather than sharing the entire screen. Our opinion is that this is a good move for privacy, but may cause some confusion if this experiment lands in Stable initially. 

Audio issues on Android 13 if AudioContext is used

An interesting bug on Android has surfaced, where if you create an AudioContext before making your first getUserMedia/startCamera call, Android might return the internal microphone even if external microphones are connected. 

In our opinion, this is unlikely to cause major issues for end users. In fact, for some it might actually provide a better experience. In addition, if you specify a specific device, this bug doesn’t happen.

However, if you think this might affect you, make sure you only create AudioContexts after the initial getUserMedia/startCamera call.

Reports of distorted audio is increasing

We have noticed that the number of reports of distorted audio, static audio, or crackling audio have increased lately. We haven’t been able to find any patterns yet, but we’ll keep you updated if any leads pop up. So far it looks like the issue might be browser-related as we have seen reports also outside the Daily context, but we’ll keep you posted once we figure out the impact.

Older Apple devices using Safari may send distorted audio after 10 minutes in a call

The above bug comes at the same time another obscure bug hits iOS 16, where audio can become distorted after 10 minutes for remote participants. Detecting this in code is currently impossible (but please correct me if you’ve found a way!), so we are left with no options. For affected devices using a headset could help solve this problem. Our opinion is that this smells a lot like echo cancellation issues, but disabling that without headphones is not recommended.

Calling getUserMedia twice in parallel can cause Chrome to crash on Android

This bug can be quite nasty if you hit it. If you are implementing your own hair check before a call, while also joining a Daily room, you could encounter an issue where two calls to getUserMedia are done at the same time, causing Chrome to crash

If you are building your own haircheck, we recommend following this excellent guide by Jess on our blog. Using that guide you should be guaranteed not to run into this issue.


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 below!

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.