New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 602587 link

Starred by 4 users

Issue metadata

Status: Fixed
Owner:
OOO Dec 22 - Jan 8
Closed: May 2016
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 1
Type: Bug

Blocking:
issue 586427



Sign in to add a comment

Restore larger output buffer size when output stream requiring smaller size goes away

Project Member Reported by grunell@chromium.org, Apr 12 2016

Issue description

When 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.
 
Summary: Restore larger output buffer size when output stream requiring smaller size goes away (was: Restore larger input buffer size when output stream requiring smaller size goes away)
It should be output. Maybe change both if it makes sense to do it at the same.
Given that I am currently working on an input related issue I would like to avoid making additional
changes until it has been resolved.
To clarify, output side only first.
Status: Started (was: Assigned)
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. 

Comment 6 by m...@chromium.org, 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).
Cc: m...@chromium.org
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.
Project Member

Comment 8 by bugdroid1@chromium.org, 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

Project Member

Comment 9 by bugdroid1@chromium.org, 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

Project Member

Comment 10 by bugdroid1@chromium.org, 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

Owner: olka@chromium.org
Status: Fixed (was: Started)
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