Support pipewire as host

[Decodetalkers]

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]

Seems pipewire need edition 2024..

[Decodetalkers]

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

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

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

[Decodetalkers]

ok, only one ci that I cannot fix

[Decodetalkers]

ok cross-rs based on ubuntu20.04, so

[Be-ing]

How does this differ from #692?

[Decodetalkers]

How does this differ from #692?

This one is a finished version, and used the roundtrip to get the information, instead of using thread to control it.

[roderickvd]

You think this renders #692 obsolete - should we close that in favor of this one?

[Decodetalkers]

You think this renders #692 obsolete - should we close that in favor of this one?

Maybe . If you think that is no problem