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
