From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752253AbdIEHYM (ORCPT ); Tue, 5 Sep 2017 03:24:12 -0400 Received: from webclient5.webclient5.de ([136.243.32.179]:35980 "EHLO webclient5.webclient5.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752013AbdIEHYH (ORCPT ); Tue, 5 Sep 2017 03:24:07 -0400 Subject: Re: [alsa-devel] [PATCH RESEND1 00/12] ALSA: vsnd: Add Xen para-virtualized frontend driver To: Oleksandr Andrushchenko , Takashi Sakamoto , Oleksandr Grytsov Cc: alsa-devel@alsa-project.org, Oleksandr Andrushchenko , tiwai@suse.com, linux-kernel@vger.kernel.org, xen-devel@lists.xen.org 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> From: Clemens Ladisch Message-ID: <8542f293-f2d0-9ba3-7082-967b32fcec17@ladisch.de> Date: Tue, 5 Sep 2017 09:24:04 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <162b7251-4040-c61f-1fcd-c32f65bd3c67@gmail.com> Content-Type: text/plain; charset=us-ascii Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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