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/
Home Products Support Community News


Re: [Xen-devel] Xen PV audio XenStore

To: Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] Xen PV audio XenStore
From: George Boutsioukis <gboutsioukis@xxxxxxxxx>
Date: Thu, 7 Jul 2011 09:31:56 +0200
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Thu, 07 Jul 2011 00:33:04 -0700
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=erUgdyfWXddHlwEgm84G8NXguPSVaul73Us3fWbm/28=; b=ilRhcDHVt4xlqrOXHAOga5x+3irPemZ9D13DIgz6hOfpBNYvEVshJwIBGSc2oKnqBu kItNJuK2SV9w6cgpywAuwtN6vkCGz4vI6PDL8yEmKRwf/8bmByTURM1mAiUpvyKCEGSJ qaLkGlOUevDsgbngAXxPBYm+w4KqUSqNU2+D0=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <1309941103.634.158.camel@xxxxxxxxxxxxxxxxxxxxxx>
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>
References: <CANnAuxArNOO_1qAaDfMxN9CDEgvHxhk0BAhxzUf7fZdvs4t7UQ@xxxxxxxxxxxxxx> <1309867328.634.116.camel@xxxxxxxxxxxxxxxxxxxxxx> <CANnAuxCKWduOkkd6Kh6-_7Eo-R9hoWed4iZbu4R0oOGcV2_gjQ@xxxxxxxxxxxxxx> <1309941103.634.158.camel@xxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
> So the guest can decide to use something else entirely at its whim?
> Unless the backend is going to be written to cope with anything at all
> which the frontend throws at it you need to have some sort of two way
> negotiation about what is going to be used, including a way for the
> backend to refuse to handle certain formats etc.

Yes, I guess the backend should have a 'ready' flag to signal its
acceptance, and the frontend can wait for it. This will be more of an
issue if, for example, an ALSA or Windows frontend driver is used and
there isn't a sound API to handle resampling etc. But we'll have to
see how far this issues go and how they can be handled in practice. A
xenstore layout where at least both sides can advertise their
parameters seems adequate right now.

>> > Are there any per-channel negotiable settings or are the multiple audio
>> > channels in a stream always identical?
>> Most of the audio APIs tend to treat all channels identically. Even if
>> they did otherwise, such fine-tuning is probably beyond the scope of
>> this driver.
> Well, if it can happen then you need to at least design the xenstore API
> to be extensible in this way, which I suppose would mean per-channel
> subdirectories in xenstore. e.g.
>        /local/domain/<domID>/device/audio/<devID>/channels
>        /local/domain/<domID>/device/audio/<devID>/channel-0/{rate,format}
>        /local/domain/<domID>/device/audio/<devID>/channel-1/{rate,format}
>        /local/domain/<domID>/device/audio/<devID>/.../{rate,format}
>        /local/domain/<domID>/device/audio/<devID>/channel-<N>/{rate,format}

I don't think it can happen on common sound APIs, because it seems a
bit overly complicated. But this would be a way to support it, in any

George Boutsioukis

Xen-devel mailing list

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