PV Audio GSoC Project

PV Audio GSoC Project

[George Boutsioukis]

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.

-- 
George Boutsioukis
gboutsioukis@gmail.com

RE: PV Audio GSoC Project

[James Harper]

> 
> 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
time. I find some frustrations in the existing interfaces (block,
network) in that they were written with Linux in mind and can be a
little painful to interface to Linux.

James

Re: PV Audio GSoC Project

[Konrad Rzeszutek Wilk]

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?

> time. I find some frustrations in the existing interfaces (block,
> network) in that they were written with Linux in mind and can be a
> little painful to interface to Linux.
> 
> James
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

RE: PV Audio GSoC Project

[James Harper]

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

Re: PV Audio GSoC Project

[George Boutsioukis]

> 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 :)

The only thing I can safely say right now is that sound interfaces
seem to be more hardware-oriented than OS-oriented, so maybe there
won't be any similar issues in this case.

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

I don't think that there's any hope that this port would help in any
way. One of the reasons of using PulseAudio is to keep the backend
from becoming subsystem specific, as it would for example with an ALSA
frontend. But much of the frontend code is still going to be
OS-specific anyway.

In the particular case of Windows, it would probably waste way more
effort to implement this frontend on top of anything but the standard
(Port Class?) driver model. Especially because, at least from what
I've seen so far, the backend code for audio is relatively trivial
compared to the frontend.

Re: PV Audio GSoC Project

[Konrad Rzeszutek Wilk]

On Thu, May 05, 2011 at 10:32:53PM +0300, George Boutsioukis wrote:
> > 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 :)
> 
> The only thing I can safely say right now is that sound interfaces
> seem to be more hardware-oriented than OS-oriented, so maybe there
> won't be any similar issues in this case.

The goal would be to make the PV interface (so not the frontend, but
the ring buffer, negotatiation, etc) as OS agnostic as possible.

And as George is going through the maze of how audio systems work hopefully
the picture of the most common approach will surface.

James, would you be interested in this? As in, looking at the design
and seeing what problems it might have and also well providing ideas
of what is too Linux-y and what might be a better idea for an OS-agnostic
approach?

> 
> > 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.
> 
> I don't think that there's any hope that this port would help in any
> way. One of the reasons of using PulseAudio is to keep the backend
> from becoming subsystem specific, as it would for example with an ALSA
> frontend. But much of the frontend code is still going to be
> OS-specific anyway.
> 
> In the particular case of Windows, it would probably waste way more
> effort to implement this frontend on top of anything but the standard
> (Port Class?) driver model. Especially because, at least from what
> I've seen so far, the backend code for audio is relatively trivial
> compared to the frontend.
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel