Re: PV Audio GSoC Project

[Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>]

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