CoreAudioCaptureSource sometimes fails working. The capture callback is not called. Being able to report that to the web app may be useful.
Created attachment 315403 [details] Patch
<rdar://problem/33309776>
Patch allows triggering an owned event on a capture audio track that fails. On such case, the web application will be able to react by making another call to getUserMedia which will create a new shared unit without any user prompt. Then, the web app can use RTCPeerConnection.replaceTrack to send the audio content without any renegotiation.
Comment on attachment 315403 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=315403&action=review > Source/WebCore/platform/mediastream/RealtimeMediaSource.cpp:192 > + m_didCaptureFailed = true; Nit: "did capture failed" isn't right so maybe "m_captureFailed" or "m_captureDidFail"? > Source/WebCore/platform/mediastream/RealtimeMediaSource.h:146 > + bool didCaptureFailed() const { return m_didCaptureFailed; } Ditto.
Comment on attachment 315403 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=315403&action=review > Source/WebCore/platform/mediastream/mac/CoreAudioCaptureSource.cpp:600 > + m_verifyCapturingTimer.startRepeating(1_s); Why one second, this seems really short? FWIW, it looks like Chrome checks every five seconds and ends the track after 12 seconds without a callback: https://codereview.chromium.org/2899413004/diff/40001/media/audio/audio_input_device.cc
(In reply to Eric Carlson from comment #6) > Comment on attachment 315403 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=315403&action=review > > > Source/WebCore/platform/mediastream/mac/CoreAudioCaptureSource.cpp:600 > > + m_verifyCapturingTimer.startRepeating(1_s); > > Why one second, this seems really short? FWIW, it looks like Chrome checks > every five seconds and ends the track after 12 seconds without a callback: > https://codereview.chromium.org/2899413004/diff/40001/media/audio/ > audio_input_device.cc 1_s might be too short indeed as audio start-up might be long. I'll go with 5 seconds even if 5s without audio is quite long. We could also start with something like 10s after start/resume and lower it to something like 2 seconds after that.
Created attachment 315425 [details] Patch
(In reply to youenn fablet from comment #8) > Created attachment 315425 [details] > Patch Went with the 10 seconds then 2 seconds approach.
Created attachment 315427 [details] Patch
Comment on attachment 315427 [details] Patch Clearing flags on attachment: 315427 Committed r219511: <http://trac.webkit.org/changeset/219511>
All reviewed patches have been landed. Closing bug.