[PATCH 2/3] qemu: Generate cmd line for pipewire audio backend

[Martin Kletzander]

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).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20230516/4c5ffeeb/attachment.sig>