I've re-added xen-devel to the CC since I guess you dropped it by
mistake.
On Tue, 2011-07-05 at 19:20 +0100, George Boutsioukis wrote:
> On Tue, Jul 5, 2011 at 2:02 PM, Ian Campbell <Ian.Campbell@xxxxxxxxxx> 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
> >>
> >> 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>/...
>
> Noted that.
>
>
> >> 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).
>
> Yes, default-rate/channels/format. This will basically be the sound
> spec considered by the backend as "optimal" (this could be the maximum
> hardware capabilities, maximum channels etc., or maybe just a
> suggestion that is likely to work -- this will be tested at some point
> with different configurations). The guests would still decide whether
> to use this spec or not.
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.
> > 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}
> >> 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
|
Home