summaryrefslogtreecommitdiffstats
path: root/docs/4a-framework/README.md
diff options
context:
space:
mode:
authorLoïc Collignon [ IoT.bzh ] <loic.collignon@iot.bzh>2018-10-01 13:54:38 +0000
committerGerrit Code Review <gerrit@automotivelinux.org>2018-10-01 13:54:38 +0000
commit3e30a30b9f59415ed305688b8d1ba38998ad4fbb (patch)
tree110ee0a10ac67da76b0c84c1c3350803190fe6f4 /docs/4a-framework/README.md
parent665d2d7ec8dd1465538c83df95e29c23de2cffcb (diff)
parent75e26b091f6aae38c9edb069c173bcb04ae3ffd1 (diff)
Merge "Updated documentation"
Diffstat (limited to 'docs/4a-framework/README.md')
-rw-r--r--docs/4a-framework/README.md42
1 files changed, 42 insertions, 0 deletions
diff --git a/docs/4a-framework/README.md b/docs/4a-framework/README.md
new file mode 100644
index 0000000..90de65b
--- /dev/null
+++ b/docs/4a-framework/README.md
@@ -0,0 +1,42 @@
+# 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
+
+![applications architecture diagram](images/apps-architecture.svg)
+
+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
+
+![4a's architecture diagram](images/4a-architecture.svg)
+
+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.