cloning snd_seq_t (or creating one from client id)

cloning snd_seq_t (or creating one from client id)

[Tobias Schlemmer]

Hi,

Recently, I came upon the following problem with the ALSA sequencer
interface:
I'm surprised that the upcoming version of RtMidi uses one ALSA client
per MIDI port.
As an end user I'd expect to see only one ALSA client per program
instance (e.g. using aconnect -i - o -l).
Asking for the reason of that change I got the answer that it has
something to do with broken multithread support.

Digging deeper into this problem I found out that sequencer handles
(snd_seq_t) are not thread safe.
So my question is:
Could you provide some way to implement multithreaded ALSA clients?

My idea is to provide some function
int snd_seq_clone(snd_seq_t * old, snd_seq_t ** new) /* clone a sequencer */
and/or
int snd_seq_create_from_client(int clientid, snd_seq_t ** new) /* create
a sequencer from a given client id */
and/or
int snd_seq_split_port(snd_seq_t * old, snd_seq_t ** new, int port) /*
create a sequencer that steels a port from old */

For the semantics I think cloned sequencers should act as if they don't
know each other.
Each one has its own set of ports. While the generation of port numbers
still uses the same counter. I don't expect creating a port to be that
time critical that it can't use locks.

If it helps to ease the implementation one could use a master sequencer
with some slaves. If the master sequencer is deleted the slaves are
automatically freed and must not be used anymore.

And if a subsequencer tries to access a port of another subsequncer,
ALSA could just return with an error.

Regards,

Tobias

P.S.: please, CC to me in answers.

Re: cloning snd_seq_t (or creating one from client id)

[Clemens Ladisch]

Tobias Schlemmer wrote:
> I'm surprised that the upcoming version of RtMidi uses one ALSA client
> per MIDI port.
>
> I found out that sequencer handles (snd_seq_t) are not thread safe.

A sequencer client use a common buffer for the events of all ports.

> Could you provide some way to implement multithreaded ALSA clients?

Multiple threads would have to synchronize the buffer accesses in some
way.  How exactly merging and distributing of events from/to multiple
ports is handled (even when some thread does not react) is a policy that
cannot be imposed by the ALSA library.


Regards,
Clemens

Re: cloning snd_seq_t (or creating one from client id)

[Tobias Schlemmer]

[-- Attachment #1: Type: text/plain, Size: 2091 bytes --]

Am 31.03.2014 14:29, schrieb Clemens Ladisch:
> Tobias Schlemmer wrote:
>> I'm surprised that the upcoming version of RtMidi uses one ALSA client
>> per MIDI port.
>>
>> I found out that sequencer handles (snd_seq_t) are not thread safe.
> A sequencer client use a common buffer for the events of all ports.
Yes. Thus, I suggested to split the set of ports of a client into
disjoint subsets. Then each sequencer would handle only one of these
subsets, which should reduce the interference with other ports' code.
>> Could you provide some way to implement multithreaded ALSA clients?
> Multiple threads would have to synchronize the buffer accesses in some
> way.
That is not true. Programmers tend to program lock free, as locking
creates always a bottleneck. Other problems can occur if have different
load and different priority to the program. The current aproach that is
taken by kmid and RtMidi is to use different sequencers. The ALSA docu
suggests to use different sequencers in the latter way. Unfortunately
this does not comply with the idea of clients and ports as they are
presented to end users. So I suggested to hide this implementation
detail from the end user and present him all ports from all sequencers
of a program instance under one common client id. The port ids used in
the sequencers should be the same as the ones that are presented to the
end user in order to prevent unexpected behaviour.

How exactly merging and distributing of events from/to multiple
ports is handled (even when some thread does not react) is a policy that
cannot be imposed by the ALSA library.

The current policy is forcing the client to serialise events of
different connections that don't interfere. The ALSA imposes a policy
that is obviously is not necessary from a technical point of view as
every program instance can use different sequencer clients already with
the current implementation at the cost of worsening the usability. My
suggestion is to losen this restriction.

Regards,

Tobias

P.S.: We are talking about the library API right?

[-- Attachment #2: 0x73A2F90C.asc --]
[-- Type: application/pgp-keys, Size: 4372 bytes --]

[-- Attachment #3: Type: text/plain, Size: 0 bytes --]

Re: cloning snd_seq_t (or creating one from client id)

[Clemens Ladisch]

Tobias Schlemmer wrote:
> ALSA imposes a policy
> that is obviously is not necessary from a technical point of view as
> every program instance can use different sequencer clients already with
> the current implementation at the cost of worsening the usability. My
> suggestion is to losen this restriction.

What you call "loosening this restriction" would actually involve
a nontrivial amount of code.

> P.S.: We are talking about the library API right?

Most of the client event handling is implemented in the kernel.

However, a threadsafe event (de)multiplexer could just as well be
implemented completely outside of the ALSA library.


Regards,
Clemens