[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [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) _______________________________________________ Embedded-pv-devel mailing list Embedded-pv-devel@xxxxxxxxxxxxxxxxxxxx http://lists.xenproject.org/cgi-bin/mailman/listinfo/embedded-pv-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |