Confirmed users, Bureaucrats and Sysops emeriti
1,680
edits
Plugins:PepperAudioAPI: Difference between revisions
Jump to navigation
Jump to search
no edit summary
No edit summary |
|||
| Line 17: | Line 17: | ||
=====Objective:===== | =====Objective:===== | ||
*First pass implementation is to provide 16bit, stereo, CD (44.1kHz) or DAT (48kHz) | *First pass implementation is to provide 16bit, stereo, CD (44.1kHz) or DAT (48kHz) quality audio. | ||
*Deliver low latency audio on systems that have good audio drivers. (<=20ms) | *Deliver low latency audio on systems that have good audio drivers. (<=20ms) | ||
*Be flexible enough to scale additional features in future versions | *Be flexible enough to scale additional features in future versions | ||
| Line 33: | Line 33: | ||
*Implemented in Pepper's device API | *Implemented in Pepper's device API | ||
The browser might be responsible for applying additional user volume or muting control,and may upsample/downsample the audio data before mixing with other browser | The browser might be responsible for applying additional user volume or muting control,and may upsample/downsample the audio data before mixing with other browser audio sources. | ||
All future versions of PEPPER will support version 1 (this proposal) as a bare minimum. | All future versions of PEPPER will support version 1 (this proposal) as a bare minimum. | ||
| Line 42: | Line 42: | ||
*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. | *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. | ||
*Callback API does not require application to setup/teardown audio thread, and the | *Callback API does not require application to setup/teardown audio thread, and the API entry points are all on the NPAPI thread -- only the callback occurs on an implicit, dedicated audio thread. | ||
*There might be some subtle implementation details when it comes to how each | *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. | ||
=====Background:===== | =====Background:===== | ||
| Line 57: | Line 57: | ||
===Changes to Pepper's Device API=== | ===Changes to Pepper's Device API=== | ||
Previously, Pepper's device API consisted of the methods initializeContext, flushContext, and destroyContext. Audio extends this API to queryCapability, queryConfig, initializeContext, | 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. | ||
:queryCapability - ask a device about a specific capability | :queryCapability - ask a device about a specific capability | ||
| Line 71: | Line 71: | ||
The following device methods must be called from the NPAPI thread (Tp). They should notbe called from any other thread, unless it is via NPN_ThreadAsyncCall. | The following device methods must be called from the NPAPI thread (Tp). They should notbe called from any other thread, unless it is via NPN_ThreadAsyncCall. | ||
:queryCapability, queryConfig, initializeContext, getStateContext, setStateContext,destroyContext | :queryCapability, queryConfig, initializeContext, getStateContext, setStateContext, destroyContext | ||
The only device method that can be called from another thread is flushContext when using the push model. When using the callback model, it is expected that the user supplied callback will be invoked on a thread dedicated to audio. This dedicated audio thread is not an NPAPI thread. | The only device method that can be called from another thread is flushContext when using the push model. When using the callback model, it is expected that the user supplied callback will be invoked on a thread dedicated to audio. This dedicated audio thread is not an NPAPI thread. | ||
| Line 126: | Line 126: | ||
channels or sample rate. | channels or sample rate. | ||
To make the most common cases easy, Pepper audio guarantees availability of 44.1kHz, 48kHz, int16 sample types, and stereo output. Pepper audio will automatically | To make the most common cases easy, Pepper audio guarantees availability of 44.1kHz, 48kHz, int16 sample types, and stereo output. Pepper audio will automatically re-sample if needed, and do stereo->mono mixdown if needed. | ||
If an application desires, it can query Pepper audio for the system's internal sample rate. Using this sample rate will avoid | If an application desires, it can query Pepper audio for the system's internal sample rate. Using this sample rate will avoid re-sampling (which may occur at either the device driver level or a software mixer.) | ||
===Mode One: Callback Model=== | ===Mode One: Callback Model=== | ||