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-* 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. 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. -- George Boutsioukis _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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@lists.xensource.com http://lists.xensource.com/xen-devel
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/<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>/channelsAnd "format" is...? string? What does it look like?> > > > 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? _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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@citrix.com> 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@lists.xensource.com http://lists.xensource.com/xen-devel
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 > <konrad.wilk@oracle.com> 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 projectI am not sure why, but you dropped the xen-devel from this response. I''ve added that back in.> >> > 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 > > > > 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 > > 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. > > >> > > >> > 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/<domID>/device/audio/<devID>/format = "U8" > /local/domain/<domID>/device/audio/<devID>/rate = 44000 > /local/domain/<domID>/device/audio/<devID>/channels = 2 > /local/domain/<domID>/device/audio/<devID>/type = "source" > > /local/domain/<domID>/device/audio/<devID>/format = "MU_LAW" > (not sure if ulaw-16bit signed exists, but I guess it would be > something similar to MU_LAW_S16LE?) > /local/domain/<domID>/device/audio/<devID>/rate = 48000 > /local/domain/<domID>/device/audio/<devID>/channels = 6 > /local/domain/<domID>/device/audio/<devID>/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_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 > > <konrad.wilk@oracle.com> 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/<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 > > > > > > 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/<domID>/device/audio/<devID>/format = "U8" > > /local/domain/<domID>/device/audio/<devID>/rate = 44000 > > /local/domain/<domID>/device/audio/<devID>/channels = 2 > > /local/domain/<domID>/device/audio/<devID>/type = "source" > > > > /local/domain/<domID>/device/audio/<devID>/format = "MU_LAW" > > (not sure if ulaw-16bit signed exists, but I guess it would be > > something similar to MU_LAW_S16LE?) > > <nods> > > /local/domain/<domID>/device/audio/<devID>/rate = 48000 > > /local/domain/<domID>/device/audio/<devID>/channels = 6 > > /local/domain/<domID>/device/audio/<devID>/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_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> 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@gmail.com _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel