Messages in this thread | | | Subject | Re: [alsa-devel] [PATCH RESEND1 00/12] ALSA: vsnd: Add Xen para-virtualized frontend driver | From | Oleksandr Andrushchenko <> | Date | Tue, 26 Sep 2017 14:35:20 +0300 |
| |
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. >
| |