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).
- 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.
- 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.
- 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