blob: 2709d60c416971dd91122a0feb540a2f6372ba76 (
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
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
|
# 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 developer 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 list of audio roles.
This component manages audio roles and applies 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 different 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 manage audio streams and zones. The streams are bound to audio roles.
## 4a-softmixer
This component abstracts the real devices to virtual ones and provides some
basic mixing capabilities for devices that don'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.
|
