Scroll to navigation

dsprpcd(8) System Administration dsprpcd(8)

NAME

adsprpcd, cdsprpcd, gdsprpcd, sdsprpcd - FastRPC DSP daemon

SYNOPSIS

adsprpcd [-h | --help] pd_name domain
cdsprpcd [-h | --help] pd_name domain
gdsprpcd [-h | --help] pd_name domain
sdsprpcd [-h | --help] pd_name domain

DESCRIPTION

dsprpcd is a userspace daemon that establishes and maintains FastRPC communication between the application processor (HLOS: High-Level Operating System, e.g., Linux) and a Digital Signal Processor (DSP).

The daemon is typically executed under different names (adsprpcd, cdsprpcd, gdsprpcd, sdsprpcd), with each name targeting a specific DSP domain:

Audio DSP (ADSP)
Compute DSP (CDSP)
General purpose DSP (GDSP)
Sensor DSP (SDSP)

The daemon acts as a default listener for DSP Protection Domains (PDs), handling reverse-RPC requests from DSP firmware that require host-side services.

A Protection Domain is an isolated process and memory space that lets a component run independently so it can be restarted without affecting others.

These services include:

•
File system access via host-side interfaces (e.g., file open, read, write operations)
•
Dynamic memory allocation requests from DSP to host memory
•
Logging of DSP messages and exceptions

The daemon typically runs in the foreground and may be managed by init systems (e.g., systemd) for automatic restart and lifecycle management.

It communicates with the DSP through FastRPC device nodes, typically located under: /dev/fastrpc-*

The daemon requires appropriate permissions to access these device nodes and to perform system-level operations.

When running, the daemon maintains a persistent session with the DSP and processes incoming requests in an event-driven manner.

OPTIONS

Display help information and exit.

Start the daemon for a specific Protection Domain (PD) and DSP domain.

The domain identifies the specific DSP instance. Some DSP types provide multiple instances (e.g., cdsp0, cdsp1), while others have a single instance (e.g., adsp). In such cases, the domain argument is primarily relevant for DSPs with multiple instances.

Examples:
rootpd adsp
rootpd cdsp0
rootpd gdsp0
rootpd sdsp

FUNCTIONALITY

rootpd (Root PD / Guest OS)

Usage:

cdsprpcd
cdsprpcd rootpd cdsp1

Purpose: Attaches to the DSP Root Protection Domain (PD), which runs the guest operating system (typically QuRT). It acts as the default listener for reverse-RPC requests.

Provides file operations for components running in the Root PD. Dynamic loading (dlopen) is not supported in Root PD due to security constraints.

Routes DSP exception logs to host logging (syslog/dmesg), which is the primary client-facing use case.

Services:

•
Exception logging via host logging facilities
•
Remote file system access for Root PD components

Note: It is recommended to run the root PD daemon if visibility of DSP exception logs from dynamic Protection Domains is required.

audiopd (Audio PD)

Usage:

adsprpcd audiopd adsp

Purpose: Attaches to the Audio Protection Domain and serves reverse-RPC for audio workloads.

Supports dynamic loading of audio modules and manages memory allocation requests originating from audio components.

Services:

•
Dynamic memory allocation via RPC mechanisms
•
Dynamic module loading for audio components

sensorspd (Sensors PD)

Usage:

adsprpcd sensorspd

Purpose: Handles FastRPC requests originating from sensor DSP components and processed by a host-side daemon. Unlike typical FastRPC usage, Sensors PD supports connections from multiple applications simultaneously rather than a one-to-one process mapping.

Services:

•
File system operations on behalf of sensor DSP components
•
Dynamic loading of shared objects required by sensor workloads
•
Handling of FastRPC requests from multiple client applications connected to Sensors PD

FILES

Listener implementation for ADSP
Listener implementation for SDSP
Listener implementation for CDSP and GDSP

SEE ALSO

fastrpc(3)

May 2026 fastrpc