summaryrefslogtreecommitdiffstats
path: root/content/renderer/media/webrtc_local_audio_renderer.cc
Commit message (Collapse)AuthorAgeFilesLines
* A lot of plumbing to get render_frame_id to ↵jam@chromium.org2014-01-211-2/+6
| | | | | | | | | | | PrerenderManager::OnCreatingAudioStream. The goal is that PrerenderTracker (almost the last caller of the deprecated GetAssociatedRenderFrame) will keep track of RenderFrame IDs instead of RenderView IDs. BUG=304341 R=miu@chromium.org, nasko@chromium.org Review URL: https://codereview.chromium.org/106913004 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@246045 0039d316-1c4b-4281-b951-d872f2087c98
* Add generic interfaces for the sinks of the media stream audio track to get ↵xians@chromium.org2013-12-041-27/+11
| | | | | | | | | | the audio data, and this patch also adds interfaces of AddToAudioTrack and RemoveFromAudioTrack to connect the sink to the audio track. BUG=322547 Review URL: https://codereview.chromium.org/90743004 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@238503 0039d316-1c4b-4281-b951-d872f2087c98
* Move the SetCaptureFormat to the capture audio thread.xians@chromium.org2013-11-221-105/+144
| | | | | | | | | | | | | | | | | | | | Before this CL, the thread model of our capture class is that they will be updated with the format in the main render thread by SetCaptureFormat() and getting the audio callback in the capture audio thread. And this complicates our code since it is required that the audio format in the data callback in the capture audio thread has to be the same as the cached format we get from the main render thread. This CL simplies the thread model by moving the SetCaptureFormat() to the capture audio thread, so the format change callback will be in the same thread as the data callback. This CL fixed the problems of https://codereview.chromium.org/76293004/ (crash when the webrtcLocalSourceProvider has not been getting the format callback before the data callback) https://codereview.chromium.org/59273005/ (WebRtcLocalAudioRenderer might get a SetCaptureFormat() after Start(), in such case we should start the sink_ in WebRtcLocalAudioRenderer to adapt to the new format) TBR=joi@chromium.org BUG=320808 TEST=content_unittests Review URL: https://codereview.chromium.org/83133002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@236765 0039d316-1c4b-4281-b951-d872f2087c98
* Revert 236556 "Move the SetCaptureFormat to the capture audio th..."xians@chromium.org2013-11-211-144/+105
| | | | | | | | | | | | | | | | | | | | | | | | | | | > Move the SetCaptureFormat to the capture audio thread. > > Before this CL, the thread model of our capture class is that they will be updated with the format in the main render thread by SetCaptureFormat() and getting the audio callback in the capture audio thread. > And this complicates our code since it is required that the audio format in the data callback in the capture audio thread has to be the same as the cached format we get from the main render thread. > > This CL simplies the thread model by moving the SetCaptureFormat() to the capture audio thread, so the format change callback will be in the same thread as the data callback. > > > This CL fixed the problems of https://codereview.chromium.org/76293004/ > (crash when the webrtcLocalSourceProvider has not been getting the format callback before the data callback) > https://codereview.chromium.org/59273005/ > (WebRtcLocalAudioRenderer might get a SetCaptureFormat() after Start(), in such case we should start the sink_ in WebRtcLocalAudioRenderer to adapt to the new format) > > > BUG=320808 > TEST=content_unittests > > Review URL: https://codereview.chromium.org/77803004 TBR=xians@chromium.org Review URL: https://codereview.chromium.org/81493002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@236574 0039d316-1c4b-4281-b951-d872f2087c98
* Move the SetCaptureFormat to the capture audio thread.xians@chromium.org2013-11-211-105/+144
| | | | | | | | | | | | | | | | | | | | | Before this CL, the thread model of our capture class is that they will be updated with the format in the main render thread by SetCaptureFormat() and getting the audio callback in the capture audio thread. And this complicates our code since it is required that the audio format in the data callback in the capture audio thread has to be the same as the cached format we get from the main render thread. This CL simplies the thread model by moving the SetCaptureFormat() to the capture audio thread, so the format change callback will be in the same thread as the data callback. This CL fixed the problems of https://codereview.chromium.org/76293004/ (crash when the webrtcLocalSourceProvider has not been getting the format callback before the data callback) https://codereview.chromium.org/59273005/ (WebRtcLocalAudioRenderer might get a SetCaptureFormat() after Start(), in such case we should start the sink_ in WebRtcLocalAudioRenderer to adapt to the new format) BUG=320808 TEST=content_unittests Review URL: https://codereview.chromium.org/77803004 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@236556 0039d316-1c4b-4281-b951-d872f2087c98
* Do not copy and read data when the volume of the local renderer is 0.xians@chromium.org2013-09-241-10/+51
| | | | | | | | | | | This saves one interleave and two memcpy, which might be helpful for Clank. TEST=verify http://webrtc.googlecode.com/svn/trunk/samples/js/demos/html/pc1.html works R=henrika@chromium.org, jar@chromium.org Review URL: https://codereview.chromium.org/24262004 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@224990 0039d316-1c4b-4281-b951-d872f2087c98
* Implicit audio output device selection for getUserMedia.tommi@chromium.org2013-09-101-11/+11
| | | | | | | | | | | | | When a non-default input device is selected, do a best-effort selection of a matching output device. This is used to switch output of media stream audio tracks to the output device that matches the currently open capture device (microphone). An typical example is to support switching to USB headsets when in a audio/video call. This does not affect the audio output of non-webrtc related audio elements and only happens when there's exactly 1 active audio capture device in the page. BUG=276894 Review URL: https://chromiumcodereview.appspot.com/23731007 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@222187 0039d316-1c4b-4281-b951-d872f2087c98
* Adding key press detection in the browser process.jiayl@chromium.org2013-08-151-7/+8
| | | | | | | | | | | | | | | | | It works like this on the browser side: A new object UserInputMonitor is created on BrowserMainLoop and passed to AudioInputRendererHost to pass to AudioInputController. AudioInputController::DoRecord calls UserInputMonitor::AddKeyStrokeListener --> UserInputMonitor listens to system key events (only implemented on Linux) --> AudioInputController::OnKeyPressed is called and sets key_pressed_ --> When AudioInputController::OnData called, it writes key_pressed_ to shared memory along with the audio data buffer. On the renderer side a new param "key_pressed" is added through the code path of passing the flag to the webrtc voice engine. This CL includes all these changes except the implementation of UserInputMonitor for Windows and Mac. The impl of UserInputMonitor is mostly copied from remoting/host/local_input_monitor_linux.cc BUG= Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=217768 Review URL: https://chromiumcodereview.appspot.com/21183002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@217844 0039d316-1c4b-4281-b951-d872f2087c98
* Revert 217768 "Adding key press detection in the browser process."phoglund@chromium.org2013-08-151-8/+7
| | | | | | | | | | | | | | | | | | | | > Adding key press detection in the browser process. > It works like this on the browser side: > A new object KeyPressMonitor is created on BrowserMainLoop and passed to AudioInputRendererHost to pass to AudioInputController. > AudioInputController::DoRecord calls KeyPressMonitor::AddKeyPressListener --> KeyPressMonitor listens to system key events through UserInputMonitor(only implemented on Linux) --> AudioInputController::OnKeyPressed is called and sets key_pressed_ --> When AudioInputController::OnData called, it writes key_pressed_ to shared memory along with the audio data buffer. > On the renderer side a new param "key_pressed" is added through the code path of passing the flag to the webrtc voice engine. > This CL includes all these changes except the implementation of UserInputMonitor for Windows and Mac. The impl of UserInputMonitor is mostly copied from remoting/host/local_input_monitor_linux.cc > > > BUG= > > Review URL: https://chromiumcodereview.appspot.com/21183002 TBR=jiayl@chromium.org Review URL: https://codereview.chromium.org/22871007 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@217774 0039d316-1c4b-4281-b951-d872f2087c98
* Adding key press detection in the browser process.jiayl@chromium.org2013-08-151-7/+8
| | | | | | | | | | | | | | | It works like this on the browser side: A new object KeyPressMonitor is created on BrowserMainLoop and passed to AudioInputRendererHost to pass to AudioInputController. AudioInputController::DoRecord calls KeyPressMonitor::AddKeyPressListener --> KeyPressMonitor listens to system key events through UserInputMonitor(only implemented on Linux) --> AudioInputController::OnKeyPressed is called and sets key_pressed_ --> When AudioInputController::OnData called, it writes key_pressed_ to shared memory along with the audio data buffer. On the renderer side a new param "key_pressed" is added through the code path of passing the flag to the webrtc voice engine. This CL includes all these changes except the implementation of UserInputMonitor for Windows and Mac. The impl of UserInputMonitor is mostly copied from remoting/host/local_input_monitor_linux.cc BUG= Review URL: https://chromiumcodereview.appspot.com/21183002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@217768 0039d316-1c4b-4281-b951-d872f2087c98
* Support multiple sources for media stream AudioTrack.xians@chromium.org2013-08-071-3/+8
| | | | | | | | | | | | | | The current media stream AudioTrack only supports one source even there are different media streams, either microphone or webaudio. But from the spec, different media streams can have different sources, and we need to support such cases in order to playout file while doing recording microphone data. And we should also be able to send the audio tracks via the same(different) peerconnection(s). This patch implements this feature in chrome. BUG=262117,247027 TEST=content_unittests --gtest_filter="*MediaStream*, *WebRtc*" Review URL: https://chromiumcodereview.appspot.com/19541004 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@216162 0039d316-1c4b-4281-b951-d872f2087c98
* Update includes of message_loop_proxy.brettw@chromium.org2013-06-101-1/+1
| | | | | | | | | | | This keeps the forwarding header, just updates all current callers. BUG= R=avi@chromium.org Review URL: https://codereview.chromium.org/16514006 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@205306 0039d316-1c4b-4281-b951-d872f2087c98
* Use native buffer size preferred by hardware for local audio rendering on ↵wjia@chromium.org2013-06-051-1/+17
| | | | | | | | | | | | | Android The usage of native buffer size allows low latency playback. BUG=243506 R=henrika@chromium.org, xians@chromium.org Review URL: https://codereview.chromium.org/15795005 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@204290 0039d316-1c4b-4281-b951-d872f2087c98
* Update content/ to use scoped_refptr<T>::get() rather than implicit ↵rsleevi@chromium.org2013-06-021-7/+7
| | | | | | | | | | | | | "operator T*" Linux fixes BUG=110610 TBR=darin Review URL: https://chromiumcodereview.appspot.com/16294003 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@203624 0039d316-1c4b-4281-b951-d872f2087c98
* Fixing the webrtc local audio renderer timer between Stop() and Start().xians@chromium.org2013-05-271-4/+4
| | | | | | | | | | | | | After calling Stop(), the timer should just stop. BUG=244192 TEST= https://webrtc.googlecode.com/svn/trunk/samples/js/demos/html/local-audio-rendering.html Calling Start/Stop, the timer used to start/stop counting. Review URL: https://chromiumcodereview.appspot.com/16045004 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@202419 0039d316-1c4b-4281-b951-d872f2087c98
* Remove extra memcpys from AudioPullFifo.dalecurtis@chromium.org2013-05-231-0/+1
| | | | | | | | | | | | | | | | | | Due to AudioPullFifo always clearing the |fifo_| before reading another block from |read_cb_| we can actually remove the AudioFifo object in favor of a plain AudioBus. Speedup is ~17% over the old version per AudioConverter benchmark using --audio-converter-iterations=500000: Old: 430.04ms New: 355.44ms BUG=none TEST=media_unittests Review URL: https://chromiumcodereview.appspot.com/15394003 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@201662 0039d316-1c4b-4281-b951-d872f2087c98
* Reland 196894 - First step to add audio track support to local stream. xians@chromium.org2013-04-301-55/+21
| | | | | | | | | | | | | | | | | First step to add audio track support to local stream. This patch builds up a correct structure for the local audio track, and added a correct chromium audio track implementation to local media stream. This patch does not change the current functionalities and behaviour of local media stream, it is more like a refactoring on the structure. TBR=henrika@chromium.org BUG=164813 TEST=content_unittests --gtest_filter="*WebRtcLocalAudio*" apprtc.appspot.com and webrtc.googlecode.com/svn/trunk/samples/js/demos/html/local-audio-rendering.html Review URL: https://chromiumcodereview.appspot.com/14644005 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@197383 0039d316-1c4b-4281-b951-d872f2087c98
* Revert 197349 "Reland 196894 - First step to add audio track sup..."xians@chromium.org2013-04-301-21/+55
| | | | | | | | | | | | | | | | | | | | | | | > Reland 196894 - First step to add audio track support to local stream. > > First step to add audio track support to local stream. > This patch builds up a correct structure for the local audio track, and added a correct chromium audio track implementation to local media stream. > > This patch does not change the current functionalities and behaviour of local media stream, it is more like a refactoring on the structure. > > TBR=tommi@chromium.org > > BUG=164813 > TEST=content_unittests --gtest_filter="*WebRtcLocalAudio*" > apprtc.appspot.com and webrtc.googlecode.com/svn/trunk/samples/js/demos/html/local-audio-rendering.html > > Review URL: https://codereview.chromium.org/14640006 TBR=xians@chromium.org Review URL: https://codereview.chromium.org/14641007 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@197350 0039d316-1c4b-4281-b951-d872f2087c98
* Reland 196894 - First step to add audio track support to local stream.xians@chromium.org2013-04-301-55/+21
| | | | | | | | | | | | | | | | | First step to add audio track support to local stream. This patch builds up a correct structure for the local audio track, and added a correct chromium audio track implementation to local media stream. This patch does not change the current functionalities and behaviour of local media stream, it is more like a refactoring on the structure. TBR=tommi@chromium.org BUG=164813 TEST=content_unittests --gtest_filter="*WebRtcLocalAudio*" apprtc.appspot.com and webrtc.googlecode.com/svn/trunk/samples/js/demos/html/local-audio-rendering.html Review URL: https://codereview.chromium.org/14640006 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@197349 0039d316-1c4b-4281-b951-d872f2087c98
* Revert 197063 "Reland 196894 - First step to add audio track sup..."miket@chromium.org2013-04-291-21/+55
| | | | | | | | | | | | | | | | | | | | | | | > Reland 196894 - First step to add audio track support to local stream. > > First step to add audio track support to local stream. > This patch builds up a correct structure for the local audio track, and added a correct chromium audio track implementation to local media stream. > > This patch does not change the current functionalities and behaviour of local media stream, it is more like a refactoring on the structure. > > TBR=tommi@chromium.org > > BUG=164813 > TEST=content_unittests --gtest_filter="*WebRtcLocalAudio*" > apprtc.appspot.com and webrtc.googlecode.com/svn/trunk/samples/js/demos/html/local-audio-rendering.html > > Review URL: https://codereview.chromium.org/14359019 TBR=xians@chromium.org Review URL: https://codereview.chromium.org/14198012 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@197080 0039d316-1c4b-4281-b951-d872f2087c98
* Reland 196894 - First step to add audio track support to local stream.xians@chromium.org2013-04-291-55/+21
| | | | | | | | | | | | | | | | | First step to add audio track support to local stream. This patch builds up a correct structure for the local audio track, and added a correct chromium audio track implementation to local media stream. This patch does not change the current functionalities and behaviour of local media stream, it is more like a refactoring on the structure. TBR=tommi@chromium.org BUG=164813 TEST=content_unittests --gtest_filter="*WebRtcLocalAudio*" apprtc.appspot.com and webrtc.googlecode.com/svn/trunk/samples/js/demos/html/local-audio-rendering.html Review URL: https://codereview.chromium.org/14359019 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@197063 0039d316-1c4b-4281-b951-d872f2087c98
* Revert 196894 "First step to add audio track support to local st..."miu@chromium.org2013-04-271-21/+55
| | | | | | | | | | | | | | | | | | | > First step to add audio track support to local stream. > This patch builds up a correct structure for the local audio track, and added a correct chromium audio track implementation to local media stream. > > This patch does not change the current functionalities and behaviour of local media stream, it is more like a refactoring on the structure. > > BUG=164813 > TEST=content_unittests --gtest_filter="*WebRtcLocalAudio*" > apprtc.appspot.com and webrtc.googlecode.com/svn/trunk/samples/js/demos/html/local-audio-rendering.html > > Review URL: https://chromiumcodereview.appspot.com/13601012 TBR=xians@chromium.org Review URL: https://codereview.chromium.org/14307020 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@196900 0039d316-1c4b-4281-b951-d872f2087c98
* First step to add audio track support to local stream.xians@chromium.org2013-04-271-55/+21
| | | | | | | | | | | | | | This patch builds up a correct structure for the local audio track, and added a correct chromium audio track implementation to local media stream. This patch does not change the current functionalities and behaviour of local media stream, it is more like a refactoring on the structure. BUG=164813 TEST=content_unittests --gtest_filter="*WebRtcLocalAudio*" apprtc.appspot.com and webrtc.googlecode.com/svn/trunk/samples/js/demos/html/local-audio-rendering.html Review URL: https://chromiumcodereview.appspot.com/13601012 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@196894 0039d316-1c4b-4281-b951-d872f2087c98
* Merge AssociateStreamWithProducer message into CreateStream message for both ↵miu@chromium.org2013-04-171-3/+2
| | | | | | | | | | | | | | | | | | | | | audio output and input. Also: 1. Removed RendererAudioOutputDevice class, since it's no longer necessary to manage asynchronously associating a render view with a stream. 2. Clean-ups: Applied several changes/bug fixes to bring the audio input classes/impls up-to-date w.r.t. the audio output classes/impls. Filed bug 179597 for follow-up. 3. Added missing plumbing for associating audio input devices created by WebRtcAudioCapturer to render views. 4. Updated unit tests. BUG=166779 TEST=media_unittests, content_unittests, TSAN, chrome/test/functional/webrtc_*.py, and manual testing described in http://codereview.chromium.org/11359196/ Review URL: https://codereview.chromium.org/12383016 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@194711 0039d316-1c4b-4281-b951-d872f2087c98
* Avoids deadlock in WebRtcLocalAudioRenderer.henrika@chromium.org2013-03-181-6/+10
| | | | | | | | | BUG=208580 TEST=apprtc.com in loopback Review URL: https://chromiumcodereview.appspot.com/12769010 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@188718 0039d316-1c4b-4281-b951-d872f2087c98
* Removes WebRtcAudioCapturerSink::OnCaptureDeviceStopped.henrika@chromium.org2013-03-151-13/+0
| | | | | | | | | | | | | Given https://chromiumcodereview.appspot.com/12646009, we do lo longer have to use a callback to be informed about when stop() has been called on a media stream. This patch is a pure cleanup patch. BUG=none TEST=Several different WebRTC demos and content_unittests. Review URL: https://chromiumcodereview.appspot.com/12732008 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@188396 0039d316-1c4b-4281-b951-d872f2087c98
* Fixes WebRTC crash caused by calling RemoveCapturerSink() while capturing.henrika@chromium.org2013-03-141-4/+0
| | | | | | | | | BUG=none TEST=apprtc.appspot.com/?debug=loopback Review URL: https://codereview.chromium.org/12841004 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@188061 0039d316-1c4b-4281-b951-d872f2087c98
* Adds support of local audio streams for more than one media player.henrika@chromium.org2013-03-111-142/+147
| | | | | | | | | | | | | | | | | | | Main goal is to allow the user to use a local stream as source for more than one audio element. Adding the stream to one extra element will result in an increased output volume and the possibility to tune the volume on each element. If two elements are used, both elements must be muted to silence the audio. The design is now more clear since more work is done in the local renderer and not divided between the capturer (which used to own the FIFO) and the local renderer. The capturer only dispatches the recorded audio out to its sinks and they deal with the rest. - Removes auto-mute on local media streams when rendered by a media player. - Moves local FIFO from WebRtcAudioCapturer to WebRtcLocalAudioRenderer. - Now allows multiple WebRtcLocalAudioRenderer objects where each instance creates its own output stream. - Adds support for the enabled attribute on the MediaStreamTrack object. BUG=none TEST=All existing WebRTC demos and a new test at: https://www.corp.google.com/~henrika/webrtc/multi_local_rendering.html TBR=wjia@chromium.org Review URL: https://codereview.chromium.org/12599002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@187252 0039d316-1c4b-4281-b951-d872f2087c98
* Revert 187073crogers@google.com2013-03-091-7/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This re-lands 187048 BUG=none TEST=none TBR=ccameron@chromium.org > Revert 187048 > based on > http://build.chromium.org/p/chromium.win/builders/Win%20Aura%20Tests%20%282%29/builds/1968 > > > Enable the "Web Audio Input" feature by default. > > > > We now get the proper audio input device identifier passed into WebKit and back into chromium > > to be able to determine if the correct device will be used that the user gave permission to > > access in getUserMedia(). > > > > See related WebKit work: > > https://bugs.webkit.org/show_bug.cgi?id=90110 > > https://bugs.webkit.org/show_bug.cgi?id=93756 > > https://bugs.webkit.org/show_bug.cgi?id=101815 > > https://bugs.webkit.org/show_bug.cgi?id=106490 > > https://bugs.webkit.org/show_bug.cgi?id=106816 > > https://bugs.webkit.org/show_bug.cgi?id=109494 > > https://bugs.webkit.org/show_bug.cgi?id=110796 > > > > and chromium work: > > https://codereview.chromium.org/10830268/ > > https://codereview.chromium.org/10916105/ > > https://codereview.chromium.org/10909185/ > > https://codereview.chromium.org/10959068 > > https://codereview.chromium.org/11418125/ > > https://codereview.chromium.org/11827040/ > > https://codereview.chromium.org/11878032/ > > https://codereview.chromium.org/12218106/ > > https://codereview.chromium.org/12335072/ > > > > BUG=145092 > > TEST=none > > manual tests: > > http://chromium.googlecode.com/svn/trunk/samples/audio/visualizer-live.html > > http://dashersw.github.com/pedalboard.js/demo/ > > Review URL: https://codereview.chromium.org/12383064 > > TBR=crogers@google.com > Review URL: https://codereview.chromium.org/12649007 TBR=ccameron@chromium.org Review URL: https://codereview.chromium.org/12743002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@187095 0039d316-1c4b-4281-b951-d872f2087c98
* Revert 187048ccameron@chromium.org2013-03-081-6/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | based on http://build.chromium.org/p/chromium.win/builders/Win%20Aura%20Tests%20%282%29/builds/1968 > Enable the "Web Audio Input" feature by default. > > We now get the proper audio input device identifier passed into WebKit and back into chromium > to be able to determine if the correct device will be used that the user gave permission to > access in getUserMedia(). > > See related WebKit work: > https://bugs.webkit.org/show_bug.cgi?id=90110 > https://bugs.webkit.org/show_bug.cgi?id=93756 > https://bugs.webkit.org/show_bug.cgi?id=101815 > https://bugs.webkit.org/show_bug.cgi?id=106490 > https://bugs.webkit.org/show_bug.cgi?id=106816 > https://bugs.webkit.org/show_bug.cgi?id=109494 > https://bugs.webkit.org/show_bug.cgi?id=110796 > > and chromium work: > https://codereview.chromium.org/10830268/ > https://codereview.chromium.org/10916105/ > https://codereview.chromium.org/10909185/ > https://codereview.chromium.org/10959068 > https://codereview.chromium.org/11418125/ > https://codereview.chromium.org/11827040/ > https://codereview.chromium.org/11878032/ > https://codereview.chromium.org/12218106/ > https://codereview.chromium.org/12335072/ > > BUG=145092 > TEST=none > manual tests: > http://chromium.googlecode.com/svn/trunk/samples/audio/visualizer-live.html > http://dashersw.github.com/pedalboard.js/demo/ > Review URL: https://codereview.chromium.org/12383064 TBR=crogers@google.com Review URL: https://codereview.chromium.org/12649007 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@187073 0039d316-1c4b-4281-b951-d872f2087c98
* Enable the "Web Audio Input" feature by default.crogers@google.com2013-03-081-7/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We now get the proper audio input device identifier passed into WebKit and back into chromium to be able to determine if the correct device will be used that the user gave permission to access in getUserMedia(). See related WebKit work: https://bugs.webkit.org/show_bug.cgi?id=90110 https://bugs.webkit.org/show_bug.cgi?id=93756 https://bugs.webkit.org/show_bug.cgi?id=101815 https://bugs.webkit.org/show_bug.cgi?id=106490 https://bugs.webkit.org/show_bug.cgi?id=106816 https://bugs.webkit.org/show_bug.cgi?id=109494 https://bugs.webkit.org/show_bug.cgi?id=110796 and chromium work: https://codereview.chromium.org/10830268/ https://codereview.chromium.org/10916105/ https://codereview.chromium.org/10909185/ https://codereview.chromium.org/10959068 https://codereview.chromium.org/11418125/ https://codereview.chromium.org/11827040/ https://codereview.chromium.org/11878032/ https://codereview.chromium.org/12218106/ https://codereview.chromium.org/12335072/ BUG=145092 TEST=none manual tests: http://chromium.googlecode.com/svn/trunk/samples/audio/visualizer-live.html http://dashersw.github.com/pedalboard.js/demo/ Review URL: https://codereview.chromium.org/12383064 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@187048 0039d316-1c4b-4281-b951-d872f2087c98
* Possible solution to synchronization problems in webrtc audio capturer.phoglund@chromium.org2013-02-131-1/+1
| | | | | | | | | | | | | | Re-land of https://codereview.chromium.org/12220063/. This will hold on to a reference to the buffer while the buffer is being used by WebRTC. I also tried to fix the places where synchronization was missing (mostly for the params_ instance). BUG=173987 TBR=tommi@chromium.org Review URL: https://chromiumcodereview.appspot.com/12261003 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@182227 0039d316-1c4b-4281-b951-d872f2087c98
* Revert 181929rdsmith@chromium.org2013-02-121-1/+1
| | | | | | | | | | | | | | | | | | > Possible solution to synchronization problems in webrtc audio capturer. > > This will hold on to a reference to the buffer while the buffer is being used by WebRTC. I also tried to fix the places where synchronization was missing (mostly for the params_ instance). > > Let me know if you want an offline explanation! > > BUG=173987 > TESTED=content_unittests on win and linux, chrome + apprtc on win and linux, release-built chrome with asan on original crashing test page. > > Review URL: https://codereview.chromium.org/12220063 TBR=phoglund@chromium.org Review URL: https://codereview.chromium.org/12207127 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@181932 0039d316-1c4b-4281-b951-d872f2087c98
* Possible solution to synchronization problems in webrtc audio capturer.phoglund@chromium.org2013-02-121-1/+1
| | | | | | | | | | | | | This will hold on to a reference to the buffer while the buffer is being used by WebRTC. I also tried to fix the places where synchronization was missing (mostly for the params_ instance). Let me know if you want an offline explanation! BUG=173987 TESTED=content_unittests on win and linux, chrome + apprtc on win and linux, release-built chrome with asan on original crashing test page. Review URL: https://codereview.chromium.org/12220063 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@181929 0039d316-1c4b-4281-b951-d872f2087c98
* Adds support of rendering a local media stream for audio using HTML5 audio tag.henrika@chromium.org2012-12-141-0/+270
Overview: ========= This patch ensures that a user can add a local media stream to an audio/video element and render the captured audio locally (in loopback). Details: ======== Our current architecture is a bit hairy but I've done my best to add the new code in a structured way. I have an issue in crbug assigned to myself to refactor the code in this area since we really must improve and make it less complex to work with. One more client now implements the webkit_media::MediaStreamAudioRenderer and this client is called WebRtcLocalAudioRenderer (WLAR). The WLAR is created by the WebMediaPlayer when a local media stream is generated and this will ensure that the controls for a media element becomes visible. The main action takes place in WebRtcLocalAudioRenderer::Start() where I have gathered all the main stuff. This method is the best starting point for understanding the new data flow. A reference to an existing WebRtcAudioCapturer (WAC) (owned by the WebRTC ADM) is given to the WLAR at construction. Calling Start => - WLAR connects itself to the WAC using the WAC pointer from construction - render audio parameter are copied from the capture side (since output does resampling etc.) - creates and inits a new AudioOutputDevice (AOD) - starts the capturer and the new AOD Media flow: ----------- Data is recorded and fed to the WAC which knows that it is in "loopback mode". The WAC then stores recorded data in a FIFO. The WLAR consumes audio from the FIFO when the AOD needs data to render. The WLAR reads data from the FIFO using a callback. Testing procedure: ================== Main testing was done using a new WebRCT demo at https://www.corp.google.com/~henrika/webrtc/gum4.html. I also tried all other demos at https://webrtc-demos.appspot.com/ and the htp://apprtc.appspot.com demo. For all cases, debug filters were used to track things like calling sequences etc. BUG=157142 Review URL: https://codereview.chromium.org/11450029 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@173164 0039d316-1c4b-4281-b951-d872f2087c98
generated by cgit v1.1 at 2025-03-28 03:02:10 +0000