Added xen-devel to the CC list.
On Wed, Jul 06, 2011 at 09:14:29AM -0400, Konrad Rzeszutek Wilk wrote:
> 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
> > >> > 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
>
> So, how are the deliminated? And how does the frontend and backend negotitate
> which of the formats to use?
> >
> > 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.
>
> That is not good. We need the PV design to be OS-agnostic (and application
> agnostic). While there are many parts that are common amongst audio subsystems
> the format of this needs to be written down so that an OS can do the proper
> mapping to its backend (or 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?)
>
> <nods>
> > /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
|
Home