linux.git/Documentation/sound, branch v6.5

ALSA: compress: allow setting codec params after next track

2023-06-21T05:28:31+00:00

For gapless playback it is possible that each track can have different
codec profile with same decoder, for example we have WMA album,
we may have different tracks as WMA v9, WMA v10 and so on

Or if DSP's like QDSP have abililty to switch decoders on single stream
for each track, then this call could be used to set new codec parameters.

Existing code does not allow to change this profile while doing gapless
playback.

Reuse existing SNDRV_COMPRESS_SET_PARAMS to set this new track params along
some additional checks to enforce proper state machine.

With this new changes now the user can call SNDRV_COMPRESS_SET_PARAMS
anytime after setting next track and additional check in write should
also ensure that params are set before writing new data.

Signed-off-by: Srinivas Kandagatla 
Acked-by: Vinod Koul 
Link: https://lore.kernel.org/r/20230619092805.21649-1-srinivas.kandagatla@linaro.org
Signed-off-by: Takashi Iwai

Merge branch 'topic/midi20' into for-next

2023-06-13T05:37:59+00:00

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: docs: Update MIDI 2.0 documentation for UMP 1.1 enhancement

2023-06-12T16:22:35+00:00

There have been a few enhancements for the new UMP 1.1 features.
Update the documentation accordingly.

Link: https://lore.kernel.org/r/20230612081054.17200-11-tiwai@suse.de
Signed-off-by: Takashi Iwai

docs: sound: add 'pcmtest' driver documentation

2023-06-07T11:08:35+00:00

Add documentation for the new Virtual PCM Test Driver. It covers all
possible usage cases: errors and delay injections, random and
pattern-based data generation, playback and ioctl redefinition
functionalities testing.

We have a lot of different virtual media drivers, which can be used for
testing of the userspace applications and media subsystem middle layer.
However, all of them are aimed at testing the video functionality and
simulating the video devices. For audio devices we have only snd-dummy
module, which is good in simulating the correct behavior of an ALSA device.
I decided to write a tool, which would help to test the userspace ALSA
programs (and the PCM middle layer as well) under unusual circumstances
to figure out how they would behave. So I came up with this Virtual PCM
Test Driver.

This new Virtual PCM Test Driver has several features which can be useful
during the userspace ALSA applications testing/fuzzing, or testing/fuzzing
of the PCM middle layer. Not all of them can be implemented using the
existing virtual drivers (like dummy or loopback). Here is what can this
driver do:

- Simulate both capture and playback processes
- Check the playback stream for containing the looped pattern
- Generate random or pattern-based capture data
- Inject delays into the playback and capturing processes
- Inject errors during the PCM callbacks

Also, this driver can check the playback stream for containing the
predefined pattern, which is used in the corresponding selftest to check
the PCM middle layer data transferring functionality. Additionally, this
driver redefines the default RESET ioctl, and the selftest covers this PCM
API functionality as well.

The driver supports both interleaved and non-interleaved access modes, and
have separate pattern buffers for each channel. The driver supports up to
4 channels and up to 8 substreams.

Signed-off-by: Ivan Orlov 
Acked-by: Jaroslav Kysela 
Link: https://lore.kernel.org/r/20230606193254.20791-1-ivan.orlov0322@gmail.com
Signed-off-by: Takashi Iwai

Merge branch 'topic/midi20' into for-next

2023-05-23T12:14:47+00:00

This is a (largish) patch set for adding the support of MIDI 2.0
functionality, mainly targeted for USB devices.  MIDI 2.0 is a
complete overhaul of the 40-years old MIDI 1.0.  Unlike MIDI 1.0 byte
stream, MIDI 2.0 uses packets in 32bit words for Universal MIDI Packet
(UMP) protocol.  It supports both MIDI 1.0 commands for compatibility
and the extended MIDI 2.0 commands for higher resolutions and more
functions.

For supporting the UMP, the patch set extends the existing ALSA
rawmidi and sequencer interfaces, and adds the USB MIDI 2.0 support to
the standard USB-audio driver.

The rawmidi for UMP has a different device name (/dev/snd/umpC*D*) and
it reads/writes UMP packet data in 32bit CPU-native endianness.  For
the old MIDI 1.0 applications, the legacy rawmidi interface is
provided, too.

As default, USB-audio driver will take the alternate setting for MIDI
2.0 interface, and the compatibility with MIDI 1.0 is provided via the
rawmidi common layer.  However, user may let the driver falling back
to the old MIDI 1.0 interface by a module option, too.

A UMP-capable rawmidi device can create the corresponding ALSA
sequencer client(s) to support the UMP Endpoint and UMP Group
connections.  As a nature of ALSA sequencer, arbitrary connections
between clients/ports are allowed, and the ALSA sequencer core
performs the automatic conversions for the connections between a new
UMP sequencer client and a legacy MIDI 1.0 sequencer client.  It
allows the existing application to use MIDI 2.0 devices without
changes.

