mirror of
https://github.com/SerenityOS/serenity
synced 2024-09-06 17:06:31 +00:00
Base: Update Audio subsystem documentation
This commit is contained in:
parent
39dee6ad67
commit
834a3227f8
|
@ -6,11 +6,11 @@ Overview of the SerenityOS audio subsystem, including a brief description of [`/
|
||||||
|
|
||||||
(Note that familiarity with the basics of digitized audio, pulse code modulation (PCM), sample rate and bit depth is assumed.)
|
(Note that familiarity with the basics of digitized audio, pulse code modulation (PCM), sample rate and bit depth is assumed.)
|
||||||
|
|
||||||
SerenityOS structures audio into three groups of responsibilities: Audio drivers that talk to hardware and expose the `/dev/audio` device; the AudioServer that is responsible for talking to userland audio clients, mixing and processing audio, and controlling the hardware via the driver; the audio libraries LibAudio and LibDSP that facilitate easier handling of audio data for userland applications.
|
SerenityOS structures audio into three groups of responsibilities: The Kernel audio subsystem, including drivers that talk to hardware and expose (among others) the `/dev/audio` devices; the AudioServer that is responsible for talking to userland audio clients, mixing and processing audio, and controlling the hardware via the Kernel interfaces; the audio libraries LibAudio and LibDSP that facilitate easier handling of audio data for userland applications.
|
||||||
|
|
||||||
### Sample formats
|
### Sample formats
|
||||||
|
|
||||||
There are two primary sample formats used in SerenityOS. The `Sample` class in LibAudio provides the userland sample format. It contains 32-bit floating-point samples in multiple channels (currently 2; Stereo), which accurately represent mathematical audio signals between -1 and 1. The kernel audio interfaces use another audio format described in [audio(4)](help://man/4/audio) which userland need not worry about.
|
There are two primary sample formats used in SerenityOS. The `Sample` class in LibAudio provides the userland sample format. It contains 32-bit floating-point samples in multiple channels (currently 2; Stereo), which accurately represent mathematical audio signals between -1 and 1. The kernel audio interfaces use other audio formats described in [audio(4)](help://man/4/audio) which userland need not worry about.
|
||||||
|
|
||||||
### AudioServer
|
### AudioServer
|
||||||
|
|
||||||
|
@ -20,17 +20,20 @@ AudioServer is not present.
|
||||||
|
|
||||||
As with all system servers, AudioServer provides an IPC interface on `/tmp/session/%sid/portal/audio`, with `%sid` being
|
As with all system servers, AudioServer provides an IPC interface on `/tmp/session/%sid/portal/audio`, with `%sid` being
|
||||||
the current login session id. For specifics on how to talk to AudioServer, the IPC interface specifications are the best source
|
the current login session id. For specifics on how to talk to AudioServer, the IPC interface specifications are the best source
|
||||||
of information. For controlling mixer functionality, clients have the ability to obtain and change their own volume, or
|
of information. For controlling mixer functionality, clients have the ability to obtain and change their own volume.
|
||||||
the main volume and mute state.
|
|
||||||
|
|
||||||
Userland audio transmission happens via the AudioQueue. This is a shared memory circular queue which supports concurrent
|
Userland audio transmission happens via the AudioQueue. This is a shared memory circular queue which supports concurrent
|
||||||
lock-free writing and reading. The queue is created by the audio client and its shared memory file descriptor sent to
|
lock-free writing and reading. The queue is created by the audio client and its shared memory file descriptor sent to
|
||||||
the audio server. In order to use this queue, an audio application needs to split up its audio data into atomic chunks
|
the audio server. In order to use this queue, an audio application needs to split up its audio data into atomic chunks
|
||||||
that can then be provided to the queue. The application might need to wait around until the queue is empty in order to
|
that can then be provided to the queue. The application might need to wait around until the queue is empty in order to
|
||||||
write to it. For these reasons, there's a utility API in LibAudio's audio server IPC connection which allows audio
|
write to it. For these reasons, there's a utility API in LibAudio which allows audio
|
||||||
applications to send off a large chunk of samples which get progressively sent in the background.
|
applications to send off a large chunk of samples which get progressively sent in the background.
|
||||||
|
|
||||||
On the server → client side, AudioServer has "event" calls that the client receives. These are various mixer state changes (main volume, main mute, client volume).
|
On the server → client side, AudioServer has "event" calls that the client receives. These are various state changes relating to the client itself. Note that there are no "periodic" event calls relating to regular audio playback, such as a "buffer played" callback.
|
||||||
|
|
||||||
|
#### AudioManagerServer
|
||||||
|
|
||||||
|
AudioServer has a second IPC interface, the management interface. While the regular interface is intended for clients to be able to play audio and control the parameters of that playback, the management interface provides functionality to control AudioServer's internal behavior, such as output setup, global mixing control, as well as accessing other client's mixing properties like mute and volume. In most cases, a client needs to either access the client interface for playing audio, or the management interface for managing AudioServer itself; but not both at the same time.
|
||||||
|
|
||||||
### Libraries
|
### Libraries
|
||||||
|
|
||||||
|
@ -38,7 +41,7 @@ There are two complementary audio libraries.
|
||||||
|
|
||||||
#### LibAudio
|
#### LibAudio
|
||||||
|
|
||||||
LibAudio is the baseline audio library that provides common audio abstractions, such as audio buffers and samples. Additionally, an important feature of LibAudio are the Loaders and Writers. The Loader class provides a multitude of audio formats (currently: WAV, FLAC and MP3), can auto-detect the format of a file or stream and abstracts away the low-level complications of parsing and reading these formats. The various writer classes (currently: WAV) provide an abstraction over exporting audio in specific formats to disk.
|
LibAudio is the baseline audio library that provides common audio abstractions, such as audio buffers and samples. Additionally, an important feature of LibAudio are the Loaders and Writers. The Loader class provides a multitude of audio formats (for example: WAV, FLAC, and MP3), can auto-detect the format of a file or stream and abstracts away the low-level complications of parsing and reading these formats. The Encoder class provides an abstraction over exporting audio in specific formats (for example: WAV and FLAC) to disk.
|
||||||
|
|
||||||
#### LibDSP
|
#### LibDSP
|
||||||
|
|
||||||
|
@ -50,6 +53,8 @@ The following class diagram outlines the structure of LibDSP pertaining to DAW-l
|
||||||
|
|
||||||
LibDSP was started to support development efforts in Piano, but it is intended as a general-purpose audio processing library, building on the groundwork from LibAudio. Therefore, users of LibDSP must be familiar with LibAudio classes and concepts, as they are used extensively in LibDSP.
|
LibDSP was started to support development efforts in Piano, but it is intended as a general-purpose audio processing library, building on the groundwork from LibAudio. Therefore, users of LibDSP must be familiar with LibAudio classes and concepts, as they are used extensively in LibDSP.
|
||||||
|
|
||||||
|
LibDSP also contains a collection of general signal processing primitives, such as windowing functions and resamplers.
|
||||||
|
|
||||||
### Applications
|
### Applications
|
||||||
|
|
||||||
This is a non-exhaustive list of applications that use audio. Most of these follow the good practices laid out in this manual page and may serve as a template for new audio applications.
|
This is a non-exhaustive list of applications that use audio. Most of these follow the good practices laid out in this manual page and may serve as a template for new audio applications.
|
||||||
|
@ -59,6 +64,7 @@ This is a non-exhaustive list of applications that use audio. Most of these foll
|
||||||
* **SoundPlayer** is a UI audio file player with extra features such as playlist support and audio visualizations.
|
* **SoundPlayer** is a UI audio file player with extra features such as playlist support and audio visualizations.
|
||||||
* [**asctl**](help://man/1/asctl) is a command line audio server control utility.
|
* [**asctl**](help://man/1/asctl) is a command line audio server control utility.
|
||||||
* **Applets/Audio** (AudioApplet) is a taskbar applet for setting audio parameters through a UI.
|
* **Applets/Audio** (AudioApplet) is a taskbar applet for setting audio parameters through a UI.
|
||||||
|
* The [Browser](help://man/1/Applications/Browser) can play audio on websites.
|
||||||
|
|
||||||
### Volume
|
### Volume
|
||||||
|
|
||||||
|
@ -70,15 +76,13 @@ For example: A program may set its client volume to 0.5 and the audio will be pe
|
||||||
|
|
||||||
### Sample rate
|
### Sample rate
|
||||||
|
|
||||||
SerenityOS's audio system has no fixed sample rate. The sample rate is ultimately determined by the sound hardware and all parts of the system need to be aware of it. Audio samples passed to AudioServer are assumed to be at the system sample rate, meaning that audio applications need to query this sample rate and resample their audio data accordingly.
|
SerenityOS's audio system uses a variety of sample rates in different layers of the audio stack. For a client, one sample rate is relevant: The client's own sample rate. Audio samples passed to AudioServer are interpreted at the client sample rate, which may be changed at any time via a dedicated IPC API. The default sample rate is the current hardware sample rate, but clients are recommended to change the sample rate to whatever's most convenient for them, since this reduces the amount of resampling to be performed and therefore increases the audio quality. AudioServer uses independent hardware sample rates for audio devices, which may be configured via the management interface.
|
||||||
|
|
||||||
Although the sample rate can change at any time, it is considered a rarely-changing value and most applications don't handle sample rate changes during operation. Therefore, when the system sample rate is changed, audio applications may need to be re-opened.
|
|
||||||
|
|
||||||
## Files
|
## Files
|
||||||
|
|
||||||
* [/dev/audio](help://man/4/audio)
|
* [/dev/audio](help://man/4/audio)
|
||||||
* AudioApplet and AudioServer have settings which are managed by ConfigServer.
|
* AudioApplet and AudioServer have settings which are managed by ConfigServer.
|
||||||
* `/tmp/user/%uid/portal/audio`: AudioServer's IPC socket
|
* `/tmp/user/%uid/portal/audio`: AudioServer's client IPC socket
|
||||||
|
|
||||||
## See also
|
## See also
|
||||||
|
|
||||||
|
|
Loading…
Reference in a new issue