kernel/include/uapi/sound/asound.h, branch linux-6.14.y

ALSA: rawmidi: Make tied_device=0 as default / unknown

2025-01-14T15:52:07Z

In the original change, rawmidi_info.tied_device showed -1 for the unknown or untied device. But this would require the user-space to check the protocol version and judge the value conditionally, which is rather error-prone. Instead, set the tied_device = 0 to be default as unknown, and indicate the real device with the offset 1, for achieving more backward compatibility. Suggested-by: Jaroslav Kysela Link: https://patch.msgid.link/20250114104711.19197-1-tiwai@suse.de Signed-off-by: Takashi Iwai

ALSA: rawmidi: Bump protocol version to 2.0.5

2025-01-12T12:12:20Z

Bump the protocol version to 2.0.5, as we extended the rawmidi ABI for the new tied_device info and the substream inactive flag. Signed-off-by: Takashi Iwai Link: https://patch.msgid.link/20250110155943.31578-4-tiwai@suse.de

ALSA: rawmidi: Show substream activity in info ioctl

2025-01-12T12:12:20Z

The UMP legacy rawmidi may turn on/off the substream dynamically depending on the UMP Function Block information. So far, there was no direct way to know whether the substream is disabled (inactive) or not; at most one can take a look at the substream name string or try to open and get -ENODEV. This patch extends the rawmidi info ioctl to show the current inactive state of the given substream. When the selected substream is inactive, info flags field contains the new bit flag SNDRV_RAWMIDI_INFO_STREAM_INACTIVE. Signed-off-by: Takashi Iwai Link: https://patch.msgid.link/20250110155943.31578-3-tiwai@suse.de

ALSA: rawmidi: Expose the tied device number in info ioctl

2025-01-12T12:12:20Z

The UMP legacy rawmidi is derived from the UMP rawmidi, but currently there is no way to know which device is involved in other side. This patch extends the rawmidi info ioctl to show the tied device number. As default it stores -1, indicating that no tied device. Signed-off-by: Takashi Iwai Link: https://patch.msgid.link/20250110155943.31578-2-tiwai@suse.de

ALSA: timer: Introduce virtual userspace-driven timers

2024-08-18T07:55:54Z

Implement two ioctl calls in order to support virtual userspace-driven ALSA timers. The first ioctl is SNDRV_TIMER_IOCTL_CREATE, which gets the snd_timer_uinfo struct as a parameter and puts a file descriptor of a virtual timer into the `fd` field of the snd_timer_unfo structure. It also updates the `id` field of the snd_timer_uinfo struct, which provides a unique identifier for the timer (basically, the subdevice number which can be used when creating timer instances). This patch also introduces a tiny id allocator for the userspace-driven timers, which guarantees that we don't have more than 128 of them in the system. Another ioctl is SNDRV_TIMER_IOCTL_TRIGGER, which allows us to trigger the virtual timer (and calls snd_timer_interrupt for the timer under the hood), causing all of the timer instances binded to this timer to execute their callbacks. The maximum amount of ticks available for the timer is 1 for the sake of simplicity of the userspace API. 'start', 'stop', 'open' and 'close' callbacks for the userspace-driven timers are empty since we don't really do any hardware initialization here. Suggested-by: Axel Holzinger Signed-off-by: Ivan Orlov Signed-off-by: Takashi Iwai Link: https://patch.msgid.link/20240813120701.171743-4-ivan.orlov0322@gmail.com

ALSA: pcm: reinvent the stream synchronization ID API

2024-07-02T07:53:21Z

