Re: [Xen-devel] [alsa-devel] [PATCH RESEND1 00/12] ALSA: vsnd: Add Xen para-virtualized frontend driver

[Oleksandr Andrushchenko <andr2000@xxxxxxxxx>]

gentle reminder

On 09/26/2017 02:35 PM, Oleksandr Andrushchenko wrote:
> Clemens, Sakamoto-san,
>
> could you please review the below if you by chance have a minute?
>
> Thank you,
> Oleksandr
>
> On 09/19/2017 11:57 AM, Oleksandr Andrushchenko wrote:
> > Hi, all!
> >
> > We did some work on implementing the idea with
> >
> > feedback events from the backend to the frontend.
> >
> > Please see attached the changes to the existing sndif protocol [1]:
> >
> > 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.
> >
> > 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.
> >
> > The implementation we have showed that this is sufficient to
> > successfully play/capture w/o using emulated interrupts.
> >
> > Clemens, Sakamoto-san,
> > could you please review the changes and confirm that these are ok to
> > be upstreamed to the sndif protocol and are enough for the frontend
> > driver we want to upstream (we have it implemented, just need to make
> > sure the general approach is accepted by the ALSA community).
> >
> > Thank you very much for your time,
> > Oleksandr Andrushchenko
> > Oleksandr Grytsov
> >
> > [1] 
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/xen/interface/io/sndif.h?h=v4.14-rc1
> > On 09/12/2017 10:52 AM, Oleksandr Grytsov wrote:
> > > On Tue, Sep 5, 2017 at 10:24 AM, Clemens Ladisch 
> > > <clemens@xxxxxxxxxx> wrote:
> > > > Oleksandr Andrushchenko wrote:
> > > > > > > We understand that emulated interrupt on the frontend side is 
> > > > > > > completely not
> > > > > > > acceptable
> > > > Allow me to expand on that:  Proper synchronization requires that the
> > > > exact position is communicated, not estimated.  Just because the 
> > > > nominal
> > > > rate of the stream is known does not imply that you know the actual 
> > > > rate.
> > > > Forget for the moment that there even is a nominal rate; assume 
> > > > that it
> > > > works like, e.g., a storage controller, and that you can know that 
> > > > a DMA
> > > > buffer was consumed by the device only after it has told you.
> > > >
> > > > It's possible and likely that there is a latency when reporting the
> > > > stream position, but that is still better than guessing what the DMA
> > > > is doing.  (You would never just try to guess when writing data to
> > > > disk, would you?)
> > > >
> > > > > > > and definitely we need to provide some feedback mechanism from
> > > > > > > Dom0 to DomU.
> > > > > > >
> > > > > > > In our case it is technically impossible to provide precise 
> > > > > > > period interrupt
> > > > > > > (mostly because our backend is a user space application).
> > > > As far as I can see, all audio APIs (ALSA, PulseAudio, etc.) have 
> > > > poll()
> > > > or callbacks or similar mechanisms to inform you when new data can be
> > > > written, and always allow to query the current position.
> > > >
> > > > > [...]
> > > > > ok, so the main concern here is that we cannot properly 
> > > > > synchronize Dom0-DomU.
> > > > > If we put this apart for a second are there any other concerns on 
> > > > > having ALSA
> > > > > frontend driver? If not, can we have the driver with timer 
> > > > > implementation upstreamed
> > > > > as experimental until we have some acceptable synchronization 
> > > > > solution?
> > > > > This will allow broader audience to try and feel the solution and 
> > > > > probably contribute?
> > > > I doubt that the driver architecture will stay completely the same, 
> > > > so I
> > > > do not think that this experimental driver would demonstrate how the
> > > > solution would feel.
> > > >
> > > > As the first step, I would suggest creating a driver with proper
> > > > synchronization, even if it has high latency.  Reducing the latency
> > > > would then be 'just' an optimization.
> > > >
> > > >
> > > > Regards,
> > > > Clemens
> > > Definitely feedback from the backend side is required. Currently
> > > we are working on synchronized version on the backend
> > > and frontend side. We will be back once we have the solution.
> > >
> > > Thanks.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel