Files
Psychotoxical 34b4445c13 feat(lyrics): YouLyPlus karaoke + fix(macos): suppress mic prompt
Two independent user-facing fixes rolled together.

── Lyrics: YouLyPlus provider (issue #172) ──
Adds word-by-word synced (karaoke) lyrics as an alternative lyrics mode.
Backed by the public lyricsplus aggregator (Apple Music / Spotify /
Musixmatch / QQ Music) — no API keys on our side, subscription costs are
borne by the backend operator. Five mirrors are tried on network failure.

Settings → Lyrics now exposes a mode radio (Standard vs YouLyPlus) plus
a static-only toggle. YouLyPlus misses silently fall back to the existing
server + LRCLIB + Netease pipeline so obscure tracks still resolve. The
drag-to-reorder source list is hidden in YouLyPlus mode since the
external aggregator manages its own source priority.

Rendering: per-word spans on each line, active word highlighted with
accent-tinted glow. Subscribed imperatively via usePlayerStore.subscribe
so 500 ms progress ticks do not re-render the whole lyrics block. The
Fullscreen Player reuses the same pattern; the 5-line rail layout is
unchanged. white-space: pre on .fs-lyric-word preserves the trailing
spaces the API embeds in each syllabus token (flex context would
otherwise collapse them).

i18n: new keys in all 8 locales (de, en, fr, nl, nb, ru, es, zh).

── macOS mic-prompt suppression ──
Ships a vendored cpal 0.15.3 at patches/cpal-0.15.3/ wired via
[patch.crates-io]. The only change is in src/host/coreaudio/macos/mod.rs:
audio_unit_from_device now unconditionally uses IOType::DefaultOutput for
output streams instead of conditionally choosing HalOutput.

AUHAL (HalOutput) is classified as input-capable by macOS TCC and
triggers the microphone-permission dialog at first launch / after each
update even for playback-only apps. Previous attempts (removing
NSMicrophoneUsageDescription, setting com.apple.security.device.audio-input
false in Entitlements.plist) did not suppress the prompt because TCC
fires at AudioUnit instantiation, not at plist level. The upstream fix
in cpal PR #1070 / cpal 0.17 only helps when the pinned device equals
the system default; always-DefaultOutput covers all cases.

Tradeoff: per-device output selection is a no-op on macOS — the stream
always follows the system default. Settings.tsx surfaces this via
audioOutputDeviceMacNotice (hides the CustomSelect on macOS) and skips
audio_list_devices + device-watcher effects there. Matches the behaviour
of Apple Music / Spotify on macOS.

Also removes the now-obsolete com.apple.security.device.audio-input
entitlement (sandbox is disabled anyway, so it was ignored).

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-04-17 21:30:31 +02:00

6.5 KiB

CPAL - Cross-Platform Audio Library

Actions Status Crates.io docs.rs

Low-level library for audio input and output in pure Rust.

This library currently supports the following:

  • Enumerate supported audio hosts.
  • Enumerate all available audio devices.
  • Get the current default input and output devices.
  • Enumerate known supported input and output stream formats for a device.
  • Get the current default input and output stream formats for a device.
  • Build and run input and output PCM streams on a chosen device with a given stream format.

Currently, supported hosts include:

  • Linux (via ALSA or JACK)
  • Windows (via WASAPI by default, see ASIO instructions below)
  • macOS (via CoreAudio)
  • iOS (via CoreAudio)
  • Android (via Oboe)
  • Emscripten

Note that on Linux, the ALSA development files are required. These are provided as part of the libasound2-dev package on Debian and Ubuntu distributions and alsa-lib-devel on Fedora.

Compiling for Web Assembly

If you are interested in using CPAL with WASM, please see this guide in our Wiki which walks through setting up a new project from scratch.

Feature flags for audio backends

Some audio backends are optional and will only be compiled with a feature flag.

  • JACK (on Linux): jack
  • ASIO (on Windows): asio

Oboe can either use a shared or static runtime. The static runtime is used by default, but activating the oboe-shared-stdcxx feature makes it use the shared runtime, which requires libc++_shared.so from the Android NDK to be present during execution.

ASIO on Windows

ASIO is an audio driver protocol by Steinberg. While it is available on multiple operating systems, it is most commonly used on Windows to work around limitations of WASAPI including access to large numbers of channels and lower-latency audio processing.

CPAL allows for using the ASIO SDK as the audio host on Windows instead of WASAPI.

Locating the ASIO SDK

The location of ASIO SDK is exposed to CPAL by setting the CPAL_ASIO_DIR environment variable.

The build script will try to find the ASIO SDK by following these steps in order:

  1. Check if CPAL_ASIO_DIR is set and if so use the path to point to the SDK.
  2. Check if the ASIO SDK is already installed in the temporary directory, if so use that and set the path of CPAL_ASIO_DIR to the output of std::env::temp_dir().join("asio_sdk").
  3. If the ASIO SDK is not already installed, download it from https://www.steinberg.net/asiosdk and install it in the temporary directory. The path of CPAL_ASIO_DIR will be set to the output of std::env::temp_dir().join("asio_sdk").

In an ideal situation you don't need to worry about this step.

Preparing the build environment

  1. bindgen, the library used to generate bindings to the C++ SDK, requires clang. Download and install LLVM from here under the "Pre-Built Binaries" section. The version as of writing this is 17.0.1.

  2. Add the LLVM bin directory to a LIBCLANG_PATH environment variable. If you installed LLVM to the default directory, this should work in the command prompt:

    setx LIBCLANG_PATH "C:\Program Files\LLVM\bin"
    
  3. If you don't have any ASIO devices or drivers available, you can download and install ASIO4ALL. Be sure to enable the "offline" feature during installation despite what the installer says about it being useless.

  4. Our build script assumes that Microsoft Visual Studio is installed if the host OS for compilation is Windows. The script will try to find vcvarsall.bat and execute it with the right host and target machine architecture regardless of the Microsoft Visual Studio version. If there are any errors encountered in this process which is unlikely, you may find the vcvarsall.bat manually and execute it with your machine architecture as an argument. The script will detect this and skip the step.

    A manually executed command example for 64 bit machines:

    "C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Auxiliary\Build\vcvarsall.bat" amd64
    

    For more information please refer to the documentation of `vcvarsall.bat``.

  5. Select the ASIO host at the start of our program with the following code:

    let host;
    #[cfg(target_os = "windows")]
    {
       host = cpal::host_from_id(cpal::HostId::Asio).expect("failed to initialise ASIO host");
    }
    

    If you run into compilations errors produced by asio-sys or bindgen, make sure that CPAL_ASIO_DIR is set correctly and try cargo clean.

  6. Make sure to enable the asio feature when building CPAL:

    cargo build --features "asio"
    

    or if you are using CPAL as a dependency in a downstream project, enable the feature like this:

    cpal = { version = "*", features = ["asio"] }
    

Updated as of ASIO version 2.3.3.

Cross compilation

When Windows is the host and the target OS, the build script of asio-sys supports all cross compilation targets which are supported by the MSVC compiler. An exhaustive list of combinations could be found here with the addition of undocumented arm64, arm64_x86, arm64_amd64 and arm64_arm targets. (5.11.2023)

It is also possible to compile Windows applications with ASIO support on Linux and macOS.

For both platforms the common way to do this is to use the MinGW-w64 toolchain.

Make sure that you have included the MinGW-w64 include directory in your CPLUS_INCLUDE_PATH environment variable. Make sure that LLVM is installed and include directory is also included in your CPLUS_INCLUDE_PATH environment variable.

Example for macOS for the target of x86_64-pc-windows-gnu where mingw-w64 is installed via brew:

export CPLUS_INCLUDE_PATH="$CPLUS_INCLUDE_PATH:/opt/homebrew/Cellar/mingw-w64/11.0.1/toolchain-x86_64/x86_64-w64-mingw32/include"