[pulseaudio-discuss] PulseAudio Xen module
Konrad Rzeszutek Wilk
konrad.wilk at oracle.com
Tue Nov 1 07:11:05 PDT 2011
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.
More information about the pulseaudio-discuss
mailing list