Re: [PATCH RESEND1 00/12] ALSA: vsnd: Add Xen para-virtualized frontend driver

[Oleksandr Andrushchenko]

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