The MIDI-CI, which is another major extension in MIDI 2.0, isn't
covered by this patch set.  It would be implemented rather in
user-space.

Roughly speaking, the first half of this patch set is for extending
the rawmidi and USB-audio, and the second half is for extending the
ALSA sequencer interface.

The patch set is based on 6.4-rc2 kernel, but all patches can be
cleanly applicable on 6.2 and 6.3 kernels, too (while 6.1 and older
kernels would need minor adjustment for uapi header changes).

The updates for alsa-lib and alsa-utils will follow shortly later.

The author thanks members of MIDI Association OS/API Working Group,
especially Andrew Mee, for great helps for the initial design and
debugging / testing the drivers.

Link: https://lore.kernel.org/r/20230523075358.9672-1-tiwai@suse.de
Signed-off-by: Takashi Iwai

ALSA: docs: Add MIDI 2.0 documentation

2023-05-23T10:11:40+00:00

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 
Link: https://lore.kernel.org/r/20230523075358.9672-38-tiwai@suse.de
Signed-off-by: Takashi Iwai

ALSA: emu10k1: straighten out FX send init

2023-05-17T15:04:31+00:00

The mixer structures were filled in two places: on driver init, and when
the devices are opened. The latter made the former pointless, so we
remove the former. This implies that mixer dumps may now return all
zeroes, which is OK, as restoring them is meaningless as well.

Things were even weirder for the (generally unused) secondary sends:

Some of the initialization loops were forgotten when support for Audigy
was added, thus creating the technically illegal state of multiple sends
being routed to the same FX accumulator (though it apparently doesn't
matter when the amount is zero).

The global multi-channel init used some rather bizarre values for the
secondary sends, and the init on open actually forgot to re-initialize
them. We now use a not really more useful, but simpler formula.

The direct register init was also bogus. This doesn't really matter, as
the value is overwritten when a voice comes into use, but still.

Signed-off-by: Oswald Buddenhagen 
Link: https://lore.kernel.org/r/20230516093612.3536451-2-oswald.buddenhagen@gmx.de
Signed-off-by: Takashi Iwai

ALSA: emu10k1: enable bit-exact playback, part 2: voice attenuation

2023-05-16T09:11:04+00:00

The voice volume is a raw fractional multiplier that can't actually
represent 1.0. To still enable real pass-through, we now set the volume
to 0.5 (which results in no loss of precision, as the FX bus provides
fractional values) and scale up the samples in DSP code.

To maintain backwards compatibility with existing configuration files,
we rescale the values in the mixer controls. The range is extended
upwards from 0xffff to 0x1fffd, which actually introduces the
possibility of specifying an amplification.

There is still a minor incompatibility with user space, namely if
someone loaded custom DSP code. They'll just get half the volume, so
this doesn't seem like a big deal.

Signed-off-by: Oswald Buddenhagen 
Link: https://lore.kernel.org/r/20230514170323.3408834-8-oswald.buddenhagen@gmx.de
Signed-off-by: Takashi Iwai

ALSA: docs: Fix code block indentation in ALSA driver example

2023-05-03T06:08:25+00:00

Sphinx reports htmldocs warnings:

Documentation/sound/kernel-api/writing-an-alsa-driver.rst:3997: WARNING: Literal block expected; none found.
Documentation/sound/kernel-api/writing-an-alsa-driver.rst:4004: WARNING: Literal block expected; none found.
Documentation/sound/kernel-api/writing-an-alsa-driver.rst:4009: WARNING: Unexpected indentation.
Documentation/sound/kernel-api/writing-an-alsa-driver.rst:4035: WARNING: Literal block expected; none found.

These are due to indentation of example driver snippets which is outside
the code block scope.

Fix these by indenting code blocks in question to the scope.

Fixes: 4d421eebe1465d ("ALSA: docs: writing-an-alsa-driver.rst: polishing")
Reported-by: kernel test robot 
Closes: https://lore.kernel.org/linux-doc/202305021822.4U6XOvGf-lkp@intel.com/
Signed-off-by: Bagas Sanjaya 
Link: https://lore.kernel.org/r/20230503035416.62722-1-bagasdotme@gmail.com
Signed-off-by: Takashi Iwai

ALSA: docs: Extend module parameters description

2023-05-03T06:06:37+00:00

Common ALSA module parameters look a little bit confusing because of the
description lacking, and it took me a while to understand the purpose of
their existence. To figure it out I asked the question about them to the
"alsa-devel" mailing list, and Takashi Iwai answered me with the text I
appended to the ALSA documentation in this patch.

These common module parameters aren't used a lot nowadays, but as I
understand they are important for providing compatibility with some
existing user-space apps. So in my opinion it is a good idea to document
why we need them.

Signed-off-by: Ivan Orlov 
Link: https://lore.kernel.org/r/20230501101634.476297-1-ivan.orlov0322@gmail.com
Signed-off-by: Takashi Iwai