From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Rzeszutek Wilk Subject: Re: Xen PV audio XenStore Date: Wed, 6 Jul 2011 09:15:32 -0400 Message-ID: <20110706131532.GC3454@dumpdata.com> References: <1309867328.634.116.camel@zakaz.uk.xensource.com> <20110705145457.GC13548@dumpdata.com> <20110706131429.GA3454@dumpdata.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <20110706131429.GA3454@dumpdata.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: George Boutsioukis Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org 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 > > 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//device/audio//event-channel > > >> > /local/domain//device/audio//ring-ref > > >> > /local/domain//device/audio//format > > >> > /local/domain//device/audio//rate > > >> > /local/domain//device/audio//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//device/audio//format = "U8" > > /local/domain//device/audio//rate = 44000 > > /local/domain//device/audio//channels = 2 > > /local/domain//device/audio//type = "source" > > > > /local/domain//device/audio//format = "MU_LAW" > > (not sure if ulaw-16bit signed exists, but I guess it would be > > something similar to MU_LAW_S16LE?) > > > > /local/domain//device/audio//rate = 48000 > > /local/domain//device/audio//channels = 6 > > /local/domain//device/audio//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@gmail.com