On Tue, May 16, 2023 at 12:49:02PM +0200, Michal Prívozník wrote:
On 5/16/23 11:52, Martin Kletzander wrote:On Thu, May 11, 2023 at 02:14:51PM +0200, Michal Privoznik wrote:This is mostly straightforward, except for a teensy-weensy detail: usually, there's no system wide daemon running, no system wide available socket that anybody could connect to. PipeWire uses a per user daemon approach instead. But this in turn means,I spent some time thinking about this even after I said "just give it runtime dir" and now I'm wondering, is this not similar to the dbus daemon? When we launch it with a constructed config file for graphics type='dbus' we could also launch pipewire deamon with our config file and let qemu connect to that daemon. I'm not sure what the audio permissions would look like, but it seems like a less messy approach.And how would then this per-domain pipewire daemon talk to the user session daemon that's actually doing all the mixing? I mean, how would sound from a domain get to speakers/headphones? For dbus it's fairly easy to use, because the socket (and config file) is located under configurable location (cfg->dbusStateDir) and with predictable name (domain short name) AND (more importantly) we have virDomainOpenGraphics() API which then handles virt-viewer connection requests.
I'm not sure how pipewire works in this context, my idea was that it would not go through the user's daemon at all, that would only be done for qemu:///session. But maybe my understanding is incomplete (highly probable).
signature.asc
Description: PGP signature
