PulseAudio Xen module

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [Linux Audio Users]     [AMD Graphics]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux