- 12 Jun, 2023 2 commits
-
-
Takashi Iwai authored
This patch adds the basic support for UMP Endpoint and UMP Function Block parsing, which are extended in the new UMP v1.1 spec. The patch provides a new helper function to perform the query of the UMP Endpoint information and builds up the UMP blocks based on UMP Function Block information. For the communication over the UMP Endpoint, it opens the rawmidi device once internally, inquiries the UMP Endpoint and Function Block info by sending new UMP Stream messages, and waits for the response for each query. The new UMP spec allows to update the FB info and change its associated groups or its activeness on the fly, too. For catching it, the UMP core keeps watching the incoming UMP messages, and snd_ump_receive() handles the incoming UMP Stream messages to refresh the FB info. Link: https://lore.kernel.org/r/20230612081054.17200-3-tiwai@suse.deSigned-off-by:
Takashi Iwai <tiwai@suse.de>
-
Takashi Iwai authored
Add a few more fields to snd_ump_endpoint_info and snd_ump_block_info that are added in the new v1.1 spec. Those are filled by the UMP Stream messages. The rawmidi protocol version is bumped to 2.0.4 to indicate those updates. Also, update the proc outputs to show the newly introduced fields. Link: https://lore.kernel.org/r/20230612081054.17200-2-tiwai@suse.deSigned-off-by:
-
- 05 Jun, 2023 2 commits
-
-
Takashi Iwai authored
Currently the read event packet size in snd_seq_read() is defined by client->midi_version value that is guaranteed to be zero if UMP isn't enabled. But the static analyzer doesn't know of the fact, and it still suspects as if it were leading to a potential overflow. Add the more explicit check of CONFIG_SND_SEQ_UMP to determine the aligned_size value for avoiding the confusion. Fixes: 46397622 ("ALSA: seq: Add UMP support") Reported-by:
kernel test robot <lkp@intel.com> Reported-by:
Dan Carpenter <error27@gmail.com> Closes: https://lore.kernel.org/r/202305261415.NY0vapZK-lkp@intel.com/ Link: https://lore.kernel.org/r/20230605144758.6677-2-tiwai@suse.deSigned-off-by:
-
Takashi Iwai authored
Use proper notion for 16bit values for fixing the sparse warnings. Fixes: f8ddb0fb ("ALSA: usb-audio: Define USB MIDI 2.0 specs") Reported-by:
-
- 25 May, 2023 2 commits
-
-
Takashi Iwai authored
The MIDI 1.0 parser retrieved the 0xFx command with a wrong bit shift, resulting in the bogus type. Fix the bit shift size. Fixes: 0b5288f5 ("ALSA: ump: Add legacy raw MIDI support") Reported-by:
Dan Carpenter <dan.carpenter@linaro.org> Closes: https://lore.kernel.org/r/0fbc0b27-54b8-4cda-800e-37e7a03fed39@kili.mountainSuggested-by:
-
Takashi Iwai authored
The check of a note-on event with zero velocity is done twice, and the latter one is superfluous. Let's drop it. Fixes: 0b5288f5 ("ALSA: ump: Add legacy raw MIDI support") Reported-by:
-
- 24 May, 2023 1 commit
-
-
Stephen Rothwell authored
The #endif is placed obviously at a wrong position, which caused a build error on the big endian machine. Fixes: 0b5288f5 ("ALSA: ump: Add legacy raw MIDI support") Signed-off-by:
Stephen Rothwell <sfr@canb.auug.org.au> Link: https://lore.kernel.org/r/20230524135448.3ecad334@canb.auug.org.auSigned-off-by:
-
- 23 May, 2023 33 commits
-
-
Takashi Iwai authored
Add the brief document for describing the MIDI 2.0 implementation on Linux kernel. Both rawmidi and sequencer API extensions are described. Acked-by:
Jaroslav Kysela <perex@perex.cz> Link: https://lore.kernel.org/r/20230523075358.9672-38-tiwai@suse.deSigned-off-by:
-
Takashi Iwai authored
Add a new filter bitmap for UMP groups for reducing the unnecessary read/write when the client is connected to UMP EP seq port. The new group_filter field contains the bitmap for the groups, i.e. when the bit is set, the corresponding group is filtered out and the messages to that group won't be delivered. The filter bitmap consists of each bit of 1-based UMP Group number. The bit 0 is reserved for the future use. Reviewed-by:
-
Takashi Iwai authored
This patch enhances the /proc/asound/seq/clients output to show a few more information about the assigned UMP Endpoint and Blocks. The "Groups" are shown in 1-based group number to align with the sequencer client name and port number. Reviewed-by:
-
Takashi Iwai authored
Add new ioctls for sequencer clients to query and set the UMP endpoint and block information. As a sequencer client corresponds to a UMP Endpoint, one UMP Endpoint information can be assigned at most to a single sequencer client while multiple UMP block infos can be assigned by passing the type with the offset of block id (i.e. type = block_id + 1). For the kernel client, only SNDRV_SEQ_IOCTL_GET_CLIENT_UMP_INFO is allowed. Reviewed-by:
-
Takashi Iwai authored
Create a sequencer port for broadcasting the all group inputs at the port number 0. This corresponds to a UMP Endpoint connection; application can read all UMP events from this port no matter which group the UMP packet belongs to. Unlike seq ports for other UMP groups, a UMP Endpoint port has no SND_SEQ_PORT_TYPE_MIDI_GENERIC bit, so that it won't be treated as a normal MIDI 1.0 device from legacy applications. The port is named as "MIDI 2.0" to align with representations on other operation systems. Reviewed-by:
-
Takashi Iwai authored
This patch introduces a new ALSA sequencer client for the kernel UMP object, snd-seq-ump-client. It's a UMP version of snd-seq-midi driver, while this driver creates a sequencer client per UMP endpoint which contains (fixed) 16 ports. The UMP rawmidi device is opened in APPEND mode for output, so that multiple sequencer clients can share the same UMP endpoint, as well as the legacy UMP rawmidi devices that are opened in APPEND mode, too. For input, on the other hand, the incoming data is processed on the fly in the dedicated hook, hence it doesn't open a rawmidi device. The UMP packet group is updated upon delivery depending on the target sequencer port (which corresponds to the actual UMP group). Each sequencer port sets a new port type bit, SNDRV_SEQ_PORT_TYPE_MIDI_UMP, in addition to the other standard types for MIDI. Reviewed-by:
-
Takashi Iwai authored
A sequencer client like seq_dummy rather doesn't want to convert UMP events but receives / sends as is. Add a new event filter flag to suppress the automatic UMP conversion and applies accordingly. Reviewed-by:
-
Takashi Iwai authored
This patch enables the automatic conversion of UMP events from/to the legacy ALSA sequencer MIDI events. Also, as UMP itself has two different modes (MIDI 1.0 and MIDI 2.0), yet another converters between them are needed, too. Namely, we have conversions between the legacy and UMP like: - seq legacy event -> seq UMP MIDI 1.0 event - seq legacy event -> seq UMP MIDI 2.0 event - seq UMP MIDI 1.0 event -> seq legacy event - seq UMP MIDI 2.0 event -> seq legacy event and the conversions between UMP MIDI 1.0 and 2.0 clients like: - seq UMP MIDI 1.0 event -> seq UMP MIDI 2.0 event - seq UMP MIDI 2.0 event -> seq UMP MIDI 1.0 event The translation is per best-effort; some MIDI 2.0 specific events are ignored when translated to MIDI 1.0. Reviewed-by:
-
Takashi Iwai authored
Add yet more new filed "ump_group" to snd_seq_port_info for specifying the associated UMP Group number for each sequencer port. This will be referred in the upcoming automatic UMP conversion in sequencer core. Reviewed-by:
-
Takashi Iwai authored
Add a new field "direction" to snd_seq_port_info for allowing a client to tell the expected direction of the port access. A port might still allow subscriptions for read/write (e.g. for MIDI-CI) even if the primary usage of the port is a single direction (either input or output only). This new "direction" field can help to indicate such cases. When the direction is unspecified at creating a port and the port has either read or write capability, the corresponding direction bits are set automatically as default. Reviewed-by:
-
Takashi Iwai authored
This is an extension to ALSA sequencer infrastructure to support the MIDI 2.0 UMP Endpoint port. It's a "catch-all" port that is supposed to be present for each UMP Endpoint. When this port is read via subscription, it sends any events from all ports (UMP Groups) found in the same client. A UMP Endpoint port can be created with the new capability bit SNDRV_SEQ_PORT_CAP_UMP_ENDPOINT. Although the port assignment isn't strictly defined, it should be the port number 0. Reviewed-by:
-
Takashi Iwai authored
This extends the ALSA sequencer port capability bit to indicate the "inactive" flag. When this flag is set, the port is essentially invisible, and doesn't appear in the port query ioctls, while the direct access and the connection to this port are still allowed. The active/inactive state can be flipped dynamically, so that it can be visible at any time later. This feature is introduced basically for UMP; some UMP Groups in a UMP Block may be unassigned, hence those are practically invisible. On ALSA sequencer, the corresponding sequencer ports will get this new "inactive" flag to indicate the invisible state. Reviewed-by:
-
Takashi Iwai authored
Starting from this commit, we add the basic support of UMP (Universal MIDI Packet) events on ALSA sequencer infrastructure. The biggest change here is that, for transferring UMP packets that are up to 128 bits, we extend the data payload of ALSA sequencer event record when the client is declared to support for the new UMP events. A new event flag bit, SNDRV_SEQ_EVENT_UMP, is defined and it shall be set for the UMP packet events that have the larger payload of 128 bits, defined as struct snd_seq_ump_event. For controlling the UMP feature enablement in kernel, a new Kconfig, CONFIG_SND_SEQ_UMP is introduced. The extended event for UMP is available only when this Kconfig item is set. Similarly, the size of the internal snd_seq_event_cell also increases (in 4 bytes) when the Kconfig item is set. (But the size increase is effective only for 32bit architectures; 64bit archs already have padding there.) Overall, when CONFIG_SND_SEQ_UMP isn't set, there is no change in the event and cell, keeping the old sizes. For applications that want to access the UMP packets, first of all, a sequencer client has to declare the user-protocol to match with the latest one via the new SNDRV_SEQ_IOCTL_USER_PVERSION; otherwise it's treated as if a legacy client without UMP support. Then the client can switch to the new UMP mode (MIDI 1.0 or MIDI 2.0) with a new field, midi_version, in snd_seq_client_info. When switched to UMP mode (midi_version = 1 or 2), the client can write the UMP events with SNDRV_SEQ_EVENT_UMP flag. For reads, the alignment size is changed from snd_seq_event (28 bytes) to snd_seq_ump_event (32 bytes). When a UMP sequencer event is delivered to a legacy sequencer client, it's ignored or handled as an error. Conceptually, ALSA sequencer client and port correspond to the UMP Endpoint and Group, respectively; each client may have multiple ports and each port has the fixed number (16) of channels, total up to 256 channels. As of this commit, ALSA sequencer core just sends and receives the UMP events as-is from/to clients. The automatic conversions between the legacy events and the new UMP events will be implemented in a later patch. Along with this commit, bump the sequencer protocol version to 1.0.3. Reviewed-by:
-
Takashi Iwai authored
For the future extension of ALSA sequencer ABI, introduce a new ioctl SNDRV_SEQ_IOCTL_USER_PVERSION. This is similar like the ioctls used in PCM and other interfaces, for an application to specify its supporting ABI version. The use of this ioctl will be mandatory for the upcoming UMP support. Reviewed-by:
-
Takashi Iwai authored
Some port numbers are special, such as 254 for subscribers and 255 for broadcast. Return error if application tries to create such a port. Reviewed-by:
-
Takashi Iwai authored
The client type and the port info validity check should be done before actually creating a port, instead of unnecessary create-and-scratch. Reviewed-by:
-
Takashi Iwai authored
We didn't check if a port with the given port number has been already present at creating a new port. Check it and return -EBUSY properly if the port number conflicts. Reviewed-by:
-
Takashi Iwai authored
The broadcast and multicast supports have been never enabled. Let's drop the dead code. Reviewed-by:
-
Takashi Iwai authored
Introduce the new helpers, snd_seq_kernel_client_get() and _put() for kernel client drivers to treat the snd_seq_client more directly. This allows us to reduce the exported symbols and APIs at each time we need to access some field in future. Reviewed-by:
-
Takashi Iwai authored
Create a new variant of snd_seq_expand_var_event() for expanding the data starting from the given byte offset. It'll be used by the new UMP sequencer code later. Reviewed-by:
-
Takashi Iwai authored
There can be a small memory hole that may not be cleared at expanding an event with the variable length type. Make sure to clear it. Reviewed-by:
-
Takashi Iwai authored
When parsing Group Terminal Blocks, we overwrote the preferred protocol and the protocol capabilities silently from the last parsed GTB. This patch adds the information print indicating the unexpected overrides instead of silent action. Reviewed-by:
-
Takashi Iwai authored
Attach the legacy rawmidi devices when enabled in Kconfig accordingly. Reviewed-by:
-
Takashi Iwai authored
This patch extends the UMP core code to support the legacy MIDI 1.0 rawmidi devices. When the new kconfig CONFIG_SND_UMP_LEGACY_RAWMIDI is set, the UMP core allows to attach an additional rawmidi device for each UMP Endpoint. The rawmidi device contains 16 substreams where each substream corresponds to a UMP Group belonging to the EP. The device reads/writes the legacy MIDI 1.0 byte streams and translates from/to UMP packets. The legacy rawmidi devices are exclusive with the UMP rawmidi devices, hence both of them can't be opened at the same time unless the UMP rawmidi is opened in APPEND mode. Reviewed-by:
-
Takashi Iwai authored
This is a code refactoring for abstracting the rawmidi access to the UMP's own helpers. It's a preliminary work for the later code refactoring of the UMP layer. Until now, we access to the rawmidi substream directly from the driver via rawmidi access helpers, but after this change, the driver is supposed to access via the newly introduced snd_ump_ops and receive/transmit via snd_ump_receive() and snd_ump_transmit() helpers. As of this commit, those are merely wrappers for the rawmidi substream, and no much function change is seen here. Reviewed-by:
-
Takashi Iwai authored
USB MIDI spec defines the Group Terminal Blocks (GTB) that associate multiple UMP Groups. Those correspond to snd_ump_block entities in ALSA UMP abstraction, and now we create those UMP Block objects for each UMP Endpoint from the parsed GTB information. Reviewed-by:
-
Takashi Iwai authored
A single USB audio device may have multiple interfaces for different purposes (e.g. audio, MIDI and HID), where the iInterface descriptor of each interface may contain an own suffix, e.g. "MIDI" for a MIDI interface. as such a suffix is superfluous as a rawmidi and UMP Endpoint name, this patch trims the superfluous "MIDI" suffix from the name string. Reviewed-by:
-
Takashi Iwai authored
USB descriptor may provide a nicer name for USB interface, and we may take it as the UMP Endpoint name. The UMP EP name is copied as the rawmidi name, too. Also, fill the UMP block product_id field from the iSerialNumber string of the USB device descriptor as a recommended unique id, too. Reviewed-by:
-
Takashi Iwai authored
This patch provides a basic support for USB MIDI 2.0. As of this patch, the driver creates a UMP device per MIDI I/O endpoints, which serves as a dumb terminal to read/write UMP streams. A new Kconfig CONFIG_SND_USB_AUDIO_MIDI_V2 manages whether to enable or disable the MIDI 2.0 support. Also, the driver provides a new module option, midi2_enable, to allow disabling the MIDI 2.0 at runtime, too. When MIDI 2.0 support is disabled, the driver tries to fall back to the already existing MIDI 1.0 device (each MIDI 2.0 device is supposed to provide the MIDI 1.0 interface at the altset 0). For now, the driver doesn't manage any MIDI-CI or other protocol setups by itself, but relies on the default protocol given via the group terminal block descriptors. The MIDI 1.0 messages on MIDI 2.0 device will be automatically converted in ALSA sequencer in a later patch. As of this commit, the driver accepts merely the rawmidi UMP accesses. The driver builds up the topology in the following way: - Create an object for each MIDI endpoint belonging to the USB interface - Find MIDI EP "pairs" that share the same GTB; note that MIDI EP is unidirectional, while UMP is (normally) bidirectional, so two MIDI EPs can form a single UMP EP - A UMP endpoint object is created for each I/O pair - For remaining "solo" MIDI EPs, create unidirectional UMP EPs - Finally, parse GTBs and fill the protocol bits on each UMP So the driver may support multiple UMP Endpoints in theory, although most devices are supposed to have a single UMP EP that can contain up to 16 groups -- which should be large enough. Reviewed-by:
-
Takashi Iwai authored
Define new structs and constants from USB MIDI 2.0 specification, to be used in the upcoming MIDI 2.0 support in USB-audio driver. A new class-specific endpoint descriptor and group terminal block descriptors are defined. Acked-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Acked-by:
-
Takashi Iwai authored
We're going to create rawmidi objects for MIDI 2.0 in a different code from the current code for USB-MIDI 1.0. As a preliminary work, this patch adds the number of rawmidi objects to keep globally in a USB-audio card instance, so that it can be referred from both MIDI 1.0 and 2.0 code. Reviewed-by:
-
Takashi Iwai authored
UMP devices may have more interesting information than the traditional rawmidi. Extend the rawmidi_global_ops to allow the optional proc info output and show some more bits in the proc file for UMP. Note that the "Groups" field shows the first and the last UMP Groups, and both numbers are 1-based (i.e. the first group is 1). Reviewed-by:
-
Takashi Iwai authored
It'd be convenient to have ioctls to inquiry the UMP Endpoint and UMP Block information directly via the control API without opening the rawmidi interface, just like SNDRV_CTL_IOCTL_RAWMIDI_INFO. This patch extends the rawmidi ioctl handler to support those; new ioctls, SNDRV_CTL_IOCTL_UMP_ENDPOINT_INFO and SNDRV_CTL_IOCTL_UMP_BLOCK_INFO, return the snd_ump_endpoint and snd_ump_block data that is specified by the device field, respectively. Suggested-by:
-
