2011/10/31 George Boutsioukis <gboutsioukis at gmail.com>: > Hello PulseAudio people! > As part of a Google Summer of code project for Xen during this summer, I > wrote a PulseAudio module that acts as the frontend part of a Xen > paravirtualized audio driver. Basically what it does is push audio frames > over a ring buffer placed in memory shared between different Xen domains, > using Xen's interrupt-like events to notify the playback backend that audio > data is available. > The driver right now works well and we are thinking of the best possible way > to distribute it. Since (and correct me if I'm wrong) it's not possible to > build PulseAudio modules with the usual headers provided for PulseAudio > applications, we can't simply merge it with Xen's build system without the > whole. We'd like to be able to build something like a pulseaudio-modules-xen > package for a few common distro's, but in the most (reasonably) > maintenance-free way possible. Indeed, getting the module upstream and integrated into our buildsystem would be the easiest. > So, what would it take to check this into PulseAudio? (and build only when > the Xen headers are found) Well, obviously a patch against the pulseaudio tree would be better. The symdef file is autogenerated, so you only have to add the source file to src/modules and copy some boilerplate in configure.ac and src/Makefile.am. > You can find the code here: > http://code.google.com/p/xen-audio/source/browse/#hg/frontend > (ignore the xenpv-source module, doesn't really work yet) So why is this based on pulse 0.9.21? I'd say try building against 1.1 or even git master, as that's what's needed to get the module upstreamed. (Not that I expect that a lot of changes are necessary) In the Makefile I can see you include the pulse directory, but I don't see the module being linked against libpulse/libpulsecommon/libpulsecore, is this correct? > The playback module was based on pipe-sink. There are definitely some > mistakes in there (I'm not even close to a sound programming expert), but if > it's an issue of code quality I could clean it up to an acceptable state. A general comment: please follow our codings style for the frontend pulse module. http://pulseaudio.org/wiki/CodingStyle In particular: - Only use /* */ comments, not // - Why do you define the DPRINTF macro? Just use pa_log_debug directly, unconditionally. - Opening brace of a function block goes on the line declaring the function. - Use a space around if(condition)statement; - Use static functions for non-exported functionality Also, it seems you have to update the modargs, because you don't use file anymore. > Thanks, > Giorgos > There's a design document that describes the driver's design in detail here: > https://docs.google.com/document/d/1rS8afKlCbiVAOdKYCHfRPn6ihkSnl7PZw1QMoOmC9b4 Seems empty. > For more info on how paravirtualized drivers in general work in Xen see: > http://wiki.xen.org/xenwiki/XenSplitDrivers Maarten
