[pulseaudio-discuss] PulseAudio Xen module
mkbosmans at gmail.com
Mon Oct 31 14:10:24 PDT 2011
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
> You can find the code here:
> (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
- Only use /* */ comments, not //
- Why do you define the DPRINTF macro? Just use pa_log_debug
- 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
> There's a design document that describes the driver's design in detail here:
> For more info on how paravirtualized drivers in general work in Xen see:
More information about the pulseaudio-discuss