Hash: SHA256

On Mon, Jun 19, 2017 at 09:55:35AM +0100, Matt McCutchen wrote:
> On Sun, 2017-06-18 at 20:56 +0200, Marek Marczykowski-Górecki wrote:
> > #1 is definitely better for latency, but also from architecture point of
> > view - ultimately it will allow to get rid of one more thing out of dom0
> > (either to dedicated AudioVM, or to GUI VM).
> Thanks for the helpful information!
> > Technically, you need to pass domain ID to vchan initialization in
> > module-vchan-sink (gui-agent-linux/pulse/module-vchan-sink.c). I think
> > you should use Qubes DB to let VMs know this ID (and set it during VM
> > startup in dom0, based on some VM property).
> I was assuming there would be a single AudioVM.  I guess it might not
> be that much more complicated to have each VM specify an AudioVM, but
> is there a reasonable use case?

I was rather thinking about ability to set "none" there for some VMs.
But I'm not strongly attached to this idea, because without additional
code, it would only hide AudioVM (if one guess its ID, it would
connect), not prevent the connection.

> > Recording
> > control is currently implemented over dbus (session bus). It's easy to
> > expose it over qrexec - just add one/two qrexec services with
> > appropriate dbus-send commands.
> OK.  Some questions:
> 1. Currently, Qubes Manager monitors the recording status via a D-Bus
> signal, which is nice because Qubes Manager will update properly if
> another process sets the D-Bus property.  Are you prepared to give up
> that functionality, or can you propose another way to implement it?
> 2. How should dom0 tell pacat-simple-vchan to exit when the VM shuts
> down?  An additional D-Bus method?

This will happen automatically - pacat-simple-vchan will detect when
target VM disappears.

> One way to solve both problems would be to have a pacat "controller"
> process in Dom0 that executes pacat-simple-vchan in the AudioVM and
> keeps pipes open to and from it.  The controller would then provide the
> existing D-Bus API and communicate with pacat-simple-vchan via a simple
> text-based protocol.  However, I don't know if this is an architectural
> style we'd want to encourage in general.

When moving it out of dom0, better not depend on such controller there.
For monitoring, we can have additional qrexec service, which fill
function as a pipe in your idea, but terminated with something based on
dbus-monitor (in practice probably a simple python script). And Qubes
Manager (whether running in dom0 or GUI VM) will connect to it to
monitor audio status. And use separate qrexec calls to control audio.

> > For good UX, there should be shortcut to start audio mixer there and
> > also some audio applet. And probably appropriate handling of volume
> > control keys (up/down/mute). All over qrexec.
> I'm not sure I would bother with this just for myself, but I might do
> it if it makes the difference between the feature being accepted
> upstream or not.  ISTM that even if we aren't completely happy with the
> UX to advertise the feature to all users, we could offer it via qvm-
> prefs or something.

Yes :)

This also means that exposing on qrexec functionality currently provided
through dbus can be done in another iteration. And for 4.1, where
probably GUI VM (with Qubes Manager) will be the same as Audio VM, it
may still not be needed.

- -- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
Version: GnuPG v2


You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-devel@googlegroups.com.
To view this discussion on the web visit 
For more options, visit https://groups.google.com/d/optout.

Reply via email to