Re: Questions about event implementation in ALSA Sequencer

[Takashi Sakamoto <o-takashi@sakamocchi.jp>]

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