interdependencies (MAP ? ) of Audio subsystem packages ?

[drsnx60]

Hi,

is there a list /map on how to put together all the Audio Drivers /subsystems and which module is dependent on the other ?

ALSA , JACK, SNDIO , PULSEAUDIO, OSS, PORTAUDIO, PIPEWIRE , LDSPA , SPEEX. OPENAL, and more

As dozens of ports have multiple choices for audio drivers its a challenge to build a consistent set across desktop managers and applications.

If for ex: ffmpeg has a different selection of subsystems compared to Gnome/Mate/KDE and a video decoder such as MPV with yet another set of audio options,
the whole setup becomes unusable probably.

A "modern" Motherboard have some Audio circuitry that attached a HDA OS-level kernel driver.
On TOP of the Kernel HDA driver, in Userland, we will have the above list of Audio subsystems .
HANDBOOK has a section about setting up the Kernel audio-driver , but does not dive into the topic of desktop/apps audio subsystems.

so when you design a Desktop environment:

which audio subsystems are mutually exclusive ?
which are congenial neighbors ?
which are interdependent ?
what is the mission statement for each audio package ? which job does it perform ?

 

[cracauer@]

It's variable.

Many of those have various backends to stack them on different things. For example, on Linux it is not uncommon to have a stack like this:
- ALSA as in the hardware driver
- PULSE on top of ALSA
- ALSA as in the compatibility library sitting on top on pulse

Myself I use a stack like this:
- OSS or ALSA as in the hardware layer
- jack demon for important things
- pulse on top of jack for the rest of the junk incl. web browsers

 

[drsnx60]

It's variable.

Many of those have various backends to stack them on different things. For example, on Linux it is not uncommon to have a stack like this:
- ALSA as in the hardware driver
- PULSE on top of ALSA
- ALSA as in the compatibility library sitting on top on pulse

Myself I use a stack like this:
- OSS or ALSA as in the hardware layer
- jack demon for important things
- pulse on top of jack for the rest of the junk incl. web browsers

very good.
When compiling Audio Ports, most of them can be built with the other drivers/subsystems as plugins. ( some examples below )

To construct the dependency tree you describe , are the options to be selected from the kernel to userland or
from userland towards kernel ?

eg KDE6/Plasma6 -> Pulse -> JACK -> ALSA -> kernel or the other way around. ?

Does this imply that PulseAudio is to include the JACK plugin ?
that JACK is to include the ALSA plugin ?
Or how is this dependency tree constructed ?

sorry but im just trying to make sense of this


root@sh570r6:/var/db/ports # cat audio_pulseaudio/options
# This file is auto-generated by 'make config'.
# Options for pulseaudio-17.0_3
_OPTIONS_READ=pulseaudio-17.0_3
_FILE_COMPLETE_OPTIONS_LIST=AVAHI GSETTINGS SIMD TEST X11 TDB GDBM SIMPLE ALSA JACK SOXR SPEEX WEBRTC_AEC
OPTIONS_FILE_SET+=AVAHI
OPTIONS_FILE_UNSET+=GSETTINGS
OPTIONS_FILE_SET+=SIMD
OPTIONS_FILE_UNSET+=TEST
OPTIONS_FILE_SET+=X11
OPTIONS_FILE_UNSET+=TDB
OPTIONS_FILE_UNSET+=GDBM
OPTIONS_FILE_SET+=SIMPLE
OPTIONS_FILE_SET+=ALSA
OPTIONS_FILE_SET+=JACK
OPTIONS_FILE_SET+=SOXR
OPTIONS_FILE_SET+=SPEEX
OPTIONS_FILE_SET+=WEBRTC_AEC

root@sh570r6:/var/db/ports # cat audio_jack/options
# This file is auto-generated by 'make config'.
# Options for jackit-1.9.22_3
_OPTIONS_READ=jackit-1.9.22_3
_FILE_COMPLETE_OPTIONS_LIST=ALSA DBUS OPUS PROFILING SOSSO
OPTIONS_FILE_SET+=ALSA
OPTIONS_FILE_SET+=DBUS
OPTIONS_FILE_SET+=OPUS
OPTIONS_FILE_UNSET+=PROFILING
OPTIONS_FILE_UNSET+=SOSSO

root@sh570r6:/var/db/ports # cat audio_alsa-plugins/options
# This file is auto-generated by 'make config'.
# Options for alsa-plugins-1.2.12_1
_OPTIONS_READ=alsa-plugins-1.2.12_1
_FILE_COMPLETE_OPTIONS_LIST=FFMPEG JACK PULSEAUDIO SAMPLERATE SPEEX
OPTIONS_FILE_UNSET+=FFMPEG
OPTIONS_FILE_SET+=JACK
OPTIONS_FILE_SET+=PULSEAUDIO
OPTIONS_FILE_UNSET+=SAMPLERATE
OPTIONS_FILE_SET+=SPEEX

 

[cracauer@]

very good.
When compiling Audio Ports, most of them can be built with the other drivers/subsystems as plugins. ( some examples below )

To construct the dependency tree you describe , are the options to be selected from the kernel to userland or
from userland towards kernel ?

eg KDE6/Plasma6 -> Pulse -> JACK -> ALSA -> kernel or the other way around. ?

Does this imply that PulseAudio is to include the JACK plugin ?
that JACK is to include the ALSA plugin ?
Or how is this dependency tree constructed ?

sorry but im just trying to make sense of this

That diagram is userland to kernel.

On FreeBSD jackd sits on OSS and doesn't need changed options when compiling. Pulse needs to have the jack option enabled.

There are some ports that have a jack option that needs turning on, e.g. mplayer which I use for my music playing.

 

[Zare]

To construct the dependency tree you describe , are the options to be selected from the kernel to userland or
from userland towards kernel ?

eg KDE6/Plasma6 -> Pulse -> JACK -> ALSA -> kernel or the other way around. ?

Does this imply that PulseAudio is to include the JACK plugin ?
that JACK is to include the ALSA plugin ?
Or how is this dependency tree constructed ?

sorry but im just trying to make sense of this

Left to right, meaning left component must hook on to right's API.