Lines Matching refs:of
16 reduction of power consumption compared to host-based
18 mostly because of a lack of a generic API available in the mainline
21 Rather than requiring a compatibility break with an API change of the
25 The design of this API was inspired by the 2-year experience with the
27 API in the mainline kernel instead of the staging tree and make it
37 estimate reliably the duration of audio buffers when handling
40 reporting of the number of samples rendered at any given time.
42 - Handling of multiple formats. PCM data only requires a specification
43 of the sampling rate, number of channels and bits per sample. In
44 contrast, compressed data comes in a variety of formats. Audio DSPs
45 may also provide support for a limited number of audio encoders and
47 dynamic download of libraries.
54 - Handling of multiple configurations. Even for a given format like
57 cycles. The new API needs to provide a generic way of listing these
60 - Rendering/Grabbing only. This API does not provide any means of
68 API assumes the existence of a platform-specific compatibility layer
69 to expose, translate and make use of the capabilities of the audio
71 applications are not supposed to make use of this API.
76 The new API shares a number of concepts with the PCM API for flow
80 The concept of memory ring buffer divided in a set of fragments is
86 The notion of rewinds/forwards is not supported. Data committed to the
92 possible. As in the ALSA PCM case, a core set of routines is exposed;
93 each driver implementer will have to write support for a set of
94 mandatory routines and possibly make use of optional ones.
99 This routine returns the list of audio formats supported. Querying the
103 - get_codec_caps For each codec, this routine returns a list of
105 correspond to valid settings, and to minimize the risks of
107 the number of channels supported may depend on a specific profile. If
109 that a specific combination of profiles/channels/formats may not be
111 it is likely that some implementations make the list of capabilities
114 implementation. This information can be a function of the DMA buffer
115 sizes, the number of bytes required to synchronize, etc, and can be
131 of bytes transferred, the number of samples processed and the number
132 of samples rendered/grabbed. All these values can be used to determine
136 Note that the list of codecs/profiles/modes was derived from the
137 OpenMAX AL specification instead of reinventing the wheel.
139 - Addition of FLAC and IEC formats
140 - Merge of encoder/decoder capabilities
142 - Addition of set_params for decoders (missing in OpenMAX AL)
143 - Addition of AMR/AMR-WB encoding modes (missing in OpenMAX AL)
144 - Addition of format information for WMA
145 - Addition of encoding options when required (derived from OpenMAX IL)
146 - Addition of rateControlSupported (missing in OpenMAX AL)
156 difficult to reach with all types of compressed data, but works fine with most
175 This is called when end of file is reached. The userspace can inform DSP that
183 - Set metadata of the first track
184 - Fill data of the first track
188 - Set metadata of the next track
189 - then call partial_drain to flush most of buffer in DSP
190 - Fill data of the next track
196 - Support for VoIP/circuit-switched calls is not the target of this
215 above. It is possible to route the output of a decoder to a capture
220 hooks to query the utilization of the audio DSP, nor any preemption
223 - No notion of underrun/overrun. Since the bytes written are compressed
233 demonstrating and quantifying the benefits of audio offload on a