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