[RFC v1] ALSA: xen-front: Add Xen para-virtualized frontend driver

[RFC v1] ALSA: xen-front: Add Xen para-virtualized frontend driver

[Oleksandr Andrushchenko]

Hi, all!

Foreword
========

This RFC is aimed to introduce support of para-virtualized sound frontend
driver for Xen [1] and gather opinions from the relevant communities
(ALSA, Xen). It implements the protocol from [2] 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 scenarios where unprivileged OS
(e.g. Android, AGL etc) uses software mixers.
Both capture and playback are supported.

The relevant backend is implemented as a user-space application [3]
and uses accompanying helper library [4].

Both frontend driver and backend were tested on real HW running Xen 
hypervisor
(Renesas R-Car ARM based H3/M3 boards, x86).

Discussion
==========

During the first attempt to upstream the driver [5] number of comments and
concerns were raised, one of the biggest flaws in the design were questioned
by both Clemens Ladisch [6] and Takashi Sakamoto [7]: the absence of
synchronization between frontend and backend during capture/playback.
Two options were discussed:

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

and finally a change to the existing protocol was suggested:

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

This is implemented as a change to the sndif protocol [8] and allows 
removing
period emulation:
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 (in Linux
    implementation). 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.

Along with these changes other comments on the driver were addressed,
e.g. split into smaller chunks, moved the driver from misc to xen etc.


Hope, this helps to get the full picture of what was discussed and makes it
possible to move forward.

Waiting for your valuable comments,

Thank you,
Oleksandr

[1] https://github.com/andr2000/linux/commits/snd_upstream_v1
[2] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/xen/interface/io/sndif.h
[3] https://github.com/xen-troops/snd_be
[4] https://github.com/xen-troops/libxenbe
[5] https://lkml.org/lkml/2017/8/7/363
[6] 
http://mailman.alsa-project.org/pipermail/alsa-devel/2017-August/123617.html
[7] 
http://mailman.alsa-project.org/pipermail/alsa-devel/2017-August/123744.html
[8] 
https://github.com/andr2000/linux/commit/095d7feae00bf00c852c67c4f1044de5601678ed



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

Re: [RFC v1] ALSA: xen-front: Add Xen para-virtualized frontend driver

[Oleksandr Andrushchenko]

On 12/22/2017 05:58 PM, Konrad Rzeszutek Wilk wrote:
> On Fri, Dec 22, 2017 at 05:48:45PM +0200, Oleksandr Andrushchenko wrote:
>> On 12/22/2017 05:12 PM, Konrad Rzeszutek Wilk wrote:
>>> On Mon, Dec 11, 2017 at 10:45:27AM +0200, Oleksandr Andrushchenko wrote:
>>>> ping
>>> ..snip..
>>>>>> This is implemented as a change to the sndif protocol [8] and allows
>>>>>> [8] https://github.com/andr2000/linux/commit/095d7feae00bf00c852c67c4f1044de5601678ed
>>> .. I must have missed it being posted.
>>>
>>> But it looks OK to me - could you repost it and please have me on To: list?
>>>
>> Did I get you right that you want me to repost the RFC again?
> Yes pls, but pls skip the RFC part of the patch. Just as v1 please.
Ah, well, I am not quite sure this is the right time to discuss the changes
in terms of patches: I would like to discuss the idea first, e.g.
if the approach itself is acceptable by the ALSA community and if it is,
then I'll push v1, e.g move to patches stage. Hence, here is the RFC...

The driver itself (at the moment) is just a proof-of-concept for the
community to show that the approach we are offering in the RFC actually 
works.

Does the above make sense?

Thank you,
Oleksandr

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [RFC v1] ALSA: xen-front: Add Xen para-virtualized frontend driver

[Konrad Rzeszutek Wilk]

On Fri, Dec 22, 2017 at 05:48:45PM +0200, Oleksandr Andrushchenko wrote:
> 
> On 12/22/2017 05:12 PM, Konrad Rzeszutek Wilk wrote:
> > On Mon, Dec 11, 2017 at 10:45:27AM +0200, Oleksandr Andrushchenko wrote:
> > > ping
> > ..snip..
> > > > > This is implemented as a change to the sndif protocol [8] and allows
> > > > > [8] https://github.com/andr2000/linux/commit/095d7feae00bf00c852c67c4f1044de5601678ed
> > .. I must have missed it being posted.
> > 
> > But it looks OK to me - could you repost it and please have me on To: list?
> > 
> Did I get you right that you want me to repost the RFC again?

Yes pls, but pls skip the RFC part of the patch. Just as v1 please.
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [RFC v1] ALSA: xen-front: Add Xen para-virtualized frontend driver

[Oleksandr Andrushchenko]

On 12/22/2017 05:12 PM, Konrad Rzeszutek Wilk wrote:
> On Mon, Dec 11, 2017 at 10:45:27AM +0200, Oleksandr Andrushchenko wrote:
>> ping
> ..snip..
>>>> This is implemented as a change to the sndif protocol [8] and allows
>>>> [8] https://github.com/andr2000/linux/commit/095d7feae00bf00c852c67c4f1044de5601678ed
> .. I must have missed it being posted.
>
> But it looks OK to me - could you repost it and please have me on To: list?
>
Did I get you right that you want me to repost the RFC again?


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [RFC v1] ALSA: xen-front: Add Xen para-virtualized frontend driver

[Konrad Rzeszutek Wilk]

On Mon, Dec 11, 2017 at 10:45:27AM +0200, Oleksandr Andrushchenko wrote:
> ping
..snip..
> > > This is implemented as a change to the sndif protocol [8] and allows
> > > [8] https://github.com/andr2000/linux/commit/095d7feae00bf00c852c67c4f1044de5601678ed

.. I must have missed it being posted.

But it looks OK to me - could you repost it and please have me on To: list?



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [RFC v1] ALSA: xen-front: Add Xen para-virtualized frontend driver

[Oleksandr Andrushchenko]

ping

On 11/17/2017 10:08 AM, Oleksandr Andrushchenko wrote:
> ping
>
> On 11/02/2017 03:11 PM, Oleksandr Andrushchenko wrote:
>> Hi, all!
>>
>> Foreword
>> ========
>>
>> This RFC is aimed to introduce support of para-virtualized sound 
>> frontend
>> driver for Xen [1] and gather opinions from the relevant communities
>> (ALSA, Xen). It implements the protocol from [2] 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 scenarios where unprivileged OS
>> (e.g. Android, AGL etc) uses software mixers.
>> Both capture and playback are supported.
>>
>> The relevant backend is implemented as a user-space application [3]
>> and uses accompanying helper library [4].
>>
>> Both frontend driver and backend were tested on real HW running Xen 
>> hypervisor
>> (Renesas R-Car ARM based H3/M3 boards, x86).
>>
>> Discussion
>> ==========
>>
>> During the first attempt to upstream the driver [5] number of 
>> comments and
>> concerns were raised, one of the biggest flaws in the design were 
>> questioned
>> by both Clemens Ladisch [6] and Takashi Sakamoto [7]: the absence of
>> synchronization between frontend and backend during capture/playback.
>> Two options were discussed:
>>
>> “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.
>> “
>>
>> and finally a change to the existing protocol was suggested:
>>
>> “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.”
>>
>> This is implemented as a change to the sndif protocol [8] and allows 
>> removing
>> period emulation:
>> 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 (in Linux
>>    implementation). 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.
>>
>> Along with these changes other comments on the driver were addressed,
>> e.g. split into smaller chunks, moved the driver from misc to xen etc.
>>
>>
>> Hope, this helps to get the full picture of what was discussed and 
>> makes it
>> possible to move forward.
>>
>> Waiting for your valuable comments,
>>
>> Thank you,
>> Oleksandr
>>
>> [1] https://github.com/andr2000/linux/commits/snd_upstream_v1
>> [2] 
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/xen/interface/io/sndif.h
>> [3] https://github.com/xen-troops/snd_be
>> [4] https://github.com/xen-troops/libxenbe
>> [5] https://lkml.org/lkml/2017/8/7/363
>> [6] 
>> http://mailman.alsa-project.org/pipermail/alsa-devel/2017-August/123617.html
>> [7] 
>> http://mailman.alsa-project.org/pipermail/alsa-devel/2017-August/123744.html
>> [8] 
>> https://github.com/andr2000/linux/commit/095d7feae00bf00c852c67c4f1044de5601678ed
>>
>>
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> https://lists.xen.org/xen-devel
>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [RFC v1] ALSA: xen-front: Add Xen para-virtualized frontend driver

[Oleksandr Andrushchenko]

ping

On 11/02/2017 03:11 PM, Oleksandr Andrushchenko wrote:
> Hi, all!
>
> Foreword
> ========
>
> This RFC is aimed to introduce support of para-virtualized sound frontend
> driver for Xen [1] and gather opinions from the relevant communities
> (ALSA, Xen). It implements the protocol from [2] 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 scenarios where unprivileged OS
> (e.g. Android, AGL etc) uses software mixers.
> Both capture and playback are supported.
>
> The relevant backend is implemented as a user-space application [3]
> and uses accompanying helper library [4].
>
> Both frontend driver and backend were tested on real HW running Xen 
> hypervisor
> (Renesas R-Car ARM based H3/M3 boards, x86).
>
> Discussion
> ==========
>
> During the first attempt to upstream the driver [5] number of comments 
> and
> concerns were raised, one of the biggest flaws in the design were 
> questioned
> by both Clemens Ladisch [6] and Takashi Sakamoto [7]: the absence of
> synchronization between frontend and backend during capture/playback.
> Two options were discussed:
>
> “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.
> “
>
> and finally a change to the existing protocol was suggested:
>
> “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.”
>
> This is implemented as a change to the sndif protocol [8] and allows 
> removing
> period emulation:
> 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 (in Linux
>    implementation). 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.
>
> Along with these changes other comments on the driver were addressed,
> e.g. split into smaller chunks, moved the driver from misc to xen etc.
>
>
> Hope, this helps to get the full picture of what was discussed and 
> makes it
> possible to move forward.
>
> Waiting for your valuable comments,
>
> Thank you,
> Oleksandr
>
> [1] https://github.com/andr2000/linux/commits/snd_upstream_v1
> [2] 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/xen/interface/io/sndif.h
> [3] https://github.com/xen-troops/snd_be
> [4] https://github.com/xen-troops/libxenbe
> [5] https://lkml.org/lkml/2017/8/7/363
> [6] 
> http://mailman.alsa-project.org/pipermail/alsa-devel/2017-August/123617.html
> [7] 
> http://mailman.alsa-project.org/pipermail/alsa-devel/2017-August/123744.html
> [8] 
> https://github.com/andr2000/linux/commit/095d7feae00bf00c852c67c4f1044de5601678ed
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> https://lists.xen.org/xen-devel


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

[RFC v1] ALSA: xen-front: Add Xen para-virtualized frontend driver

[Oleksandr Andrushchenko]

Hi, all!

Foreword
========

This RFC is aimed to introduce support of para-virtualized sound frontend
driver for Xen [1] and gather opinions from the relevant communities
(ALSA, Xen). It implements the protocol from [2] 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 scenarios where unprivileged OS
(e.g. Android, AGL etc) uses software mixers.
Both capture and playback are supported.

The relevant backend is implemented as a user-space application [3]
and uses accompanying helper library [4].

Both frontend driver and backend were tested on real HW running Xen 
hypervisor
(Renesas R-Car ARM based H3/M3 boards, x86).

Discussion
==========

During the first attempt to upstream the driver [5] number of comments and
concerns were raised, one of the biggest flaws in the design were questioned
by both Clemens Ladisch [6] and Takashi Sakamoto [7]: the absence of
synchronization between frontend and backend during capture/playback.
Two options were discussed:

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

and finally a change to the existing protocol was suggested:

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

This is implemented as a change to the sndif protocol [8] and allows 
removing
period emulation:
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 (in Linux
    implementation). 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.

Along with these changes other comments on the driver were addressed,
e.g. split into smaller chunks, moved the driver from misc to xen etc.


Hope, this helps to get the full picture of what was discussed and makes it
possible to move forward.

Waiting for your valuable comments,

Thank you,
Oleksandr

[1] https://github.com/andr2000/linux/commits/snd_upstream_v1
[2] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/xen/interface/io/sndif.h
[3] https://github.com/xen-troops/snd_be
[4] https://github.com/xen-troops/libxenbe
[5] https://lkml.org/lkml/2017/8/7/363
[6] 
http://mailman.alsa-project.org/pipermail/alsa-devel/2017-August/123617.html
[7] 
http://mailman.alsa-project.org/pipermail/alsa-devel/2017-August/123744.html
[8] 
https://github.com/andr2000/linux/commit/095d7feae00bf00c852c67c4f1044de5601678ed

[RFC v1] ALSA: xen-front: Add Xen para-virtualized frontend driver

[Oleksandr Andrushchenko]

Hi, all!

Foreword
========

This RFC is aimed to introduce support of para-virtualized sound frontend
driver for Xen [1] and gather opinions from the relevant communities
(ALSA, Xen). It implements the protocol from [2] 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 scenarios where unprivileged OS
(e.g. Android, AGL etc) uses software mixers.
Both capture and playback are supported.

The relevant backend is implemented as a user-space application [3]
and uses accompanying helper library [4].

Both frontend driver and backend were tested on real HW running Xen 
hypervisor
(Renesas R-Car ARM based H3/M3 boards, x86).

Discussion
==========

During the first attempt to upstream the driver [5] number of comments and
concerns were raised, one of the biggest flaws in the design were questioned
by both Clemens Ladisch [6] and Takashi Sakamoto [7]: the absence of
synchronization between frontend and backend during capture/playback.
Two options were discussed:

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

and finally a change to the existing protocol was suggested:

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

This is implemented as a change to the sndif protocol [8] and allows 
removing
period emulation:
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 (in Linux
    implementation). 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.

Along with these changes other comments on the driver were addressed,
e.g. split into smaller chunks, moved the driver from misc to xen etc.


Hope, this helps to get the full picture of what was discussed and makes it
possible to move forward.

Waiting for your valuable comments,

Thank you,
Oleksandr

[1] https://github.com/andr2000/linux/commits/snd_upstream_v1
[2] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/xen/interface/io/sndif.h
[3] https://github.com/xen-troops/snd_be
[4] https://github.com/xen-troops/libxenbe
[5] https://lkml.org/lkml/2017/8/7/363
[6] 
http://mailman.alsa-project.org/pipermail/alsa-devel/2017-August/123617.html
[7] 
http://mailman.alsa-project.org/pipermail/alsa-devel/2017-August/123744.html
[8] 
https://github.com/andr2000/linux/commit/095d7feae00bf00c852c67c4f1044de5601678ed


_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel