Add safety when the .src attribute of an <audio> or <video> element is changed and it's used with t…

Add safety when the .src attribute of an <audio> or <video> element is changed and it's used with the Web Audio API

When this happens, the underlying WebMediaPlayer is changed, with the old one destroyed and the new one created.
We need to take care to synchronize this destruction of the old WebMediaPlayer.

Part of this change involves making sure WebMediaPlayerClientImpl::AudioSourceProviderImpl::wrap(0)
calls WebAudioSourceProvider::setClient(0) for the old WebAudioSourceProvider.

We also add locking in the WebMediaPlayerClientImpl::AudioSourceProviderImpl methods.

BUG=239897
R=abarth@chromium.org, dalecurtis@chromium.org, kbr@chromium.org

Committed: https://src.chromium.org/viewvc/blink?view=rev&revision=150330

[acolwell GONE FROM CHROMIUM, 2013-05-13 22:58:54]

A couple quick questions. The lock is needed because one of those three methods
are called from a different thread? What are the threads involved here?

[Ken Russell (switch to Gerrit), 2013-05-13 23:42:50]

LGTM

[Chris Rogers, 2013-05-13 23:47:02]

On 2013/05/13 22:58:54, acolwell wrote:
> A couple quick questions. The lock is needed because one of those three
methods
> are called from a different thread? What are the threads involved here?

Yes, exactly.  The provideInput() method is called from the real-time audio
thread.  So we want to make sure that changing the WebAudioSourceProvider is
synchronized there.

[Chris Rogers, 2013-05-13 23:48:25]

jamesr: OWNERS rubber-stamp please?

[DaleCurtis, 2013-05-13 23:48:33]

lgtm

[abarth-chromium, 2013-05-14 18:52:23]

Mutex....  ok.  LGTM

[Chris Rogers, 2013-05-14 19:03:09]

Committed patchset #3 manually as r150330 (presubmit successful).