On Tue, 06 Mar 2018 12:25:07 +0100,
Oleksandr Andrushchenko wrote:
> 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_andrushche...@epam.com>
> >> 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 ,  and gather opinions from the relevant communities
> >> (ALSA, Xen) on the change.
> >> The relevant backend is implemented as a user-space application 
> >> and uses accompanying helper library .
> >> 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  number
> >> of comments and concerns were raised, one of the biggest flaws in the
> >> design were questioned by both Clemens Ladisch  and
> >> Takashi Sakamoto : 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 
> > 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 . Basically part of hw_params configuration is written
> to XenStore  as a part of domain configuration which depends on
> 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.
OK, that restricts minimally. So at least there is the restriction /
communication about the buffer size. But it merely means the
*maximum* buffer size is set. Application may request still any
shorter value than that.
And, there are no restriction about period sizes (except for the
periods_max, which is calculated from buffer_bytes_max).
That is, application may request any size between them; and it expects
the wake up by this value.
I think that's a still missing stone in the design.
> > thanks,
> > Takashi
> >> Waiting for your valuable comments,
> >> Thank you,
> >> Oleksandr
> >>  https://github.com/andr2000/linux/commits/snd_upstream_v1
> >> 
> >> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/xen/interface/io/sndif.h
> >>  https://github.com/xen-troops/snd_be
> >>  https://github.com/xen-troops/libxenbe
> >>  https://lkml.org/lkml/2017/8/7/363
> >> 
> >> http://mailman.alsa-project.org/pipermail/alsa-devel/2017-August/123617.html
> >> 
> >> 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-de...@alsa-project.org
> >> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>  https://firstname.lastname@example.org/msg124356.html
Xen-devel mailing list