While Bluetooth headset is connected, sounds tends to be interrupted when playing movie of news site using Chrome application.
Reported by
smcs...@gmail.com,
Sep 27 2016
|
|||||||||||
Issue descriptionExample URL: http://www.bbc.com Steps to reproduce the problem: [Precondition] 1. "Low latency" is unsupported or remove /system/etc/permissions/android.hardware.audio.low_latency.xml 2. Connect Bluetooth to the testing device. [Step] 1. Display top page of Yahoo Japan by using Chrome browser. 2. Select "Movie" from the tab at the top and play any news movie you like. What is the expected behavior? The movie should be played properly without sound interruption. What went wrong? Sounds from movie tend to be choppy. Did this work before? N/A Is it a problem with Flash or HTML5? N/A Does this work in other browsers? Yes Chrome version: 53.0.2785.116 Channel: stable OS Version: Flash Version: here's issue which introduces choppy sound on playing movie news provided from ANN, NNN,JNN on Yahoo Japan or ones on http://www.bbc.com. This issue is observed only on products which "doesn't" support "Low latency". https://source.android.com/compatibility/android-cdd.html#5_6_audio_latency This is because the issue is only in the case where IsAudioLowLatencySupported() returns "false". https://chromium.googlesource.com/chromium/src/media/+/master/audio/android/audio_manager_android.cc#403 We confirmed this issue can be observed with product below by removing /system/etc/permissions/android.hardware.audio.low_latency.xml. Nexus5 (hammerhead) MMB29V Note:This issue is observed only with Chrome version 52 or later.
,
Sep 27 2016
,
Sep 27 2016
On Android, IO>Bluetooth is only responsible for low energy and even then it's only used by web bluetooth. I don't think it's a problem on IO>Bluetooth's side.
,
Sep 27 2016
Will take a look. Can repro with the removal step: 09-27 16:48:02.170 4130 4204 E chromium: [ERROR:audio_manager_android.cc(396)] Low latency support? 0 09-27 16:48:02.171 4130 4204 E chromium: [ERROR:audio_manager_android.cc(417)] Recommending buffer size of : 11160, (AudioTrack says: 11160, LowLatency says: 240) We're using a massive buffer here. If I force that buffer size I can reproduce with 3.5mm headphones too -- so possibly some media stack issue. Looking now.
,
Sep 27 2016
,
Sep 28 2016
This is the same root cause as issue issue 624780, but for non-MSE playbacks. I can reproduce this problem even on desktop with huge buffer sizes. The issue is two fold: 1. Our decoded buffer queue is sized too small (9600) frames, so we only partially fill requests. 2. Our logic to increase the queue capacity for under fill does not kick in, it only kicks in when no data is written. It should instead kick in for any underflow. Though we shouldn't pause in this case. I'll put together a fix and test for both these cases shortly.
,
Sep 28 2016
Should be issue 621863 that I meant to reference.
,
Sep 28 2016
Should be issue 621863 that I meant to reference. https://codereview.chromium.org/2375713003 fixes it locally.
,
Sep 29 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/95d0b149bbb2ec028a24d833ddb5351912f40a93 commit 95d0b149bbb2ec028a24d833ddb5351912f40a93 Author: dalecurtis <dalecurtis@chromium.org> Date: Thu Sep 29 00:13:08 2016 Fix initial buffer sizes and improve partial underflow support. On devices with massive buffer sizes, src= playback will often use a size too small to satisfy the OS request. So we end up only filling most of it, but end up with enough data such that the next call does not cause an underflow. The fixes are two fold: 1. Use a better initial size when possible. 2. Increase queue capacity anytime we have a partial fill. BUG= 650601 TEST=new unittests. --audio-buffer-size=11160 doesn't glitch. Review-Url: https://codereview.chromium.org/2375713003 Cr-Commit-Position: refs/heads/master@{#421691} [modify] https://crrev.com/95d0b149bbb2ec028a24d833ddb5351912f40a93/media/renderers/audio_renderer_impl.cc [modify] https://crrev.com/95d0b149bbb2ec028a24d833ddb5351912f40a93/media/renderers/audio_renderer_impl_unittest.cc
,
Sep 29 2016
,
Sep 29 2016
Your change meets the bar and is auto-approved for M54 (branch: 2840)
,
Sep 29 2016
Your change meets the bar and is auto-approved for M54 (branch: 2840)
,
Sep 29 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/e8271e28d949967b994dc99f608e742f64c8b33b commit e8271e28d949967b994dc99f608e742f64c8b33b Author: Dale Curtis <dalecurtis@chromium.org> Date: Thu Sep 29 22:55:06 2016 Merge M54: "Fix initial buffer sizes and improve partial underflow support." On devices with massive buffer sizes, src= playback will often use a size too small to satisfy the OS request. So we end up only filling most of it, but end up with enough data such that the next call does not cause an underflow. The fixes are two fold: 1. Use a better initial size when possible. 2. Increase queue capacity anytime we have a partial fill. BUG= 650601 TEST=new unittests. --audio-buffer-size=11160 doesn't glitch. Review-Url: https://codereview.chromium.org/2375713003 Cr-Commit-Position: refs/heads/master@{#421691} (cherry picked from commit 95d0b149bbb2ec028a24d833ddb5351912f40a93) Review URL: https://codereview.chromium.org/2382093002 . Cr-Commit-Position: refs/branch-heads/2840@{#591} Cr-Branched-From: 1ae106dbab4bddd85132d5b75c670794311f4c57-refs/heads/master@{#414607} [modify] https://crrev.com/e8271e28d949967b994dc99f608e742f64c8b33b/media/renderers/audio_renderer_impl.cc [modify] https://crrev.com/e8271e28d949967b994dc99f608e742f64c8b33b/media/renderers/audio_renderer_impl_unittest.cc
,
Sep 29 2016
Your change meets the bar and is auto-approved for M54 (branch: 2840)
,
Sep 29 2016
,
Oct 27 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/e8271e28d949967b994dc99f608e742f64c8b33b commit e8271e28d949967b994dc99f608e742f64c8b33b Author: Dale Curtis <dalecurtis@chromium.org> Date: Thu Sep 29 22:55:06 2016 Merge M54: "Fix initial buffer sizes and improve partial underflow support." On devices with massive buffer sizes, src= playback will often use a size too small to satisfy the OS request. So we end up only filling most of it, but end up with enough data such that the next call does not cause an underflow. The fixes are two fold: 1. Use a better initial size when possible. 2. Increase queue capacity anytime we have a partial fill. BUG= 650601 TEST=new unittests. --audio-buffer-size=11160 doesn't glitch. Review-Url: https://codereview.chromium.org/2375713003 Cr-Commit-Position: refs/heads/master@{#421691} (cherry picked from commit 95d0b149bbb2ec028a24d833ddb5351912f40a93) Review URL: https://codereview.chromium.org/2382093002 . Cr-Commit-Position: refs/branch-heads/2840@{#591} Cr-Branched-From: 1ae106dbab4bddd85132d5b75c670794311f4c57-refs/heads/master@{#414607} [modify] https://crrev.com/e8271e28d949967b994dc99f608e742f64c8b33b/media/renderers/audio_renderer_impl.cc [modify] https://crrev.com/e8271e28d949967b994dc99f608e742f64c8b33b/media/renderers/audio_renderer_impl_unittest.cc |
|||||||||||
►
Sign in to add a comment |
|||||||||||
Comment 1 by smcs...@gmail.com
, Sep 27 2016