Restore larger output buffer size when output stream requiring smaller size goes away |
||||
Issue descriptionWhen an input stream is opened, we decrease the input buffer size if the new stream requires that. We never increase (restore) the buffer size when a stream goes away. We need to do that for the new mixing strategy.
,
Apr 12 2016
Given that I am currently working on an input related issue I would like to avoid making additional changes until it has been resolved.
,
Apr 12 2016
To clarify, output side only first.
,
Apr 18 2016
,
Apr 19 2016
Some early implementation notes. Today, some devices can be shared between input and output, e.g. USB devices. It means that both sides are represented by the same ID. I will not do any work for these devices initially since it adds a complex dependency between input and output sides. I.e., trying to restore a buffer size for output will also affect input and don't want to go there at this early stage. The most important case will be built-in mic + built-in speaker and that will be covered in the initial implementation.
,
Apr 21 2016
BTW--Not sure if this is relevant, but if you're making changes to WebRtcAudioCapturer, please be aware of this WIP: https://codereview.chromium.org/1834323002/ In this change, I've eliminated the re-opening of the audio source since it's known at creation time whether high- or low- latency audio is required. Also, there was an e-mail thread a few weeks back (IIRC, you were cc'ed), where some use cases *require* high latency audio to minimize CPU/power consumption; and the latest from that was to use the MediaStreamTrack "latency" constraint as input to the calculation for buffer sizes (e.g., >500ms latency would mean we should use a larger buffer size, <=500ms would mean to use the 10ms buffer size).
,
Apr 22 2016
All changes are in the browser level only and nothing affects input/capture side. I have seen the "require high latency" discussion but not been involved in the details. It is not clear to me how such a constraint would work in practice since any stream asking for a higher latency would still have to use the lowest required native I/O buffer size that is required by other streams using the same device. Hence, a perceived larger latency would only result in a real CPU gain if no other streams were active. Mac does not allow you to run parallel streams at different I/O buffer sizes unless they use separate audio devices.
,
Apr 29 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/2f3180327f0c71452bb38e853c048c43945047b7 commit 2f3180327f0c71452bb38e853c048c43945047b7 Author: henrika <henrika@chromium.org> Date: Fri Apr 29 13:55:55 2016 Restores a larger output buffer size when output stream requiring smaller size is closed if no input stream is currently using the same audio device. BUG= 602587 TEST=Manual tests and extra debug logging using a wide mix of audio applications (audio tag, WebAudio and WebRTC). Review-Url: https://codereview.chromium.org/1903753002 Cr-Commit-Position: refs/heads/master@{#390638} [modify] https://crrev.com/2f3180327f0c71452bb38e853c048c43945047b7/media/audio/mac/audio_auhal_mac.cc [modify] https://crrev.com/2f3180327f0c71452bb38e853c048c43945047b7/media/audio/mac/audio_auhal_mac.h [modify] https://crrev.com/2f3180327f0c71452bb38e853c048c43945047b7/media/audio/mac/audio_manager_mac.cc [modify] https://crrev.com/2f3180327f0c71452bb38e853c048c43945047b7/media/audio/mac/audio_manager_mac.h
,
Apr 29 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/44f738f80780b75b0e1267c8be900b4cd5079d3e commit 44f738f80780b75b0e1267c8be900b4cd5079d3e Author: dvadym <dvadym@chromium.org> Date: Fri Apr 29 15:45:53 2016 Revert of Restores larger output buffer size when output stream requiring smaller size is closed (patchset #14 id:260001 of https://codereview.chromium.org/1903753002/ ) Reason for revert: This CL breaks Asan tests on Mac 10.9: https://build.chromium.org/p/chromium.memory/builders/Mac%20ASan%2064%20Tests%20%281%29/builds/15389 Original issue's description: > Restores a larger output buffer size when output stream requiring smaller size is closed if > no input stream is currently using the same audio device. > > BUG= 602587 > TEST=Manual tests and extra debug logging using a wide mix of audio applications (audio tag, WebAudio and WebRTC). TBR=grunell@chromium.org,olka@chromium.org,henrika@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG= 602587 Review-Url: https://codereview.chromium.org/1936553002 Cr-Commit-Position: refs/heads/master@{#390657} [modify] https://crrev.com/44f738f80780b75b0e1267c8be900b4cd5079d3e/media/audio/mac/audio_auhal_mac.cc [modify] https://crrev.com/44f738f80780b75b0e1267c8be900b4cd5079d3e/media/audio/mac/audio_auhal_mac.h [modify] https://crrev.com/44f738f80780b75b0e1267c8be900b4cd5079d3e/media/audio/mac/audio_manager_mac.cc [modify] https://crrev.com/44f738f80780b75b0e1267c8be900b4cd5079d3e/media/audio/mac/audio_manager_mac.h
,
May 12 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/04fa4fc3ea17b4b93904f79bcf7fb0ced0dfb90b commit 04fa4fc3ea17b4b93904f79bcf7fb0ced0dfb90b Author: henrika <henrika@chromium.org> Date: Thu May 12 16:05:10 2016 (Relanding) Restores larger output buffer size when output stream requiring smaller size is closed Previous attempt was done at: https://codereview.chromium.org/1903753002/ but it broke an ASAN bot on Mac. This is the second attempt to land. Restores a larger output buffer size when output stream requiring smaller size is closed if no input stream is currently using the same audio device. BUG= 602587 TEST=Manual tests and extra debug logging using a wide mix of audio applications (audio tag, WebAudio and WebRTC). I have also verified that all tests now passes under ASAN Review-Url: https://codereview.chromium.org/1973503003 Cr-Commit-Position: refs/heads/master@{#393261} [modify] https://crrev.com/04fa4fc3ea17b4b93904f79bcf7fb0ced0dfb90b/media/audio/mac/audio_auhal_mac.cc [modify] https://crrev.com/04fa4fc3ea17b4b93904f79bcf7fb0ced0dfb90b/media/audio/mac/audio_auhal_mac.h [modify] https://crrev.com/04fa4fc3ea17b4b93904f79bcf7fb0ced0dfb90b/media/audio/mac/audio_manager_mac.cc [modify] https://crrev.com/04fa4fc3ea17b4b93904f79bcf7fb0ced0dfb90b/media/audio/mac/audio_manager_mac.h
,
May 24 2016
Marking as fixed and reassigns to Olga to ensure that the change can be incorporated into the ongoing mixing work. |
||||
►
Sign in to add a comment |
||||
Comment 1 by grunell@chromium.org
, Apr 12 2016