Microphone access on Safari / MacOs when window is in the background - javascript

Since the last two major updates on Mac (BigSur, Monterey) i'm having this issue where Safari microhone capture via getUserMedia does only work when the Safari window is visible on the screen (1px is sufficient). Whenever Safari is moved to the background the microphone stops transmitting sound, as if it was muted by a hardware button. For the web-application this is not transparent afaik.
Is there a setting or even a documentation or blog post for this? I wasn't able to find any info on how or why this is happening (even though i can imagine why).
This behaviour is especially inconvenient for multi user web-apps using webrtc, where microphone input can be used together with screen sharing (getDisplayMedia). Users usually assume that they can be heared when sharing their entire screen, even if safari is not in the foreground / visible. It feels inconsistent to on the one hand allow screen sharing when the safari window is not visible, but on the other hand block microphone transmission.
I would be grateful for information on why this is happening and if there is a plan from apple to change this in the future.

It seems that this is actually a bug in audio context and has nothing to do with getUserMedia. In my case the microphone stream was processed through an audio context. The bug causes audio contexts to be halted, when the Safari window is moved to the background.
Here is the link to the bugtracker:
https://bugs.webkit.org/show_bug.cgi?id=231105

Related

Continue running WebApp with "Screen off/Background" on mobile devices

I am making a WebApp that uses WebSpeech API for Text to Speech.
The problem I am facing is that whenever the screen goes off or
browser window is switched, particularly on mobile devices, the speech
synthesis is just stopped. When the text to be read takes longer time,
the device screen times out, the reading progress is lost, which is
really bad UX.
The basic synthesis controller is is created by const synth=window.speechSynthesis; which is attached to window.
I have overcome with a dirty workaround of keeping the screen on by using NoSleep.js, which essentially plays a video in the background to keep the device awake.
However, I noticed that some music players can play audio when browser is minimised and even when the screen is turned off. Example: wynk.in
Is it possible to achieve the same in my case? Any inputs on how is it done in music apps? Is attaching to anything other than window going to help?
Link to my WebApp: https://yakshag.github.io/tts.html
Link to my JS Script: https://yakshag.github.io/js/tts.js
PS: I am a beginner in JavaScript :p

Audio doesn't play anymore in Safari 13 unless getUserMedia is called

