Local AudioTracks do not become 'ended' if audio source initialization fails |
|||||
Issue descriptionIf an error occurs during initialization of an audio input stream (such as if we hit the global limit of 16 concurrent input streams), an error is not reported up to the blink layer. This has the effect that getUserMedia calls succeed with seemingly valid audio tracks (as far as the web app is concerned), but are backed by a source that receives no audio. The audio source object (either ProcessedLocalAudioSource or LocalMediaStreamAudioSource) is furthermore cached, which means that subsequent getUserMedia calls will also succeed and be linked to the non-functional audio source. This is a problem in a situation such as: 1. The browser somehow reaches the maximum number of input sources (16). This can happen in a number of ways, but exactly how, doesn't matter for this bug. 2. A web app calls getUserMedia requesting an audio track. 3. The call succeeds but the audio source for the track, isn't backed by any audio. 4. The browser recovers from the state reached in #1, and now the microphone should be accessible. 5. The web app from #2 still can't access the microphone due to the cached audio source. The audio source furthermore does not enter an 'ended' state, which would cause it to not be cached, associated audio tracks would enter the 'ended' state and applications could get notified of this event via the onended() event. This is one of two issues I discovered today that can contribute to device errors. I'll file a second report for the other issue.
,
Jan 5 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/c57d9c242d1be6076c12838c4fc91a081b887c01 commit c57d9c242d1be6076c12838c4fc91a081b887c01 Author: tommi <tommi@chromium.org> Date: Thu Jan 05 21:28:54 2017 Fix issue with audio input streams where an error would not be reported if an initialization error occurs while creating an audio stream. BUG= 678697 CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel Review-Url: https://codereview.chromium.org/2611063003 Cr-Commit-Position: refs/heads/master@{#441758} [modify] https://crrev.com/c57d9c242d1be6076c12838c4fc91a081b887c01/media/audio/BUILD.gn [modify] https://crrev.com/c57d9c242d1be6076c12838c4fc91a081b887c01/media/audio/audio_input_device.cc [add] https://crrev.com/c57d9c242d1be6076c12838c4fc91a081b887c01/media/audio/audio_input_device_unittest.cc
,
Jan 5 2017
With the above fix, if a web page calls getUserMedia, requesting an audio source that then fails for whatever reason, the associated audio track will enter the 'ended' state as soon as the source's initialization has finished. This fixes one thing, the other part which is to fix getUserMedia to not report success until the audio sources have been verifiably successfully initialized, is on the way (will file a bug with details).
,
Jan 5 2017
Re comment #1: Yes, I'm working on fixing the gUM behavior right it is more involved so you could consider this an intermediate state. Here are the basic behaviors: Before the fix that just landed: * Open up 17 tabs that use gUM to access a local mic. All will seemingly succeed but the last tab will not get any audio. Close the first 16 tabs and the one remaining tab will still not be able to get audio from the mic even though more gUM calls are made. With the fix that just landed: * gUM on the 17th tab will succeed but the audio track on the stream will become 'ended' as soon as the source fails to initialize. Closing one of the other tabs will then furthermore allow a gUM call on the 17th tab to succeed. Next step: * Fix gUM so that local audio sources are initialized before tracks are reported as ready. Once this is done, the gUM call on the 17th page would report an error.
,
Jan 5 2017
Ah, I think I was confused and thought you were talking about HTMLMediaElement onended/onerror, but you're referring only to the media stream tracks. Sounds like a good find and fix either way :)
,
Jan 9 2017
Could you link to the bug for the next step, please? Was this bug detected by a test? If not, would it be possible to write a test that would've caught this, so we can be sure not to regress on this behavior? Thanks :)
,
Jan 9 2017
There was no test for it. The test that I added with the CL would have caught it.
,
Jan 12 2017
,
Feb 16 2017
|
|||||
►
Sign in to add a comment |
|||||
Comment 1 by dalecur...@chromium.org
, Jan 5 2017