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
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
|
# 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.
### Softmixer
The 4a softmixer is a sound server. It is a more secured, more CPU-friendly
server than PulseAudio.
It is mandatory to have a sound server to share a sound card between
several applications, that may write to the sound card at different
sound rates and formats.
It is the responsibility of the 4a-softmixer to instantiate the dmix
alsa plugin, based on the 4A config files.
#### snd-aloop
snd-aloop, which has recently been replaced by a more flexible implementation
(called avirt), proxifies the access from playback application to sound cards.
The 4a-softmixer reads from snd-aloop (or avirt) captures, and will perform
the rate conversion, soft volume control for hardware that does not implement
it, routing to configured audio channels, and mixing at the end.
A security label (SMACK) can be put on the snd-aloop PCM playback devices,
and since each these devices matches an audio role, that applications have to
claim to the 4A high level API, this makes a gatekeeper for audio apps.
snd-aloop introduces one more buffer copy; but the measured performances and
CPU load on the tested boards do not have revealed any unacceptable levels, up
to now.
The CPU load (which could be even better with some unimplemented optimizations
today) is typically less than 5% on the Renesas RCAR board, and similar
numbers have been seen on Intel Atom boards.
#### avirt
Introduced recently on the master branch of AGL, it provides to 4A high level
a common interface for both softmixing, and DSP-accelerated mixing. I also
sets user-readable names to the dynamically-configured playback devices, that
match the 4A audio roles (aka streams).
The avirt-loop backend is a loop implementation that provides the same
functionality as snd-aloop, with enhanced security (each playback has a
dedicated PCM device, on which a SMACK label can be put), and with the
flexibility offered by the top avirt layer.
It is not limited to 8 channels like snd-aloop.
|
