Re: [qubes-devel] Routing Qubes master audio to a VM

2017-06-19 Thread Matt McCutchen 
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?

> 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?

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.

> 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.

Matt

-- 
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 
https://groups.google.com/d/msgid/qubes-devel/1497862535.3008.1.camel%40mattmccutchen.net.
For more options, visit https://groups.google.com/d/optout.

[qubes-devel] Routing Qubes master audio to a VM

2017-06-18 Thread Matt McCutchen 
I have a Bluetooth headset that I'd like to use with multiple VMs. 
Assigning the Bluetooth controller to each VM (at either the PCI or USB
level) when I want to use that VM isn't an ideal solution because each
VM needs a pairing key to secure the Bluetooth connection to the
headset.  If I copy the same pairing key to all of the VMs, then an
attacker within Bluetooth range who had access to one VM could
intercept the audio connection when I'm using the headset with a
different VM.  It might work to have each VM use a different Bluetooth
device address and share a separate pairing key with the headset, but
I'm liable to reach the headset's limit on number of paired devices.

So I'd like to try to implement a better solution: assigning the
Bluetooth controller to one VM (call it the "AudioVM") and routing the
Qubes master audio source and sink to that VM.  I can think of two
basic ways to do this:

1. Run all the pacat-simple-vchan processes in the AudioVM instead of
Dom0.  Will it just work for client VMs to specify the domain ID of the
AudioVM when creating the vchan, or are there restrictions?  A new
protocol would be needed for Dom0 to control the lifecycle and the
recording-allowed state of the pacat-simple-vchan processes.

2. Run one more module-vchan-sink / pacat-simple-vchan pair (but
without recording restrictions) from Dom0 to the AudioVM.  Might
increase latency.

Are there any issues I should be aware of before starting
implementation?  If I'm just doing this for myself, I'm inclined to try
#2 first because it should require less new code and high latency isn't
a big problem for me (as long as it's stable, which it has been so far:
I play StepMania!).  But if Qubes maintainers are interested in having
the feature upstream and prefer #1, I'll do that instead.

I found a previous thread about roughly the same problem.  The author
proposed approach #2, but apparently it wasn't implemented.

https://groups.google.com/d/topic/qubes-users/GrN5OhCwttw/discussion

Thanks,
Matt

-- 
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 
https://groups.google.com/d/msgid/qubes-devel/1497799022.4151.2.camel%40mattmccutchen.net.
For more options, visit https://groups.google.com/d/optout.