Re: [PATCH - alsa-utils 5/5] The amidicat program itself, better late than never

[Clemens Ladisch <clemens@ladisch.de>]

Josh Lehan wrote:
> Somehow, the aseqdump program overcomes this limitation, though!  I need
> to figure out how it does that.  I think it has something to do with how
> the connection is made: simultaneously acting as both a direct
> connection and a subscription connection at the same time.

Have a look at how aseqdump decides what PORT_CAP bits to set.

> Also, what about ALSA permissions that amidicat itself advertises?  To
> make a long story short, I think I have this backwards.

These bits specify what _other_ clients can do with the port.

> Multiple copies of aseqdump can be
> ran at the same time, and everything still works (ALSA correctly
> multiplexes the output of vkeybd to all interested subscribers).
>
> However, this doesn't work for amidicat, and that's a bug.  When
> amidicat is running, ALSA blocks delivery of vkeybd events to the
> aseqdump clients.  When amidicat exits, this blockage clears, and all
> the blocked events are suddenly delivered to aseqdump (that's why you
> get the flood of output in aseqdump when amidicat exits).  Obviously,
> amidicat is doing something wrong, and confusing ALSA.

Does the thread actually read the delivered events from the kernel
buffer?

> Also, try "amidicat --list", which will give you output similar to
> "aplaymidi -l" but include more devices (unlike aplaymidi, amidicat does
> no filtering, it shows you everything, even including itself in the list).

It should list only those ports it can use, i.e., connect from/to.


Regards,
Clemens