Load libasound at runtime, or make the ALSA host optional, so Linux binaries don't require libasound

Aperta
  • Qualcosa non va?
#1,421 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
14/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
linux, rust
Ambito
build-system

Direzione di ricerca

Start with the ALSA host's is_available(), which currently returns a hardcoded true, and the Host::new(), default_host() and available_hosts() paths that depend on it. The alsa-sys dependency and its pkg-config link are where the runtime-loading option would go. The issue asks for a maintainer decision between two designs (dlopen in alsa-sys, or a default-on alsa feature), so it is not ready for a patch yet. Done would be an agreed design plus a build with no libasound in NEEDED.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

dependencies host - alsa platform - linux

Problem

On Linux and the BSDs, cpal always depends on alsa, and alsa-sys links libasound through pkg-config. So every binary that uses cpal has libasound.so.2 in NEEDED, and that has two costs:

  • At run time, the binary won't start without libasound (error while loading shared libraries: libasound.so.2), even when audio is an optional part of a larger program and the host never touches a device: a headless server, a minimal container, a CI runner.
  • At build time, every build needs the ALSA headers and pkg-config (libasound2-dev), including cargo install on a machine that only wants the non-audio parts. This also gets in the way of cross and static builds (see #982 and diwic/alsa-sys#10).

The ALSA host's is_available() is the natural place to report this, but today it returns a hardcoded true.

Proposal

Either of these would solve it. The first is preferred, because it keeps raw ALSA on hosts without a sound server.

  1. Load libasound at runtime (dlopen). An opt-in feature in which the ALSA host resolves the snd_* symbols from libasound.so.2 on first use. is_available() returns false when the library is missing, Host::new() returns HostUnavailable, and default_host()/available_hosts() fall through. The loading would most naturally live in alsa-sys behind a feature (bindgen can generate a dynamic-loading wrapper), and cpal would forward it. The build then needs no ALSA headers or pkg-config either. This is how other audio stacks handle it: SDL (SDL_AUDIO_DRIVER_ALSA_DYNAMIC), miniaudio (runtime linking by default), and Firefox's cubeb all dlopen libasound.
  2. Make the ALSA host optional on Linux. A default-on alsa feature, so a build with default-features = false, features = ["pulseaudio"] uses only the PulseAudio host. That host is built on the pure-Rust pulseaudio protocol crate, so the build needs no system audio library at all. The cost is that hosts without a sound server have no devices. This is close to the alsa feature being considered for FreeBSD in #1404 (also mentioned in #988 and asked about in #929), extended to Linux.

Use case

moq ships moq-cli, a tool for publishing and playing live media, as prebuilt binaries and through cargo install. Microphone capture and speaker playback go through cpal (0.18.2). On Linux, cpal is the one dependency that links a system library at load time: camera capture needs none, and our hardware video codecs (VA-API, NVENC) already dlopen theirs. So capture and playback are off by default today. Turning them on would make every Linux user install libasound2-dev to cargo install, and the same binary that runs on a desktop wouldn't start on a server or in a container without ALSA, even when it's only publishing a file. We'd like to ship one Linux binary that uses ALSA (or PulseAudio) where it exists and reports no audio host where it doesn't.

(Written by Opus 5.5)

Lingua principale
Rust
Stelle
4k
Fork
554
Merge medio
3g 3h
PR unite (30g)
4

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di RustAudio/cpal

Tutte le issue di RustAudio/cpal

Issue simili

Altre issue su Rust

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.