Sound Open Firmware infrastructure provides an open source, development-centric environment that includes architecture-agnostic, real-time control pieces, and open source tools.


Sound Open Firmware aims to democratize audio firmware and its development in the community by:

  • Providing a platform agnostic open source audio DSP firmware and developer tools.
  • Providing you the freedom to use open source and or proprietary development tool chain of your choice.
  • Producing a set of high quality and tunable open source audio processing component to accompany the firmware.

Firmware Architecture

The firmware architecture is split into four main sections:

Firmware Architecture

  1. Audio Components: The audio components can be used to form an audio processing pipeline from the host Direct Memory Access (DMA) buffer to the DSP digital audio interface. Audio components have a source and sink buffer where they usually transform or route audio data as part of their processing.
  2. Generic Micro Kernel: The micro kernel manages and abstracts the DSP hardware for the rest of the system. It also exports C APIs for memory allocation, scheduling work, event notifications and power management.
  3. Platform Drivers: The platform drivers control any external IP to the DSP IP. This will usually be things like DMA engines or Digital Audio Interface (DAI) controllers. These drivers are used by the audio components and pipelines to send/receive data to/from the host and external codecs.
  4. Audio Tasks: The audio task manages the audio pipelines at run time. It manages the transportation of data from source to sink component within the pipeline. The pipelines are currently statically defined in the firmware, but infrastructure is now in place to allow the dynamic creation of pipelines from Linux userspace.

Driver Architecture

The driver architecture is also split into four sections or layers, like a protocol stack, each with a different purpose.

Driver Architecture

  1. Machine Driver: The ASoC machine driver does all the machine/board audio hardware integration. It also glues the platform driver and drivers for any codec(s) together so they appear as a single ALSA sound card. Sound Open Firmware can reuse existing upstream machine drivers (as only the platform name need change) or can have custom machine drivers.
  2. Generic PCM Driver: The PCM driver creates ALSA PCMs, DAPM and kcontrols based on the topology data loaded at run time. The PCM driver also allocates buffers for DMA and registers with run time PM. It is architecture and platform generic code.
  3. Generic IPC driver: The IPC driver is the messaging bridge between the host and DSP and defines the messaging ABI and protocol. It is architecture and platform generic code.
  4. DSP Platform Driver: The platform driver is a platform specific driver that abstracts the low level platform DSP hardware into a common generic API that is used by the upper layers. This includes code that will initialize the DSP and boot the firmware.

Software Development Kit

The Sound Open Firmware SDK provides you with the tools to develop, debug, integrate, tune and deploy firmware as well as audio processing components, pipelines and drivers. You have the flexibility to select and use tools from the open source community or from proprietary vendors.

The SDK can also be wrapped inside a Docker™ container for easy installation and deployment within your development teams, so there is no need to locally modify your development environment specifically for Sound Open Firmware.