Add a new parameter |latency| to PPB_Audio.

ppapi/api/ppb_audio.idl

Index: ppapi/api/ppb_audio.idl
diff --git a/ppapi/api/ppb_audio.idl b/ppapi/api/ppb_audio.idl
index 6d0dcb8d2b1f10d2b34208b6e43dc4c0c532db49..0525e96663ef43a98f8b8ca9db383fe76d454db3 100644
--- a/ppapi/api/ppb_audio.idl
+++ b/ppapi/api/ppb_audio.idl
@@ -8,10 +8,9 @@
  * realtime stereo audio streaming capabilities.
  */
 
-[generate_thunk]
-
 label Chrome {
-  M14 = 1.0
+  M14 = 1.0,
+  M30 = 1.1
 };
 
 /**
@@ -19,9 +18,16 @@ label Chrome {
  * function used to fill the audio buffer with data. Please see the
  * Create() function in the <code>PPB_Audio</code> interface for
  * more details on this callback.
+ *
+ * @param[in] sample_buffer A buffer to fill with audio data.
+ * @param[in] buffer_size_in_bytes The size of the buffer in bytes.
+ * @param[in] latency How long before the audio data is to be presented.
+ * @param[inout] user_data An opaque pointer that was passed into
+ * <code>PPB_Audio.Create()</code>.
  */
 typedef void PPB_Audio_Callback([out] mem_t sample_buffer,
                                 [in] uint32_t buffer_size_in_bytes,
+                                [in, version=1.1] PP_TimeDelta latency,
                                 [inout] mem_t user_data);

[dmichael (off chromium), 2013/08/06 19:43:25]

Should we consider defining 2 kinds of callbacks in stable, and having 2
Creates? (e.g., Create and CreateWithLatency). We're preserving ABI
compatibility here but breaking code compatibility for C. I guess it should be
fairly easy to adapt to, but it might be nice to strive for code compatibility.
WDYT?

[yzshen1, 2013/08/07 20:51:06]

I am a little bit concerned about that, because making two Creates bloats the
API. And the preferred way has to have a longer name CreateWithLatency().

If we think the callback with latency information makes more sense, it seems
okay to deprecate the old callback in new versions of APIs.

IMO (I could be wrong), we don't promise that a new version of API is a superset
of the older APIs, right?

If a user decides to use PPB_AUDIO_INTERFACE (instead of
PPB_AUDIO_INTERFACE_1_0) to query for interface, it means they would like to
compile with the latest API, and it is their responsibility to make necessary
modifications when they update the SDK they compile with.
If they use PPB_AUDIO_INTERFACE_1_0 to query for interface, there won't be a
problem.

What do you think?

On 2013/08/06 19:43:25, dmichael wrote:

 
 /**