diff options
Diffstat (limited to 'docs/1.Introduction.md')
| -rw-r--r-- | docs/1.Introduction.md | 24 |
1 files changed, 13 insertions, 11 deletions
diff --git a/docs/1.Introduction.md b/docs/1.Introduction.md index e189c7c..c36717c 100644 --- a/docs/1.Introduction.md +++ b/docs/1.Introduction.md @@ -3,7 +3,7 @@ Introduction ## Problem -The existing solution contains the following drawbacks: +The existing audio solution in [AGL](https://www.automotivelinux.org/) (Automotive Grade Linux) utilizes the ALSA loopback module together with [4a-softmixer](https://github.com/iotbzh/4a-softmixer). There are drawbacks to this solution: 1. Non-generic interface for configurable hardware cases @@ -17,20 +17,22 @@ The existing solution contains the following drawbacks: - Substreams cannot have SMACK labels applied, inherently leaving different audio streams insecure, or a single label applied to all. -## AVIRTs Solution +## The AVIRT Solution -The ALSA Virtual Sound Driver (AVIRT) aims to provide a Linux kernel solution to the issue of audio routing in kernel-space, as well as security per-stream, and dynamic configuration of streams at the kernel level. +The ALSA Virtual Sound Driver (AVIRT) aims to provide a Linux kernel solution to the issue of audio routing in kernel-space, as well as security per audio stream, and dynamic configuration of audio streams at the kernel level. -A top-level abstract dynamic audio driver is presented to the user-space via an ALSA middle-layer card. From there, respective low-level "real" audio drivers can subscribe to it as an "Audio Path". +AVIRT addresses the aforementioned problems by: -The top-level driver is configured (currently) using by utilising configfs. +1. Providing a standard user-space interface via `configfs` to configure a variable number of 'streams' which can be mapped to audio paths. +2. Optimize the audio routing by connecting directly with the desired audio path. This can include routing audio through directly to hardware, to an implemented loopback interface, or to a DSP. +3. Each 'stream' is separated to its own ALSA PCM device, therefore differing security attributes can be applied to each 'stream'. This means that each of the audio roles can have separate security contexts from one another. -AVIRT attempts to address the aforementioned problems by: +A top-level abstract dynamic audio driver is presented to the user-space via an ALSA middle-layer card. The card's PCM devices are configured using `configfs` via the accompanying userspace library [libavirt](https://github.com/fiberdyne/libavirt). The low-level "real" audio drivers can subscribe to the top-level as an "Audio Path". The Audio Path accepts routed audio streams from the abstracted top-level, and is then able to direct the audio streams accordingly. -1. Providing a standard interface through configfs to configure a variable number of 'streams' which can be mapped to audio paths. -2. Optimize the audio routing by connecting directly with the desired audio path. This can include routing audio through directly to hardware, or to an implemented loopback interface. -3. Each 'stream' is separated to its own device, therefore security can be applied to each 'stream'. This means that each of the audio roles can be separately secured from each other. + -A sample dummy Audio Path is provided as an example to show how a low-level audio driver would subscribe to AVIRT, and accept audio routing for playback. +The following Audio Paths are currently implemented for AVIRT: -Currently, the Fiberdyne DSP hardmixer is supported on the Renesas R-Car M3 AGL reference platform, and the default loopback softmixer can be used to emulate this in cases where the former is not available. +- **ap_dummy** - This is provided as an example to show how a low-level audio driver would subscribe to AVIRT, and accept audio routing for playback. +- **ap_fddsp** - This is the Fiberdyne DSP hardmixer. This is only supported on the Renesas R-Car M3 AGL reference platform, and utilizes the HiFi2 DSP core to provide advanced DSP and audio mixing. An accompanying UI can be used to control the DSP parameters. +- **ap_loopback** - This is the default loopback for use with the softmixer. This is the stock AGL solution to be used to emulate the hardmixer when not available. |