Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751316AbdHXHFC (ORCPT ); Thu, 24 Aug 2017 03:05:02 -0400 Received: from mail-wr0-f193.google.com ([209.85.128.193]:34710 "EHLO mail-wr0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751124AbdHXHFB (ORCPT ); Thu, 24 Aug 2017 03:05:01 -0400 Subject: Re: [PATCH RESEND1 00/12] ALSA: vsnd: Add Xen para-virtualized frontend driver To: Takashi Sakamoto , Oleksandr Grytsov Cc: clemens@ladisch.de, alsa-devel@alsa-project.org, xen-devel@lists.xen.org, linux-kernel@vger.kernel.org, tiwai@suse.com, Oleksandr Andrushchenko 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> From: Oleksandr Andrushchenko Message-ID: <162b7251-4040-c61f-1fcd-c32f65bd3c67@gmail.com> Date: Thu, 24 Aug 2017 10:04:55 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <3fde10f8-4727-e37b-8001-ce2356fffb2b@sakamocchi.jp> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2772 Lines: 70 Hello, On 08/24/2017 07:38 AM, Takashi Sakamoto wrote: > On Aug 23 2017 23:51, Oleksandr Grytsov wrote: >> Hi, >> >> Thank you for detailed explanation. >> >> We understand that emulated interrupt on the frontend side is >> completely not >> acceptable 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). >> The best we can implement it is provide number of frames (time, bytes >> etc.) >> consumed by real HW. This info will be outdated due to different >> delays but >> we can provide precise timestamps when this info was acquired. > > Stuffs of ALSA PCM in kernel land is an abstraction layer for actual > hardware for data transmission. The stuffs get affects from a design of > actual hardware. Furthermore, sound subsystems on the other operating > systems such as Microsoft Windows are also designed with a consideration > about actual hardware. When you design any interfaces as an abstraction > for such software layer, it's better to understand actual hardware and > design of low-level software layer somehow. > > Actually the 'sndif' has no good abstraction for actual hardware, > therefore an idea to implement frontend driver as an ALSA driver is not > reasonable at all. the reason for that is that you can use the same frontend driver for various DomUs without the need to write yet another HAL/application, e.g. if one of the DomUs has no PulseAudio (uses ALSA) and yet another DomU has PulseAudio, then using the same driver allows you to enable both out of the box with the same codebase. If we can imagine something else running on top of ALSA (say some other mixing software other than PulseAudio) then we will have to support that as well > It's better to implement it as an application in > the other software layer, e.g. sinks/sources of PulseAudio in DomU please see our reasoning above > via > Xenbus. This idea is nearer an original concept of Xen framework, I > guess. But I don't know we can write any applications of Xenbus in user > land of DomU or not. > > Anyway, it's not a good idea to have an ALSA driver for the present > 'sndif', in my opinion. > 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? > > Regards > > Takashi Sakamoto Thank you very much for your time, Oleksandr Andrushchenko