Re: pipewire etc

On 6/26/26 6:02 PM, Russell Coker wrote:
> Why do we need different policies for alsa, pipewire, and pulseaudio?  They
> all do the same things, why not just have an audioserver policy that supports
> all of them?

Can we add wireplumber to this, too?  Before the (very) new pipewire_t domain,
I put pipewire and wireplumber into the pulseaudio_t domain, and it needed
minimal extra permission to work.

> Why do we need an ifdef for server vs user operation of pipewire?  Why not
> just have a policy with a pipewire_t for the system daemon and pipewire_user_t
> for the user process?
> 
> https://wiki.archlinux.org/title/
> PipeWire#Sharing_audio_devices_with_computers_on_the_network
> 
> For people wondering as I did why we even need a pipewire_user_t domain, the
> above section of the Arch Wiki documents sharing audio via Airplay and RTP
> among others - definitely need that isolated!
> 
> Is a pipewire_client_t domain just for the test program really useful?
> 
> It looks like the policy is well structured and replacing the cruft from years
> of support of alsa and pulseaudio is a good thing.  So I think we should go
> all the way and delete the separate policy for the old sound servers.
> 

Related:

I've modified this (and am trying to get cleaned up for up-streaming) an
attribute pipewire_client that mirrors the pulseaudio_client attribute.  Is
there a reason to prefer the many pipewire_{stream_connect,rw_stream_sockets,etc.}
macros vs something like pipewire_client_domain() ?


Antonio