[pulseaudio-discuss] PulseAudio Xen module

[Arun Raghavan]

On Tue, 2011-11-01 at 10:11 -0400, Konrad Rzeszutek Wilk wrote:
> On Tue, Nov 01, 2011 at 10:19:45AM +0530, Arun Raghavan wrote:
> > On Mon, 2011-10-31 at 17:33 +0100, George Boutsioukis wrote:
> > > Hello PulseAudio people!
> > > 
> > > 
> > > As part of a Google Summer of code project for Xen during this summer,
> > > I wrote a PulseAudio module that acts as the frontend part of a Xen
> > > paravirtualized audio driver. Basically what it does is push audio
> > > frames over a ring buffer placed in memory shared between different
> > > Xen domains, using Xen's interrupt-like events to notify the playback
> > > backend that audio data is available. 
> > 
> > Incidentally, Is there a reason you chose not to do this by exposing the
> > host server over the network[1] instead of having to invent your own
> > protocol for host/guest communication?
> 
> Couple of things:
>  - security (firewall rules might will to open on the guest/host)
>  - traffic is mungled along with the other traffic that might have nothing
>    to do with audio.
>  - extra configuration setup of making it work - you would need to pass
>    to the guest the IP of the host, and the host would need to dynamically
>    add an ACL for the guest.
> 
> One way to make some of these issues disappear is to create a second interface
> between host and guest that is private and will only be used for audio traffic.
> It won't solve the 'extra configuration' issue. It also will be complex to setup -
> both the guest and host have to know which of the interfaces is used for normal
> traffic vs audio traffic.
> 
> Making it use the XenBus and using a ring-buffer bypasses a bunch of these
> issues - the configuration is negotiated with the XenBus. This means that the host
> and guest know where each is (they only have to negotiate the event channel (think
> IRQ), and ring reference (think virtual memory for shared page)).
> 
> In regards to the ring implementation the idea behind it is to be the standard
> for PV audio. Which means that you can have different backends and frontends using
> a different implementation. For Windows, you could write the frontend using DSound
> and it would "pass" the audio frames on the ring, while the backend (host) would
> pick them up and feed them in PulseAudio.

Thanks for the explanation -- does make more sense to make a virtual
card and support arbitrary guests.

-- Arun