I'm recording audio using getUserMedia, then allowing the user to click a button to listen to either the recording or another buffer. This has all worked fine for a year, so I don't think I'm violating any of the rules that cause AudioContext to be suspended. And, anyway, I'm testing the AudioContext to make sure it isn't suspended in my button handler.
This has all been working fine on all modern systems with many browsers. However, this is not playing the audio in Safari 13 in iOS. It will return from the promises as if it were playing audio, but nothing sounds until I call getUserMedia again.
As an experiment, I put the following line on the top of my button handler:
navigator.mediaDevices.getUserMedia({
audio: {
echoCancellation: {ideal: false},
}
});
And it works!
But, why? I'm not comfortable with that solution because I'm not sure why the browser wants that. It doesn't make sense to me that I'd have to request the microphone to play any sound.
The only clue I have is that once I do the getUserMedia I keep the recording open on Safari (I do that because Safari has a time out - when I request the mic, it pops up a dialog to the user to allow the mic. Sometimes it might take the user 90 seconds to get around to pressing "record", and if I don't leave the mic open it pops up the dialog again.)
Anyone have any idea what is going on? And, I haven't been able to find any technical write up of Safari and audio. Is there anything beyond the standard MDN?
IOS13 also broke one of our applications. It's been working fine for years. No errors are thrown and we are not violating any rules. Here is the link to my post:
Has IOS13 broken <audio> tags used as audio buffers connected to the audio context?
Even though it is a different use of the api, I believe it is related. Apple clearly broke something on this new release.
This was confirmed to be a bug in Safari 13 and was fixed in a maintenance release. We haven't heard any more reports from the field so I guess it auto updated for everyone.

Screen sharing freezes in Chrome on Mac Air with HTML5 MediaRecorder

I have developed an application which records screen, video and audio using HTML5 MediaRecorder. The entire process of recording works without any issues on Windows Machine. But If I access the same web application on Mac Air, I have a strange issue (Refer below scenario)
Recording without screen freeze
Open browser > Start recording. Open another application like word or notepad etc. Keep both the screens stacked side by side.
Recording (screen freeze)
Open browser > Start recording. Open another application like word or notepad etc. Make sure both applications are displayed in fullscreen mode.
It seems the recording works smoothly when the browser is in foreground. As soon as browser window goes in background and another application window is displayed, the video recording freezes but audio gets recorded.
Is there any configuration/setting that can be applied at Mac/Chrome level to ensure applications running in the background are not suspended from display rendering.
PS: The screen sharing permission dialog also doesn't display all the open windows in "Application Window" tab. It just displays chrome tab.
Update 1
The behavior is confirmed after few trials and errors. This is happening due to spaces. Each new application window is getting started in new spaces. Even after turning off the spaces from mission control, there is still a problem. If an application is viewed as full screen, it gets assigned to new display. Same happens with powerpoint presentation mode. Workaround is to make sure that press alt/option key while clicking on maximize button (no fullscreen / no presentation).

"Click to use Flash" button doesn't always show on Safari

I'm working on a site that uses a video recorded via the user's webcam. The recorder library is not my code, but at a high level, it tries to use HTML5 (Media Recorder API) where possible and falls back onto Flash where not. On Safari, this means Flash. Basically, I supply the library with a div where I want the recorder to appear and it inserts it there.
However, some of my users were reporting confusion on Safari (the video recorder was not showing up) and I was able to reproduce this confusing situation. With Safari 12.0 on Mac OS 10.13.6 with Adobe Flash installed and enabled in Safari:
when I navigate to the page with the video recorder, I expect to see a "Click to use Flash" button on the video recorder area. But, when I first load the page, the area is complete blank. Strangely, it appears that the button is indeed there, but just not showing:
When I click on the area where the button should be, it responds (and prompts me to enable flash)
When I open the Web Inspector tool, the button appears (you can also see the code for the Flash object here that gets inserted dynamically)
When I simply resize the window, the button appears
I don't use Safari as my regular browser, so it's not like I have a highly customized configuration. Unless I'm missing something, this feels like a bug in Safari (I filed a bug report, but they specifically say they do not respond).
I've tried some javascript tricks to "re-draw" the element (e.g. hide then show) to try and get the button to show up right away, but without any luck. Obviously I can't tell users "resize the window" or "click in the middle where there is supposed to be a button".
Any ideas what could be causing this and how to fix it?

Limitations of HTML5 Audio on iOS 4? Playlisting, background, etc

I've been evaluating HTML5 audio on iOS 4 and have been trying to understand its limitations. From what I can tell...
It is possible to play audio in the background
It is not possible to fire JavaScript events in the background upon track completion
It is possible to fire JavaScript events while the screen is off, but Safari must be in the foreground (before turning the screen off)
My goal for this current project is to create a dynamic playlist that will continue to fire events and move to the next track even while Safari is not in the foreground. Is this possible with the current way HTML5 audio works on iOS?
I am curious about how the chaining of JavaScript events works on iOS if anyone has additional information. It seems that you are allowed to queue back to back sounds, but it must happen shortly after a "human" function happens (for example, tapping an element). Anything else that tries to queue a sound outside of this human function is denied the ability to play.
Also...
Is it even possible to have events that fire to move a real iOS application to the next track? It seems as if the application is only allowed to finish its current audio stream and then it goes into an idle state. Just trying to figure out all the angles here!
This is quite an old question, so I'm not sure if you've found an answer already or not.
One thing I know is that an audio clip cannot be played via JavaScript on mobile Safari.
Autoplay audio files on an iPad with HTML5
The only way to make audio play, is through a click event. This wasn't the case on 3.x, but on 4.x it is. This is because Apple doesn't want the webapp to download audio on a 3g connection programmatically, so they force the user to initiate it.
I would think that if all of the tracks were started downloading (cached), then it may be possible. I would try forcing the user to start one track, and at the same time call .load() on all of the other tracks (in the same click handler). This will force the iOS device to start downloading the audio tracks, and you may be able to play the next track (not sure though).

Categories

Resources