Re: [Xen-devel] Xen PV audio XenStore

[Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>]

On Tue, Jul 05, 2011 at 08:53:29PM +0200, George Boutsioukis wrote:
> On Tue, Jul 5, 2011 at 4:54 PM, Konrad Rzeszutek Wilk
> <konrad.wilk@xxxxxxxxxx> wrote:
> > On Tue, Jul 05, 2011 at 01:02:08PM +0100, Ian Campbell wrote:
> >> On Mon, 2011-07-04 at 23:16 +0100, George Boutsioukis wrote:
> >> > Hello everyone, as some of you may remember there is a GSoC project

I am not sure why, but you dropped the xen-devel from this response.

I've added that back in.

> >> > this year to implement a paravirtualized audio driver and I am the
> >> > student undertaking this effort.
> >> >
> >> > As the rest of the PV audio drivers, my frontend uses XenStore to pass
> >> > the event channel & grant reference to the backend, along with a few
> >> > configuration data. Although the driver is far from usable, the
> >> > XenStore layout is not going to change much in the future, so I think
> >> > it would be useful to describe it to the community.
> >> >
> >> > First of all, although the frontend is implemented in userspace, I
> >> > tried to follow the scheme used by the rest of the PV drivers. This
> >> > looks something like:
> >> >
> >> > /local/domain/<domID>/device/audio/<devID>/event-channel
> >> > /local/domain/<domID>/device/audio/<devID>/ring-ref
> >> > /local/domain/<domID>/device/audio/<devID>/format
> >> > /local/domain/<domID>/device/audio/<devID>/rate
> >> > /local/domain/<domID>/device/audio/<devID>/channels
> >
> > And "format" is...? string? What does it look like?
> 
> It's a string. There are only a handful of common PCM formats; they
> look like this: S16LE(signed 16-bit integer, low endian), U8 for 8-bit
> unsigned etc. A good reference is the ALSA documentation:
> 
> http://www.alsa-project.org/alsa-doc/alsa-lib/group___p_c_m.html#g3df0b888477ce2dc3817d9095db859b1
> 
> Exactly which ones will be used depends on what the backend sound API
> can support. Pulseaudio(used currently by the backend) supports a
> smaller subset, but it is obviously enough for the current, also
> pulseaudio, frontend.
> 
> >> >
> >> > where devID is a unique device ID for the guest system.
> >
> > Could you provide an example of what this layout looks like for
> > stereo microphone (each channel is 8bit-unsigned, 44Khz) and
> > 5.1 channel output with 48Khz of ulaw-16bit signed?
> >
> 
> Ah, I guess I should a parameter to declare the device as output or
> input. Something like type="sink"/"source" should be enough. So, the
> layout for these examples would be:
> 
> /local/domain/<domID>/device/audio/<devID>/format = "U8"
> /local/domain/<domID>/device/audio/<devID>/rate = 44000
> /local/domain/<domID>/device/audio/<devID>/channels = 2
> /local/domain/<domID>/device/audio/<devID>/type = "source"
> 
> /local/domain/<domID>/device/audio/<devID>/format = "MU_LAW"
> (not sure if ulaw-16bit signed exists, but I guess it would be
> something similar to MU_LAW_S16LE?)
> /local/domain/<domID>/device/audio/<devID>/rate = 48000
> /local/domain/<domID>/device/audio/<devID>/channels = 6
> /local/domain/<domID>/device/audio/<devID>/type = "sink"
> 
> Of course a 5.1 scheme might likely need a channel-to-speaker map, but
> this can be handled through the dom0 sound server.
> 
> 
> -- 
> George Boutsioukis
> gboutsioukis@xxxxxxxxx

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel