Support pipewire as host by Decodetalkers · Pull Request #1093 · RustAudio/cpal

Decodetalkers · 2026-01-06T12:20:27Z

Add support to pipewire

You can test it with pipewire feature open

Pipewire support use config to define rates. So the default config of cpal with pipewire can be changed through config like following.

cat ~/.config/pipewire/pipewire.conf.d/custom-rates.conf
context.properties = {
    default.clock.rate          = 48000
    default.clock.allowed-rates = [ 44100 48000 88200 96000 176400 192000 ]
}

Still problems left:

*~~once we do 'pipewire::init', we can only dequeue it after the whole thread. even put the function to another thread, the function still works.. But seems we can run init many times..~~ (Ok, seems it is not a problem, because in when we call init, the init action will only be called once. I think it will be ok)
*~~The crates by pipewire need edition 2024. I think that should be another pr.~~

Decodetalkers · 2026-01-06T14:59:35Z

Seems pipewire need edition 2024..

Decodetalkers · 2026-01-07T11:32:35Z

@roderickvd can you help review this pr? Thanks, and when can this crate be upgraded to edition 2024? I would also want to help

roderickvd · 2026-01-07T19:55:44Z

@roderickvd can you help review this pr?

Definitely will help you review it. Need a bit more time.

Thanks, and when can this crate be upgraded to edition 2024? I would also want to help

Actually cpal itself doesn't need to be upgraded to Rust 2024, it just needs a MSRV of Rust of 1.85 or higher to support dependencies that are Rust 2024 already.

When we can I'd like to stick cpal to Rust 2021 so we keep our MSRV down.

SuperKenVery · 2026-01-08T18:12:30Z

Super cool man! Happy to see cpal having better linux support, opening the possibility of loopback recording on Linux!

Decodetalkers · 2026-01-09T22:35:42Z

ok, only one ci that I cannot fix

Decodetalkers · 2026-01-10T16:25:00Z

ok cross-rs based on ubuntu20.04, so

Be-ing · 2026-01-15T22:56:15Z

How does this differ from #692?

Yes, it should be marked as Copy, but it should in another pr

I do not know if it is right. At least I should not set the rate

use "node.force-quantum" to force the buffer size

open the feature of v0_3_45

roderickvd

Thanks so much for this work! Let's focus on getting it merged for v0.18, and so I spent some time on a code review.

src/host/pipewire/mod.rs

roderickvd · 2026-02-21T18:39:11Z

src/host/pipewire/mod.rs

+    type Devices = Devices;
+    type Device = Device;
+    fn is_available() -> bool {
+        true


Could it test for availability like with a socket connection?

Ok, I have added a simple way to check it

src/host/pipewire/stream.rs

roderickvd · 2026-02-21T18:46:32Z

.github/workflows/platforms.yml


      - name: Run tests (all features)
-        run: cargo +${{ steps.msrv.outputs.all-features }} test --all-features --workspace --verbose
+        run: cargo +${{ steps.msrv.outputs.all-features }} test --features=jack --workspace --verbose


Please keep this test to compile with all features, and instead update the CI to include PipeWire similar to what we're doing with PulseAudio now (see latest master).

Doing so please also revert the MSRV for unrelated hosts (ALSA, AAudio, WASIP1).

It won't compile on cross, because the container of cross is ubuntu 20.04, which does not have pipewire. So I limited it to jack

And I have said before, pipewire need cargo over 1.85? So I modified it, but seems now it is too high. I also tried to upgrade the edition once for it

ok. I do not remember what trouble I met, and update the compiler. but seems now it all be good. Then it is fine, But I have said before. the cross-rs needs to be upgrade to ubuntu24.04, or it won't contain the package of pipewire. maybe I should also let it test PulseAudio

In f2f92ad what we did to have separate MSRVs for ALSA, JACK and PulseAudio and work with --all-features. You could copy that pattern.

src/host/mod.rs

src/host/pipewire/device.rs

roderickvd · 2026-02-21T19:57:57Z

src/host/pipewire/device.rs

+                                ("playback", Role::Source) => DeviceDirection::Output,
+                                ("capture", _) => DeviceDirection::Input,
+                                // Bluetooth and other non-ALSA devices use generic port group
+                                // names like "stream.0" — derive direction from media.class


That sounds smart - but it does not seem implemented?

src/host/pipewire/stream.rs

yara-blue · 2026-02-21T22:32:28Z

src/host/pipewire/stream.rs

+        None,
+        pw::stream::StreamFlags::AUTOCONNECT
+            | pw::stream::StreamFlags::MAP_BUFFERS
+            | pw::stream::StreamFlags::RT_PROCESS,


Pipewire docs specify no allocations or file access should be done by any callback when RT_PROCESS is set. I don't think this is currently in the CPAL contract? Consider documenting this or making this a feature flag/or option for this specific host. (I do think RT_PROCESS is really valuable to have as an option).

For context Rodio currently does file access on in the callback. Though maybe it should not ... there is a lot it should not do :)

source: https://docs.pipewire.org/page_streams.html

ok, I will remove it and add a comment

@Decodetalkers there's the feature audio_thread_priority that you could gate this option behind.

@yara-blue yeah... your session title "dragging a ten year old crate into 2026" is hitting harder the more we think about it 😉 ideally the decoders should work on another thread.

audio_thread_priority is not in the features, it seems a bug.. Is it?

Yes, probably lost during rebasing somewhere. Feel free to re-add to Cargo.toml:

