Plugins:PepperAudioAPI: Difference between revisions

All future versions of PEPPER will support version 1 (this proposal) as a bare minimum.

Trusted PEPPER modules will be able to open more than one audio context. Untrusted PEPPER modules might be restricted to a single audio context. In either environment, it is assumed multi-threading is available.

This document contains two models - one based on callbacks, and one based on a blocking push model. While both models are fundamentally the same, they do carry some subtle differences:  

*Blocking Push API provides more control, and assumes threading will be explicitly handled by the application. When writing trusted PEPPER modules without a platform independent threading library, this may imply the application writer to #if WIN32, #if PTHREADS, etc. around the application's audio thread setup code.  

*There might be some subtle implementation details when it comes to how each model needs to signal between the audio device and the PEPPER audio interface. These signals will need to be as fast and low latency as possible, so minimizing how many signals are required will be important.

Native Client plug-ins have up until now used an audio API very similar to a blockingflushContext() call, usually done on a thread dedicated to audio. The API call wasimplemented as a syscall, and at the service runtime (kernel) level used SDL to deliver low latency audio across multiple platforms. As Native Client moves into a more secure sandbox environment, untrusted code will no longer be able to communicate directly with audio devices in the same process. In the new audio model, trusted code in another process will be attached to the audio device, and the sandboxed Native Client untrusted application will use shared memory and sockets to communicate its audio needs outside the sandbox. The new API for this model will be part of PEPPER, a variant of NPAPI that is designed to be platform neutral.  

Please refer to Appendix A for a list of links pertaining to audio.Please refer to Appendix B for PEPPER design wiki -- where this document will migrate once approved.  

 

Both models support multi-channel configurations. Please refer to Appendix E for multi-channel output scenarios.Please refer to Appendix F for input scenarios. Please refer to Appendix G for contributors.  

 

Previously, Pepper's device API consisted of the methods initializeContext, flushContext, and destroyContext. Audio extends this API to queryCapability, queryConfig, initializeContext, flushContext, getState, setState, and destroyContext.