Re: [Xen-devel] [RFC v1] ALSA: xen-front: Add Xen para-virtualized frontend driver

[Oleksandr Andrushchenko <andr2000@xxxxxxxxx>]

ping

On 11/17/2017 10:08 AM, Oleksandr Andrushchenko wrote:
> ping
>
> On 11/02/2017 03:11 PM, Oleksandr Andrushchenko wrote:
> > Hi, all!
> >
> > Foreword
> > ========
> >
> > This RFC is aimed to introduce support of para-virtualized sound 
> > frontend
> > driver for Xen [1] and gather opinions from the relevant communities
> > (ALSA, Xen). It implements the protocol from [2] with the
> > following limitations:
> >   - mute/unmute is not supported
> >   - get/set volume is not supported
> > Volume control is not supported for the reason that most of the 
> > use-cases
> > (at the moment) are based on scenarios where unprivileged OS
> > (e.g. Android, AGL etc) uses software mixers.
> > Both capture and playback are supported.
> >
> > The relevant backend is implemented as a user-space application [3]
> > and uses accompanying helper library [4].
> >
> > Both frontend driver and backend were tested on real HW running Xen 
> > hypervisor
> > (Renesas R-Car ARM based H3/M3 boards, x86).
> >
> > Discussion
> > ==========
> >
> > During the first attempt to upstream the driver [5] number of 
> > comments and
> > concerns were raised, one of the biggest flaws in the design were 
> > questioned
> > by both Clemens Ladisch [6] and Takashi Sakamoto [7]: the absence of
> > synchronization between frontend and backend during capture/playback.
> > Two options were discussed:
> >
> > “In design of ALSA PCM core, drivers are expected to synchronize to
> > actual hardwares for semi-realtime data transmission. The
> > synchronization is done by two points:
> > 1) Interrupts to respond events from actual hardwares.
> > 2) Positions of actual data transmission in any serial sound interfaces
> >     of actual hardwares.
> > “
> >
> > and finally a change to the existing protocol was suggested:
> >
> > “In 'include/xen/interface/io/sndif.h', there's no functionalities I
> > described the above:
> > 1. notifications from DomU to Dom0 about the size of period for
> >     interrupts from actual hardwares. Or no way from Dom0 to DomU about
> >     the configured size of the period.
> > 2. notifications of the interrupts from actual hardwares to DomU.”
> >
> > This is implemented as a change to the sndif protocol [8] and allows 
> > removing
> > period emulation:
> > 1. Introduced a new event channel from back to front
> > 2. New event with number of bytes played/captured (XENSND_EVT_CUR_POS,
> >    to be used for sending snd_pcm_period_elapsed at frontend (in Linux
> >    implementation). Sent in bytes, not frames to make the protocol
> >    generic and consistent)
> > 3. New request for playback/capture control (XENSND_OP_TRIGGER) with
> >    start/pause/stop/resume sub-ops.
> >
> > Along with these changes other comments on the driver were addressed,
> > e.g. split into smaller chunks, moved the driver from misc to xen etc.
> >
> >
> > Hope, this helps to get the full picture of what was discussed and 
> > makes it
> > possible to move forward.
> >
> > Waiting for your valuable comments,
> >
> > Thank you,
> > Oleksandr
> >
> > [1] https://github.com/andr2000/linux/commits/snd_upstream_v1
> > [2] 
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/xen/interface/io/sndif.h
> > [3] https://github.com/xen-troops/snd_be
> > [4] https://github.com/xen-troops/libxenbe
> > [5] https://lkml.org/lkml/2017/8/7/363
> > [6] 
> > http://mailman.alsa-project.org/pipermail/alsa-devel/2017-August/123617.html
> > [7] 
> > http://mailman.alsa-project.org/pipermail/alsa-devel/2017-August/123744.html
> > [8] 
> > https://github.com/andr2000/linux/commit/095d7feae00bf00c852c67c4f1044de5601678ed
> >
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@xxxxxxxxxxxxx
> > https://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel