Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753298AbdIDHVg (ORCPT ); Mon, 4 Sep 2017 03:21:36 -0400 Received: from mail-wr0-f196.google.com ([209.85.128.196]:32837 "EHLO mail-wr0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751949AbdIDHVe (ORCPT ); Mon, 4 Sep 2017 03:21:34 -0400 X-Google-Smtp-Source: ADKCNb6h0n5wGAtkIq26DSO/CV03piujJ5lpM38WKlfCgOUTLSYr7vfid4MefZL3CYweQCRq4QzmbQ== Subject: Re: [PATCH RESEND1 00/12] ALSA: vsnd: Add Xen para-virtualized frontend driver From: Oleksandr Andrushchenko 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> <162b7251-4040-c61f-1fcd-c32f65bd3c67@gmail.com> Message-ID: Date: Mon, 4 Sep 2017 10:21:30 +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: <162b7251-4040-c61f-1fcd-c32f65bd3c67@gmail.com> 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: 2949 Lines: 75 On 08/24/2017 10:04 AM, Oleksandr Andrushchenko wrote: > 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? any thoughts on this? >> >> Regards >> >> Takashi Sakamoto > Thank you very much for your time, > Oleksandr Andrushchenko