Introduce AudioRendererSink::IsOptimizedForHardwareParameters

media/base/audio_renderer_sink.h

Index: media/base/audio_renderer_sink.h
diff --git a/media/base/audio_renderer_sink.h b/media/base/audio_renderer_sink.h
index 4052112bab555b6703c90962422323f5cbeff0e4..90c68daae8e750e96ae50e94bc7825265319cc6e 100644
--- a/media/base/audio_renderer_sink.h
+++ b/media/base/audio_renderer_sink.h
@@ -71,7 +71,8 @@ class AudioRendererSink
   // If the sink is not associated with any output device, |device_status| of
   // OutputDeviceInfo should be set to OUTPUT_DEVICE_STATUS_ERROR_INTERNAL.
   // Must never be called on the IO thread.
-  virtual OutputDeviceInfo GetOutputDeviceInfo() = 0;
+  virtual OutputDeviceInfo GetOutputDeviceInfo(
+      const AudioParameters& preferred_params = AudioParameters()) = 0;

[o1ka, 2017/04/26 14:27:54]

I understand why you are doing this for
https://codereview.chromium.org/2752323002/.
But what is the meaning of |preferred_params| in general?
All the implementations except  WebAudioSourceProviderImpl just ignore the
parameters. So how would you describe the contract of this method? Also, what is
expected to be returned if "the sink is not associated with any output device"?

[flim-chromium, 2017/04/26 16:24:09]

|preferred_params| would be the native parameters from the stream, which the
implementation can choose to use instead of the sink params. If that makes
sense, I can add this to the comments?
It should return OUTPUT_DEVICE_STATUS_ERROR_INTERNAL - I've now fixed the case
in WebAudioSourceProviderImpl.

[o1ka, 2017/04/26 17:40:29]

This does not quite make sense to me in the context of AudioRendererSink
interface. Sink implementation does not really choose to use anything, it uses
parameters provided by the user in Initialize() method. And it's up to the user
to render using native parameters or sink parameters, or whatever.

Also, WebAudioSourceProviderImpl has SetClient() method, it can switch from
using |sink_| to |client_| and back. Which makes GetOutputDeviceInfo() return
rather a random result, doesn't it?

[DaleCurtis, 2017/04/26 18:25:59]

That should be okay, we'll just end using the browser side conversion process
instead then. Mostly we want the common case work well.  I.e. attach WebAudio,
then set src=. If we ever get around to implementing a device change API in the
renderer we could use that here.

 
   // If DCHECKs are enabled, this function returns true if called on rendering
   // thread, otherwise false. With DCHECKs disabled, it returns true. Thus, it