From: Oleksandr Andrushchenko <andr2000@gmail.com>
To: Oleksandr Grytsov <al1img@gmail.com>,
Clemens Ladisch <clemens@ladisch.de>,
Takashi Sakamoto <o-takashi@sakamocchi.jp>,
tiwai@suse.com
Cc: alsa-devel@alsa-project.org,
Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>,
linux-kernel@vger.kernel.org, xen-devel@lists.xen.org,
Oleksandr Grytsov <oleksandr_grytsov@epam.com>
Subject: Re: [alsa-devel] [PATCH RESEND1 00/12] ALSA: vsnd: Add Xen para-virtualized frontend driver
Date: Tue, 26 Sep 2017 14:35:20 +0300 [thread overview]
Message-ID: <5421f97e-cd7a-dd22-7557-b0fc25899c1b@gmail.com> (raw)
In-Reply-To: <d29615e8-0fc2-68b8-d158-90378dc5ebeb@gmail.com>
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@ladisch.de>
>> 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.
>
next prev parent reply other threads:[~2017-09-26 11:35 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-07 12:22 [PATCH RESEND1 00/12] ALSA: vsnd: Add Xen para-virtualized frontend driver Oleksandr Andrushchenko
2017-08-07 12:22 ` [PATCH RESEND1 01/12] ALSA: vsnd: Introduce Xen para-virtualized sound " Oleksandr Andrushchenko
2017-08-07 12:22 ` [PATCH RESEND1 02/12] ALSA: vsnd: Implement driver's probe/remove Oleksandr Andrushchenko
2017-08-07 12:22 ` [PATCH RESEND1 03/12] ALSA: vsnd: Implement Xen bus state handling Oleksandr Andrushchenko
2017-08-07 12:22 ` [PATCH RESEND1 04/12] ALSA: vsnd: Read sound driver configuration from Xen store Oleksandr Andrushchenko
2017-08-07 12:22 ` [PATCH RESEND1 05/12] ALSA: vsnd: Implement Xen event channel handling Oleksandr Andrushchenko
2017-08-07 12:22 ` [PATCH RESEND1 06/12] ALSA: vsnd: Implement handling of shared buffers Oleksandr Andrushchenko
2017-08-07 12:22 ` [PATCH RESEND1 07/12] ALSA: vsnd: Introduce ALSA virtual sound driver Oleksandr Andrushchenko
2017-08-07 12:22 ` [PATCH RESEND1 08/12] ALSA: vsnd: Initialize virtul sound card Oleksandr Andrushchenko
2017-08-07 12:22 ` [PATCH RESEND1 09/12] ALSA: vsnd: Add timer for period interrupt emulation Oleksandr Andrushchenko
2017-08-07 12:22 ` [PATCH RESEND1 10/12] ALSA: vsnd: Implement ALSA PCM operations Oleksandr Andrushchenko
2017-08-07 12:22 ` [PATCH RESEND1 11/12] ALSA: vsnd: Implement communication with backend Oleksandr Andrushchenko
2017-08-07 12:22 ` [PATCH RESEND1 12/12] ALSA: vsnd: Introduce Kconfig option to enable Xen PV sound Oleksandr Andrushchenko
2017-08-10 3:14 ` [PATCH RESEND1 00/12] ALSA: vsnd: Add Xen para-virtualized frontend driver Takashi Sakamoto
2017-08-10 8:10 ` Oleksandr Andrushchenko
2017-08-17 10:05 ` [Xen-devel] " Oleksandr Grytsov
2017-08-18 5:43 ` Takashi Sakamoto
2017-08-18 5:56 ` Oleksandr Andrushchenko
2017-08-18 7:17 ` Takashi Sakamoto
2017-08-18 7:23 ` Oleksandr Andrushchenko
2017-08-22 2:43 ` Takashi Sakamoto
2017-08-23 14:51 ` Oleksandr Grytsov
2017-08-24 4:38 ` Takashi Sakamoto
2017-08-24 7:04 ` Oleksandr Andrushchenko
2017-09-04 7:21 ` Oleksandr Andrushchenko
2017-09-05 7:24 ` [alsa-devel] " Clemens Ladisch
2017-09-12 7:52 ` Oleksandr Grytsov
2017-09-19 8:57 ` Oleksandr Andrushchenko
2017-09-26 11:35 ` Oleksandr Andrushchenko [this message]
2017-10-04 6:50 ` Oleksandr Andrushchenko
2017-10-13 6:15 ` Oleksandr Andrushchenko
2017-10-30 6:33 ` [RFC] " Oleksandr Andrushchenko
2017-11-02 9:44 ` Takashi Sakamoto
2017-11-02 9:55 ` Oleksandr Andrushchenko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5421f97e-cd7a-dd22-7557-b0fc25899c1b@gmail.com \
--to=andr2000@gmail.com \
--cc=al1img@gmail.com \
--cc=alsa-devel@alsa-project.org \
--cc=clemens@ladisch.de \
--cc=linux-kernel@vger.kernel.org \
--cc=o-takashi@sakamocchi.jp \
--cc=oleksandr_andrushchenko@epam.com \
--cc=oleksandr_grytsov@epam.com \
--cc=tiwai@suse.com \
--cc=xen-devel@lists.xen.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).