Skip to content

Comments

Support pipewire as host#1093

Open
Decodetalkers wants to merge 57 commits intoRustAudio:masterfrom
Decodetalkers:pipewire
Open

Support pipewire as host#1093
Decodetalkers wants to merge 57 commits intoRustAudio:masterfrom
Decodetalkers:pipewire

Conversation

@Decodetalkers
Copy link

@Decodetalkers Decodetalkers commented Jan 6, 2026

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 Decodetalkers marked this pull request as draft January 6, 2026 12:20
@Decodetalkers Decodetalkers changed the title Pipewire support Support pipewire as host Jan 6, 2026
@Decodetalkers Decodetalkers marked this pull request as ready for review January 6, 2026 14:41
@Decodetalkers Decodetalkers force-pushed the pipewire branch 4 times, most recently from 9e2ef9f to fd59a29 Compare January 6, 2026 14:57
@Decodetalkers
Copy link
Author

Seems pipewire need edition 2024..

@Decodetalkers
Copy link
Author

@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
Copy link
Member

@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
Copy link
Contributor

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

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

ok, only one ci that I cannot fix

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

ok cross-rs based on ubuntu20.04, so

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

Be-ing commented Jan 15, 2026

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 roderickvd mentioned this pull request Feb 21, 2026
3 tasks
Copy link
Member

@roderickvd roderickvd left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

type Devices = Devices;
type Device = Device;
fn is_available() -> bool {
true
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could it test for availability like with a socket connection?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, I have added a simple way to check it


- 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
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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).

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Author

@Decodetalkers Decodetalkers Feb 22, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

not the problem of rust version, it is the problem of cross-rs, I think I cannot fix it.. The pr for cross-rs does not move at all now..

("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
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That sounds smart - but it does not seem implemented?

None,
pw::stream::StreamFlags::AUTOCONNECT
| pw::stream::StreamFlags::MAP_BUFFERS
| pw::stream::StreamFlags::RT_PROCESS,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ok, I will remove it and add a comment

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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"]

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Both ways fine for me.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

(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,
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

9 participants