3 ms·

I realize that upcoming system PipeWire has a very good compatibility layer, but I am curious what this would look like, architecturally, were it to target Pipe

I realize that upcoming system PipeWire has a very good compatibility layer, but I am curious what this would look like, architecturally, were it to target PipeWire instead of PulseAudio. Probably not a big shift. Are the PipeWire apis sufficient to manipulate various devices? Would we need instead to orchestrate & control a higher level session system, like WirePlumber? Would we need to develop a plugin/extension for PipeWire? Really interesting really lovely project here. It'd work on any modern free desktop. I do think it'd be an interesting thing to suggest, to use to explore upcoming technology (PipeWire), to understand more of this other new tech.

JetSpiegel 5y ago
Thanks for the kind words. Actually, the Pulseaudio interaction is minimal (just muting-unmuting the mic), I farm out all the work to pulseaudio-ctl (which is just a shell script calling pacmd). I actually opened an issue on that project to support PipeWire, but the CLI is not exactly the same. From what I can tell, this is blocked on some `pacmd` missing features on the PipeWire equivalent. https://github.com/graysky2/pulseaudio-ctl/issues/68 https://github.com/graysky2/pulseaudio-ctl/issues/68 Technically, `pw-cli` could grow those features or some processing would be done on top of `pulseaudio-ctl`, and PipeWire support would be included in this project "for free".