# Audio thread priority elevation # Raises the audio callback thread to real-time priority for lower latency and fewer glitches # Requires: On Linux, either rtkit or appropriate user permissions (e.g. limits.conf or capabilities) # Platform: Linux, DragonFly BSD, FreeBSD, NetBSD, Windows audio_thread_priority = ["dep:audio_thread_priority"]

ok. seems there are already so many commits, I prefer add the feature of RT_PROCESS later in another pr. If rebase this branch, I may be hard to read the timeline

Both ways fine for me.

I don't think this is currently in the CPAL contract?

Allocations and filesystem access shouldn't be done in any audio callback, regardless of the backend API or whether that's documented or not, or the priority of the thread.

Have not solved all suggestions yet

maybe add an option later

Decodetalkers · 2026-02-22T09:45:34Z

src/host/pipewire/device.rs

+                                (group::CAPTURE, _) => DeviceDirection::Input,
+                                // Bluetooth and other non-ALSA devices use generic port group
+                                // names like "stream.0" — derive direction from media.class
+                                (_, Role::Sink) => DeviceDirection::Output,


@Frando I was wandering. I know sink can also be output, but why source is input here?

they were typos

it should return &[SampleRate]

We solve it after set the feature of pipewire to v0_3_49 and with the new function of request

Decodetalkers marked this pull request as draft January 6, 2026 12:20

Decodetalkers force-pushed the pipewire branch from 19070c2 to 1eca9ce Compare January 6, 2026 12:26

Decodetalkers changed the title ~~Pipewire support~~ Support pipewire as host Jan 6, 2026

Decodetalkers marked this pull request as ready for review January 6, 2026 14:41

Decodetalkers force-pushed the pipewire branch 4 times, most recently from 9e2ef9f to fd59a29 Compare January 6, 2026 14:57

Decodetalkers force-pushed the pipewire branch 3 times, most recently from 07bc999 to 6cea2ad Compare January 9, 2026 22:31

Decodetalkers force-pushed the pipewire branch 3 times, most recently from a81e104 to 5a3817c Compare January 10, 2026 16:19

Decodetalkers force-pushed the pipewire branch 9 times, most recently from 721beb0 to 424d78f Compare January 11, 2026 09:53

Decodetalkers added 6 commits February 20, 2026 10:51

fix: support support audio rate

783698d

fix: do not make StreamConfig Copyable

6fc76e3

Yes, it should be marked as Copy, but it should in another pr

fix: not set rate but the quantum

f20297c

I do not know if it is right. At least I should not set the rate

fix: buffer_size not work

1acff3f

use "node.force-quantum" to force the buffer size

chore: use NODE_FORCE_QUANTUM instead

cda6ecf

open the feature of v0_3_45

chore: adjust the examples

56fa93e

Decodetalkers force-pushed the pipewire branch from 34ef049 to 56fa93e Compare February 20, 2026 01:56

Decodetalkers added 2 commits February 20, 2026 10:58

chore: do fmt

0921393

fix: unit test

2f09be8

roderickvd mentioned this pull request Feb 21, 2026

Support Pipewire as a host #692

Closed

3 tasks

roderickvd requested changes Feb 21, 2026

View reviewed changes

yara-blue reviewed Feb 21, 2026

View reviewed changes

Decodetalkers force-pushed the pipewire branch from b295297 to a756e42 Compare February 22, 2026 02:09

chore: do as suggested, use the type alias, join thread and etc

2ac2686

Have not solved all suggestions yet

Decodetalkers force-pushed the pipewire branch from a756e42 to 2ac2686 Compare February 22, 2026 03:22

Decodetalkers added 6 commits February 22, 2026 12:22

chore: comment RT_PROCESS

eda4c08

maybe add an option later

chore: better error handle

9382dc7

chore: do error callback if the rate or channels does not fit the input

a3f717b

chore: rename class_type to class

6a6ea31

chore: use keys in pipewire crate

d2d6344

chore: use constants and the keys in pipewire

a2d9922

Decodetalkers force-pushed the pipewire branch from a1ce05f to a2d9922 Compare February 22, 2026 05:16

chore: try downgrade the compiler version

e8adc38

Decodetalkers commented Feb 22, 2026

View reviewed changes

Decodetalkers added 6 commits February 22, 2026 22:09

chore: set default_input to DefaultInput not DefaultSink

413daf2

chore: handle state change in pipewire

5a818bc

fix: typos pedding and peddinglist

e5789d0

they were typos

fix: allow_rates return wrong type

b3dc646

it should return &[SampleRate]

chore: add pipewire available check

969ce5b

fix: connect_output does not listen to the FixedBuffer

eaed1d1

We solve it after set the feature of pipewire to v0_3_49 and with the new function of request

Comments

Conversation

Decodetalkers commented Jan 6, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Still problems left:

Uh oh!

Decodetalkers commented Jan 6, 2026

Uh oh!

Decodetalkers commented Jan 7, 2026

Uh oh!

roderickvd commented Jan 7, 2026

Uh oh!

SuperKenVery commented Jan 8, 2026

Uh oh!

Decodetalkers commented Jan 9, 2026

Uh oh!

Decodetalkers commented Jan 10, 2026

Uh oh!

Be-ing commented Jan 15, 2026

Uh oh!

roderickvd left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Decodetalkers Feb 22, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

9 participants

Decodetalkers commented Jan 6, 2026 •

edited

Loading

Decodetalkers Feb 22, 2026 •

edited

Loading