Re: [Xen-devel] [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



___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

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

[Oleksandr Andrushchenko]

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?


Regards

Takashi Sakamoto

Thank you very much for your time,
Oleksandr Andrushchenko

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

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

[Takashi Sakamoto]

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. It's better to implement it as an application in
the other software layer, e.g. sinks/sources of PulseAudio in DomU 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.



Regards

Takashi Sakamoto

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

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

[Oleksandr Grytsov]

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.

Would this info be useful to update the frontend driver state?

If you have in mind any other solution we would appreciate.

-- 
Best Regards,
Oleksandr Grytsov.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

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

[Takashi Sakamoto]

Hi,

On Aug 18 2017 16:23, Oleksandr Andrushchenko wrote:
>> You mean that any alsa-lib or libpulse applications run on Dom0 as a
>> backend driver for the frontend driver on DomU?
>>
> No, the sound backend [1] is a user-space application (ALSA/PulseAudio
> client)
> which runs as a Xen para-virtual backend in Dom0 and serves all the
> frontends running in DomU(s).
> Other ALSA/PulseAudio clients in Dom0 are also allowed to run at the
> same time.
>
> [1] https://github.com/xen-troops/snd_be

Actually, you did what I meant.

Playback Capture
 delay   DomU-ADomU-BDomU-C  delay
- - -
|   | |   | |   |
(queueing)  | App-A | | App-B | | App-C |   (handling)
|   |   | |   | |   |   ^
|   | (TSS) | | (TSS) | | (TSS) |   |
|   |   | |   | |   |   |
|   ---^- ^ ^   |
|   ===|==|=| XenBus and|
|   ---|--| |   mapped page frame   |
|  Dom0 |  v  v v   |   |
|   |App-0  App-1 App-2 |   |
|   |  ^  ^ ^   |   |
|   |  |-> App-3<-| |   |   |
|   |(IPC)  ^   (IPC)   |   |   |
|   |   v   v   |   |
|   |==HW abstraction for TSS ==|   |
|   |  ^ ^  |   |
|   ---|-|---   |
|  | |(TSS = Time Sharing System)   |
|  v v  |
|  Hardwares|
v v |
(presenting)  physical part (sampling)

I can easily imagine that several applications (App[0|1|2]) run in Dom0
as backend drivers of this context, to add several 'virtual' sound
device for DomU, via Xenbus. The backend drivers can handle different
hardware for the 'virtual' sound devices; e.g. it can be BSD socket
applications.  Of course, this is a sample based on my imagination.
Actually, you assume that your application exclusively produces the
'virtual' sound cards, I guess.  Anyway, it's not a point of this
discussion.

> In order to implement option 1) discussed (Interrupts to respond 
events from

> actual hardware) we did number of experiments to find out if it can be
> implemented in the way it satisfies the requirements with respect to 
latency,

> interrupt number and use-cases.
>
> First of all the sound backend is a user-space application which uses 
either

> ALSA or PulseAudio to play/capture audio depending on configuration.
> Most of the use-cases we have are using PulseAudio as it allows to
> implement more complex use cases then just plain ALSA.

When assuming App-3 in the above diagram as PulseAudio, a combination
of App-0/App-1/App-3 may correspond to the backend driver in your
use-case.

> We started to look at how can we get such an event so it can be used as
> a period elapsed notification to the backend.
>
> In case of ALSA we used poll mechanism to wait for events from ALSA:
> we configured SW params to have period event, but the problem here is 
that
> it is notified not only when period elapses, but also when ALSA is 
ready to

> consume more data. There is no mechanism to distinguish between these
> two events (please correct us if there is one). Anyways, even if ALSA 
provides

> period event to user-space (again, backend is a user-space application)
> latency will consist of: time from kernel to user-space, user-space 
Dom0 to

