WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] Xen PV audio XenStore

To: George Boutsioukis <gboutsioukis@xxxxxxxxx>
Subject: Re: [Xen-devel] Xen PV audio XenStore
From: Ian Campbell <Ian.Campbell@xxxxxxxxxx>
Date: Tue, 5 Jul 2011 13:02:08 +0100
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Tue, 05 Jul 2011 05:03:48 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <CANnAuxArNOO_1qAaDfMxN9CDEgvHxhk0BAhxzUf7fZdvs4t7UQ@xxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Organization: Citrix Systems, Inc.
References: <CANnAuxArNOO_1qAaDfMxN9CDEgvHxhk0BAhxzUf7fZdvs4t7UQ@xxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
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
> 
> where devID is a unique device ID for the guest system.
> 
> Accordingly the backend will use something like:
> 
> /local/domain/0/backend/audio/default-*

The backend path typically includes the frontend <domID> and <devID>.
Like: /local/domain/0/backend/audio/<domID>/<devID>/...

> which will likely be a way for the backend to advertise the
> capabilities of the sound hardware to the guests and perhaps pass a
> few other parameters.

So default-* is stuff like default-rate? What happens if the f.e. wants
a different rate? Is there some concept of advertising support rates
from the backend or some minimal subset any backend must be willing to
support? (similarly for channels, format etc).

Are there any per-channel negotiable settings or are the multiple audio
channels in a stream always identical?

> This looked like the simplest way to go. Of course I'm only new here
> and I might be missing something grave, so please let me know what you
> think.
> 



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

<Prev in Thread] Current Thread [Next in Thread>