[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Xen-devel] PV Audio GSoC Project

> On Thu, May 05, 2011 at 10:36:16PM +1000, James Harper wrote:
> > >
> > > Hello, my name is George Boutsioukis and I'm a student at the
> > > Aristotle University in Greece. I submitted a GSoC proposal for
> > > implementing Paravirtualized Audio to Xen and this summer I will
> > > working on this under the mentorship of Konrad Rzeszutek Wilk.
> > > will be either a split-driver with an ALSA interface to the guest
> > > an interdomain communication layer for PulseAudio; we are
> > > weighing these two options, but the latter looks better right now.
> > >
> > > This is a very brief description of the project, but if anyone is
> > > interested in getting more details about this feel free to ask.
> > > in mind though that we are still at a very early stage.
> > >
> > > Any comments or suggestions regarding this project are more than
> > > welcome of course.
> > >
> >
> > Is windows compatibility part of the scope of your project? I don't
> > a windows implementation, just making sure that the interface you
> > develop isn't going to painful to interface to Windows at some
> Are there any documents on what the audio subsystem is and expects in

Plenty. Whether it is useful to read without spending weeks doing so is
another question. This seems like a good starting point
http://msdn.microsoft.com/en-us/library/ff536191%28v=vs.85%29.aspx but
unless you know a bit about the windows device model there will be a lot
of terms in there that don't mean anything to you. From a very brief
read, I think any windows driver that interfaces the backend that you
will write would be a "Port Class" driver -
http://msdn.microsoft.com/en-us/library/ff536829%28v=vs.85%29.aspx - but
that's based on 30 seconds of browsing.

The problem I have with the xen block device interface is that the vbd
ring expects data aligned to a 512 byte boundary, and windows has no
such limitation, and manipulating the data in a scsiport driver under
Windows is problematic. That's an artificial limitation under Linux I
believe - the underlying block device has no such limitation.

The problems with the network interface are that there is a limit to the
number of scatter-gather elements that can exist in one packet (this
_is_ a limitation of the Linux network stack though, so is
understandable), and that you don't get enough control over the various
offload functions.

Those are the two examples. I know very little about the audio systems
under Linux and Windows so I don't know how well they could mesh
together and what problems could be expected. I guess I'll have to wait
and see what design you come up with before I can comment :)

I've just looked up what PulseAudio actually is, and it appears that it
already runs under Windows although that may not be in a useful way for
your project.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.