RESOLVED FIXED 168898
[WebRTC] Fix remote audio rendering
https://bugs.webkit.org/show_bug.cgi?id=168898
Summary [WebRTC] Fix remote audio rendering
Jer Noble
Reported 2017-02-26 22:06:15 PST
[WebRTC] Fix remote audio rendering
Attachments
Patch (45.36 KB, patch)
2017-02-26 23:43 PST, Jer Noble
eric.carlson: review+
Patch for landing (45.33 KB, patch)
2017-02-27 09:16 PST, Jer Noble
no flags
Jer Noble
Comment 1 2017-02-26 23:43:18 PST
youenn fablet
Comment 2 2017-02-27 09:06:23 PST
Comment on attachment 302825 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=302825&action=review > Source/WebCore/ChangeLog:8 > + Test: webrtc/audio-peer-connection-webaudio.html Great test! > Source/WebCore/platform/mediastream/mac/RealtimeIncomingAudioSource.cpp:95 > + m_audioSourceProvider->prepare(&m_streamFormat); OnData is called on one of webrtc threads (probably the network one). audioSourceProvider getter method will probably be called on the main thread. Shouldn't we execute this code in the main thread? > LayoutTests/webrtc/audio-peer-connection-webaudio.html:11 > + internals.useMockRTCPeerConnectionFactory("TwoRealPeerConnections"); Could you move this within the test block, just before the call to createConnections? That may help if we add future tests in this file. Btw, if one doesn't like async_test, promise_test can be used instead. One would need to return the getUserMedia promise and create a new promise inside it. The small benefit here would be the automatic handling of gum promise being rejected. Not probably worth changing the test here.
Jer Noble
Comment 3 2017-02-27 09:15:19 PST
(In reply to comment #2) > Comment on attachment 302825 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=302825&action=review > > > Source/WebCore/ChangeLog:8 > > + Test: webrtc/audio-peer-connection-webaudio.html > > Great test! > > > Source/WebCore/platform/mediastream/mac/RealtimeIncomingAudioSource.cpp:95 > > + m_audioSourceProvider->prepare(&m_streamFormat); > > OnData is called on one of webrtc threads (probably the network one). > audioSourceProvider getter method will probably be called on the main thread. > Shouldn't we execute this code in the main thread? The getter will probably be called on the WebAudio thread, but WebAudioSourceProviderAVFObjC has a lock which protects against prepare() and provideInput() being called simultaneously, so this should be fine. (The provideInput() side is a try-lock.) > > LayoutTests/webrtc/audio-peer-connection-webaudio.html:11 > > + internals.useMockRTCPeerConnectionFactory("TwoRealPeerConnections"); > > Could you move this within the test block, just before the call to > createConnections? > That may help if we add future tests in this file. Sure. > Btw, if one doesn't like async_test, promise_test can be used instead. > One would need to return the getUserMedia promise and create a new promise > inside it. > The small benefit here would be the automatic handling of gum promise being > rejected. > Not probably worth changing the test here. Yeah, if I were to re-write this test, I'd probably use the promise_test path.
Jer Noble
Comment 4 2017-02-27 09:16:27 PST
Created attachment 302844 [details] Patch for landing
WebKit Commit Bot
Comment 5 2017-02-27 10:24:41 PST
Comment on attachment 302844 [details] Patch for landing Clearing flags on attachment: 302844 Committed r213080: <http://trac.webkit.org/changeset/213080>
Note You need to log in before you can comment on or make changes to this bug.