Re: [Xen-devel] [alsa-devel] [PATCH 0/2] sndif: add explicit back and front synchronization

[Oleksandr Andrushchenko <andr2000@xxxxxxxxx>]

On 03/06/2018 12:52 PM, Takashi Iwai wrote:
> On Mon, 05 Feb 2018 09:24:58 +0100,
> Oleksandr Andrushchenko wrote:
> > From: Oleksandr Andrushchenko <oleksandr_andrushchenko@xxxxxxxx>
> >
> > Hi, all!
> >
> > Foreword
> > ========
> >
> > This change is aimed to add support for explicit back and front
> > synchronization during playback and capture in response to comments
> > raised during upstream attempt of the para-virtualized sound frontend
> > driver for Xen [1], [2] and gather opinions from the relevant communities
> > (ALSA, Xen) on the change.
> >
> > 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) to make sure the proposed
> > solution does work.
> >
> > Rationale
> > =========
> >
> > During the first attempt to upstream the Linux front 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 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
> > 4. Playback/capture buffer size is set on the backend side via
> >     XENSND_FIELD_BUFFER_SIZE XenStore entry
> So the new addition looks serving well for the point that was
> suggested in the previous thread.  As I see no frontend driver
> implementation, it's hard to tell about the details, but through a
> quick glance, the protocol should be OK.
Thank you, the driver is at [1]
> Now, going back to a big picture: I took a look at the previous
> patchset, and wonder what about the hw_params setup.  Basically the
> (frontend) application may request any size of buffer and periods
> unless the driver sets up the hw constraints at open callback.  That
> is, app may request even the 16 bytes of buffer size, or 1GB of
> buffer.  The periods aren't always integer, so it can be 1024 bytes of
> buffer with 400 bytes of periods.
>
> And, if such parameters are set up freely in the frontend side, how
> the backend is supposed to behave?  From the frontend POV, it expects
> receiving the wakeup/notification at each period processing (e.g. 400
> bytes in the case above).  But, the backend is another application, so
> how would it work for such requirements?  Am I missing something here?
Well, the frontend is not that free to decide as it might look like,
e.g. please see [2]. Basically part of hw_params configuration is written
to XenStore [3] as a part of domain configuration which depends on 
system/backend
capabilities. E.g., we usually set buffer sizes to match real HW at 
backend side
if we use ALSA and we have more freedom if we use PulseAudio there.
Finally, if backend decides that the requested buffer/period sizes are
not acceptable it will reject such a configuration.
> thanks,
>
> Takashi
>
>
> > 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
> >
> >
> > Oleksandr Andrushchenko (2):
> >    sndif: introduce protocol version
> >    sndif: add explicit back and front synchronization
> >
> >   xen/include/public/io/sndif.h | 173 +++++++++++++++++++++++++++++++++++++++++-
> >   1 file changed, 170 insertions(+), 3 deletions(-)
> >
> > --
> > 2.7.4
> >
> > _______________________________________________
> > Alsa-devel mailing list
> > Alsa-devel@xxxxxxxxxxxxxxxx
> > http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
[1] 
https://github.com/andr2000/linux/commits/tiwai_sound_for_next_pv_snd_upstream_v1
[2] 
https://github.com/andr2000/linux/blob/tiwai_sound_for_next_pv_snd_upstream_v1/sound/xen/xen_snd_front_cfg.c#L239
[3] https://www.mail-archive.com/xen-devel@xxxxxxxxxxxxx/msg124356.html

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