| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
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
be
> > > working on this under the mentorship of Konrad Rzeszutek Wilk.
This
> > > will be either a split-driver with an ALSA interface to the guest
or
> > > an interdomain communication layer for PulseAudio; we are
currently
> > > 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.
Keep
> > > 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
mean
> > a windows implementation, just making sure that the interface you
> > develop isn't going to painful to interface to Windows at some
future
>
> Are there any documents on what the audio subsystem is and expects in
Windows?
>
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.
James
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home