[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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?
- how general/granular/configurable should it be in term of the potentially 
many and different sound devices present in dom0?
- 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)
- Should the protocol allow the backend to publish many capabilities so the 
frontend can chose how to best use them?
- how easy/feasible would be to write frontend and backend drivers using the 
protocol for different OSs?
- 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..)

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.