Re: [Xen-devel] Xen PV audio XenStore

[George Boutsioukis <gboutsioukis@xxxxxxxxx>]

> 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
case.

-- 
George Boutsioukis
gboutsioukis@xxxxxxxxx

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