Moved AudioUtil static functions to AudioManager interfaces

Moved AudioUtil static functions:
GetAudioHardwareSampleRate
GetAudioInputHardwareSampleRate
GetAudioHardwareBufferSize
GetAudioInputHardwareChannelLayout
to AudioManager interfaces:
GetDefaultOutputStreamParameters()
GetDefaultInputStreamParameters(const std::string& device_id)

By doing this, we remove the messy ifdef statements in AudioUtil, allow getting the native sample rate for Pulse, each AudioManager is responsible for providing the optimal audio params to achieve the best audio performance, for example, cras can raise the buffer size to reduce CPU consumption without affecting other Linux products.


BUG=178142, 137326, 120319
TEST=media_unittests, content_unittests

Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=186180

[no longer working on chromium, 2013-02-26 18:27:15]

Dale and Tommi, could you please review this CL?


Thanks,

SX

[DaleCurtis, 2013-02-27 02:46:11]

Nice work Shijing!

We should figure out how to collapse the two methods we have now for getting
default output parameters.

Here are a couple thoughts:
- Keep the methods split out similar to how we have in AudioHardwareConfig; i.e.
GetOutputBufferSize(), GetInputChannelLayout(), etc.

- Keep the GetPreferredLowLatencyOutputStreamParameters() method and add a 
AudioManager::GetAudioHardwareConfig() method which returns a pointer to a
AudioHardwareConfig object with the latest configuration information.  When
OnDeviceChange() events occur we could update the cache.  Problems:
http://crbug.com/158170 will probably cause this to blow up on mac.  Also we
don't have input device change events yet.

- Collapse GetPreferredLowLatencyOutputStreamParameters() and
GetDefaultOutputStreamParameters() into a single method which requires an
AudioParameters object passed in.  If the AudioParameters are valid it returns
what GetPreferredLowLatencyOutputStreamParameters() does today.  If they're
invalid, it instead returns the default parameters like your new method does
now.

Others?

cc:crogers.

https://codereview.chromium.org/12316131/diff/4001/media/audio/win/audio_mana...
File media/audio/win/audio_manager_win.cc (right):

https://codereview.chromium.org/12316131/diff/4001/media/audio/win/audio_mana...
media/audio/win/audio_manager_win.cc:51: using
WASAPIAudioInputStream::HardwareChannelCount;
I think this makes things a little confusing since we've got both input and
output methods in the file.  I'd prefer if you used the fully qualified names
below.

[no longer working on chromium, 2013-02-27 19:44:17]

Hi Dale, I got a visitor from Munich and would work on the UI things Today and
Tomorrow, but I will try to address your comments ASAP.
Follow is my current thought.

On 2013/02/27 02:46:11, DaleCurtis wrote:
> Nice work Shijing!
> 
> We should figure out how to collapse the two methods we have now for getting
> default output parameters.
> 
> Here are a couple thoughts:
> - Keep the methods split out similar to how we have in AudioHardwareConfig;
i.e.
> GetOutputBufferSize(), GetInputChannelLayout(), etc.
> 

Preferably we would like to have one API to return a AudioParameters which
contains all the necessary information. Also it is easier to extend the API to
cover more native audio parameters. 

> - Keep the GetPreferredLowLatencyOutputStreamParameters() method and add a 
> AudioManager::GetAudioHardwareConfig() method which returns a pointer to a
> AudioHardwareConfig object with the latest configuration information.  When
> OnDeviceChange() events occur we could update the cache.  Problems:
> http://crbug.com/158170 will probably cause this to blow up on mac.  Also we
> don't have input device change events yet.
> 

Given the problem we have for the listener, I am not sure if we should add
support for listening to the input device change now. Can we re-visit this idea
when http://crbug.com/158170 is fixed, and the listener gets more stable?

> - Collapse GetPreferredLowLatencyOutputStreamParameters() and
> GetDefaultOutputStreamParameters() into a single method which requires an
> AudioParameters object passed in.  If the AudioParameters are valid it returns
> what GetPreferredLowLatencyOutputStreamParameters() does today.  If they're
> invalid, it instead returns the default parameters like your new method does
> now.
> 

This sounds good to me.


