All of lore.kernel.org
 help / color / mirror / Atom feed
From: GitHub issues - opened <github@alsa-project.org>
To: alsa-devel@alsa-project.org
Subject: Difference in behaviour between physical devices and virtual endpoints
Date: Mon, 31 Mar 2025 22:40:49 +0200 (CEST)	[thread overview]
Message-ID: <1831fddaa08fb500-webhooks-bot@alsa-project.org> (raw)
In-Reply-To: <1831fddaa087b800-webhooks-bot@alsa-project.org>

alsa-project/alsa-lib issue #447 was opened from reuk:

As a disclaimer, there's a good chance this is user error/misunderstanding rather than a bug, but I'd appreciate any insights to help me understand the behaviour I'm seeing.

# Environment

- Fedora 41 x86_64
- alsa-lib-devel-1.2.13-3

# Steps

- Run `aseqdump -u 1` in a terminal
- Connect ProtoZOA hardware via USB
- Launch QjackCtl -> Graph, then connect the ProtoZOA's MIDI 2.0 output port (0) to `aseqdump`'s input port.

<img width="535" alt="Image" src="https://github.com/user-attachments/assets/17bf6a74-f83d-41b4-afc6-05413a7ab0a9" />

- Observe that `aseqdump` reports a new subscription from `24:0 -> 128:0` (the client IDs may vary, the important thing is that the subscription is between to ports with ID `0`).
- Move one of the controllers on the ProtoZOA. Observe that `aseqdump` reports channel voice events on group 0 with source `24:1`.

<img width="502" alt="Image" src="https://github.com/user-attachments/assets/2dfc5929-123f-4e33-abbb-ea0c2635c730" />

- Connect `aseqdump` to port `1:Group 1 (FB1, FB2)`, and interact with the ProtoZOA. Observe that `aseqdump` still reports channel voice events on group 0 with source `24:1`.
- Now, build and run the [seq-ump-example](https://github.com/alsa-project/alsa-lib/blob/master/test/seq-ump-example.c).
- Connect the ProtoZOA to the ACMESynth input, and the ACMESynth output to `aseqdump` as shown. Observe that `aseqdump` does **not** report channel voice events when interacting with the ProtoZOA.

<img width="790" alt="Image" src="https://github.com/user-attachments/assets/71349cd6-14b8-4df9-8ee6-ca1091c2f4f0" />

- Finally, update the connections as shown, so that `aseqdump` is connected to ACMESynth's `1:Group 1 (Filter 1)` output. Observe that `aseqdump` now reports channel voice events with source `128:1` when interacting with the ProtoZOA.

<img width="772" alt="Image" src="https://github.com/user-attachments/assets/57f4e767-b2d6-4156-8514-578851d5ed62" />

# TL;DR

When we subscribe to a USB `MIDI 2.0` port, we receive messages from all of the endpoint's ports. Messages are dispatched to the appropriate port based on the message group.

When we subscribe to a virtual UMP endpoint's `MIDI 2.0` port, this appears to *only* subscribe to that single port, and not to the rest of the ports on the endpoint, so that messages addressed to specific groups get lost.

# Questions

- Is this difference in behaviour between hardware and virtual endpoints intentional?
- What is the "correct" way to subscribe to all UMP events from an endpoint? Should I subscribe just to the `MIDI 2.0` endpoint, or to all ports on the endpoint, or something else?

Issue URL     : https://github.com/alsa-project/alsa-lib/issues/447
Repository URL: https://github.com/alsa-project/alsa-lib

           reply	other threads:[~2025-03-31 20:41 UTC|newest]

Thread overview: expand[flat|nested]  mbox.gz  Atom feed
 [parent not found: <1831fddaa087b800-webhooks-bot@alsa-project.org>]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1831fddaa08fb500-webhooks-bot@alsa-project.org \
    --to=github@alsa-project.org \
    --cc=alsa-devel@alsa-project.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.