Bug 174494 – Report CoreAudioCaptureSource failure in case shared unit stops to work properly

• Status: RESOLVED
• Resolution: FIXED
• Component: Media

[youenn fablet]

CoreAudioCaptureSource sometimes fails working.
The capture callback is not called.
Being able to report that to the web app may be useful.

[youenn fablet]

Created attachment 315403 [details]
Patch

[Radar WebKit Bug Importer]

<rdar://problem/33309776>

[youenn fablet]

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.

[youenn fablet]

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.

[Eric Carlson]

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.

[Eric Carlson]

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

[youenn fablet]

(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.

[youenn fablet]

Created attachment 315425 [details]
Patch

[youenn fablet]

(In reply to youenn fablet from comment #8)
> Created attachment 315425 [details]
> Patch

Went with the 10 seconds then 2 seconds approach.

[youenn fablet]

Created attachment 315427 [details]
Patch

[WebKit Commit Bot]

Comment on attachment 315427 [details]
Patch

Clearing flags on attachment: 315427

Committed r219511: <http://trac.webkit.org/changeset/219511>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.