Add a new parameter |latency| to PPB_Audio.

ppapi/api/ppb_audio.idl

 /* Copyright (c) 2012 The Chromium Authors. All rights reserved.
  * Use of this source code is governed by a BSD-style license that can be
  * found in the LICENSE file.
  */
 
 /**
  * This file defines the <code>PPB_Audio</code> interface, which provides
  * realtime stereo audio streaming capabilities.
  */
 
-[generate_thunk]
-
 label Chrome {
-  M14 = 1.0
+  M14 = 1.0,
+  M30 = 1.1
 };
 
 /**
  * <code>PPB_Audio_Callback</code> defines the type of an audio callback
  * 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:

 
 /**
  * The <code>PPB_Audio</code> interface contains pointers to several functions
  * for handling audio resources. Refer to the
  * <a href="/native-client/{{pepperversion}}/devguide/coding/audio">Audio</a>
  * chapter in the Developer's Guide for information on using this interface.
  * Please see descriptions for each <code>PPB_Audio</code> and
  * <code>PPB_AudioConfig</code> function for more details. A C example using
  * <code>PPB_Audio</code> and <code>PPB_AudioConfig</code> follows.
  *
@@ skipping 102 matching lines @@
    * @return A <code>PP_Bool</code> containing <code>PP_TRUE</code> if
    * successful, otherwise <code>PP_FALSE</code>. Also returns
    * <code>PP_TRUE</code> (and is a no-op) if called while playback is already
    * stopped. If a callback is in progress, StopPlayback() will block until the
    * callback completes.
    */
   PP_Bool StopPlayback(
       [in] PP_Resource audio);
 };