summaryrefslogtreecommitdiffstats
path: root/media/audio/audio_output_controller_unittest.cc
Commit message (Collapse)AuthorAgeFilesLines
* Change the code to use 2 buffers on presumable good Windows boxes.enal@chromium.org2012-06-151-1/+1
| | | | | | | | | | | | | | | | | I.e. running non-Vista and having more than single core. Changed unit tests as well. (Earlier that CL was part of bugger one, changing the way audio mixer is working, but it causes problems on Mac). BUG=132009 TEST=Startup of 2nd stream should become somewhat faster. TEST=Run tests on Win7 and XP myself. Review URL: https://chromiumcodereview.appspot.com/10540034 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@142488 0039d316-1c4b-4281-b951-d872f2087c98
* Revert 142430 - Do not stop audio physical stream immediately after logical ↵kkania@chromium.org2012-06-151-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | one had stopped. Wait some time. We are still stopping/closing the stream, as (1) it is better for battery life, and (2) some people can hear active device even when it is playing silence. That increased audio startup latency, especially on Windows, because we are using 3 buffers on Windows. To fix that I changed the code to use 2 buffers on presumable good Windows boxes -- i.e. running non-Vista and having more than single core. Changed unit tests as well. That CL finishes work on browser-side audio mixer. Not sure how important it is, though -- hopefully it will provide some time while implementing renderer-side mixer. That CL also fixes bug 131720. Looks that it was caused by timing change, and starting stream earlier causes less dropped frames. (I still cannot understand why on modern system we should have even single dropped frame, and why slight timing change caused us to drop frame, but that is different question...) BUG=114701 BUG=129190 BUG=131720 BUG=132009 TEST=Should not be noticeable difference in behavior. TEST=Startup of 2nd stream should become somewhat faster. TEST=Run tests on Win7 and XP myself. Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=141770 Review URL: https://chromiumcodereview.appspot.com/10540034 TBR=enal@chromium.org Review URL: https://chromiumcodereview.appspot.com/10544183 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@142444 0039d316-1c4b-4281-b951-d872f2087c98
* Do not stop audio physical stream immediately after logical one had stopped.enal@chromium.org2012-06-151-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Wait some time. We are still stopping/closing the stream, as (1) it is better for battery life, and (2) some people can hear active device even when it is playing silence. That increased audio startup latency, especially on Windows, because we are using 3 buffers on Windows. To fix that I changed the code to use 2 buffers on presumable good Windows boxes -- i.e. running non-Vista and having more than single core. Changed unit tests as well. That CL finishes work on browser-side audio mixer. Not sure how important it is, though -- hopefully it will provide some time while implementing renderer-side mixer. That CL also fixes bug 131720. Looks that it was caused by timing change, and starting stream earlier causes less dropped frames. (I still cannot understand why on modern system we should have even single dropped frame, and why slight timing change caused us to drop frame, but that is different question...) BUG=114701 BUG=129190 BUG=131720 BUG=132009 TEST=Should not be noticeable difference in behavior. TEST=Startup of 2nd stream should become somewhat faster. TEST=Run tests on Win7 and XP myself. Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=141770 Review URL: https://chromiumcodereview.appspot.com/10540034 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@142430 0039d316-1c4b-4281-b951-d872f2087c98
* Revert 141770 - Do not stop audio physical stream immediately after logical ↵cpu@chromium.org2012-06-131-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | one had stopped. Wait some time. We are still stopping/closing the stream, as (1) it is better for battery life, and (2) some people can hear active device even when it is playing silence. That increased audio startup latency, especially on Windows, because we are using 3 buffers on Windows. To fix that I changed the code to use 2 buffers on presumable good Windows boxes -- i.e. running non-Vista and having more than single core. Changed unit tests as well. That CL finishes work on browser-side audio mixer. Not sure how important it is, though -- hopefully it will provide some time while implementing renderer-side mixer. Also moved code for crash Mac OS X into audio mixer, because problem can manifest itself if Close() called immediately after Stop(). That CL also fixes bug 131720. Looks that it was caused by timing change, and starting stream earlier causes less dropped frames. (I still cannot understand why on modern system we should have even single dropped frame, and why slight timing change caused us to drop frame, but that is different question...) BUG=129190 BUG=131720 BUG=131720 BUG=102395 TEST=Should not be noticeable difference in behavior. Run tests on Win7 and XP myself. TEST=Mac crashes on seeks should go away, too. Review URL: https://chromiumcodereview.appspot.com/10540034 TBR=enal@chromium.org Review URL: https://chromiumcodereview.appspot.com/10532116 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@141820 0039d316-1c4b-4281-b951-d872f2087c98
* Do not stop audio physical stream immediately after logical one had stopped.enal@chromium.org2012-06-121-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Wait some time. We are still stopping/closing the stream, as (1) it is better for battery life, and (2) some people can hear active device even when it is playing silence. That increased audio startup latency, especially on Windows, because we are using 3 buffers on Windows. To fix that I changed the code to use 2 buffers on presumable good Windows boxes -- i.e. running non-Vista and having more than single core. Changed unit tests as well. That CL finishes work on browser-side audio mixer. Not sure how important it is, though -- hopefully it will provide some time while implementing renderer-side mixer. Also moved code for crash Mac OS X into audio mixer, because problem can manifest itself if Close() called immediately after Stop(). That CL also fixes bug 131720. Looks that it was caused by timing change, and starting stream earlier causes less dropped frames. (I still cannot understand why on modern system we should have even single dropped frame, and why slight timing change caused us to drop frame, but that is different question...) BUG=129190 BUG=131720 BUG=131720 BUG=102395 TEST=Should not be noticeable difference in behavior. Run tests on Win7 and XP myself. TEST=Mac crashes on seeks should go away, too. Review URL: https://chromiumcodereview.appspot.com/10540034 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@141770 0039d316-1c4b-4281-b951-d872f2087c98
* Revert 141476 - Do not stop audio physical stream immediately after logical ↵sail@chromium.org2012-06-111-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | one had stopped. Wait some time. We are still stopping/closing the stream, as (1) it is better for battery life, and (2) some people can hear active device even when it is playing silence. That increased audio startup latency, especially on Windows, because we are using 3 buffers on Windows. To fix that I changed the code to use 2 buffers on presumable good Windows boxes -- i.e. running non-Vista and having more than single core. Changed unit tests as well. BUG=129190 TEST=Should not be noticeable difference in behavior. Run tests on Win7 and XP myself. Review URL: https://chromiumcodereview.appspot.com/10540034 TBR=enal@chromium.org Review URL: https://chromiumcodereview.appspot.com/10535117 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@141505 0039d316-1c4b-4281-b951-d872f2087c98
* Do not stop audio physical stream immediately after logical one had stopped.enal@chromium.org2012-06-111-1/+1
| | | | | | | | | | | | | | | | | | | Wait some time. We are still stopping/closing the stream, as (1) it is better for battery life, and (2) some people can hear active device even when it is playing silence. That increased audio startup latency, especially on Windows, because we are using 3 buffers on Windows. To fix that I changed the code to use 2 buffers on presumable good Windows boxes -- i.e. running non-Vista and having more than single core. Changed unit tests as well. BUG=129190 TEST=Should not be noticeable difference in behavior. Run tests on Win7 and XP myself. Review URL: https://chromiumcodereview.appspot.com/10540034 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@141476 0039d316-1c4b-4281-b951-d872f2087c98
* Fix dropped Play event when there's a pending pause.dalecurtis@chromium.org2012-05-091-1/+49
| | | | | | | | | | | | | | | | If the message queue is built in such a way that DoPlay()->DoPause()->DoPlay() ends up executing before the the first DoPlay()'s PollAndStartIfDataReady() runs, we'll end up dropping the play and keeping the pause. Fixed by ensuring we drop the pause if we receive a play before the pause is consumed by PollAndStartIfDataReady(). BUG=111272 TEST=unittests, test.html test case in bug. Manual seeking in buffered areas. Review URL: https://chromiumcodereview.appspot.com/10386037 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@136162 0039d316-1c4b-4281-b951-d872f2087c98
* Move media/audio files into media namespace (relanding)vrk@google.com2012-04-031-2/+2
| | | | | | | | | | BUG=115187 TEST=compiles and runs without breaking audio tag; media_unittests, content_unittests TBR=scherkus,jam Review URL: https://chromiumcodereview.appspot.com/9968054 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@130288 0039d316-1c4b-4281-b951-d872f2087c98
* Revert 130180 - Move media/audio files into media namespacevrk@google.com2012-04-021-2/+2
| | | | | | | | | | | | BUG=115187 TEST=compiles and runs without breaking audio tag; media_unittests, content_unittests Review URL: https://chromiumcodereview.appspot.com/9805001 TBR=vrk@google.com Review URL: https://chromiumcodereview.appspot.com/9965076 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@130182 0039d316-1c4b-4281-b951-d872f2087c98
* Move media/audio files into media namespacevrk@google.com2012-04-021-2/+2
| | | | | | | | | BUG=115187 TEST=compiles and runs without breaking audio tag; media_unittests, content_unittests Review URL: https://chromiumcodereview.appspot.com/9805001 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@130180 0039d316-1c4b-4281-b951-d872f2087c98
* Fix a couple of regressions that made it in before the weekend.tommi@chromium.org2012-03-261-7/+20
| | | | | | | | | | | | | | | 1) Since the 'closed' closure now runs on the calling thread and not the audio thread assertions in the callback failed. 2) output_buffer_size() was returning the input buffer size. now fixed. Also updating the output side to follow the same rule for the 'onclosed' callback. BUG=120110,120111 TEST=Run content_unittests. Review URL: http://codereview.chromium.org/9858007 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@128895 0039d316-1c4b-4281-b951-d872f2087c98
* Make AudioManager non-refcounted.tommi@chromium.org2012-02-151-6/+6
| | | | | | | | | BUG=107087 TEST=media and content unit tests Review URL: https://chromiumcodereview.appspot.com/9382040 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@122102 0039d316-1c4b-4281-b951-d872f2087c98
* Remove "high"-latency audio code pathvrk@chromium.org2012-02-031-278/+12
| | | | | | | | | | | | | | Chrome only uses the low-latency code path. This CL removes the unused, alternative "high"-latency code path. player_x11 and player_wtl use the high-latency code path, so sound is disabled from those players for now. BUG=NONE TEST=builds; content_unittests Review URL: http://codereview.chromium.org/9121062 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@120436 0039d316-1c4b-4281-b951-d872f2087c98
* Removes the AudioInputControllerThread from AudioInputController.henrika@chromium.org2012-02-031-8/+6
| | | | | | | | | | | Now runs on the audio-manager thread instead. BUG=none TEST=media_unitest and content_unittests Review URL: https://chromiumcodereview.appspot.com/9307049 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@120330 0039d316-1c4b-4281-b951-d872f2087c98
* Remove task.h and finish base::Bind() migration.ajwong@chromium.org2012-01-061-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Over 341 CLs, in ~3 months, touching 3251 unique files! Top 5 most CLs: (121) jhawkins ( 45) dcheng ( 24) achuith ( 23) csilv ( 12) tfarina ( 12) groby ~1000 files touched: (918) jhawkins 100+ files touched: (486) ajwong (385) willchan (372) dcheng (126) csilv (123) fischman (112) sergeyu 49+ files touched: (65) tfarina (57) acolwell (52) adamk (49) tzik BUG=35223 TEST=existing Review URL: http://codereview.chromium.org/9114020 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@116748 0039d316-1c4b-4281-b951-d872f2087c98
* Enable the AudioOutputController tests on all bots.tommi@chromium.org2011-12-141-31/+0
| | | | | | | | | These tests don't require audio hardware, so it should be safe to run them on the waterfall and increase our coverage. TEST=Hopefully won't break the build! Run media_unittests. Review URL: http://codereview.chromium.org/8912018 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@114412 0039d316-1c4b-4281-b951-d872f2087c98
* Remove the AudioManager singleton.tommi@chromium.org2011-12-121-22/+55
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Unit tests now instantiate their own AudioManager and can choose to use the default one or provide their own mock implementation without having to worry about conflicting with the singleton. The teardown sequence of the AudioManager and its thread has been cleaned up significantly and I don't think it has been completely tested before as the audio thread was terminated before all objects that belonged to the thread had a chance to do cleanup. The AudioManager unit tests do not use the actual audio thread, so this part seems to have been left out. In Chrome, the AudioManager instance is now owned by BrowserProcessImpl and always constructed on the UI thread. This instance is then shared in the same way that several other 'manager' type objects are shared to 'content' code, via content::ResourceContext. Audio specific classes do though receive a direct pointer to the AudioManager and are required to do proper reference counting if they need to hold onto the instance. I chose to use the ResourceContext rather than direct use of g_browser_process to avoid requiring another singleton when writing relatively simple tests that touch the AudioManager. I added a couple of safeguards to guard against future regressions: - Not more than one instance of the AudioManager should be created. - The AudioManager should not be addrefed by its own thread. This can basically become a circular reference and prevent deterministic shutdown. Reviewers: Of course you're free to review everything, but here's the breakdown in terms of the bare minimum from the standpoint of "Owners approval". I'm asking Henrik to be the main reviewer of the entire patch (sorry!). Henrik: Everything minus the below, but it would be great if you could take a look at the whole thing, specifically media/audio. Pawel: I'd like you to take a generic look at this approach. The key areas as far as the singleton itself goes are in media/audio/audio_manager[_base].* and chrome/browser/browser_process*.* Satish: content/browser/speech/* media/audio/audio_manager_base.* (new reference counting code) Andrew: content/browser/renderer_host/media/* content/renderer/media/webrtc_audio_device_unittest.cc (Owner) Avi: content/browser/renderer_host/render_process_host_impl.cc content/browser/resource_context.* William: chrome/browser/profiles/profile_io_data.cc chrome/browser/browser_process*.* Robert: This is basically a heads up. I hope that I didn't break the OpenBSD implementation, but unfortunately I have no way of knowing for sure. Shijing: Please take a look at AudioManagerLinux. I replaced the set of active streams with a simple counter. BUG=105249 TEST=content_unittests, media_unittests, browser_tests. Review URL: http://codereview.chromium.org/8818012 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@114084 0039d316-1c4b-4281-b951-d872f2087c98
* Harden audio output controller making it safe to call Pause() before Play() ↵enal@chromium.org2011-10-241-0/+45
| | | | | | | | | | | | really started. Not sure if it really fixes the crash, but crash started happening only after Play() was split into several tasks and become much slower (http://codereview.chromium.org/8229013/ change 105311). Added unit test. BUG=100650 Review URL: http://codereview.chromium.org/8371013 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@106983 0039d316-1c4b-4281-b951-d872f2087c98
* Fix DCHECK() when running test on Linux.enal@chromium.org2011-10-151-1/+1
| | | | | | | | When asking for data should return reasonable packet size. Review URL: http://codereview.chromium.org/8305017 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@105690 0039d316-1c4b-4281-b951-d872f2087c98
* Fix problem when we did not play beginning of HTML5 audio stream in low ↵enal@chromium.org2011-10-131-0/+54
| | | | | | | | | | | | | | | | | | | | | | | latency mode. Problem manifested itself on Mac because Mac code is especially sensitive to timing, and because Mac code ignores length of data in buffer -- it assumes buffer is always full, and gives to OS the entire buffer (zeroed out in that case). Fix consists of 2 parts: * When starting audio stream, send request for the data -- previously code depended on data length in the buffer being 0, so it assumed no data would be played, and data would be returned starting from 2nd request. * Implement polling "is data ready?" when starting new stream. Start physical stream only after first chunk data is available (or after ~9ms had passed, to correctly handle "old" clients not writing metadata into buffer). Polling is not continuous, it is done by task delayed by 3ms. Fix is definitely not necessary on Windows, where we have mechanism that handles "bad" timing when requesting new data, but I decided it is better to implement it on all platforms. Added test. BUG=98674 TEST=Go to http://www.jimmysparkle.me/dump/chrome-bug/ and listen to the audio stream. Review URL: http://codereview.chromium.org/8229013 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@105311 0039d316-1c4b-4281-b951-d872f2087c98
* Convert all of media/ over to the new base::{Bind,Callback} hotness.fischman@chromium.org2011-09-291-3/+4
| | | | | | | | | | | | | | | | | | | Mostly this was a rote conversion, replacing: - Pass-by-pointer CallbackN<>'s become pass-by-const-ref Callback<>'s. - scoped_ptr<CallbackN<>> members become Callback<> members. - several dedicated FooCallback typedefs became base::Closure. Because it was only used in a small handful of places and only in one place profitably, I deleted AutoCallbackRunner. Because it tickles a Bind bug I disabled mfdecoder in .gyp (about to get deleted in a scherkus CL). BUG=none TEST=media_tests, trybots Review URL: http://codereview.chromium.org/8071007 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@103376 0039d316-1c4b-4281-b951-d872f2087c98
* [Reverted due to check_deps failure]zea@chromium.org2011-07-151-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Revert 92749 - Fix problem when 'ended' event was fired before stream really ended. That caused impression that rewind does not work. With that change small JS program var a = new Audio("file:///home/enal/temp/click2/click2.wav"); var num_played = 0; a.addEventListener('canplaythrough', function() { a.play(); }); a.addEventListener('ended', function() { num_played ++; if (num_played < 10) { a.currentTime = 0; a.play(); } }); works correctly, you hear 10 clicks one after another, and it takes ~1.5 seconds to play all 10 sounds (one click is 146ms). Current Chrome plays only beginnings of the first 9 clicks and then entire 10th click -- 'ended' event fires too early, so rewind stops audio playback for all clicks but last one. With that fix you can easily create pool of audio objects -- on 'ended' event just add audio object to the pool. Fix consists of 3 parts: 1) For low-latency code path pass entire "audio state" object to the renderer process. That allows renderer take into account number of pending bytes in the buffer. 2) When using low-latency code path renderer not only fills the buffer with data, but also writes length of data into first word of the buffer. That allows host process to pass correct byte counts to renderer. 3) Renderer now keeps track of the earliest time playback can end based on the number of rendered bytes, and will not call 'ended' callback till that time. BUG=http://code.google.com/p/chromium/issues/detail?id=78992 http://codereview.chromium.org/7328030 Review URL: http://codereview.chromium.org/7328030 TBR=enal@chromium.org Review URL: http://codereview.chromium.org/7395014 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@92753 0039d316-1c4b-4281-b951-d872f2087c98
* Fix problem when 'ended' event was fired before stream really ended.enal@chromium.org2011-07-151-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | That caused impression that rewind does not work. With that change small JS program var a = new Audio("file:///home/enal/temp/click2/click2.wav"); var num_played = 0; a.addEventListener('canplaythrough', function() { a.play(); }); a.addEventListener('ended', function() { num_played ++; if (num_played < 10) { a.currentTime = 0; a.play(); } }); works correctly, you hear 10 clicks one after another, and it takes ~1.5 seconds to play all 10 sounds (one click is 146ms). Current Chrome plays only beginnings of the first 9 clicks and then entire 10th click -- 'ended' event fires too early, so rewind stops audio playback for all clicks but last one. With that fix you can easily create pool of audio objects -- on 'ended' event just add audio object to the pool. Fix consists of 3 parts: 1) For low-latency code path pass entire "audio state" object to the renderer process. That allows renderer take into account number of pending bytes in the buffer. 2) When using low-latency code path renderer not only fills the buffer with data, but also writes length of data into first word of the buffer. That allows host process to pass correct byte counts to renderer. 3) Renderer now keeps track of the earliest time playback can end based on the number of rendered bytes, and will not call 'ended' callback till that time. BUG=http://code.google.com/p/chromium/issues/detail?id=78992 http://codereview.chromium.org/7328030 Review URL: http://codereview.chromium.org/7328030 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@92749 0039d316-1c4b-4281-b951-d872f2087c98
* Description:annacc@chromium.org2011-05-161-10/+10
| | | | | | | | | | | | | | | | | This patch gets the channel layout for surround sound channel order from ffmpeg and stores it so that chromium will be able to re-order the channels for various sound cards and OSes later. - AudioParameters gets a new field (channel_layout). - channel_layout.h stores an enum that we will use in chromium for channel values. - ffmpeg_common.h gets a new method for mapping the channel layout received from ffmpeg to an internal chromium enum value. BUG=None (though storing the channel order should help us solve some other bugs soon) TEST=media_unittests Review URL: http://codereview.chromium.org/6930039 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@85541 0039d316-1c4b-4281-b951-d872f2087c98
* Revert 74590 - Disable AudioOutputControllerTest.CreateAndClose since it ↵sergeyu@chromium.org2011-02-121-5/+0
| | | | | | | | | | | | | | crashes on Windows in release. BUG=72718 TEST=none Review URL: http://codereview.chromium.org/6489032 TBR=maruel@chromium.org Review URL: http://codereview.chromium.org/6513007 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@74729 0039d316-1c4b-4281-b951-d872f2087c98
* Disable AudioOutputControllerTest.CreateAndClose since it crashes on Windows ↵maruel@chromium.org2011-02-111-0/+5
| | | | | | | | | | | in release. BUG=72718 TEST=none Review URL: http://codereview.chromium.org/6489032 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@74590 0039d316-1c4b-4281-b951-d872f2087c98
* Move CancellationFlag and WaitableEvent to the synchronization subdirectory.brettw@chromium.org2011-01-021-1/+1
| | | | | | | | TEST=it compiles BUG=none Review URL: http://codereview.chromium.org/5977010 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@70369 0039d316-1c4b-4281-b951-d872f2087c98
* Simplified AudioOutputStream interface.sergeyu@chromium.org2010-11-111-19/+15
| | | | | | | | | | | | | 1. Removed packet_size parameter from Open(). 2. Removed OnClose() from the callback. Now the callback is guaranteed to be called only between Start() and Stop(). 3. Added samples_per_packet in the AudioParameters struct. BUG=39825 TEST=Unittests Review URL: http://codereview.chromium.org/4661001 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@65766 0039d316-1c4b-4281-b951-d872f2087c98
* Add AudioBuffersState struct. Use it for audio synchronization.sergeyu@chromium.org2010-09-291-37/+51
| | | | | | | | | | | | | The new AudioBuffersState contains current state of the audio buffers. This object is passed all the way from the device to the audio renderer. Audio renderer uses this information to synchronize audio. BUG=52196,49110 TEST=see repro steps for 51637 and 52196. Review URL: http://codereview.chromium.org/3444017 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@60891 0039d316-1c4b-4281-b951-d872f2087c98
* Make AudioOutputController.Close() truly asynchronous.sergeyu@chromium.org2010-09-171-16/+29
| | | | | | | | | | | | | Added closed_task parameter in this method. This parameter is used to notify the caller when the stream is actually closed. Callbacks may be called until closed_task is executed. BUG=55755 TEST=Unittests, audio still works, doesn't crash Review URL: http://codereview.chromium.org/3415007 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@59869 0039d316-1c4b-4281-b951-d872f2087c98
* Revert 59600 - Make AudioOutputController.Close() truly asynchronous.sergeyu@chromium.org2010-09-161-29/+16
| | | | | | | | | | | | | | | | Added closed_task parameter in this method. This parameter is used to notify the caller when the stream is actually closed. Callbacks may be called until closed_task is executed. BUG=55755 TEST=Unittests, audio still works, doesn't crash Review URL: http://codereview.chromium.org/3415007 TBR=sergeyu@chromium.org Review URL: http://codereview.chromium.org/3425008 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@59601 0039d316-1c4b-4281-b951-d872f2087c98
* Make AudioOutputController.Close() truly asynchronous.sergeyu@chromium.org2010-09-161-16/+29
| | | | | | | | | | | | | Added closed_task parameter in this method. This parameter is used to notify the caller when the stream is actually closed. Callbacks may be called until closed_task is executed. BUG=55755 TEST=Unittests, audio still works, doesn't crash Review URL: http://codereview.chromium.org/3415007 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@59600 0039d316-1c4b-4281-b951-d872f2087c98
* Add AudioParameters struct. Use it everywhere.sergeyu@chromium.org2010-08-311-19/+19
| | | | | | | | | BUG=None TEST=unittests Review URL: http://codereview.chromium.org/3226012 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@58097 0039d316-1c4b-4281-b951-d872f2087c98
* FBTF: Remove unneeded headers from base/ (part 7)thestig@chromium.org2010-08-271-0/+1
| | | | | | | | BUG=none TEST=none Review URL: http://codereview.chromium.org/3176026 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@57737 0039d316-1c4b-4281-b951-d872f2087c98
* Share one thread between all AudioOutputControllers instead of creating one ↵sergeyu@chromium.org2010-08-251-10/+33
| | | | | | | | | | | per stream. TEST=unittests BUG=39825 Review URL: http://codereview.chromium.org/3185022 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@57392 0039d316-1c4b-4281-b951-d872f2087c98
* Revert 57254 - Share one thread between all AudioOutputControllers instead ↵scherkus@chromium.org2010-08-241-33/+10
| | | | | | | | | | | | | | of creating one per stream. TEST=unittests BUG=39825 Review URL: http://codereview.chromium.org/3185022 TBR=sergeyu@chromium.org Review URL: http://codereview.chromium.org/3192017 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@57256 0039d316-1c4b-4281-b951-d872f2087c98
* Share one thread between all AudioOutputControllers instead of creating one ↵sergeyu@chromium.org2010-08-241-10/+33
| | | | | | | | | | | per stream. TEST=unittests BUG=39825 Review URL: http://codereview.chromium.org/3185022 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@57254 0039d316-1c4b-4281-b951-d872f2087c98
* base: rename Environment::HasEnv to Environment::HasVar.tfarina@chromium.org2010-08-041-1/+1
| | | | | | | | | | | | This is the part 2 of this series. More two comming. Splitting this into small parts, so it is more easy to review and reduce the size of the CL. BUG=None TEST=trybots Review URL: http://codereview.chromium.org/3035050 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@54996 0039d316-1c4b-4281-b951-d872f2087c98
* base: Rename EnvVarGetter to Environment.tfarina@chromium.org2010-08-031-2/+2
| | | | | | | | | | | | | | | Now EnvVarGetter do much more than getting environment variables. Per suggestion from Pawel in http://codereview.chromium.org/3043018/. BUG=None TEST=trybots Signed-off-by: Thiago Farina <tfarina@chromium.org> Review URL: http://codereview.chromium.org/3052034 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@54696 0039d316-1c4b-4281-b951-d872f2087c98
* Audio pause and seek betterhclam@chromium.org2010-07-151-15/+63
| | | | | | | | | | | | | BUG=39885 Pause for audio is now in effect in less than 200ms. Seek for audio is also much better as we play also very short amount after seek. Review URL: http://codereview.chromium.org/2931014 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@52560 0039d316-1c4b-4281-b951-d872f2087c98
* Rename a header and some methods to make way for subsequent audio recording ↵satish@chromium.org2010-07-121-7/+7
| | | | | | | | | | | | | additions. Renaming audio_output.h to audio_io.h as future patches will add audio recording code to this file. Also renamed a couple of methods to make it clear that these are for audio playback/output and similar methods will be added for audio capture/recording soon. BUG=none TEST=no change in functionality. Review URL: http://codereview.chromium.org/2962006 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@52125 0039d316-1c4b-4281-b951-d872f2087c98
* Renamed AudioController to AudioOutputController.satish@chromium.org2010-07-091-0/+237
This is in preparation to add an AudioInputController for audio recording in subsequent changes. BUG=none TEST=no functional change Review URL: http://codereview.chromium.org/2964005 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@52015 0039d316-1c4b-4281-b951-d872f2087c98
generated by cgit v1.1 at 2025-02-07 09:51:34 +0000