Questions about event implementation in ALSA Sequencer

Questions about event implementation in ALSA Sequencer

[Takashi Sakamoto]

Hi,

I'm working for alsa-gobject[1] so that it supports API for ALSA Sequencer.
At present I've mostly done it just with direct dispatch support[2] (thus
transmission via queue is for my later work). Then I have some questions
about the design of event in ALSA Sequencer. I'd like to ask for some advices
(mainly Iwai-san, perhaps).

1. use case of SNDRV_SEQ_EVENT_LENGTH_VARUSR in 'struct snd_seq_event'

In my understanding, the flag is used for a case that sender transmits the
value of pointer itself and its length to the receiver in the shape of
'struct snd_seq_ev_ext'. I assume that two use cases. If the sender and
receiver are in the same process, the event is a request for the receiver to
operate data in the same VMA. If the sender and receiver are in different
processes, the event is a request for pointer-based calculation between the
peer.

If the above understanding is correct, it's hard to represent this type of
event for g-i interface because g-i is the object-based framework. Any raw
pointer without explicit type is hard to be exposed to g-i applications as
long as I know, and it's going to be unsupported, perhaps.


2. event data type corresponding to event type

Some event types are expected to specific data type; e.g. SNDRV_SEQ_EVENT_NOTE
is for 'struct snd_seq_ev_note' and SNDRV_SEQ_EVENT_CONTROLLER is for
'struct snd_seq_ev_ctrl'. However there're some types for any data type; e.g.
SNDRV_SEQ_EVENT_ECHO or SNDRV_SEQ_EVENT_USR0. For the kind of types, the
event structure has no information about which data type should be used and
user applications voluntarily decide the data type. Therefore the sender
and receiver should share a kind of protocol in advance.

This means that userspace applications require API to select data type
independent of event type itself.


3. quote event and specific event types.

Two event types are reserved for 'struct snd_seq_ev_quote'; i.e.
SNDRV_SEQ_EVENT_KERNEL_ERROR and SNDRV_SEQ_EVENT_KERNEL_QUOTE(obsoleted?).
However, the quote structure is exposed to userspace itself. Furthermore,
as of v5.5 kernel, there's no in-kernel code to check the quote data
from/to user client.

Is it better to produce API so that userspace application can transfer
the quote event?

[1] https://github.com/alsa-project/alsa-gobject
[2] https://github.com/takaswie/alsa-gobject/tree/topic/seq

Regards


Takashi Sakamoto

Re: Questions about event implementation in ALSA Sequencer

[Takashi Iwai]

On Tue, 18 Feb 2020 04:11:02 +0100,
Takashi Sakamoto wrote:
> 
> Hi,
> 
> I'm working for alsa-gobject[1] so that it supports API for ALSA Sequencer.
> At present I've mostly done it just with direct dispatch support[2] (thus
> transmission via queue is for my later work). Then I have some questions
> about the design of event in ALSA Sequencer. I'd like to ask for some advices
> (mainly Iwai-san, perhaps).
> 
> 1. use case of SNDRV_SEQ_EVENT_LENGTH_VARUSR in 'struct snd_seq_event'
> 
> In my understanding, the flag is used for a case that sender transmits the
> value of pointer itself and its length to the receiver in the shape of
> 'struct snd_seq_ev_ext'. I assume that two use cases. If the sender and
> receiver are in the same process, the event is a request for the receiver to
> operate data in the same VMA. If the sender and receiver are in different
> processes, the event is a request for pointer-based calculation between the
> peer.
> 
> If the above understanding is correct, it's hard to represent this type of
> event for g-i interface because g-i is the object-based framework. Any raw
> pointer without explicit type is hard to be exposed to g-i applications as
> long as I know, and it's going to be unsupported, perhaps.

To be more exact, the usage isn't restricted whether belonging to the
same process or not.  The event with VARUSR is processed only for the
direct transfer, not for the scheduled transfer.  That is, the written
packet is immediately processed and the user-space data is copied to
the destinations at this point.  In this sense, it's no zero-copy but
rather just for saving the space in the input pool.


> 2. event data type corresponding to event type
> 
> Some event types are expected to specific data type; e.g. SNDRV_SEQ_EVENT_NOTE
> is for 'struct snd_seq_ev_note' and SNDRV_SEQ_EVENT_CONTROLLER is for
> 'struct snd_seq_ev_ctrl'. However there're some types for any data type; e.g.
> SNDRV_SEQ_EVENT_ECHO or SNDRV_SEQ_EVENT_USR0. For the kind of types, the
> event structure has no information about which data type should be used and
> user applications voluntarily decide the data type. Therefore the sender
> and receiver should share a kind of protocol in advance.
> 
> This means that userspace applications require API to select data type
> independent of event type itself.

Right, those 'any-type' events have no specification of the event
data, hence both sender and receiver need to agree with the handling.
IOW, if not known, the receiver should discard the event.


