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

[Oleksandr Andrushchenko]

ping

On 10/04/2017 09:50 AM, Oleksandr Andrushchenko wrote:

gentle reminder

On 09/26/2017 02:35 PM, Oleksandr Andrushchenko wrote:

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 
 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.

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

[Oleksandr Andrushchenko]

ping

On 10/04/2017 09:50 AM, Oleksandr Andrushchenko wrote:

gentle reminder

On 09/26/2017 02:35 PM, Oleksandr Andrushchenko wrote:

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 
 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.

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

[Oleksandr Andrushchenko]

gentle reminder

On 09/26/2017 02:35 PM, Oleksandr Andrushchenko wrote:

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 
 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.

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

[Oleksandr Andrushchenko]

gentle reminder

On 09/26/2017 02:35 PM, Oleksandr Andrushchenko wrote:

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 
 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.

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

[Oleksandr Andrushchenko]

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  
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.

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

[Oleksandr Andrushchenko]

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  
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.

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

[Oleksandr Andrushchenko]

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  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.


diff --git a/include/xen/interface/io/sndif.h b/include/xen/interface/io/sndif.h
index 5c918276835e..763a3f0164f4 100644
--- a/include/xen/interface/io/sndif.h
+++ b/include/xen/interface/io/sndif.h
@@ -38,6 +38,13 @@
 
 /*
  **
+ *   Protocol version
+ **
+ */
+#define XENDISPL_PROTOCOL_VERSION	"2"
+
+/*
+ **
  *  Feature and Parameter Negotiation
  **
  *
@@ -104,8 +111,10 @@
  * /local/domain/1/device/vsnd/0/0/0/sample-formats = "s8,u8"
  * /local/domain/1/device/vsnd/0/0/0/unique-id = "0"
  *
- * /local/domain/1/device/vsnd/0/0/0/ring-ref = "386"
- * /local/domain/1/device/vsnd/0/0/0/event-channel = "15"
+ * /local/domain/1/device/vsnd/0/0/0/req-ring-ref = "386"
+ * /local/domain/1/device/vsnd/0/0/0/req-event-channel = "15"
+ * /local/domain/1/device/vsnd/0/0/0/evt-ring-ref = "1386"
+ * /local/domain/1/device/vsnd/0/0/0/evt-event-channel = "215"
  *
  *-- Stream 1, capture 
  *
@@ -113,8 +122,10 @@
  * /local/domain/1/device/vsnd/0/0/1/channels-max = "2"
  * /local/domain/1/device/vsnd/0/0/1/unique-id = "1"
  *
- * /local/domain/1/device/vsnd/0/0/1/ring-ref = "384"
- * /local/domain/1/device/vsnd/0/0/1/event-channel = "13"
+ * 

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

[Oleksandr Andrushchenko]

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  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.


diff --git a/include/xen/interface/io/sndif.h b/include/xen/interface/io/sndif.h
index 5c918276835e..763a3f0164f4 100644
--- a/include/xen/interface/io/sndif.h
+++ b/include/xen/interface/io/sndif.h
@@ -38,6 +38,13 @@
 
 /*
  **
+ *   Protocol version
+ **
+ */
+#define XENDISPL_PROTOCOL_VERSION	"2"
+
+/*
+ **
  *  Feature and Parameter Negotiation
  **
  *
@@ -104,8 +111,10 @@
  * /local/domain/1/device/vsnd/0/0/0/sample-formats = "s8,u8"
  * /local/domain/1/device/vsnd/0/0/0/unique-id = "0"
  *
- * /local/domain/1/device/vsnd/0/0/0/ring-ref = "386"
- * /local/domain/1/device/vsnd/0/0/0/event-channel = "15"
+ * /local/domain/1/device/vsnd/0/0/0/req-ring-ref = "386"
+ * /local/domain/1/device/vsnd/0/0/0/req-event-channel = "15"
+ * /local/domain/1/device/vsnd/0/0/0/evt-ring-ref = "1386"
+ * /local/domain/1/device/vsnd/0/0/0/evt-event-channel = "215"
  *
  *-- Stream 1, capture 
  *
@@ -113,8 +122,10 @@
  * /local/domain/1/device/vsnd/0/0/1/channels-max = "2"
  * /local/domain/1/device/vsnd/0/0/1/unique-id = "1"
  *
- * /local/domain/1/device/vsnd/0/0/1/ring-ref = "384"
- * /local/domain/1/device/vsnd/0/0/1/event-channel = "13"
+ * 

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

[Oleksandr Grytsov]

On Tue, Sep 5, 2017 at 10:24 AM, Clemens Ladisch  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.

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

[Oleksandr Grytsov]

On Tue, Sep 5, 2017 at 10:24 AM, Clemens Ladisch  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.

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

[Clemens Ladisch]

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

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

[Clemens Ladisch]

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