1 files changed, 31 insertions, 0 deletions
diff --git a/docs/4a-framework/components.md b/docs/4a-framework/components.md
new file mode 100644
index 0000000..e63fd52
--- /dev/null
+++ b/docs/4a-framework/components.md
@@ -0,0 +1,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.
+\ No newline at end of file