blob: e63fd521177937a107f724ed3c48273da4967515 (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
|
# Components
4a framework is made of several components which provide features to each other. The High Level API component is the only one that exports a public API. This means that, as an application developper you only need to care about the High Level API.
## High level API
This is the publicly exported API. It exposes one verb for each audio roles, plus **get_roles** to get the audio role list.
This component manages audio roles and apply permissions, signaling and policies. Because each role is a unique verb, it means that each role can have its own smack label.
It makes use of the **4a-hal-manager** to list all HALs and their configurations. Then it uses directly the enabled HALs.
## 4a-hal-manager
This component is responsible for HALs detection, initialization and state management.
## 4a-hal-*
This block represents all the differents HALs. You can load multiple HALs provided that they don't interfere with each other.
HALs can be provided by two means:
* Built directly by the **4a-hal-manager** using it's controller and json files.
* External HAL (like the unicens one), that have to register themselves to the **4a-hal-manager**.
HALs manages audio streams and zones. The streams are bound to audio roles.
## 4a-softmixer
This component abstracts the real devices to virtuals one and provide some basic mixing capabilities for devices that doesn't have this feature builtin.
It exposes streams named like the audio roles.
This component can be used by HALs, but this is not mandatory.
HALs can either :
* use 4a-softmixer (for example when hardware doesn't provide mixing feature), or
* take advantage from the hardware to provide the mixing capabilities.
|
