[PR #786] [CLOSED] Add CPAL backend #1079

New issue

Closed

opened 2026-02-27 20:01:04 +03:00 by kerem · 0 comments

kerem commented

2026-02-27 20:01:04 +03:00

Owner

📋 Pull Request Information

Original PR: https://github.com/librespot-org/librespot/pull/786
Author: @roderickvd
Created: 6/1/2021
Status: ❌ Closed

Base: dev ← Head: cpal-backend

📝 Commits (10+)

998fc02 Add cpal backend
938029b Merge remote-tracking branch 'Johannesd3/cpal-backend-simple' into cpal-backend
cf3b7df Use default format when requested format is unsupported
9de54f4 Implement start/stop for CPAL
3962d63 Fix compilation on Rust < 1.50
23ed104 Tune ring buffer size
d8ab4bd Add cpaljack backend
f648c9f Use generic instead of macro
939e081 Fix build for cpaljack without cpal backend
6c45a1a Buffer size is in elements not bytes

📊 Changes

5 files changed (+345 additions, -5 deletions)

View changed files

📝 Cargo.lock (+16 -0)
📝 Cargo.toml (+4 -2)
📝 playback/Cargo.toml (+6 -3)
➕ playback/src/audio_backend/cpal.rs (+312 -0)
📝 playback/src/audio_backend/mod.rs (+7 -0)

📄 Description

This is a working CPAL backend based on the extensive initial work by @Johannesd3 (thanks!).

The intention is to deprecate Rodio in favour of CPAL: Rodio is based on CPAL, and builds on it, but there is nothing extra we need in Rodio that isn't already in CPAL. This has been discussed in various places, notably #648 and https://github.com/librespot-org/librespot/discussions/734#discussioncomment-725127.

So far I have successfully tested this backend on Linux (S16, F32) and macOS (F32).

Todo

Pass the build on MSRV
Test on Windows (help needed: I don't have Windows machines to compile on)
Refactor slightly to bring it more in line with the other backends
Implement a companion CpalJack variant (like we also have RodioJack)
Promote it to default backend status

Open questions

What do we want to do with the Rodio backend for the upcoming release: replace it with CPAL? Or keep it around for planned deprecation in a release sometime later?
The code that checks whether the requested audio format is available, or falls back to the system default otherwise, actually returns the highest supported audio format by default. Currently librespot defaults to S16 but this code gives another opportunity: we could change format selection to an Option<AudioFormat>, selecting the highest quality by default unless specified otherwise. For other backends, that do not easily support querying supported formats, we could still default to S16 unless specified otherwise. Should we get this in or leave it be? This would be another PR but I'd first like to hear your thoughts before I put time in. No it would work with idiosyncracies for every backend and not be very transparent to the user.
For an out-of-the-box experience on Windows, we need resampling. Do we want to add this, or forget about this PR and stick with Rodio? See: https://github.com/librespot-org/librespot/pull/786#issuecomment-852891109

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/librespot-org/librespot/pull/786 **Author:** [@roderickvd](https://github.com/roderickvd) **Created:** 6/1/2021 **Status:** ❌ Closed **Base:** `dev` ← **Head:** `cpal-backend` --- ### 📝 Commits (10+) - [`998fc02`](https://github.com/librespot-org/librespot/commit/998fc02323080155418ceccd0ae28e945d39d417) Add cpal backend - [`938029b`](https://github.com/librespot-org/librespot/commit/938029bcb774e92c02ba08fd863ec7e16e79c8ba) Merge remote-tracking branch 'Johannesd3/cpal-backend-simple' into cpal-backend - [`cf3b7df`](https://github.com/librespot-org/librespot/commit/cf3b7df6250948e2c92e16b7fc376ff5dee632a0) Use default format when requested format is unsupported - [`9de54f4`](https://github.com/librespot-org/librespot/commit/9de54f435c6a374c04225e84606aaf883c3d9607) Implement start/stop for CPAL - [`3962d63`](https://github.com/librespot-org/librespot/commit/3962d638481c48298f9b799f316a33a76048ae71) Fix compilation on Rust < 1.50 - [`23ed104`](https://github.com/librespot-org/librespot/commit/23ed1042fc929c3319a659e39d868a9c9ebeb65a) Tune ring buffer size - [`d8ab4bd`](https://github.com/librespot-org/librespot/commit/d8ab4bdaa08ee61c9743dff3add06bac1114cf51) Add `cpaljack` backend - [`f648c9f`](https://github.com/librespot-org/librespot/commit/f648c9fcb70f03c40c7004432d1f81f6c6e2e17f) Use generic instead of macro - [`939e081`](https://github.com/librespot-org/librespot/commit/939e081fd06a2232346be63c353eb08f080f27db) Fix build for `cpaljack` without `cpal` backend - [`6c45a1a`](https://github.com/librespot-org/librespot/commit/6c45a1a19095850354e35eb05ec18d39186073d4) Buffer size is in elements not bytes ### 📊 Changes **5 files changed** (+345 additions, -5 deletions) <details> <summary>View changed files</summary> 📝 `Cargo.lock` (+16 -0) 📝 `Cargo.toml` (+4 -2) 📝 `playback/Cargo.toml` (+6 -3) ➕ `playback/src/audio_backend/cpal.rs` (+312 -0) 📝 `playback/src/audio_backend/mod.rs` (+7 -0) </details> ### 📄 Description This is a working CPAL backend based on the extensive initial work by @Johannesd3 (thanks!). The intention is to deprecate Rodio in favour of CPAL: Rodio is based on CPAL, and builds on it, but there is nothing extra we need in Rodio that isn't already in CPAL. This has been discussed in various places, notably #648 and https://github.com/librespot-org/librespot/discussions/734#discussioncomment-725127. So far I have successfully tested this backend on Linux (`S16`, `F32`) and macOS (`F32`). ### Todo - [x] Pass the build on MSRV - [ ] Test on Windows (help needed: I don't have Windows machines to compile on) - [x] Refactor slightly to bring it more in line with the other backends - [x] Implement a companion `CpalJack` variant (like we also have `RodioJack`) - [ ] Promote it to default backend status ### Open questions 1. What do we want to do with the Rodio backend for the upcoming release: replace it with CPAL? Or keep it around for planned deprecation in a release sometime later? 2. ~~The code that checks whether the requested audio format is available, or falls back to the system default otherwise, actually returns the highest supported audio format by default. Currently `librespot` defaults to `S16` but this code gives another opportunity: we could change format selection to an `Option<AudioFormat>`, selecting the highest quality by default unless specified otherwise. For other backends, that do not easily support querying supported formats, we could still default to `S16` unless specified otherwise. Should we get this in or leave it be? This would be another PR but I'd first like to hear your thoughts before I put time in.~~ No it would work with idiosyncracies for every backend and not be very transparent to the user. 3. For an out-of-the-box experience on Windows, we need resampling. Do we want to add this, or forget about this PR and stick with Rodio? See: https://github.com/librespot-org/librespot/pull/786#issuecomment-852891109 --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>

kerem

2026-02-27 20:01:04 +03:00

closed this issue
added the
pull-request
label

kerem referenced this issue

2026-02-27 20:01:38 +03:00

[PR #1079] [MERGED] Fix bug where playlists containing a local track would fail to load #1224

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

starred/librespot#1079

No description provided.

Rows
Columns