aseqsend silently fails (ENODEV) with hardware port

aseqsend silently fails (ENODEV) with hardware port

[GitHub issues - opened]

alsa-project/alsa-utils issue #300 was opened from michaelforney:

When I use `aseqsend` to send a sysex message to a device, it doesn't seem to work, though there is no error message. Running with strace, it seems it is failing with ENODEV.

```sh
$ strace aseqsend -p 32:0 'F0 43 7D 10 41 30 01 00 00 01 F7'
...
open("/dev/snd/seq", O_WRONLY|O_LARGEFILE|O_CLOEXEC) = 3
fcntl(3, F_SETFD, FD_CLOEXEC)           = 0
ioctl(3, SNDRV_SEQ_IOCTL_PVERSION, 0x7fffef1ae678) = 0
ioctl(3, SNDRV_SEQ_IOCTL_USER_PVERSION, 0x7fffef1ae67c) = 0
mmap(NULL, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f6ae25f7000
ioctl(3, SNDRV_SEQ_IOCTL_CLIENT_ID, 0x7fffef1ae67c) = 0
ioctl(3, SNDRV_SEQ_IOCTL_RUNNING_MODE, 0x7fffef1ae680) = 0
ioctl(3, SNDRV_SEQ_IOCTL_GET_CLIENT_INFO, 0x7fffef1ae940) = 0
ioctl(3, SNDRV_SEQ_IOCTL_SET_CLIENT_INFO, 0x7fffef1ae940) = 0
ioctl(3, SNDRV_SEQ_IOCTL_GET_CLIENT_INFO, 0x7fffef1ae940) = 0
ioctl(3, SNDRV_SEQ_IOCTL_SET_CLIENT_INFO, 0x7fffef1ae940) = 0
ioctl(3, SNDRV_SEQ_IOCTL_CREATE_PORT, 0x7fffef1ae960) = 0
write(3, "\202\4\0\375\0\0\0\0\0\0\0\0\0\0 \0\v\0\0\0\320\212WN\361U\0\0\360C}\20"..., 39) = -1 ENODEV (No such device)
nanosleep({tv_sec=0, tv_nsec=1000000}, 0x7fffef1aea20) = 0
close(3)                                = 0
munmap(0x7f6ae25f7000, 20480)           = 0
exit_group(0)                           = ?
+++ exited with 0 +++
$
```

`amidi -S ...` works as expected. If I modify `aseqsend` to first subscribe to the port, it seems to work:

```diff
diff --git a/seq/aseqsend/aseqsend.c b/seq/aseqsend/aseqsend.c
index 92354eb..ad0a636 100644
--- a/seq/aseqsend/aseqsend.c
+++ b/seq/aseqsend/aseqsend.c
@@ -364,6 +364,7 @@ int main(int argc, char *argv[])
 	char do_port_list = 0;
 	char verbose = 0;
 	int k;
+	int err;
 
 	while ((c = getopt_long(argc, argv, "hi:Vvlp:s:u:", long_options, NULL)) != -1) {
 		switch (c) {
@@ -439,6 +440,8 @@ int main(int argc, char *argv[])
 		error("Unable to parse port name!");
 		exit(EXIT_FAILURE);
 	}
+	err = snd_seq_connect_to(seq, 0, addr.client, addr.port);
+	check_snd("connect to port", err);
 
 	sent_data_c = 0; //counter of actually sent bytes
```

>From what I've read, I don't think it should be necessary to subscribe to a port to send it messages. However, I did find one sentence in the alsa-lib docs that seem to indicate that it is needed for hardware ports:
> There is another subscription type for opposite direction: Suppose a MIDI sequencer program which sends events to a MIDI output device. In ALSA system, MIDI device is not opened until the associated MIDI port is accessed. Thus, in order to activate MIDI device, we have to subscribe to MIDI port for write. After this connection is established, events will be properly sent to MIDI output device.

This seems to be a pretty basic use of `aseqsend`, so I am a bit surprised that it wasn't working. Is the subscription the right way to fix the problem, or am I doing something else wrong?

Issue URL     : https://github.com/alsa-project/alsa-utils/issues/300
Repository URL: https://github.com/alsa-project/alsa-utils

Re: aseqsend silently fails (ENODEV) with hardware port

[braxtonangelic97]

Older ALSA behavior or some virtual/software ports didn’t enforce this strict requirement — those ports accept events without a subscription. On modern kernels and with hardware endpoints, this handshake step became necessary for correct device activation.
https://driftbossgame.io

Re: aseqsend silently fails (ENODEV) with hardware port

[gratianaolive]

Interesting issue! The ENODEV error suggests a device access problem. Perhaps a missing initialization step within aseqsend is the culprit, not handled correctly like in amidi. The diff showing subscription as a fix is telling. Anyone else see this when configuring ALSA after playing Snow Rider? https://snowridergame.io