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