> Others?
> 
> cc:crogers.
> 
>
https://codereview.chromium.org/12316131/diff/4001/media/audio/win/audio_mana...
> File media/audio/win/audio_manager_win.cc (right):
> 
>
https://codereview.chromium.org/12316131/diff/4001/media/audio/win/audio_mana...
> media/audio/win/audio_manager_win.cc:51: using
> WASAPIAudioInputStream::HardwareChannelCount;
> I think this makes things a little confusing since we've got both input and
> output methods in the file.  I'd prefer if you used the fully qualified names
> below.

[Chris Rogers, 2013-02-27 19:54:37]

+rtoy for Android changes

[Chris Rogers, 2013-02-27 20:06:14]

Looks pretty good!  Just to let you know, I'm working on a change which affects
some of the same code in RenderMessageFilter::OnGetAudioHardwareConfig().  I'm
working on getting more info transferred across the IPC to AudioHardwareConfig. 
I'll have to make some changes based on your work, but think it will work out
well once the dust settles.

https://codereview.chromium.org/12316131/diff/4001/media/audio/audio_manager.h
File media/audio/audio_manager.h (right):

https://codereview.chromium.org/12316131/diff/4001/media/audio/audio_manager....
media/audio/audio_manager.h:129: virtual AudioParameters
GetDefaultInputStreamParameters(
It seems like a better name for GetDefaultInputStreamParameters() would be
GetInputStreamParameters(), since you're passing in the device and not using the
default.

https://codereview.chromium.org/12316131/diff/4001/media/audio/audio_manager_...
File media/audio/audio_manager_base.cc (right):

https://codereview.chromium.org/12316131/diff/4001/media/audio/audio_manager_...
media/audio/audio_manager_base.cc:409: return AudioParameters();
seems a bit dangerous -- should probably add NOTREACHED()

https://codereview.chromium.org/12316131/diff/4001/media/audio/audio_manager_...
media/audio/audio_manager_base.cc:414: return AudioParameters();
seems a bit dangerous -- should probably add NOTREACHED()

[Raymond Toy (Google), 2013-02-28 00:30:45]

Looks good, except for one small question.

https://codereview.chromium.org/12316131/diff/4001/media/audio/android/audio_...
File media/audio/android/audio_manager_android.cc (right):

https://codereview.chromium.org/12316131/diff/4001/media/audio/android/audio_...
media/audio/android/audio_manager_android.cc:63: static const int
kDefaultBufferSize = 1024
Didn't this used to be 2048?  Is 1024 the desired value now?

[Chris Rogers, 2013-02-28 00:32:50]

On 2013/02/28 00:30:45, rtoy wrote:
> Looks good, except for one small question.
> 
>
https://codereview.chromium.org/12316131/diff/4001/media/audio/android/audio_...
> File media/audio/android/audio_manager_android.cc (right):
> 
>
https://codereview.chromium.org/12316131/diff/4001/media/audio/android/audio_...
> media/audio/android/audio_manager_android.cc:63: static const int
> kDefaultBufferSize = 1024
> Didn't this used to be 2048?  Is 1024 the desired value now?

Does this mean that Clank Web Audio will use 16KHz?  I thought iOS was at least
22KHz.

[tommi (sloooow) - chröme, 2013-03-01 11:29:29]

This is a very welcome change.  I've got a few comments (and sorry for the slow
response), but overall looks great.

https://codereview.chromium.org/12316131/diff/4001/content/browser/renderer_h...
File content/browser/renderer_host/media/media_stream_manager.cc (right):

https://codereview.chromium.org/12316131/diff/4001/content/browser/renderer_h...
content/browser/renderer_host/media/media_stream_manager.cc:856:
audio_manager_->GetDefaultOutputStreamParameters();
Can we move this outside the loop?

https://codereview.chromium.org/12316131/diff/4001/media/audio/audio_manager.h
File media/audio/audio_manager.h (right):

https://codereview.chromium.org/12316131/diff/4001/media/audio/audio_manager....
media/audio/audio_manager.h:129: virtual AudioParameters
GetDefaultInputStreamParameters(
On 2013/02/27 20:06:14, Chris Rogers wrote:
> It seems like a better name for GetDefaultInputStreamParameters() would be
> GetInputStreamParameters(), since you're passing in the device and not using
the
> default.

+1

https://codereview.chromium.org/12316131/diff/4001/media/audio/audio_manager_...
File media/audio/audio_manager_base.cc (right):

https://codereview.chromium.org/12316131/diff/4001/media/audio/audio_manager_...
media/audio/audio_manager_base.cc:409: return AudioParameters();
On 2013/02/27 20:06:14, Chris Rogers wrote:
> seems a bit dangerous -- should probably add NOTREACHED()

Can we make these methods pure virtual?

https://codereview.chromium.org/12316131/diff/4001/media/audio/cras/audio_man...
File media/audio/cras/audio_manager_cras.h (right):

https://codereview.chromium.org/12316131/diff/4001/media/audio/cras/audio_man...
media/audio/cras/audio_manager_cras.h:26: virtual AudioParameters
GetDefaultOutputStreamParameters() OVERRIDE;
pure virtual? (are there any derived classes that don't implement this?)

[no longer working on chromium, 2013-03-01 16:44:33]

Hi, I think I have already addressed all the comments. The biggest change in
this version is that I merged GetPreferredLowLatencyOutputStreamParameters to
GetDefaultOutputStreamParameters. I believe it is a good move since it is more
readable and clearer on how we choose the audio parameters for the streams.
And I am going to carefully double check the change on each platforms on Monday.

Thanks,
SX

https://codereview.chromium.org/12316131/diff/4001/content/browser/renderer_h...
File content/browser/renderer_host/media/media_stream_manager.cc (right):

https://codereview.chromium.org/12316131/diff/4001/content/browser/renderer_h...
content/browser/renderer_host/media/media_stream_manager.cc:856:
audio_manager_->GetDefaultOutputStreamParameters();
On 2013/03/01 11:29:29, tommi wrote:
> Can we move this outside the loop?

We call GetDefaultOutputStreamParameters() only for MEDIA_TAB_AUDIO_CAPTURE, but
not for other type.
Moving this out of the loop results in calling
GetDefaultOutputStreamParameters() unnecessarily for other media request.

And since the StreamDeviceInfoArray will contain at most one 
content::MEDIA_TAB_AUDIO_CAPTURE device, so it is fine to do it this way.

https://codereview.chromium.org/12316131/diff/4001/media/audio/android/audio_...
File media/audio/android/audio_manager_android.cc (right):

https://codereview.chromium.org/12316131/diff/4001/media/audio/android/audio_...
media/audio/android/audio_manager_android.cc:63: static const int
kDefaultBufferSize = 1024
On 2013/02/28 00:30:45, rtoy wrote:
> Didn't this used to be 2048?  Is 1024 the desired value now?

Yes, it used to be 2048, but I think 2048 to 16K is too much, it means 120.8ms
buffer, isn't fine to reduce it to half?

We can fall back to the old value if you think we should keep 2048.

https://codereview.chromium.org/12316131/diff/4001/media/audio/audio_manager.h
File media/audio/audio_manager.h (right):

https://codereview.chromium.org/12316131/diff/4001/media/audio/audio_manager....
media/audio/audio_manager.h:129: virtual AudioParameters
GetDefaultInputStreamParameters(
On 2013/02/27 20:06:14, Chris Rogers wrote:
> It seems like a better name for GetDefaultInputStreamParameters() would be
> GetInputStreamParameters(), since you're passing in the device and not using
the
> default.

Done.

https://codereview.chromium.org/12316131/diff/4001/media/audio/audio_manager_...
File media/audio/audio_manager_base.cc (right):

https://codereview.chromium.org/12316131/diff/4001/media/audio/audio_manager_...
media/audio/audio_manager_base.cc:409: return AudioParameters();
On 2013/02/27 20:06:14, Chris Rogers wrote:
> seems a bit dangerous -- should probably add NOTREACHED()

Done.

https://codereview.chromium.org/12316131/diff/4001/media/audio/audio_manager_...
media/audio/audio_manager_base.cc:409: return AudioParameters();
On 2013/02/27 20:06:14, Chris Rogers wrote:
> seems a bit dangerous -- should probably add NOTREACHED()

I make it pure virtual to for the developer to implement their own
GetDefaultOutputStreamParameters on all AudioManagers

https://codereview.chromium.org/12316131/diff/4001/media/audio/audio_manager_...
media/audio/audio_manager_base.cc:414: return AudioParameters();
On 2013/02/27 20:06:14, Chris Rogers wrote:
> seems a bit dangerous -- should probably add NOTREACHED()

Done.

https://codereview.chromium.org/12316131/diff/4001/media/audio/cras/audio_man...
File media/audio/cras/audio_manager_cras.h (right):

https://codereview.chromium.org/12316131/diff/4001/media/audio/cras/audio_man...
media/audio/cras/audio_manager_cras.h:26: virtual AudioParameters
GetDefaultOutputStreamParameters() OVERRIDE;
On 2013/03/01 11:29:29, tommi wrote:
> pure virtual? (are there any derived classes that don't implement this?)

Done.

https://codereview.chromium.org/12316131/diff/4001/media/audio/win/audio_mana...
File media/audio/win/audio_manager_win.cc (right):

https://codereview.chromium.org/12316131/diff/4001/media/audio/win/audio_mana...
media/audio/win/audio_manager_win.cc:51: using
WASAPIAudioInputStream::HardwareChannelCount;
On 2013/02/27 02:46:11, DaleCurtis wrote:
> I think this makes things a little confusing since we've got both input and
> output methods in the file.  I'd prefer if you used the fully qualified names
> below.

true, done now. Thanks for pointing out.

[DaleCurtis, 2013-03-02 01:53:56]

lgtm % some nits.  Though all this passing of AudioParameters around by copy is
making me twitch.  I wonder if its worth making that DISALLOW_COPY_AND_ASSIGN().

https://codereview.chromium.org/12316131/diff/18001/content/renderer/media/we...
File content/renderer/media/webrtc_audio_capturer.cc (right):

https://codereview.chromium.org/12316131/diff/18001/content/renderer/media/we...
content/renderer/media/webrtc_audio_capturer.cc:54: if (sample_rate == 44100)
Hmm, what is this?

https://codereview.chromium.org/12316131/diff/18001/content/renderer/media/we...
File content/renderer/media/webrtc_audio_device_unittest.cc (right):

https://codereview.chromium.org/12316131/diff/18001/content/renderer/media/we...
content/renderer/media/webrtc_audio_device_unittest.cc:42:
input_parameters.sample_rate(), input_parameters.channel_layout() ));
extra space.

https://codereview.chromium.org/12316131/diff/18001/media/audio/ios/audio_man...
File media/audio/ios/audio_manager_ios.mm (right):

https://codereview.chromium.org/12316131/diff/18001/media/audio/ios/audio_man...
media/audio/ios/audio_manager_ios.mm:52: AudioParameters
AudioManagerIOS::GetDefaultOutputStreamParameters(
Shouldn't these just be NOTREACHED() right now?

https://codereview.chromium.org/12316131/diff/18001/media/audio/linux/audio_m...
File media/audio/linux/audio_manager_linux.cc (right):

https://codereview.chromium.org/12316131/diff/18001/media/audio/linux/audio_m...
media/audio/linux/audio_manager_linux.cc:110: // Since Linux doesn't actually
have a low latency path the hardware buffer
Comment can be deleted now.

[Chris Rogers, 2013-03-04 01:04:11]

Looking very good:

https://codereview.chromium.org/12316131/diff/18001/content/browser/renderer_...
File content/browser/renderer_host/media/media_stream_manager.cc (right):

https://codereview.chromium.org/12316131/diff/18001/content/browser/renderer_...
content/browser/renderer_host/media/media_stream_manager.cc:857:
media::AudioParameters());
It seems clunky to have to pass in a "bogus" AudioParameters object just to get
to the default values.  Please see my comments in audio_manager.h

https://codereview.chromium.org/12316131/diff/18001/media/audio/audio_manager.h
File media/audio/audio_manager.h (right):

https://codereview.chromium.org/12316131/diff/18001/media/audio/audio_manager...
media/audio/audio_manager.h:128: virtual AudioParameters
GetDefaultOutputStreamParameters(
It would be good to have another version of this method taking no
|input_params|.  This would just be a convenience method so clients don't have
to pass in a "bogus" AudioParameter value just to get the default values. 
Several places in this CL have to pass in these empty "bogus" AudioParameters
which seems a bit clunky.

This convenience method wouldn't need to be implemented for each AudioManager
sub-class of course.

https://codereview.chromium.org/12316131/diff/18001/media/audio/win/audio_man...
File media/audio/win/audio_manager_win.cc (right):

https://codereview.chromium.org/12316131/diff/18001/media/audio/win/audio_man...
media/audio/win/audio_manager_win.cc:293: buffer_size = 256;16
256;16 ??

https://codereview.chromium.org/12316131/diff/18001/media/audio/win/audio_man...
media/audio/win/audio_manager_win.cc:304: channel_layout =
WASAPIAudioOutputStream::HardwareChannelLayout();
you need to set |input_channels| here to what |input_params| says

[no longer working on chromium, 2013-03-04 14:55:04]

https://codereview.chromium.org/12316131/diff/18001/content/renderer/media/we...
File content/renderer/media/webrtc_audio_capturer.cc (right):

https://codereview.chromium.org/12316131/diff/18001/content/renderer/media/we...
content/renderer/media/webrtc_audio_capturer.cc:54: if (sample_rate == 44100)
On 2013/03/02 01:53:56, DaleCurtis wrote:
> Hmm, what is this?

Oh, this change is making the webrtc audio work when the sample rate is 44100,
but it should be done in another CL.

Removed.

https://codereview.chromium.org/12316131/diff/18001/content/renderer/media/we...
File content/renderer/media/webrtc_audio_device_unittest.cc (right):

https://codereview.chromium.org/12316131/diff/18001/content/renderer/media/we...
content/renderer/media/webrtc_audio_device_unittest.cc:42:
input_parameters.sample_rate(), input_parameters.channel_layout() ));
On 2013/03/02 01:53:56, DaleCurtis wrote:
> extra space.

Done.

https://codereview.chromium.org/12316131/diff/18001/media/audio/audio_manager.h
File media/audio/audio_manager.h (right):

https://codereview.chromium.org/12316131/diff/18001/media/audio/audio_manager...
media/audio/audio_manager.h:128: virtual AudioParameters
GetDefaultOutputStreamParameters(
On 2013/03/04 01:04:11, Chris Rogers wrote:
> It would be good to have another version of this method taking no
> |input_params|.  This would just be a convenience method so clients don't have
> to pass in a "bogus" AudioParameter value just to get the default values. 
> Several places in this CL have to pass in these empty "bogus" AudioParameters
> which seems a bit clunky.
> 
> This convenience method wouldn't need to be implemented for each AudioManager
> sub-class of course.

I agree that is a bit clunky to force the clients to inject an empty
AudioParameters object. But adding one overloading method to the interface does
not seem suitable for AudioManager interface.
Lets take one step back instead.
GetDefaultOutputStreamParameters() is the interface to clients outside media.
GetDefaultOutputStreamParameters(const AudioParameters& input_params) is only
called by AudioManagerBase.
We want one implementation but two interfaces.

After talking to Tommi, I would suggest fallback to
GetDefaultOutputStreamParameters() in AudioManager, and add back one
GetPreferredOutputStreamParameters(const AudioParameters& input_params) to
AudioManagerBase.
The implementation of GetDefaultOutputStreamParameters() is in AudioManageBase,
which calls GetPreferredOutputStreamParameters(input_params), and DO NOT each
AudioManager to implement their own version.
Instead, each AudioManager should put the implementation in
GetPreferredOutputStreamParameters(const AudioParameters& input_params).

Chris and Dale, how do you think here? I uploaded a new version of code to
demonstrate the idea. Hope this version looks better.

https://codereview.chromium.org/12316131/diff/18001/media/audio/ios/audio_man...
File media/audio/ios/audio_manager_ios.mm (right):

https://codereview.chromium.org/12316131/diff/18001/media/audio/ios/audio_man...
media/audio/ios/audio_manager_ios.mm:52: AudioParameters
AudioManagerIOS::GetDefaultOutputStreamParameters(
On 2013/03/02 01:53:56, DaleCurtis wrote:
> Shouldn't these just be NOTREACHED() right now?

I am not sure here. audio_util.cc methods cover the IOS case, but I believe they
are simply returning some ok values.
And GetPreferredLowLatencyOutputStreamParameters() is UNREACHED() for IOS.
If we don't change the behavior, we should add a NOTREACHED() under
input_params.IsValid().

https://codereview.chromium.org/12316131/diff/18001/media/audio/linux/audio_m...
File media/audio/linux/audio_manager_linux.cc (right):

https://codereview.chromium.org/12316131/diff/18001/media/audio/linux/audio_m...
media/audio/linux/audio_manager_linux.cc:110: // Since Linux doesn't actually
have a low latency path the hardware buffer
On 2013/03/02 01:53:56, DaleCurtis wrote:
> Comment can be deleted now.

Delete the first comment, and I think the other is still valid.

https://codereview.chromium.org/12316131/diff/18001/media/audio/win/audio_man...
File media/audio/win/audio_manager_win.cc (right):

https://codereview.chromium.org/12316131/diff/18001/media/audio/win/audio_man...
media/audio/win/audio_manager_win.cc:293: buffer_size = 256;16
On 2013/03/04 01:04:11, Chris Rogers wrote:
> 256;16 ??

oh, a mistake. Removed now. thanks.

https://codereview.chromium.org/12316131/diff/18001/media/audio/win/audio_man...
media/audio/win/audio_manager_win.cc:304: channel_layout =
WASAPIAudioOutputStream::HardwareChannelLayout();
On 2013/03/04 01:04:11, Chris Rogers wrote:
> you need to set |input_channels| here to what |input_params| says

Fixed now.

[DaleCurtis, 2013-03-05 01:40:53]

still lgtm % interface nit.

https://codereview.chromium.org/12316131/diff/12006/media/audio/audio_manager...
File media/audio/audio_manager_base.h (right):

https://codereview.chromium.org/12316131/diff/12006/media/audio/audio_manager...
media/audio/audio_manager_base.h:91: virtual AudioParameters
GetPreferredOutputStreamParameters(
Move to protected? Ditto for implementations.

[commit-bot: I haz the power, 2013-03-05 10:09:23]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/xians@chromium.org/12316131/36001

[no longer working on chromium, 2013-03-05 10:09:35]

Landing soon.

Thanks for all.

SX

https://codereview.chromium.org/12316131/diff/12006/media/audio/audio_manager...
File media/audio/audio_manager_base.h (right):

https://codereview.chromium.org/12316131/diff/12006/media/audio/audio_manager...
media/audio/audio_manager_base.h:91: virtual AudioParameters
GetPreferredOutputStreamParameters(
On 2013/03/05 01:40:53, DaleCurtis wrote:
> Move to protected? Ditto for implementations.

Done.

[commit-bot: I haz the power, 2013-03-05 10:09:36]

Presubmit check for 12316131-36001 failed and returned exit status 1.

INFO:root:Found 34 file(s).

Running presubmit commit checks ...
Running /b/commit-queue/workdir/chromium/PRESUBMIT.py

** Presubmit ERRORS **
Missing LGTM from an OWNER for these files:
    content/browser/renderer_host/render_message_filter.cc

Presubmit checks took 2.6s to calculate.

Was the presubmit check useful? Please send feedback & hate mail to
maruel@chromium.org!

[no longer working on chromium, 2013-03-05 10:16:27]

Nico, can I have your owner stamp for
content/browser/renderer_host/render_message_filter.cc?

Thanks,
SX

[Nico, 2013-03-05 10:23:19]

lgtm

[commit-bot: I haz the power, 2013-03-05 10:29:16]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/xians@chromium.org/12316131/36001

[no longer working on chromium, 2013-03-05 10:29:44]

On 2013/03/05 10:23:19, Nico wrote:
> lgtm

Nice! It is super quick one.

[commit-bot: I haz the power, 2013-03-05 11:52:17]

Retried try job too often on win7_aura for step(s) browser_tests
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=win7_aura&...

[commit-bot: I haz the power, 2013-03-05 12:02:40]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/xians@chromium.org/12316131/36001

[commit-bot: I haz the power, 2013-03-05 15:31:47]

Change committed as 186180

[DaleCurtis, 2013-03-05 18:26:26]

This morning I remembered the --audio-buffer-size flag; your CL breaks its
functionality.  Can you fix this in a followup CL? On Linux and Mac the flag is
important for compatibility and debugging issues still.

The code to use the flag is still in audio_util.cc too, so that should be
cleaned up.

[no longer working on chromium, 2013-03-06 22:37:40]

Thanks for the message, I will fix it tomorrow.


On Tue, Mar 5, 2013 at 7:26 PM, <dalecurtis@chromium.org> wrote:

> This morning I remembered the --audio-buffer-size flag; your CL breaks its
> functionality.  Can you fix this in a followup CL? On Linux and Mac the
> flag is
> important for compatibility and debugging issues still.
>
> The code to use the flag is still in audio_util.cc too, so that should be
> cleaned up.
>
>
https://codereview.chromium.**org/12316131/<https://codereview.chromium.org/1...
>