[lkml]   [2017]   [Sep]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH RESEND1 00/12] ALSA: vsnd: Add Xen para-virtualized frontend driver

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

 \ /
  Last update: 2017-09-04 09:22    [W:0.073 / U:4.736 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site