Background
From Fedora 43 onward, the PipeWire raop-discover module is enabled by default. It uses mDNS/DNS-SD (zeroconf, via Avahi) to discover network audio devices on the local network and automatically creates audio sink devices for them, which then appear in Plasma’s Sound settings.
Enabling this by default is a Fedora decision, not a KDE one. But I think it has illuminated a UX issue in Plasma itself: audio device discovery and connection are coupled into a single event. The moment a device is discovered, a sink is created for it and there’s no step where the user explicitly chooses which network devices the system actually connects to. When network discovery is on, everything advertised on the network becomes a live output.
The issue (including a privacy concern)
This coupling has a real implication for user privacy: audio including calls, text-to-speech and media can be output to a network device without the user’s consent. Automatic output switching to connected network audio output happens when physically connected audio output (line-out, HDMI, etc.) are unavailable, Eg. A user is watching a video with captions as they don’t have connected speakers. A network audio device can be auto-select for output so that audio end up on a stranger’s speaker without awareness of the user.
The reasonable user expectation is that audio output stays limited to physical outputs (line-out, HDMI, etc.) or to Bluetooth/network devices that user have explicity connected.
Proposed solution
Bluetooth already models this correctly. It has its own section in System Settings: you see nearby devices, you explicitly connect one, and only then does it appear as a device in the Sound section. Discovery and connection are separate steps, and connection is a deliberate user action.
Network audio devices should behave the same way: discovery populates a list of available devices, and turning one into an active output is an explicit connect action, with a matching disconnect. See it, connect it, audio starts; disconnect it, it stops. No surprise routing, no uninvited entries in the output list.
A broader question: a “Network Devices” section?
The same mDNS/DNS-SD protocol that discovers audio devices is also used for printers (AirPrint/IPP), casting, file shares, and more. They’re just distinguished by different zeroconf service types. So a natural question is where is the most logical place for people to discover network devices. A network devices sections for all device types might model the underlying protocol in the same way bluetooth devices are connected. However unlike bluetooth, these protocols for device discovery are branded in different ways. eg. airplay, chromecast, airprint, among non branded protocols. Should they be grouped by function eg. network audio devices, network printers? or even under their own sections eg. sounds, printers etc. where users might look for them first?
I’d raise this as an open question rather than the core ask, for one reason: these device classes are owned by different subsystems (audio by PipeWire/WirePlumber, printers by CUPS, and so on), so a unified panel would be an aggregator over several backends rather than one thing. Worth noting there’s precedent for the interaction itself — modern CUPS driverless printing already discovers printers via mDNS and only creates a queue on demand when you print, which is essentially this “discovered but not connected until used” model, in production today. So the pattern is proven; the open question is just how far to generalise the UI.
Scope / where the boundaries are
To be clear about which layer owns what: the decision to open a sink on discovery vs on demand lives below Plasma, in PipeWire/WirePlumber policy. What Plasma can own is the UI, surfacing discovered-but-unconnected devices and providing the connect/disconnect affordance that tells the layer below to open or tear down the sink. The ask isn’t for the Sound panel to do audio routing; it’s to expose an explicit connect/disconnect interaction over a list of available network audio devices.
Caveats I’m aware of
- These protocols generally have no native “paired but idle” state the way Bluetooth does. Right now, creating the sink is what makes a device selectable at all, so a clean on-demand model probably needs the session manager to hold a placeholder and only open the real stream on selection.
- Devices are often announced twice (IPv4 and IPv6), so any “available devices” list needs sensible de-duplication.
What I’m hoping to learn from this thread
- Does this fit how Plasma wants to handle audio devices, or does it belong somewhere I’m not thinking of?
- Is the right surface the existing Sound settings, a network-audio addition, or a broader Network Devices section?
- Has anyone already proposed or started something like this? I couldn’t find an existing request, but I may have missed it.
Keen to hear where I’ve got the layering wrong or where this collides with existing plans.
