summaryrefslogtreecommitdiffstats
path: root/media/audio/audio_output_mixer.cc
Commit message (Collapse)AuthorAgeFilesLines
* Delete AudioOutputMixer.dalecurtis@chromium.org2013-02-011-248/+0
| | | | | | | | | | | | | | Not used. If we do enable browser side mixing in the future it'll be based on AudioConverter. With renderer side mixing and AudioOutputProxy, there's not a pressing need for this function. BUG=none TEST=compile Review URL: https://chromiumcodereview.appspot.com/12082111 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@180072 0039d316-1c4b-4281-b951-d872f2087c98
* Revert 142862 - Change the way we are stopping audio stream on Mac once again.kkania@chromium.org2012-06-191-16/+34
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | r142235 was not enough, we were not touching audio buffers after stop, but OS could still touch audio queue. That causes problems if we were deleting audio stream immediately after stopping, e.g. if audio mixer tried to keep audio stream opened after last logical stream stopped and then stopped/closed it. I was able to reproduce the problem locally (for whatever reason this time it worked), and after the fix it (finally) went away -- browsert_tests PPAPITest.Audio_Creation successfully runs for 300 iterations. When I revert to previos way of signaling, problem resurfaces again. Fix is to use "property listener" to listen to "is running" audio queue property, and signal "stream stopped" event only after "is running" property changes to false. Functions that do are documented in the Apple core audio documentation but not used in samples, so they are hard to find if you don't know what to look for. Also re-enabling mixer change to keep physical stream opened for some time, That should complete browser-side mixer work and fix several related bugs. BUG=102395 BUG=114701 BUG=129190 BUG=131720 TEST=No observable diffs, but crashes and seek problems should go away. Review URL: https://chromiumcodereview.appspot.com/10560038 TBR=enal@chromium.org Review URL: https://chromiumcodereview.appspot.com/10583009 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@142886 0039d316-1c4b-4281-b951-d872f2087c98
* Change the way we are stopping audio stream on Mac once again.enal@chromium.org2012-06-181-34/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | r142235 was not enough, we were not touching audio buffers after stop, but OS could still touch audio queue. That causes problems if we were deleting audio stream immediately after stopping, e.g. if audio mixer tried to keep audio stream opened after last logical stream stopped and then stopped/closed it. I was able to reproduce the problem locally (for whatever reason this time it worked), and after the fix it (finally) went away -- browsert_tests PPAPITest.Audio_Creation successfully runs for 300 iterations. When I revert to previos way of signaling, problem resurfaces again. Fix is to use "property listener" to listen to "is running" audio queue property, and signal "stream stopped" event only after "is running" property changes to false. Functions that do are documented in the Apple core audio documentation but not used in samples, so they are hard to find if you don't know what to look for. Also re-enabling mixer change to keep physical stream opened for some time, That should complete browser-side mixer work and fix several related bugs. BUG=102395 BUG=114701 BUG=129190 BUG=131720 TEST=No observable diffs, but crashes and seek problems should go away. Review URL: https://chromiumcodereview.appspot.com/10560038 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@142862 0039d316-1c4b-4281-b951-d872f2087c98
* Revert 142430 - Do not stop audio physical stream immediately after logical ↵kkania@chromium.org2012-06-151-16/+34
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-34/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-28/+34
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-34/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-16/+34
| | | | | | | | | | | | | | | | | | | | | | | | 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-34/+16
| | | | | | | | | | | | | | | | | | | 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 wrong timing when audio is muted.enal@chromium.org2012-06-041-4/+0
| | | | | | | | | BUG=131039 TEST=Added case to unit tests, and test in the bug. Review URL: https://chromiumcodereview.appspot.com/10466007 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@140405 0039d316-1c4b-4281-b951-d872f2087c98
* Change the way audio mixer gets "pending bytes" (amount of data currently ↵enal@chromium.org2012-05-011-27/+31
| | | | | | | | | | | | | | | | | | | buffered but not yet played). Underlying code expects per-logical-stream pending bytes, while all mixer gets when called for more data is pending bytes per combined stream. Fix is to keep track of * amount of data in every buffer * buffers for every logical stream and manually calculate per-logical-stream pending bytes. That is last CL in initial audio mixer implementation, after it go through mixer should be ready for full testing. Review URL: http://codereview.chromium.org/10154007 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@134675 0039d316-1c4b-4281-b951-d872f2087c98
* Remove unused parameter "stream" from all variants of OnMoreData().enal@chromium.org2012-04-241-4/+1
| | | | | | | | (Also fixing some minor lint errors...) Review URL: http://codereview.chromium.org/10184011 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@133726 0039d316-1c4b-4281-b951-d872f2087c98
* Re-land software audio mixer.enal@chromium.org2012-04-191-0/+251
| | | | | | | | | | | Code goes through old or new paths depending on the AudioParameters or command-line flag. Added unit tests. Changed suppression for http://code.google.com/p/chromium/issues/detail?id=123112 because call stack changed (class was split into 2). Review URL: http://codereview.chromium.org/9691001 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@133010 0039d316-1c4b-4281-b951-d872f2087c98
* Revert 132891 - Software audio mixer.thestig@chromium.org2012-04-191-251/+0
| | | | | | | | | | | | Code goes through old or new paths depending on the AudioParameters or command-line flag. Added unit tests. Review URL: http://codereview.chromium.org/9691001 TBR=enal@chromium.org Review URL: https://chromiumcodereview.appspot.com/10127002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@132929 0039d316-1c4b-4281-b951-d872f2087c98
* Software audio mixer.enal@chromium.org2012-04-181-0/+251
Code goes through old or new paths depending on the AudioParameters or command-line flag. Added unit tests. Review URL: http://codereview.chromium.org/9691001 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@132891 0039d316-1c4b-4281-b951-d872f2087c98
generated by cgit v1.1 at 2025-04-01 12:21:49 +0000