blob: c9a7d8fe738208c1e27a05a9c476187d2715e8cf (
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
|
# AGL Advanced Audio Architecture (4a)
## Abstract
4a is an audio framework made to handle automotive use cases like stream
priority and interruptions. It does **not** deal with the audio by itself but
rather with the policies and signaling around it. This means that 4a must be
used in conjunction with an other API that is in charge of the audio stuff,
like **alsa** or **pulseaudio**.
## Architecture
### Global architecture
This detailed diagram shows the interactions between all components.
This diagram shows the global architecture that any application playing audio
should follow. As a developer, when you want to play audio, you rely on APIs
such as alsa, pulseaudio or higher level API(s). To play audio you usually have
some kind of device URI that you have to open in order to write audio data to
it.
4a does **not** change anything about that. You still have to do all of this. 4a
provides permissions, signals and policies. This means that all compliant
applications have to ask 4a for a 'role' when they want to play audio. If 4a
grants them the permission, it returns a device URI that applications have to
open.
Nothing prevent an application to directly open a device, but in this case no
policies can be applied and access permissions are handled by system policies.
### 4a Architecture
Even if applications only deal with the high level API, 4a is made of multiple
components that rely on each other.
The high level API uses the hal-manager to list enabled HALs then it uses
directly those HALs.
HALs rely directly on drivers and/or softmixer.
|
