linux.git/include/uapi/sound, branch v6.12.80

ALSA: uapi: Fix typo in asound.h comment

2025-12-18T12:55:20+00:00

[ Upstream commit 9a97857db0c5655b8932f86b5d18bb959079b0ee ]

Fix 'level-shit' to 'level-shift' in struct snd_cea_861_aud_if comment.

Fixes: 7ba1c40b536e ("ALSA: Add definitions for CEA-861 Audio InfoFrames")
Signed-off-by: Andres J Rosa 
Link: https://patch.msgid.link/20251203162509.1822-1-andyrosa@gmail.com
Signed-off-by: Takashi Iwai 
Signed-off-by: Sasha Levin

ASoC: topology: Bump minimal topology ABI version

2024-10-10T11:15:03+00:00

When v4 topology support was removed, minimal topology ABI version
should have been bumped.

Fixes: fe4a07454256 ("ASoC: Drop soc-topology ABI v4 support")
Reviewed-by: Cezary Rojewski 
Signed-off-by: Amadeusz Sławiński 
Link: https://patch.msgid.link/20241009081230.304918-1-amadeuszx.slawinski@linux.intel.com
Signed-off-by: Mark Brown

Merge branch 'for-linus' into for-next

2024-09-10T08:28:00+00:00

Signed-off-by: Takashi Iwai

ASoC: SOF: ipc: replace "enum sof_comp_type" field with "uint32_t"

2024-08-26T18:29:39+00:00

Normally, the type of enums is "unsigned int" or "int". GCC has
the "-fshort-enums" option, which instructs the compiler to
use the smallest data type that can hold all the values in
the enum (i.e: char, short, int or their unsigned variants).

According to the GCC documentation, "-fshort-enums" may be
default on some targets. This seems to be the case for SOF
when built for a certain 32-bit ARM platform.

On Linux, this is not the case (tested with "aarch64-linux-gnu-gcc")
which means enums such as "enum sof_comp_type" will end up having
different sizes on Linux and SOF. Since "enum sof_comp_type" is used in
IPC-related structures such as "struct sof_ipc_comp", this means
the fields of the structures will end up being placed at different
offsets. This, in turn, leads to SOF not being able to properly
interpret data passed from Linux.

With this in mind, replace "enum sof_comp_type" from
"struct sof_ipc_comp" with "uint32_t".

Signed-off-by: Laurentiu Mihalcea 
Reviewed-by: Pierre-Louis Bossart 
Reviewed-by: Bard Liao 
Reviewed-by: Daniel Baluta 
Link: https://patch.msgid.link/20240826182442.6191-1-laurentiumihalcea111@gmail.com
Signed-off-by: Mark Brown

ALSA: timer: Introduce virtual userspace-driven timers

2024-08-18T07:55:54+00:00

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: ump: Handle MIDI 1.0 Function Block in MIDI 2.0 protocol

2024-08-06T07:01:23+00:00

The UMP v1.1 spec says in the section 6.2.1:
"If a UMP Endpoint declares MIDI 2.0 Protocol but a Function Block
represents a MIDI 1.0 connection, then may optionally be used for
messages to/from that Function Block."

It implies that the driver can (and should) keep MIDI 1.0 CVM
exceptionally for those FBs even if UMP Endpoint is running in MIDI
2.0 protocol, and the current driver lacks of it.

This patch extends the sequencer port info to indicate a MIDI 1.0
port, and tries to send/receive MIDI 1.0 CVM as is when this port is
the source or sink.  The sequencer port flag is set by the driver at
parsing FBs and GTBs although application can set it to its own
user-space clients, too.

Link: https://patch.msgid.link/20240806070024.14301-1-tiwai@suse.de
Signed-off-by: Takashi Iwai

ALSA: seq: Add tempo base unit for MIDI2 Set Tempo messages

2024-07-06T07:38:27+00:00

MIDI2 Set Tempo message defines the tempo in 10ns unit for finer
accuracy, while MIDI1 was defined in 1us unit.  For adapting this
different unit, introduce "tempo_base" field to snd_seq_queue_tempo
struct so that user-space can pass the proper tempo base unit.

The accepted value is limited, it must be either 0, 10 or 1000.

The protocol version is bumped to 1.0.4 along with this.

The access with the older protocol version ignores the tempo-base
value in ioctls and always treats as 1000.

Reviewed-by: Jaroslav Kysela 
Link: https://patch.msgid.link/20240705160344.6481-1-tiwai@suse.de
Signed-off-by: Takashi Iwai

ALSA: pcm: reinvent the stream synchronization ID API

2024-07-02T07:53:21+00:00

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

Merge tag 'asoc-v6.10' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus

2024-05-13T09:39:49+00:00

ASoC: Updates for v6.10

This is a very big update, in large part due to extensive work the Intel
people have been doing in their drivers though it's also been busy
elsewhere.  There's also a big overhaul of the DAPM documentation from
Luca Ceresoli arising from the work he did putting together his recent
ELC talk, and he also contributed a new tool for visualising the DAPM
state.

 - A new tool dapm-graph for visualising the DAPM state.
 - Substantial fixes and clarifications for the DAPM documentation.
 - Very large updates throughout the Intel audio drivers.
 - Cleanups of accessors for driver data, module labelling, and for
   constification.
 - Modernsation and cleanup work in the Mediatek drivers.
 - Several fixes and features for the DaVinci I2S driver.
 - New drivers for several AMD and Intel platforms, Nuvoton NAU8325,
   Rockchip RK3308 and Texas Instruments PCM6240.

ALSA/ASoC: include: clarify Copyright information

2024-05-09T18:26:34+00:00

For some reason a number of files included the "All rights reserved"
statement. Good old copy-paste made sure this mistake proliferated.

Remove the "All rights reserved" in all Intel-copyright to align with
internal guidance.

Reviewed-by: Cezary Rojewski 
Signed-off-by: Pierre-Louis Bossart 
Reviewed-by: Bard Liao 
Reviewed-by: Péter Ujfalusi 
Link: https://lore.kernel.org/r/20240503140359.259762-10-pierre-louis.bossart@linux.intel.com
Signed-off-by: Takashi Iwai