Until the commit e11f0f90a626 ("ALSA: pcm: remove SNDRV_PCM_IOCTL1_INFO internal command"), there was a possibility to pass information about the synchronized streams to the user space. The mentioned commit removed blindly the appropriate code with an irrelevant comment. The revert may be appropriate, but since this API was lost for several years without any complains, it's time to improve it. The hardware parameters may change the used stream clock source (e.g. USB hardware) so move this synchronization ID to hw_params as read-only field. It seems that pipewire can benefit from this API (disable adaptive resampling for perfectly synchronized PCM streams) now. Note that the contents of ID is not supposed to be used for direct comparison with a specific byte sequence. The "empty" case is when all bytes are zero (driver does not offer this information) and all other cases must be only used for equal comparison among PCM streams (including different sound cards) if they are using identical hardware clock. Cc: Takashi Sakamoto Signed-off-by: Jaroslav Kysela Signed-off-by: Takashi Iwai Link: https://patch.msgid.link/20240625172836.589380-2-perex@perex.cz

ALSA: pcm: clarify and fix default msbits value for all formats

2024-02-23T08:44:46Z

Return used most significant bits from sample bit-width rather than the whole physical sample word size. The starting bit offset is defined in the format itself. The behaviour is not changed for 32-bit formats like S32_LE. But with this change - msbits value 24 instead 32 is returned for 24-bit formats like S24_LE etc. Also, commit 2112aa034907 ("ALSA: pcm: Introduce MSBITS subformat interface") compares sample bit-width not physical sample bit-width to reset MSBITS_MAX bit from the subformat bitmask. Probably no applications are using msbits value for other than S32_LE/U32_LE formats, because no drivers are reducing msbits value for other formats (with the msb offset) at the moment. For sanity, increase PCM protocol version, letting the user space to detect the changed behaviour. Signed-off-by: Jaroslav Kysela Link: https://lore.kernel.org/r/20240222173649.1447549-1-perex@perex.cz Signed-off-by: Takashi Iwai

ALSA: pcm: Introduce MSBITS subformat interface

2023-11-27T16:24:26Z

Improve granularity of format selection for S32/U32 formats by adding constants representing 20, 24 and MAX most significant bits. The MAX means the maximum number of significant bits which can the physical format hold. For 32-bit formats, MAX is related to 32 bits. For 8-bit formats, MAX is related to 8 bits etc. As there is only one user currently (format S32_LE), subformat is represented by a simple u32 and stores flags only for that one user alone. The approach of subformat being part of struct snd_pcm_hardware is a compromise between ALSA and ASoC allowing for hw_params-intersection code to be alloc/free-less while not adding any new responsibilities to ASoC runtime structures. Acked-by: Mark Brown Signed-off-by: Jaroslav Kysela Co-developed-by: Cezary Rojewski Signed-off-by: Cezary Rojewski Link: https://lore.kernel.org/r/20231117120610.1755254-2-cezary.rojewski@intel.com Signed-off-by: Takashi Iwai

Merge branch 'topic/midi20' into for-next

2023-06-13T05:37:59Z

As the updated MIDI 2.0 spec has been published freshly, this is a catch up to add the support for new specs, especially UMP v1.1 features, on Linux kernel. The new UMP v1.1 introduced the concept of Function Blocks (FB), which is a kind of superset of USB MIDI 2.0 Group Terminal Blocks (GTB). The patch set adds the support for FB as the primary information source while keeping the parse of GTB as fallback. Also UMP v1.1 supports the groupless messages, the protocol switch, static FBs, and other new fundamental features, and those are supported as well. Link: https://www.midi.org/midi-articles/details-about-midi-2-0-midi-ci-profiles-and-property-exchange Link: https://lore.kernel.org/r/20230612081054.17200-1-tiwai@suse.de Signed-off-by: Takashi Iwai

ALSA: ump: Add info flag bit for static blocks

2023-06-12T16:22:34Z

UMP v1.1 spec allows to inform whether the function blocks are static and not dynamically updated. Add a new flag bit to snd_ump_endpoint_info to reflect that attribute, too. The flag is set when a USB MIDI device is still in the old MIDI 2.0 without UMP 1.1 support. Then the driver falls back to GTBs, and they are supposed to be static-only. Link: https://lore.kernel.org/r/20230612081054.17200-10-tiwai@suse.de Signed-off-by: Takashi Iwai