diff options
author | dalecurtis@chromium.org <dalecurtis@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2012-10-22 22:05:53 +0000 |
---|---|---|
committer | dalecurtis@chromium.org <dalecurtis@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2012-10-22 22:05:53 +0000 |
commit | 938666c23104b52c4df14792923630976cc47c65 (patch) | |
tree | d3029d63645d60a17dab6a6dc0953a8957e0b65b /device | |
parent | dd3bf8e2b94fb9fecbab0c2303521c4684cab5d0 (diff) | |
download | chromium_src-938666c23104b52c4df14792923630976cc47c65.zip chromium_src-938666c23104b52c4df14792923630976cc47c65.tar.gz chromium_src-938666c23104b52c4df14792923630976cc47c65.tar.bz2 |
Enable renderer side mixing by default for Mac and Windows.
On Windows and Mac we can use the low latency pipeline because they provide
accurate and smooth delay information. On other platforms like Linux there
are a couple issues:
- The low latency audio clock provided by ALSA (or simulated ALSA when
pulse is behind the scenes) is not smooth enough and causes jitter.
- AudioRendererImpl misuses the latency information currently with the
assumption that it's the only audio provider. Which is false when mixing
data between renderers and results in jitter.
This change also enables the low latency pipeline if audio renderer mixing is
disabled but audio output resampling is not. It's useful to have both enabled
to help troubleshoot where issues might be in the field (i.e. with the low
latency pipeline itself or specifically for renderer side mixing).
It was necessary to move the switch from content to media to ensure this check
can be made at runtime w/o a layering violation. And really most of the code
lives in media, so it makes sense for the switch to live there.
BUG=133637
TEST=Audio on mac / windows plays correctly.
Review URL: https://chromiumcodereview.appspot.com/11192068
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@163398 0039d316-1c4b-4281-b951-d872f2087c98
Diffstat (limited to 'device')
0 files changed, 0 insertions, 0 deletions