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 >