> 3. quote event and specific event types.
> 
> Two event types are reserved for 'struct snd_seq_ev_quote'; i.e.
> SNDRV_SEQ_EVENT_KERNEL_ERROR and SNDRV_SEQ_EVENT_KERNEL_QUOTE(obsoleted?).
> However, the quote structure is exposed to userspace itself. Furthermore,
> as of v5.5 kernel, there's no in-kernel code to check the quote data
> from/to user client.
> 
> Is it better to produce API so that userspace application can transfer
> the quote event?

You can, but it makes little sense other than as a fuzzer.
The quote events are only for the error bounce that is used
internally.


thanks,

Takashi

> 
> [1] https://github.com/alsa-project/alsa-gobject
> [2] https://github.com/takaswie/alsa-gobject/tree/topic/seq
> 
> Regards
> 
> 
> Takashi Sakamoto
> 

Re: Questions about event implementation in ALSA Sequencer

[Takashi Sakamoto]

Hi,

Thanks for your reply ;)

On Tue, Feb 18, 2020 at 08:28:04AM +0100, Takashi Iwai wrote:
> On Tue, 18 Feb 2020 04:11:02 +0100,
> Takashi Sakamoto wrote:
> > 
> > Hi,
> > 
> > I'm working for alsa-gobject[1] so that it supports API for ALSA Sequencer.
> > At present I've mostly done it just with direct dispatch support[2] (thus
> > transmission via queue is for my later work). Then I have some questions
> > about the design of event in ALSA Sequencer. I'd like to ask for some advices
> > (mainly Iwai-san, perhaps).
> > 
> > 1. use case of SNDRV_SEQ_EVENT_LENGTH_VARUSR in 'struct snd_seq_event'
> > 
> > In my understanding, the flag is used for a case that sender transmits the
> > value of pointer itself and its length to the receiver in the shape of
> > 'struct snd_seq_ev_ext'. I assume that two use cases. If the sender and
> > receiver are in the same process, the event is a request for the receiver to
> > operate data in the same VMA. If the sender and receiver are in different
> > processes, the event is a request for pointer-based calculation between the
> > peer.
> > 
> > If the above understanding is correct, it's hard to represent this type of
> > event for g-i interface because g-i is the object-based framework. Any raw
> > pointer without explicit type is hard to be exposed to g-i applications as
> > long as I know, and it's going to be unsupported, perhaps.
> 
> To be more exact, the usage isn't restricted whether belonging to the
> same process or not.  The event with VARUSR is processed only for the
> direct transfer, not for the scheduled transfer.  That is, the written
> packet is immediately processed and the user-space data is copied to
> the destinations at this point.  In this sense, it's no zero-copy but
> rather just for saving the space in the input pool.

Yes. VARUSR is available with direct transfer only.

In alsa-lib documentation, I can see 'only for a special purpose like a bulk
data transfer':
https://www.alsa-project.org/alsa-doc/alsa-lib/seq.html#seq_ev_data

I guess in this case page frame sharing is used between the peers, like
POSIX shared memory or System V shared memory. Then VARUSR is used to
point on the memory insted of copying the buld data.

> > 2. event data type corresponding to event type
> > 
> > Some event types are expected to specific data type; e.g. SNDRV_SEQ_EVENT_NOTE
> > is for 'struct snd_seq_ev_note' and SNDRV_SEQ_EVENT_CONTROLLER is for
> > 'struct snd_seq_ev_ctrl'. However there're some types for any data type; e.g.
> > SNDRV_SEQ_EVENT_ECHO or SNDRV_SEQ_EVENT_USR0. For the kind of types, the
> > event structure has no information about which data type should be used and
> > user applications voluntarily decide the data type. Therefore the sender
> > and receiver should share a kind of protocol in advance.
> > 
> > This means that userspace applications require API to select data type
> > independent of event type itself.
> 
> Right, those 'any-type' events have no specification of the event
> data, hence both sender and receiver need to agree with the handling.
> IOW, if not known, the receiver should discard the event.
>
>
> > 3. quote event and specific event types.
> > 
> > Two event types are reserved for 'struct snd_seq_ev_quote'; i.e.
> > SNDRV_SEQ_EVENT_KERNEL_ERROR and SNDRV_SEQ_EVENT_KERNEL_QUOTE(obsoleted?).
> > However, the quote structure is exposed to userspace itself. Furthermore,
> > as of v5.5 kernel, there's no in-kernel code to check the quote data
> > from/to user client.
> > 
> > Is it better to produce API so that userspace application can transfer
> > the quote event?
> 
> You can, but it makes little sense other than as a fuzzer.
> The quote events are only for the error bounce that is used
> internally.
 
In the view of generic IPC mechanism (in my understanding ALSA Sequencer is
a sort of IPC mechanism), error bounce is not only required for kernel
stuffs, but also for userspace applications. However it seems to be a bit hard
to express the nested event structure as GObject class, I leave it as
unsupported in this time.
 

Thanks

Takashi Sakamoto

> thanks,
> 
> Takashi
> 
> > 
> > [1] https://github.com/alsa-project/alsa-gobject
> > [2] https://github.com/takaswie/alsa-gobject/tree/topic/seq
> > 
> > Regards
> > 
> > 
> > Takashi Sakamoto