# Audio
Source: [https://docs.qualcomm.com/doc/80-88500-4/topic/140_Audio.html](https://docs.qualcomm.com/doc/80-88500-4/topic/140_Audio.html)
The audio subsystem allows a user space application to capture audio and request
playback. The abstraction to the audio subsystem is provided by PulseAudio.
The PulseAudio is the sound server supported on the platform. A GStreamer application can
open the pulsesink and pulsesrc elements to render and capture the audio respectively.
Further, the captured audio can be rendered out to a ROS2 node for further processing.
The audio subsystem can be accessed through either of the following:
- GST pulse elements (sink and src)
- Pulse client (this is a possibility where a user application can create a pulse client to access the audio data via the PulseAudio)
Figure : Flow for audio capture and playback
Note: For more information on the Smart Audio platform, see [http://www.qualcomm.com/products/internet-of-things/consumer/audio](http://www.qualcomm.com/products/internet-of-things/consumer/audio).
## PulseAudio recording
The following flow diagram shows the sequence for a record session:
The figure shows the following major elements:
- Client application: Any GStreamer-based application or applications directly built on
top of the PulseAudio client abstraction.
- Protocol native: The communication layer interfacing with the PulseAudio server.
- Record stream: The stream that is holding the recorded data, which is consumed by the
client application.
- Source output: The stream data that is pushed to the source.
- Source: The device that produces the data.
## PulseAudio sources
The following code provides the PulseAudio sources, which can be used to record various use
cases:
[Source regular0]
description = qahw source to capture pcm via regular record path
type = regular
flags = AUDIO_INPUT_FLAG_NONE
default-encoding = pcm
default-sample-rate = 48000
default-sample-format = s16le
default-channel-map = front-left,front-right
encodings = pcm
port-names = builtin-mic
presence = always
source-type = AUDIO_SOURCE_MICCopy to clipboard
The recording use case is differentiated based on the flags received from the PulseAudio
module. The table lists the recording modes that are supported:
| Mode name | Description |
| --- | --- |
| Compress | In this mode, the encoded packets are received by the APSS directly from the
audio DSP; it is supported for AMR WB format only. |
| Non-tunnel |
- In this mode, the pulse code modulation (PCM) data from the mic is
preprocessed in DSP and received by APSS.
- APSS then encodes the PCM to the required encoding format by using the
DSP-based or software-based encoder.
|
The figure shows the flow of data during audio recording:
- **[Audio playback use case](https://docs.qualcomm.com/doc/80-88500-4/topic/audio_playback_use_case.html)**
The PulseAudio module exposes many sink and sources to the PulseAudio core and selects the appropriate sink/source based on stream type. The playback modes are differentiated based on the flags received from the PulseAudio module.
- **[Audio DSP](https://docs.qualcomm.com/doc/80-88500-4/topic/141_DSP.html)**
The audio DSP (aDSP) is the DSP component responsible for capture and playback.
Last Published: Aug 18, 2023
[Previous Topic
Graphics features](https://docs.qualcomm.com/bundle/publicresource/80-88500-4/topics/139_Graphics_features.md) [Next Topic
Audio playback use case](https://docs.qualcomm.com/bundle/publicresource/80-88500-4/topics/audio_playback_use_case.md)