[alsa-devel] [Xen-devel][PATCH v2 0/3] sndif: add explicit back and front synchronization
From: Oleksandr Andrushchenko oleksandr_andrushchenko@epam.com
Hello, all!
In order to provide explicit synchronization between backend and frontend the following changes are introduced in the protocol: - bump protocol version to 2 - add new ring buffer for sending asynchronous events from backend to frontend to report number of bytes played by the frontend (XENSND_EVT_CUR_POS) - introduce trigger events for playback control: start/stop/pause/resume - add "req-" prefix to event-channel and ring-ref to unify naming of the Xen event channels for requests and events
Changes since v1:
1. Changed protocol version definition from string to integer, so it can easily be used in comparisons. Konrad, I have removed your r-b tag for the reason of this change.
2. In order to provide explicit stream parameter negotiation between backend and frontend the following changes are introduced in the protocol: add XENSND_OP_HW_PARAM_QUERY request to read/update configuration space for the parameter given: request passes desired parameter interval (mask) and the response to this request returns min/max interval (mask) for the parameter to be used.
Parameters supported by this request/response: - format mask - sample rate interval - number of channels interval - buffer size, interval, frames - period size, interval, frames
Thank you, Oleksandr Andrushchenko
Oleksandr Andrushchenko (3): sndif: Introduce protocol version sndif: Add explicit back and front synchronization sndif: Add explicit back and front parameter negotiation
xen/include/public/io/sndif.h | 295 ++++++++++++++++++++++++++++++++++++++++-- 1 file changed, 286 insertions(+), 9 deletions(-)
From: Oleksandr Andrushchenko oleksandr_andrushchenko@epam.com
Protocol version was referenced in the protocol description, but missed its definition. Fix this by adding a constant for current protocol version.
Signed-off-by: Oleksandr Andrushchenko oleksandr_andrushchenko@epam.com --- xen/include/public/io/sndif.h | 7 +++++++ 1 file changed, 7 insertions(+)
diff --git a/xen/include/public/io/sndif.h b/xen/include/public/io/sndif.h index c5c1978406b3..667e610fda2b 100644 --- a/xen/include/public/io/sndif.h +++ b/xen/include/public/io/sndif.h @@ -38,6 +38,13 @@
/* ****************************************************************************** + * Protocol version + ****************************************************************************** + */ +#define XENSND_PROTOCOL_VERSION 1 + +/* + ****************************************************************************** * Feature and Parameter Negotiation ****************************************************************************** *
On Wed, Mar 14, 2018 at 06:02:43PM +0200, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko oleksandr_andrushchenko@epam.com
Protocol version was referenced in the protocol description, but missed its definition. Fix this by adding a constant for current protocol version.
Signed-off-by: Oleksandr Andrushchenko oleksandr_andrushchenko@epam.com
Reviewed-by: Konrad Rzeszutek Wilk konrad.wilk@oracle.com
Thank you!
xen/include/public/io/sndif.h | 7 +++++++ 1 file changed, 7 insertions(+)
diff --git a/xen/include/public/io/sndif.h b/xen/include/public/io/sndif.h index c5c1978406b3..667e610fda2b 100644 --- a/xen/include/public/io/sndif.h +++ b/xen/include/public/io/sndif.h @@ -38,6 +38,13 @@
/*
Protocol version
- */
+#define XENSND_PROTOCOL_VERSION 1
+/*
Feature and Parameter Negotiation
-- 2.7.4
From: Oleksandr Andrushchenko oleksandr_andrushchenko@epam.com
In order to provide explicit synchronization between backend and frontend the following changes are introduced in the protocol: - bump protocol version to 2 - add new ring buffer for sending asynchronous events from backend to frontend to report number of bytes played by the frontend (XENSND_EVT_CUR_POS) - introduce trigger events for playback control: start/stop/pause/resume - add "req-" prefix to event-channel and ring-ref to unify naming of the Xen event channels for requests and events
Signed-off-by: Oleksandr Andrushchenko oleksandr_andrushchenko@epam.com Signed-off-by: Oleksandr Grytsov oleksandr_grytsov@epam.com Cc: Konrad Rzeszutek Wilk konrad.wilk@oracle.com Cc: Takashi Iwai tiwai@suse.de Cc: Takashi Sakamoto o-takashi@sakamocchi.jp Cc: Clemens Ladisch clemens@ladisch.de --- xen/include/public/io/sndif.h | 168 +++++++++++++++++++++++++++++++++++++++++- 1 file changed, 164 insertions(+), 4 deletions(-)
diff --git a/xen/include/public/io/sndif.h b/xen/include/public/io/sndif.h index 667e610fda2b..1a6a1467f253 100644 --- a/xen/include/public/io/sndif.h +++ b/xen/include/public/io/sndif.h @@ -41,7 +41,7 @@ * Protocol version ****************************************************************************** */ -#define XENSND_PROTOCOL_VERSION 1 +#define XENSND_PROTOCOL_VERSION 2
/* ****************************************************************************** @@ -113,6 +113,8 @@ * * /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/evt-ring-ref = "1386" + * /local/domain/1/device/vsnd/0/0/0/evt-event-channel = "215" * *------------------------------ Stream 1, capture ---------------------------- * @@ -122,6 +124,8 @@ * * /local/domain/1/device/vsnd/0/0/1/ring-ref = "384" * /local/domain/1/device/vsnd/0/0/1/event-channel = "13" + * /local/domain/1/device/vsnd/0/0/1/evt-ring-ref = "1384" + * /local/domain/1/device/vsnd/0/0/1/evt-event-channel = "213" * *------------------------------- PCM device 1 -------------------------------- * @@ -135,6 +139,8 @@ * * /local/domain/1/device/vsnd/0/1/0/ring-ref = "387" * /local/domain/1/device/vsnd/0/1/0/event-channel = "151" + * /local/domain/1/device/vsnd/0/1/0/evt-ring-ref = "1387" + * /local/domain/1/device/vsnd/0/1/0/evt-event-channel = "351" * *------------------------------- PCM device 2 -------------------------------- * @@ -147,6 +153,8 @@ * * /local/domain/1/device/vsnd/0/2/0/ring-ref = "389" * /local/domain/1/device/vsnd/0/2/0/event-channel = "152" + * /local/domain/1/device/vsnd/0/2/0/evt-ring-ref = "1389" + * /local/domain/1/device/vsnd/0/2/0/evt-event-channel = "452" * ****************************************************************************** * Backend XenBus Nodes @@ -292,6 +300,23 @@ * The Xen grant reference granting permission for the backend to map * a sole page in a single page sized ring buffer. * + *--------------------- Stream Event Transport Parameters --------------------- + * + * This communication path is used to deliver asynchronous events from backend + * to frontend, set up per stream. + * + * evt-event-channel + * Values: <uint32_t> + * + * The identifier of the Xen event channel used to signal activity + * in the ring buffer. + * + * evt-ring-ref + * Values: <uint32_t> + * + * The Xen grant reference granting permission for the backend to map + * a sole page in a single page sized ring buffer. + * ****************************************************************************** * STATE DIAGRAMS ****************************************************************************** @@ -439,6 +464,19 @@ #define XENSND_OP_GET_VOLUME 5 #define XENSND_OP_MUTE 6 #define XENSND_OP_UNMUTE 7 +#define XENSND_OP_TRIGGER 8 + +#define XENSND_OP_TRIGGER_START 0 +#define XENSND_OP_TRIGGER_PAUSE 1 +#define XENSND_OP_TRIGGER_STOP 2 +#define XENSND_OP_TRIGGER_RESUME 3 + +/* + ****************************************************************************** + * EVENT CODES + ****************************************************************************** + */ +#define XENSND_EVT_CUR_POS 0
/* ****************************************************************************** @@ -455,6 +493,8 @@ #define XENSND_FIELD_VCARD_LONG_NAME "long-name" #define XENSND_FIELD_RING_REF "ring-ref" #define XENSND_FIELD_EVT_CHNL "event-channel" +#define XENSND_FIELD_EVT_RING_REF "evt-ring-ref" +#define XENSND_FIELD_EVT_EVT_CHNL "evt-event-channel" #define XENSND_FIELD_DEVICE_NAME "name" #define XENSND_FIELD_TYPE "type" #define XENSND_FIELD_STREAM_UNIQUE_ID "unique-id" @@ -566,9 +606,7 @@ * +----------------+----------------+----------------+----------------+ * | gref_directory | 24 * +----------------+----------------+----------------+----------------+ - * | reserved | 28 - * +----------------+----------------+----------------+----------------+ - * |//////////////////////////////////| + * | period_sz | 28 * +----------------+----------------+----------------+----------------+ * | reserved | 32 * +----------------+----------------+----------------+----------------+ @@ -578,6 +616,14 @@ * pcm_channels - uint8_t, number of channels of this stream, * [channels-min; channels-max] * buffer_sz - uint32_t, buffer size to be allocated, octets + * period_sz - uint32_t, event period size, octets + * This is the requested value of the period at which frontend would + * like to receive XENSND_EVT_CUR_POS notifications from the backend when + * stream position advances during playback/capture. + * It shows how many octets are expected to be played/captured before + * sending such an event. + * If set to 0 no XENSND_EVT_CUR_POS events are sent by the backend. + * * gref_directory - grant_ref_t, a reference to the first shared page * describing shared buffer references. At least one page exists. If shared * buffer size (buffer_sz) exceeds what can be addressed by this single page, @@ -592,6 +638,7 @@ struct xensnd_open_req { uint16_t reserved; uint32_t buffer_sz; grant_ref_t gref_directory; + uint32_t period_sz; };
/* @@ -750,8 +797,36 @@ struct xensnd_rw_req { * * The 'struct xensnd_rw_req' is also used for XENSND_OP_SET_VOLUME, * XENSND_OP_GET_VOLUME, XENSND_OP_MUTE, XENSND_OP_UNMUTE. + * + * Request stream running state change - trigger PCM stream running state + * to start, stop, pause or resume: + * + * 0 1 2 3 octet + * +----------------+----------------+----------------+----------------+ + * | id | _OP_TRIGGER | reserved | 4 + * +----------------+----------------+----------------+----------------+ + * | reserved | 8 + * +----------------+----------------+----------------+----------------+ + * | type | reserved | 12 + * +----------------+----------------+----------------+----------------+ + * | reserved | 16 + * +----------------+----------------+----------------+----------------+ + * | reserved | 20 + * +----------------+----------------+----------------+----------------+ + * | reserved | 24 + * +----------------+----------------+----------------+----------------+ + * | reserved | 28 + * +----------------+----------------+----------------+----------------+ + * | reserved | 32 + * +----------------+----------------+----------------+----------------+ + * + * type - uint8_t, XENSND_OP_TRIGGER_XXX value */
+struct xensnd_trigger_req { + uint8_t type; +}; + /* *---------------------------------- Responses -------------------------------- * @@ -774,8 +849,51 @@ struct xensnd_rw_req { * id - uint16_t, copied from the request * operation - uint8_t, XENSND_OP_* - copied from request * status - int32_t, response status, zero on success and -XEN_EXX on failure + * + *----------------------------------- Events ---------------------------------- + * + * Events are sent via a shared page allocated by the front and propagated by + * evt-event-channel/evt-ring-ref XenStore entries + * All event packets have the same length (32 octets) + * All event packets have common header: + * 0 1 2 3 octet + * +----------------+----------------+----------------+----------------+ + * | id | type | reserved | 4 + * +----------------+----------------+----------------+----------------+ + * | reserved | 8 + * +----------------+----------------+----------------+----------------+ + * + * id - uint16_t, event id, may be used by front + * type - uint8_t, type of the event + * + * + * Current stream position - event from back to front when stream's + * playback/capture position has advanced: + * 0 1 2 3 octet + * +----------------+----------------+----------------+----------------+ + * | id | _EVT_CUR_POS | reserved | 4 + * +----------------+----------------+----------------+----------------+ + * | reserved | 8 + * +----------------+----------------+----------------+----------------+ + * | position low 32-bit | 12 + * +----------------+----------------+----------------+----------------+ + * | position high 32-bit | 16 + * +----------------+----------------+----------------+----------------+ + * | reserved | 20 + * +----------------+----------------+----------------+----------------+ + * |//////////////////////////////////| + * +----------------+----------------+----------------+----------------+ + * | reserved | 32 + * +----------------+----------------+----------------+----------------+ + * + * position - current value of stream's playback/capture position, octets + * */
+struct xensnd_cur_pos_evt { + uint64_t position; +}; + struct xensnd_req { uint16_t id; uint8_t operation; @@ -783,6 +901,7 @@ struct xensnd_req { union { struct xensnd_open_req open; struct xensnd_rw_req rw; + struct xensnd_trigger_req trigger; uint8_t reserved[24]; } op; }; @@ -795,8 +914,49 @@ struct xensnd_resp { uint8_t reserved1[24]; };
+struct xensnd_evt { + uint16_t id; + uint8_t type; + uint8_t reserved[5]; + union { + struct xensnd_cur_pos_evt cur_pos; + uint8_t reserved[24]; + } op; +}; + DEFINE_RING_TYPES(xen_sndif, struct xensnd_req, struct xensnd_resp);
+/* + ****************************************************************************** + * Back to front events delivery + ****************************************************************************** + * In order to deliver asynchronous events from back to front a shared page is + * allocated by front and its granted reference propagated to back via + * XenStore entries (evt-ring-ref/evt-event-channel). + * This page has a common header used by both front and back to synchronize + * access and control event's ring buffer, while back being a producer of the + * events and front being a consumer. The rest of the page after the header + * is used for event packets. + * + * Upon reception of an event(s) front may confirm its reception + * for either each event, group of events or none. + */ + +struct xensnd_event_page { + uint32_t in_cons; + uint32_t in_prod; + uint8_t reserved[24]; +}; + +#define XENSND_EVENT_PAGE_SIZE 4096 +#define XENSND_IN_RING_OFFS (sizeof(struct xensnd_event_page)) +#define XENSND_IN_RING_SIZE (XENSND_EVENT_PAGE_SIZE - XENSND_IN_RING_OFFS) +#define XENSND_IN_RING_LEN (XENSND_IN_RING_SIZE / sizeof(struct xensnd_evt)) +#define XENSND_IN_RING(page) \ + ((struct xensnd_evt *)((char *)(page) + XENSND_IN_RING_OFFS)) +#define XENSND_IN_RING_REF(page, idx) \ + (XENSND_IN_RING((page))[(idx) % XENSND_IN_RING_LEN]) + #endif /* __XEN_PUBLIC_IO_SNDIF_H__ */
/*
Back to front events delivery
- In order to deliver asynchronous events from back to front a shared page is
- allocated by front and its granted reference propagated to back via
- XenStore entries (evt-ring-ref/evt-event-channel).
- This page has a common header used by both front and back to synchronize
- access and control event's ring buffer, while back being a producer of the
- events and front being a consumer. The rest of the page after the header
- is used for event packets.
- Upon reception of an event(s) front may confirm its reception
- for either each event, group of events or none.
- */
+struct xensnd_event_page {
- uint32_t in_cons;
- uint32_t in_prod;
- uint8_t reserved[24];
Could this be aligned at 64 bytes?
+};
On 03/15/2018 10:17 PM, Konrad Rzeszutek Wilk wrote:
Back to front events delivery
- In order to deliver asynchronous events from back to front a shared page is
- allocated by front and its granted reference propagated to back via
- XenStore entries (evt-ring-ref/evt-event-channel).
- This page has a common header used by both front and back to synchronize
- access and control event's ring buffer, while back being a producer of the
- events and front being a consumer. The rest of the page after the header
- is used for event packets.
- Upon reception of an event(s) front may confirm its reception
- for either each event, group of events or none.
- */
+struct xensnd_event_page {
- uint32_t in_cons;
- uint32_t in_prod;
- uint8_t reserved[24];
Could this be aligned at 64 bytes?
Sure, will make the struct 64 bytes
+};
From: Oleksandr Andrushchenko oleksandr_andrushchenko@epam.com
In order to provide explicit stream parameter negotiation between backend and frontend the following changes are introduced in the protocol: add XENSND_OP_HW_PARAM_QUERY request to read/update configuration space for the parameter given: request passes desired parameter interval (mask) and the response to this request returns min/max interval (mask) for the parameter to be used.
Parameters supported by this request/response: - format mask - sample rate interval - number of channels interval - buffer size, interval, frames - period size, interval, frames
Signed-off-by: Oleksandr Andrushchenko oleksandr_andrushchenko@epam.com Cc: Konrad Rzeszutek Wilk konrad.wilk@oracle.com Cc: Takashi Iwai tiwai@suse.de --- xen/include/public/io/sndif.h | 124 +++++++++++++++++++++++++++++++++++++++--- 1 file changed, 117 insertions(+), 7 deletions(-)
diff --git a/xen/include/public/io/sndif.h b/xen/include/public/io/sndif.h index 1a6a1467f253..ff0ba15b0462 100644 --- a/xen/include/public/io/sndif.h +++ b/xen/include/public/io/sndif.h @@ -465,12 +465,19 @@ #define XENSND_OP_MUTE 6 #define XENSND_OP_UNMUTE 7 #define XENSND_OP_TRIGGER 8 +#define XENSND_OP_HW_PARAM_QUERY 9
#define XENSND_OP_TRIGGER_START 0 #define XENSND_OP_TRIGGER_PAUSE 1 #define XENSND_OP_TRIGGER_STOP 2 #define XENSND_OP_TRIGGER_RESUME 3
+#define XENSND_OP_HW_PARAM_FORMAT 0 +#define XENSND_OP_HW_PARAM_RATE 1 +#define XENSND_OP_HW_PARAM_BUFFER 2 +#define XENSND_OP_HW_PARAM_PERIOD 3 +#define XENSND_OP_HW_PARAM_CHANNELS 4 + /* ****************************************************************************** * EVENT CODES @@ -828,28 +835,127 @@ struct xensnd_trigger_req { };
/* + * Request stream configuration parameter range: request interval or + * bit mask of the supported values for the parameter given. + * + * Sound device configuration for a particular stream is a limited subset + * of the multidimensional configuration available on XenStore, for instance, + * once frame rate has been selected there is a limited supported range + * for sample rates becomes available (which might be the same set configured + * on XenStore or less). For example, selecting 96kHz sample rate may limit + * number of channels available for such configuration from 4 to 2 etc. + * Thus, each call to XENSND_OP_HW_PARAM_QUERY will reduce configuration + * space making it possible to iteratively get the final stream configuration, + * used in XENSND_OP_OPEN request. + * + * See response format for this request. + * + * 0 1 2 3 octet + * +----------------+----------------+----------------+----------------+ + * | id | _HW_PARAM_QUERY| reserved | 4 + * +----------------+----------------+----------------+----------------+ + * | reserved | 8 + * +----------------+----------------+----------------+----------------+ + * | param | reserved | 12 + * +----------------+----------------+----------------+----------------+ + * | min or mask low 32-bit | 16 + * +----------------+----------------+----------------+----------------+ + * | max or mask high 32-bit | 20 + * +----------------+----------------+----------------+----------------+ + * | reserved | 24 + * +----------------+----------------+----------------+----------------+ + * | reserved | 28 + * +----------------+----------------+----------------+----------------+ + * | reserved | 32 + * +----------------+----------------+----------------+----------------+ + * + * param - uint8_t, XENSND_OP_HW_PARAM_XXX value + * + * The following parameters' payload treated as interval: + * XENSND_OP_HW_PARAM_RATE + * XENSND_OP_HW_PARAM_BUFFER + * XENSND_OP_HW_PARAM_PERIOD + * XENSND_OP_HW_PARAM_CHANNELS + * + * For interval parameters the payload of the request: + * min - uint32_t, minimum value of the parameter + * max - uint32_t, maximum value of the parameter + * + * For the following parameters their min and max values are expressed in + * frames: + * XENSND_OP_HW_PARAM_BUFFER + * XENSND_OP_HW_PARAM_PERIOD + * where frame is defined as a product of the number of channels by the + * number of octets per one sample. + * + * The following parameters' payload treated as a bit mask: + * XENSND_OP_HW_PARAM_FORMAT + * + * For mask parameters the payload of the request: + * mask - uint64_t, bit mask representing values of the parameter + */ + +struct xensnd_query_hw_param_req { + uint8_t param; + uint8_t reserved[3]; + union { + struct { + uint32_t min; + uint32_t max; + } interval; + uint64_t mask; + } val; +}; + +/* *---------------------------------- Responses -------------------------------- * * All response packets have the same length (32 octets) * - * Response for all requests: + * All response packets have common header: + * 0 1 2 3 octet + * +----------------+----------------+----------------+----------------+ + * | id | operation | reserved | 4 + * +----------------+----------------+----------------+----------------+ + * | status | 8 + * +----------------+----------------+----------------+----------------+ + * + * id - uint16_t, copied from the request + * operation - uint8_t, XENSND_OP_* - copied from request + * status - int32_t, response status, zero on success and -XEN_EXX on failure + * + * + * HW parameter query response - response for XENSND_OP_HW_PARAM_QUERY: * 0 1 2 3 octet * +----------------+----------------+----------------+----------------+ * | id | operation | reserved | 4 * +----------------+----------------+----------------+----------------+ * | status | 8 * +----------------+----------------+----------------+----------------+ - * | reserved | 12 + * | min or mask low 32-bit | 12 + * +----------------+----------------+----------------+----------------+ + * | max or mask high 32-bit | 16 + * +----------------+----------------+----------------+----------------+ + * | reserved | 20 * +----------------+----------------+----------------+----------------+ * |//////////////////////////////////| * +----------------+----------------+----------------+----------------+ * | reserved | 32 * +----------------+----------------+----------------+----------------+ * - * id - uint16_t, copied from the request - * operation - uint8_t, XENSND_OP_* - copied from request - * status - int32_t, response status, zero on success and -XEN_EXX on failure - * + * The payload meaning is the same as in the corresponing HW parameter + * request: see XENSND_OP_HW_PARAM_QUERY for details. + */ + +union xensnd_query_hw_param_resp { + struct { + uint32_t min; + uint32_t max; + } interval; + uint64_t mask; +}; + +/* *----------------------------------- Events ---------------------------------- * * Events are sent via a shared page allocated by the front and propagated by @@ -902,6 +1008,7 @@ struct xensnd_req { struct xensnd_open_req open; struct xensnd_rw_req rw; struct xensnd_trigger_req trigger; + struct xensnd_query_hw_param_req hw_param; uint8_t reserved[24]; } op; }; @@ -911,7 +1018,10 @@ struct xensnd_resp { uint8_t operation; uint8_t reserved; int32_t status; - uint8_t reserved1[24]; + union { + union xensnd_query_hw_param_resp hw_param; + uint8_t reserved1[24]; + } resp; };
struct xensnd_evt {
participants (2)
-
Konrad Rzeszutek Wilk -
Oleksandr Andrushchenko