> frontend driver DomU. Both are variable and depend on many factors,
> so the latency is not deterministic.
>
> (We were also thinking that we can implement a helper driver in Dom0 
to have
> a dedicated channel from ALSA to the backend to deliver period 
elapsed event,
> so for instance, it can have some kind of a hook on 
snd_pcm_period_elapsed,

> but it will not solve the use-case with PulseAudio discussed below.
> Also it is unclear how to handle scenario when multiple DomU plays 
through

> mixer with different frame rates, channels etc.).

In design of ALSA PCM core, processes are awakened from poll wait by
the other running tasks, which calculate available space on PCM buffer.
This is done by a call of 'snd_pcm_hw_prw0()' in 'sound/core/pcm_lib.c'
in kernel land. In this function, ALSA PCM core calls implementation of
'struct snd_pcm_ops.pointer()' in each driver and get current position
of data transmission within buffer size, then 'hw_ptr' of PCM buffer
is updated, then 

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

[Oleksandr Andrushchenko]

On 08/18/2017 10:17 AM, Takashi Sakamoto wrote:

On Aug 18 2017 14:56, Oleksandr Andrushchenko wrote:
Taking into account the fact that the backend we have is a user-space 
application

running on top of ALSA/PulseAudio we cannot get HW pointers from actual
hardware by any means (PulseAudio use-case is the most tough thing in 
equation)


You mean that any alsa-lib or libpulse applications run on Dom0 as a
backend driver for the frontend driver on DomU?

No, the sound backend [1] is a user-space application (ALSA/PulseAudio 
client)

which runs as a Xen para-virtual backend in Dom0 and serves all the
frontends running in DomU(s).
Other ALSA/PulseAudio clients in Dom0 are also allowed to run at the
same time.


Regards

Takashi Sakamoto

Thank you,
Oleksandr

[1] https://github.com/xen-troops/snd_be

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

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

[Takashi Sakamoto]

On Aug 18 2017 14:56, Oleksandr Andrushchenko wrote:
Taking into account the fact that the backend we have is a user-space 
application

running on top of ALSA/PulseAudio we cannot get HW pointers from actual
hardware by any means (PulseAudio use-case is the most tough thing in 
equation)


You mean that any alsa-lib or libpulse applications run on Dom0 as a
backend driver for the frontend driver on DomU?


Regards

Takashi Sakamoto

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

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

[Oleksandr Andrushchenko]

Hello,

On 08/18/2017 08:43 AM, Takashi Sakamoto wrote:

On Aug 17 2017 19:05, Oleksandr Grytsov wrote:
So, from the above we think that period elapsed event derived in the 
described
ways may not improve latency and will complicate the system. So, for 
that
reason we are thinking of the option 2) (Positions of actual data 
transmission

in any serial sound interfaces of actual hardwares.)


Please declare the way to enable stuffs on DomU to get the positions 
from actual hardware.


This is what we haven't investigated yet in detail as we were mostly 
focusing on

period elapsed approach, so we can report our findings to the community.

Taking into account the fact that the backend we have is a user-space 
application

running on top of ALSA/PulseAudio we cannot get HW pointers from actual
hardware by any means (PulseAudio use-case is the most tough thing in 
equation)


At the moment we are seeking for any advise from more experienced developers
in the field on possible ways to solve the problem of Dom0/DomU 
synchronization.
Hope, together we can identify such a way that would be accepted by the 
community.


If you have something on your mind could you please share your thoughts?


Regards

Takashi Sakamoto

Thank you,
Oleksandr Andrushchenko

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

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

[Takashi Sakamoto]

On Aug 17 2017 19:05, Oleksandr Grytsov wrote:

So, from the above we think that period elapsed event derived in the described
ways may not improve latency and will complicate the system. So, for that
reason we are thinking of the option 2) (Positions of actual data transmission
in any serial sound interfaces of actual hardwares.)


Please declare the way to enable stuffs on DomU to get the positions 
from actual hardware.



Regards

Takashi Sakamoto

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

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

[Oleksandr Grytsov]

On Thu, Aug 10, 2017 at 11:10 AM, Oleksandr Andrushchenko
 wrote:
> Hi,
>
> thank you very much for valuable comments and your time!
>
>
> On 08/10/2017 06:14 AM, Takashi Sakamoto wrote:
>>
>> Hi,
>>
>> On Aug 7 2017 21:22, Oleksandr Andrushchenko wrote:
>>>
>>> From: Oleksandr Andrushchenko 
>>>
>>> This patch series adds support for Xen [1] para-virtualized
>>> sound frontend driver. It implements the protocol from
>>> include/xen/interface/io/sndif.h with the following limitations:
>>> - mute/unmute is not supported
>>> - get/set volume is not supported
>>> Volume control is not supported for the reason that most of the
>>> use-cases (at the moment) are based on scenarious where
>>> unprivileged OS (e.g. Android, AGL etc) use software mixers.
>>>
>>> Both capture and playback are supported.
>>>
>>> Thank you,
>>> Oleksandr
>>>
>>> Resending because of rebase onto [2] + added missing patch
>>>
>>> [1] https://xenproject.org/
>>> [2]
>>> https://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git/log/?h=for-next
>>>
>>> Oleksandr Andrushchenko (12):
>>>ALSA: vsnd: Introduce Xen para-virtualized sound frontend driver
>>>ALSA: vsnd: Implement driver's probe/remove
>>>ALSA: vsnd: Implement Xen bus state handling
>>>ALSA: vsnd: Read sound driver configuration from Xen store
>>>ALSA: vsnd: Implement Xen event channel handling
>>>ALSA: vsnd: Implement handling of shared buffers
>>>ALSA: vsnd: Introduce ALSA virtual sound driver
>>>ALSA: vsnd: Initialize virtul sound card
>>>ALSA: vsnd: Add timer for period interrupt emulation
>>>ALSA: vsnd: Implement ALSA PCM operations
>>>ALSA: vsnd: Implement communication with backend
>>>ALSA: vsnd: Introduce Kconfig option to enable Xen PV sound
>>>
>>>   sound/drivers/Kconfig |   12 +
>>>   sound/drivers/Makefile|2 +
>>>   sound/drivers/xen-front.c | 2107
>>> +
>>>   3 files changed, 2121 insertions(+)
>>>   create mode 100644 sound/drivers/xen-front.c
>>
>>
>> For this patchset, I have the same concern which Clemens Ladisch
>> denoted[1]. If I can understand your explanation about queueing between
>> Dom0/DomU stuffs, the concern can be described in short words; this
>> driver works without any synchronization to data transmission by actual
>> sound hardwares.
>>
> Yes, both your concerns and understanding are correct
>>
>> In design of ALSA PCM core, drivers are expected to synchronize to
>> actual hardwares for semi-realtime data transmission. The
>> synchronization is done by two points:
>> 1) Interrupts to respond events from actual hardwares.
>> 2) Positions of actual data transmission in any serial sound interfaces
>>of actual hardwares.
>>
>> These two points comes from typical designs of actual hardwares, thus
>> they doesn't come from unfair, unreasonable, intrusive demands from
>> software side.
>>
> This clear, thank you
>>
>> In design of typical stuffs on para-virtualization, Dom0 stuffs are hard
>> to give enough abstraction of sound hardwares in these two points for
>> DomU stuffs. Especially, it cannot abstract point 2) at all because the
>> value of position should be accurate against actual time frame, while
>> there's an overhead for DomU stuffs to read it. When DomU stuffs handles
>> the value, the value is enough past due to context switches between
>> Dom0/DomU. Therefore, this driver must rely on point 1) to synchronize
>> to actual sound hardwares.

In order to implement option 1) discussed (Interrupts to respond events from
actual hardwares) we did number of experiments to find out if it can be
implemented in the way it satisfies the requirements with respect to latency,
interrupt number and use-cases.

First of all the sound backend is a user-space application which uses either
ALSA or PulseAudio to play/capture audio depending on configuration.
Most of the use-cases we have are using PulseAudio as it allows to
implement more complex use cases then just plain ALSA.

We started to look at how can we get such an event so it can be used as
a period elapsed notification to the backend.

In case of ALSA we used poll mechanism to wait for events from ALSA:
we configured SW params to have period event, but the problem here is that
it is notified not only when period elapses, but also when ALSA is ready to
consume more data. There is no mechanism to distinguish between these
two events (please correct us if there is one). Anyways, even if ALSA provides
period event to user-space (again, backend is a user-space application)
latency will consist of: time from kernel to user-space, user-space Dom0 to
frontend driver DomU. Both are variable and depend on many factors,
so the latency is not deterministic.

(We were also thinking that we can implement a helper driver in Dom0 to have
a dedicated channel from ALSA to the backend to deliver period elapsed event,
so for instance, it can have some 

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

[Oleksandr Andrushchenko]

Hi,

thank you very much for valuable comments and your time!

On 08/10/2017 06:14 AM, Takashi Sakamoto wrote:

Hi,

On Aug 7 2017 21:22, Oleksandr Andrushchenko wrote:

From: Oleksandr Andrushchenko 

This patch series adds support for Xen [1] para-virtualized
sound frontend driver. It implements the protocol from
include/xen/interface/io/sndif.h with the following limitations:
- mute/unmute is not supported
- get/set volume is not supported
Volume control is not supported for the reason that most of the
use-cases (at the moment) are based on scenarious where
unprivileged OS (e.g. Android, AGL etc) use software mixers.

Both capture and playback are supported.

Thank you,
Oleksandr

Resending because of rebase onto [2] + added missing patch

[1] https://xenproject.org/
[2] 
https://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git/log/?h=for-next


Oleksandr Andrushchenko (12):
   ALSA: vsnd: Introduce Xen para-virtualized sound frontend driver
   ALSA: vsnd: Implement driver's probe/remove
   ALSA: vsnd: Implement Xen bus state handling
   ALSA: vsnd: Read sound driver configuration from Xen store
   ALSA: vsnd: Implement Xen event channel handling
   ALSA: vsnd: Implement handling of shared buffers
   ALSA: vsnd: Introduce ALSA virtual sound driver
   ALSA: vsnd: Initialize virtul sound card
   ALSA: vsnd: Add timer for period interrupt emulation
   ALSA: vsnd: Implement ALSA PCM operations
   ALSA: vsnd: Implement communication with backend
   ALSA: vsnd: Introduce Kconfig option to enable Xen PV sound

  sound/drivers/Kconfig |   12 +
  sound/drivers/Makefile|2 +
  sound/drivers/xen-front.c | 2107 
+

  3 files changed, 2121 insertions(+)
  create mode 100644 sound/drivers/xen-front.c


For this patchset, I have the same concern which Clemens Ladisch
denoted[1]. If I can understand your explanation about queueing between
Dom0/DomU stuffs, the concern can be described in short words; this
driver works without any synchronization to data transmission by actual
sound hardwares.


Yes, both your concerns and understanding are correct

In design of ALSA PCM core, drivers are expected to synchronize to
actual hardwares for semi-realtime data transmission. The
synchronization is done by two points:
1) Interrupts to respond events from actual hardwares.
2) Positions of actual data transmission in any serial sound interfaces
   of actual hardwares.

These two points comes from typical designs of actual hardwares, thus
they doesn't come from unfair, unreasonable, intrusive demands from
software side.


This clear, thank you

In design of typical stuffs on para-virtualization, Dom0 stuffs are hard
to give enough abstraction of sound hardwares in these two points for
DomU stuffs. Especially, it cannot abstract point 2) at all because the
value of position should be accurate against actual time frame, while
there's an overhead for DomU stuffs to read it. When DomU stuffs handles
the value, the value is enough past due to context switches between
Dom0/DomU. Therefore, this driver must rely on point 1) to synchronize
to actual sound hardwares.

Which will also introduce some latency too: time needed to deliver and
handle interrupt from Dom0 to DomU

Typically, drivers configure hardwares to
generate interrupts per period of PCM buffer. This means that this
driver should notify to Dom0 about the value of period size requested
by applications.

In 'include/xen/interface/io/sndif.h', there's no functionalities I
described the above:
1. notifications from DomU to Dom0 about the size of period for
   interrupts from actual hardwares. Or no way from Dom0 to DomU about
   the configured size of the period.

Ok, then on "open" command I will pass from DomU to Dom0 an additional
parameter, period size. Then Dom0 will respond with actual period size
for DomU to use. So, this way period size will be negotiated.
Does the above look ok to you?

2. notifications of the interrupts from actual hardwares to DomU.


Ok, I will introduce an event from Dom0 to DomU to signal period elapsed.

Taking into account the fact that period size may be as small as,
say, 1ms, do you think we can/need to mangle period size in 1) on Dom0 side
to be reasonable, so we do not flood with interrupts/events from Dom0 to 
DomU?

Do you see any "formula" to determine that reasonable/acceptable
period limit, so both Dom0 and DomU are happy?


For the reasons, your driver used kernel's timer interface to generate
'pseudo' interrupts for the purpose. However, it depends on Dom0's
abstraction different from sound hardwares and Linux kernel's
abstraction for timer functionality. In this case, gap between 'actual'
interrupts from hardware and the 'pseudo' interrupts from a combination
of several components brings unexpected result on several situations.


You are right

I think this is defects of 'sndif' interface in Xen side. I think it
better for you to work in 

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

[Takashi Sakamoto]

Hi,

On Aug 7 2017 21:22, Oleksandr Andrushchenko wrote:

From: Oleksandr Andrushchenko 

This patch series adds support for Xen [1] para-virtualized
sound frontend driver. It implements the protocol from
include/xen/interface/io/sndif.h with the following limitations:
- mute/unmute is not supported
- get/set volume is not supported
Volume control is not supported for the reason that most of the
use-cases (at the moment) are based on scenarious where
unprivileged OS (e.g. Android, AGL etc) use software mixers.

Both capture and playback are supported.

Thank you,
Oleksandr

Resending because of rebase onto [2] + added missing patch

[1] https://xenproject.org/
[2] 
https://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git/log/?h=for-next

Oleksandr Andrushchenko (12):
   ALSA: vsnd: Introduce Xen para-virtualized sound frontend driver
   ALSA: vsnd: Implement driver's probe/remove
   ALSA: vsnd: Implement Xen bus state handling
   ALSA: vsnd: Read sound driver configuration from Xen store
   ALSA: vsnd: Implement Xen event channel handling
   ALSA: vsnd: Implement handling of shared buffers
   ALSA: vsnd: Introduce ALSA virtual sound driver
   ALSA: vsnd: Initialize virtul sound card
   ALSA: vsnd: Add timer for period interrupt emulation
   ALSA: vsnd: Implement ALSA PCM operations
   ALSA: vsnd: Implement communication with backend
   ALSA: vsnd: Introduce Kconfig option to enable Xen PV sound

  sound/drivers/Kconfig |   12 +
  sound/drivers/Makefile|2 +
  sound/drivers/xen-front.c | 2107 +
  3 files changed, 2121 insertions(+)
  create mode 100644 sound/drivers/xen-front.c


For this patchset, I have the same concern which Clemens Ladisch
denoted[1]. If I can understand your explanation about queueing between
Dom0/DomU stuffs, the concern can be described in short words; this
driver works without any synchronization to data transmission by actual
sound hardwares.

In design of ALSA PCM core, drivers are expected to synchronize to
actual hardwares for semi-realtime data transmission. The
synchronization is done by two points:
1) Interrupts to respond events from actual hardwares.
2) Positions of actual data transmission in any serial sound interfaces
   of actual hardwares.

These two points comes from typical designs of actual hardwares, thus
they doesn't come from unfair, unreasonable, intrusive demands from
software side.

In design of typical stuffs on para-virtualization, Dom0 stuffs are hard
to give enough abstraction of sound hardwares in these two points for
DomU stuffs. Especially, it cannot abstract point 2) at all because the
value of position should be accurate against actual time frame, while
there's an overhead for DomU stuffs to read it. When DomU stuffs handles
the value, the value is enough past due to context switches between
Dom0/DomU. Therefore, this driver must rely on point 1) to synchronize
to actual sound hardwares. Typically, drivers configure hardwares to
generate interrupts per period of PCM buffer. This means that this
driver should notify to Dom0 about the value of period size requested
by applications.

In 'include/xen/interface/io/sndif.h', there's no functionalities I
described the above:
1. notifications from DomU to Dom0 about the size of period for
   interrupts from actual hardwares. Or no way from Dom0 to DomU about
   the configured size of the period.
2. notifications of the interrupts from actual hardwares to DomU.

For the reasons, your driver used kernel's timer interface to generate
'pseudo' interrupts for the purpose. However, it depends on Dom0's
abstraction different from sound hardwares and Linux kernel's
abstraction for timer functionality. In this case, gap between 'actual'
interrupts from hardware and the 'pseudo' interrupts from a combination
of several components brings unexpected result on several situations.

I think this is defects of 'sndif' interface in Xen side. I think it
better for you to work in Xen community to improve the above interface
at first, then work for Linux stuffs.


Additionally, in next time, please remind of several points below:
 * When a first patch adds an initial code for drivers, it should
   include entries for Makefile and Kconfig, so that the driver can be
   built even if it's still in an initial shape. Each patch should be
   self-contained and should be in a shape so that developers easily run
   bisecting. In other words, your first patch[2] includes modification
  for Makefile and Kconfig in your last patch[3].
 * When any read-only symbols is added,  it should have 'const'
   qualifier so that the symbol places to .rodata section of ELF
   binaries. For example, in your code, 'alsa_sndif_formats' is such an
   symbol. In recent Linux development, some developers work for
   constifying such symbols. Please remind of their continuous works in
   upstream[4].
 * You can split your driver to several files. In
   

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

[Oleksandr Andrushchenko]

From: Oleksandr Andrushchenko 

This patch series adds support for Xen [1] para-virtualized
sound frontend driver. It implements the protocol from
include/xen/interface/io/sndif.h with the following limitations:
- mute/unmute is not supported
- get/set volume is not supported
Volume control is not supported for the reason that most of the
use-cases (at the moment) are based on scenarious where
unprivileged OS (e.g. Android, AGL etc) use software mixers.

Both capture and playback are supported.

Thank you,
Oleksandr

Resending because of rebase onto [2] + added missing patch

[1] https://xenproject.org/
[2] 
https://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git/log/?h=for-next

Oleksandr Andrushchenko (12):
  ALSA: vsnd: Introduce Xen para-virtualized sound frontend driver
  ALSA: vsnd: Implement driver's probe/remove
  ALSA: vsnd: Implement Xen bus state handling
  ALSA: vsnd: Read sound driver configuration from Xen store
  ALSA: vsnd: Implement Xen event channel handling
  ALSA: vsnd: Implement handling of shared buffers
  ALSA: vsnd: Introduce ALSA virtual sound driver
  ALSA: vsnd: Initialize virtul sound card
  ALSA: vsnd: Add timer for period interrupt emulation
  ALSA: vsnd: Implement ALSA PCM operations
  ALSA: vsnd: Implement communication with backend
  ALSA: vsnd: Introduce Kconfig option to enable Xen PV sound

 sound/drivers/Kconfig |   12 +
 sound/drivers/Makefile|2 +
 sound/drivers/xen-front.c | 2107 +
 3 files changed, 2121 insertions(+)
 create mode 100644 sound/drivers/xen-front.c

-- 
2.7.4


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel