Re: [Xen-devel] [Embedded-pv-devel] [PATCH v6] sndif: add ABI for Para-virtual sound

[Oleksandr Dmytryshyn <oleksandr.dmytryshyn@xxxxxxxxxxxxxxx>]

Hi, Stefano.

Currently we have this configuration:
Dom0, DomD (driver domain), DomU (Android).
Sound driver is inside DomD. Backend uses ALSA for playback/capture.

On Thu, Feb 5, 2015 at 9:47 PM, Stefano Panella
<stefano.panella@xxxxxxxxxx> wrote:
> Hi all,
>
> First of all I would like to say that:
> - I am happy that PV audio is finding its way into xen and there is active 
> development on it
> - Defining a flexible and future proof PV audio protocol is very hard and 
> will probably take a bit of trial and error in the beginning.
> - I hope I will be able to save some time in the trial and error process 
> sharing a bit of my xen audio related experiences.
>
> I had a look at the patches sent and even if I am sure they are solving in a 
> practical way a specific use case scenario, the protocol specified does not 
> look general enough in my opinion and it does many assumptions which might or 
> not be acceptable.
>
> Also I could not find any discussion around the actual design of the protocol 
> including motivations and scope.
>
> I would like to think one could break the design protocol of a PV driver in 
> different areas where different people can contribute at different levels 
> bringing their particular expertise.
>
> Anyway, first it would be good to start a discussion around some basic 
> questions and then we could go into more detail.
>
> - what is the aim of the protocol? Just pipe some sort of sound data from 
> guest and dom0 or expose the guest with a real xen PV soundcard?
The aim is to expose the guest with a real xen PV soundcard.

> - how general/granular/configurable should it be in term of the potentially 
> many and different sound devices present in dom0?
Each sound device in DomD has own name and it is mapped to the selected
sound device of the PV soundcard in the frontend. I'll little rework the stream
mappings description in this protocol in the next patch-set.

> - audio, differently from any other Xen PV driver, is a real-time thing, 
> should this be reflected in the protocol? Most sound driver API require to 
> know when a particular sound sample is played on the Speaker or how old is a 
> sample coming from a Mic (particularly useful for Acoustic Echo Cancellation)
I don't know exactly how reflect it in the protocol. My PV driver adds
additional latency which is comparable to the context switching.

> - Should the protocol allow the backend to publish many capabilities so the 
> frontend can chose how to best use them?
Yes, it should. Maybe this should be added a bit later to the protocol.
At first it will be simple version of the protocol description.

> - how easy/feasible would be to write frontend and backend drivers using the 
> protocol for different OSs?
It is feasible to write backend and frontend drivers.
The main work should be done:
1. Learn how use ALSA to play/capture data (if ALSA is used for backend driver)
2. Learn how to create and use an virtual soundcard in selected OS
(linux, unix, etc.)
3. Learn how use an event channel and shared memory.

> - would the protocol map well with the current major sound driver models and 
> API for the different guest Oss? (linux alsa driver, Windows WaveCiclic or 
> WaveRT etc..)
At least the protocol map would be well with the alsa-like drivers
(Linux, QNX). BTW we've written a test version of the PV sound frontend
which works on the QNX. Unfurtunatelly I don't know about Windows WaveCiclic

>
> I hope these questions will help moving the conversation in a constructive 
> and productive way for now :)
>
> Stefano
>
> -----Original Message-----
> From: Dario Faggioli [mailto:dario.faggioli@xxxxxxxxxx]
> Sent: Monday, February 2, 2015 6:52 PM
> To: Oleksandr Dmytryshyn
> Cc: xen-devel@xxxxxxxxxxxxx; embedded-pv-devel@xxxxxxxxxxxxxxxxxxxx; Iurii 
> Konovalenko; Keir (Xen.org); Ian Campbell; Tim (Xen.org); Ian Jackson; Jan 
> Beulich; Stefano Panella
> Subject: Re: [Embedded-pv-devel] [PATCH v6] sndif: add ABI for Para-virtual 
> sound
>
> On Thu, 2015-01-29 at 13:01 +0200, Oleksandr Dmytryshyn wrote:
>> This is ABI for the two halves of a Para-virtual sound driver to
>> communicate with each to other.
>>
> I wonder whether Stefano (Cc-ed), which has a great deal of experience with 
> --real, virtual and paravirtual-- audio, could find a few minutes to have a 
> look and help us here, by saying what he thinks :-)
>
> Stefano, a bit of context (Oleksandr and Iurii, can add more, if needed, I'm 
> sure):
>
> http://marc.info/?l=xen-devel&m=142165575819173
> http://marc.info/?l=xen-devel&m=142194015107046
>
> Thanks and Regards,
> Dario
>
> --
> <<This happens because I choose it to happen!>> (Raistlin Majere)
> -----------------------------------------------------------------
> Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software 
> Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
>

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel