From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S968432AbdIZLf0 (ORCPT ); Tue, 26 Sep 2017 07:35:26 -0400 Received: from mail-wr0-f193.google.com ([209.85.128.193]:38215 "EHLO mail-wr0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965953AbdIZLfY (ORCPT ); Tue, 26 Sep 2017 07:35:24 -0400 X-Google-Smtp-Source: AOwi7QCezM7pQ8WShp7pxZl1BKZQHJ3NAHKZXkXGnm43ReHRSDWlJm0I3RcoD3Lote5J18CJ+iTXbg== Subject: Re: [alsa-devel] [PATCH RESEND1 00/12] ALSA: vsnd: Add Xen para-virtualized frontend driver From: Oleksandr Andrushchenko To: Oleksandr Grytsov , Clemens Ladisch , Takashi Sakamoto , tiwai@suse.com Cc: alsa-devel@alsa-project.org, Oleksandr Andrushchenko , linux-kernel@vger.kernel.org, xen-devel@lists.xen.org, Oleksandr Grytsov References: <1502108577-8099-1-git-send-email-andr2000@gmail.com> <7e62a406-7dcd-b5c9-b2de-ea52e1d2afd0@sakamocchi.jp> <2a2fd222-fc54-1709-bfc8-a530efc3f307@gmail.com> <3f8e535b-8607-6b15-6e17-da755a06cc1e@sakamocchi.jp> <3fde10f8-4727-e37b-8001-ce2356fffb2b@sakamocchi.jp> <162b7251-4040-c61f-1fcd-c32f65bd3c67@gmail.com> <8542f293-f2d0-9ba3-7082-967b32fcec17@ladisch.de> Message-ID: <5421f97e-cd7a-dd22-7557-b0fc25899c1b@gmail.com> Date: Tue, 26 Sep 2017 14:35:20 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 >> 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. >