May 2023 - Alsa-devel - mailman.alsa-project.org

topology: pre-processor: Add support for object arrays
by GitHub pull_request - edited 24 May '23

24 May '23

alsa-project/alsa-utils pull request #216 was edited from ranj063: Introduce a new keyword, "Objects" to instantiate multiple objects of the same class with different attirbutes. For example ``` Objects.Base.input_audio_format [ { in_rate [ 8000 16000 48000 ] in_bit_depth [ 32 ] in_valid_bit_depth [ 24 32 ] } ] ``` This would be expanded into 6 objects with the rate, bit_depth and valid_bit_depth combinations of the arrays of values above. ``` Object.Base.input_audio_format [ { in_rate 8000 in_bit_depth 32 in_valid_bit_depth 32 } { in_rate 16000 in_bit_depth 32 in_valid_bit_depth 32 } { in_rate 48000 in_bit_depth 32 in_valid_bit_depth 32 } { in_rate 8000 in_bit_depth 32 in_valid_bit_depth 24 } { in_rate 16000 in_bit_depth 32 in_valid_bit_depth 24 } { in_rate 48000 in_bit_depth 32 in_valid_bit_depth 24 } ] ``` The Objects definition is an array so that multiple combinations can be specified so that we deal with only valid combinations. For example, 16-bit bit_depth is only valid with 16-bit valid_bit_depth. So if we also want to add those combinations with the multiple rates, the definition would look like: ``` Objects.Base.input_audio_format [ { in_rate [ 8000 16000 48000 ] in_bit_depth [ 32 ] in_valid_bit_depth [ 24 32 ] } { in_rate [ 8000 16000 48000 ] in_bit_depth [ 16 ] in_valid_bit_depth [ 16 ] } ] ``` Request URL : https://github.com/alsa-project/alsa-utils/pull/216 Patch URL : https://github.com/alsa-project/alsa-utils/pull/216.patch Repository URL: https://github.com/alsa-project/alsa-utils

1 0

[PATCH v2 1/3] docs: sound: add 'pcmtest' driver documentation
by Ivan Orlov 24 May '23

24 May '23

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. Signed-off-by: Ivan Orlov <ivan.orlov0322(a)gmail.com> --- V1 -> V2: - Rename the driver from from 'valsa' to 'pcmtest'. - Implement support for interleaved and non-interleaved access modes - Add support for 8 substreams and 4 channels - Extend supported formats - Extend and rewrite in C the selftest for the driver Documentation/sound/cards/index.rst | 1 + Documentation/sound/cards/pcmtest.rst | 119 ++++++++++++++++++++++++++ 2 files changed, 120 insertions(+) create mode 100644 Documentation/sound/cards/pcmtest.rst diff --git a/Documentation/sound/cards/index.rst b/Documentation/sound/cards/index.rst index c016f8c3b88b..49c1f2f688f8 100644 --- a/Documentation/sound/cards/index.rst +++ b/Documentation/sound/cards/index.rst @@ -17,3 +17,4 @@ Card-Specific Information hdspm serial-u16550 img-spdif-in + pcmtest diff --git a/Documentation/sound/cards/pcmtest.rst b/Documentation/sound/cards/pcmtest.rst new file mode 100644 index 000000000000..ea8070eaa44e --- /dev/null +++ b/Documentation/sound/cards/pcmtest.rst @@ -0,0 +1,119 @@ +.. SPDX-License-Identifier: GPL-2.0 + +The Virtual PCM Test Driver +=========================== + +The Virtual PCM Test Driver emulates a generic PCM device, and can be used for +testing/fuzzing of the userspace ALSA applications, as well as for testing/fuzzing of +the PCM middle layer. Additionally, it can be used for simulating hard to reproduce +problems with PCM devices. + +What can this driver do? +~~~~~~~~~~~~~~~~~~~~~~~~ + +At this moment the driver can do the following things: + * Simulate both capture and playback processes + * Generate random or pattern-based capturing data + * Inject delays into the playback and capturing processes + * Inject errors during the PCM callbacks + +It supports up to 8 substreams and 4 channels. Also it supports both interleaved and +non-interleaved access modes. + +Also, this driver can check the playback stream for containing the predefined pattern, +which is used in the corresponding selftest (alsa/test-pcmtest-driver.c). 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. + +Configuration +------------- + +The driver has several parameters besides the common ALSA module parameters: + + * fill_mode (bool) - Buffer fill mode (see below) + * inject_delay (int) + * inject_hwpars_err (bool) + * inject_prepare_err (bool) + * inject_trigger_err (bool) + + +Capture Data Generation +----------------------- + +The driver has two modes of data generation: the first (0 in the fill_mode parameter) +means random data generation, the second (1 in the fill_mode) - pattern-based +data generation. Let's look at the second mode. + +First of all, you may want to specify the pattern for data generation. You can do it +by writing the pattern to the debugfs file (/sys/kernel/debug/pcmtest/fill_pattern). +Like that: + +.. code-block:: bash + + echo -n mycoolpattern > /sys/kernel/debug/pcmtest/fill_pattern + +After this, every capture action performed on the 'pcmtest' device will return +'mycoolpatternmycoolpatternmycoolpatternmy...' for every channel buffer. + +In case of interleaved access, the capture buffer will contain the repeated pattern +for every channel. Otherwise, every channel buffer will contain the repeated pattern. + +The pattern itself can be up to 4096 bytes long. + +Delay injection +--------------- + +The driver has 'inject_delay' parameter, which has very self-descriptive name and +can be used for time delay/speedup simulations. The parameter has integer type, and +it means the delay added between module's internal timer ticks. + +If the 'inject_delay' value is positive, the buffer will be filled slower, if it is +negative - faster. You can try it yourself by starting a recording in any +audio recording application (like Audacity) and selecting the 'pcmtest' device as a +source. + +This parameter can be also used for generating a huge amount of sound data in a very +short period of time (with the negative 'inject_delay' value). + +Errors injection +---------------- + +This module can be used for injecting errors into the PCM communication process. This +action can help you to figure out how the userspace ALSA program behaves under unusual +circumstances. + +For example, you can make all 'hw_params' PCM callback calls return EBUSY error by +writing '1' to the 'inject_hwpars_err' module parameter: + +.. code-block:: bash + + echo 1 > /sys/module/snd_pcmtest/parameters/inject_hwpars_err + +Errors can be injected into the following PCM callbacks: + + * hw_params (EBUSY) + * prepare (EINVAL) + * trigger (EINVAL) + + +Playback test +------------- + +This driver can be also used for the playback functionality testing - every time you +write the playback data to the 'pcmtest' PCM device and close it, the driver checks the +buffer of each channel for containing the looped pattern (which is specified in the +fill_pattern debugfs file). If the playback buffer content represents the looped pattern, +'pc_test' debugfs entry is set into '1'. Otherwise, the driver sets it to '0'. + +ioctl redefinition test +----------------------- + +The driver redefines the 'reset' ioctl, which is default for all PCM devices. To test +this functionality, we can trigger the reset ioctl and check the 'ioctl_test' debugfs +entry: + +.. code-block:: bash + + cat /sys/kernel/debug/pcmtest/ioctl_test + +If the ioctl is triggered successfully, this file will contain '1', and '0' otherwise. -- 2.34.1

2 4

topology: pre-processor: Add support for object arrays
by GitHub pull_request - edited 24 May '23

24 May '23

alsa-project/alsa-utils pull request #216 was edited from ranj063: Introduce a new keyword, "Objects" to instantiate multiple objects of the same class with different attirbutes. For example Objects.Base.input_audio_format [ { in_rate [ 8000 16000 48000 ] in_bit_depth [ 32 ] in_valid_bit_depth [ 24 32 ] } ] This would be expanded into 6 objects with the rate, bit_depth and valid_bit_depth combinations of the arrays of values above. Object.Base.input_audio_format [ { in_rate 8000 in_bit_depth 32 in_valid_bit_depth 32 } { in_rate 16000 in_bit_depth 32 in_valid_bit_depth 32 } { in_rate 48000 in_bit_depth 32 in_valid_bit_depth 32 } { in_rate 8000 in_bit_depth 32 in_valid_bit_depth 24 } { in_rate 16000 in_bit_depth 32 in_valid_bit_depth 24 } { in_rate 48000 in_bit_depth 32 in_valid_bit_depth 24 } ] The Objects definition is an array so that multiple combinations can be specified so that we deal with only valid combinations. For example, 16-bit bit_depth is only valid with 16-bit valid_bit_depth. So if we also want to add those combinations with the multiple rates, the definition would look like: Objects.Base.input_audio_format [ { in_rate [ 8000 16000 48000 ] in_bit_depth [ 32 ] in_valid_bit_depth [ 24 32 ] } { in_rate [ 8000 16000 48000 ] in_bit_depth [ 16 ] in_valid_bit_depth [ 16 ] } ] Request URL : https://github.com/alsa-project/alsa-utils/pull/216 Patch URL : https://github.com/alsa-project/alsa-utils/pull/216.patch Repository URL: https://github.com/alsa-project/alsa-utils

1 0

tooplogy: pre-processor: Add support for object arrays
by GitHub pull_request - opened 24 May '23

24 May '23

alsa-project/alsa-utils pull request #216 was opened from ranj063: Introduce a new keyword, "Objects" to instantiate multiple objects of the same class with different attirbutes. For example Objects.Base.input_audio_format [ { in_rate [ 8000 16000 48000 ] in_bit_depth [ 32 ] in_valid_bit_depth [ 24 32 ] } ] This would be expanded into 6 objects with the rate, bit_depth and valid_bit_depth combinations of the arrays of values above. Object.Base.input_audio_format [ { in_rate 8000 in_bit_depth 32 in_valid_bit_depth 32 } { in_rate 16000 in_bit_depth 32 in_valid_bit_depth 32 } { in_rate 48000 in_bit_depth 32 in_valid_bit_depth 32 } { in_rate 8000 in_bit_depth 32 in_valid_bit_depth 24 } { in_rate 16000 in_bit_depth 32 in_valid_bit_depth 24 } { in_rate 48000 in_bit_depth 32 in_valid_bit_depth 24 } ] The Objects definition is an array so that multiple combinations can be specified so that we deal with only valid combinations. For example, 16-bit bit_depth is only valid with 16-bit valid_bit_depth. So if we also want to add those combinations with the multiple rates, the definition would look like: Objects.Base.input_audio_format [ { in_rate [ 8000 16000 48000 ] in_bit_depth [ 32 ] in_valid_bit_depth [ 24 32 ] } { in_rate [ 8000 16000 48000 ] in_bit_depth [ 16 ] in_valid_bit_depth [ 16 ] } ] Request URL : https://github.com/alsa-project/alsa-utils/pull/216 Patch URL : https://github.com/alsa-project/alsa-utils/pull/216.patch Repository URL: https://github.com/alsa-project/alsa-utils

1 0

[PATCH 0/2] Improve support for sof_ipc{3|4}_bytes_ext_put
by Daniel Baluta 24 May '23

24 May '23

From: Daniel Baluta <daniel.baluta(a)nxp.com> This patch series provides better handling of cases where sending a data blob to FW results in a validation error. In this case we restore to the last good known value instead of keeping the data that firwmare rejected. Paul Olaru (2): ASoC: sof: Improve sof_ipc3_bytes_ext_put function ASoC: sof: Improve sof_ipc4_bytes_ext_put function sound/soc/sof/ipc3-control.c | 54 ++++++++++++++++++++++++++++++++---- sound/soc/sof/ipc4-control.c | 39 +++++++++++++++++++++++--- sound/soc/sof/sof-audio.h | 1 + 3 files changed, 84 insertions(+), 10 deletions(-) -- 2.25.1

2 3

[PATCH 0/4] ASoC: mt6359: kselftest fix and driver extension
by Trevor Wu 24 May '23

24 May '23

The patch series includes a kselftest fix and changes for extending driver capability to support more use cases. Trevor Wu (4): ASoC: mediatek: mt6359: add supply for MTKAIF ASoC: mediatek: mt6359: fix kselftest error of playback gain ASoC: mediatek: mt6359: add mtkaif gpio setting ASoC: mediatek: mt6359: update route for lineout mux sound/soc/codecs/mt6359.c | 152 ++++++++++++++++++++++++++++++++++---- 1 file changed, 137 insertions(+), 15 deletions(-) -- 2.18.0

2 5

[PATCH v1 0/4] Fixes and cleanup for CS35L41 HDA
by Stefan Binding 23 May '23

23 May '23

Several minor issues were found during additional testing and static analysis. These patches fix these minor issues. Stefan Binding (4): ALSA: hda: cs35l41: Clean up Firmware Load Controls ALSA: hda: cs35l41: Fix endian conversions ALSA: cs35l41: Fix default regmap values for some registers ALSA: hda/realtek: Delete cs35l41 component master during free sound/pci/hda/cs35l41_hda.c | 40 +++++++++++++++------------------- sound/pci/hda/patch_realtek.c | 2 ++ sound/soc/codecs/cs35l41-lib.c | 6 ++--- 3 files changed, 23 insertions(+), 25 deletions(-) -- 2.34.1

2 6

[PATCH v2 0/2] ASoC: do not include runtime_pm.h if not needed
by Claudiu Beznea 23 May '23

23 May '23

Hi, Series removes the pm_runtime.h inclusion in files where APIs exported though pm_runtime.h are not used. In case of files that make use of pm.h which comes form pm_runtime.h added patch 2/2. Changes were built with allmodconfig on ARM and x86_64 and checked all the changed files were built at least once. Thank you, Claudiu Beznea Changes in v2: - removed cs35l45 handling - changed a bit commit description - added patch 2/2 - collected Jarkko Nikula's tag Claudiu Beznea (2): ASoC: do not include pm_runtime.h if not used ASoC: use pm.h instead of runtime_pm.h sound/hda/hdac_regmap.c | 1 - sound/pci/hda/hda_bind.c | 1 - sound/soc/amd/acp/acp-pci.c | 1 - sound/soc/amd/acp/acp-platform.c | 1 - sound/soc/codecs/max98090.c | 1 - sound/soc/codecs/max98373-i2c.c | 2 +- sound/soc/codecs/pcm186x.c | 1 - sound/soc/codecs/rk3328_codec.c | 1 - sound/soc/codecs/rt5682-i2c.c | 1 - sound/soc/codecs/rt5682s.c | 1 - sound/soc/codecs/tas2562.c | 1 - sound/soc/codecs/tas5720.c | 1 - sound/soc/codecs/tas6424.c | 1 - sound/soc/codecs/wm_adsp.c | 1 - sound/soc/fsl/imx-audmix.c | 1 - sound/soc/intel/atom/sst/sst_acpi.c | 1 - sound/soc/intel/atom/sst/sst_ipc.c | 1 - sound/soc/intel/atom/sst/sst_loader.c | 1 - sound/soc/intel/atom/sst/sst_pci.c | 1 - sound/soc/intel/atom/sst/sst_stream.c | 1 - sound/soc/mediatek/mt8186/mt8186-afe-control.c | 1 - sound/soc/mediatek/mt8186/mt8186-mt6366-da7219-max98357.c | 1 - sound/soc/mediatek/mt8186/mt8186-mt6366-rt1019-rt5682s.c | 1 - sound/soc/mediatek/mt8192/mt8192-afe-control.c | 2 -- sound/soc/qcom/lpass-sc7180.c | 2 +- sound/soc/qcom/lpass-sc7280.c | 2 +- sound/soc/soc-compress.c | 1 - sound/soc/soc-pcm.c | 1 - sound/soc/sof/intel/hda-loader-skl.c | 1 - sound/soc/sof/intel/hda-stream.c | 1 - sound/soc/sof/intel/skl.c | 1 - sound/soc/sof/mediatek/mt8186/mt8186-clk.c | 1 - sound/soc/sof/mediatek/mt8195/mt8195-clk.c | 1 - sound/soc/tegra/tegra20_ac97.c | 1 - sound/soc/ti/omap-mcbsp-st.c | 1 - 35 files changed, 3 insertions(+), 36 deletions(-) -- 2.34.1

2 3

[PATCH next] ASoC: SOF: Intel: hda-dai: Fix locking in hda_ipc4_pre_trigger()
by Harshit Mogalapalli 23 May '23

23 May '23

hda_ipc4_pre_trigger() has two issues: 1. In the default case, we are returning without unlocking the mutex. 2. In case SNDRV_PCM_TRIGGER_STOP: when ret is less than zero it goes to out, unlocks but returns zero instead of a negative value. Fix this by changing the final return value to 'ret' instead of zero, and initialize 'ret' to zero in the start of the function. Fixes: 225f37b578a9 ("ASoC: SOF: ipc4-pcm: reset all pipelines during FE DAI hw_free") Signed-off-by: Harshit Mogalapalli <harshit.m.mogalapalli(a)oracle.com> --- Only compile tested. This is found using static anlysis with Smatch. --- sound/soc/sof/intel/hda-dai-ops.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/sound/soc/sof/intel/hda-dai-ops.c b/sound/soc/sof/intel/hda-dai-ops.c index 5a508e118e3d..1e58256c8003 100644 --- a/sound/soc/sof/intel/hda-dai-ops.c +++ b/sound/soc/sof/intel/hda-dai-ops.c @@ -183,7 +183,7 @@ static int hda_ipc4_pre_trigger(struct snd_sof_dev *sdev, struct snd_soc_dai *cp struct sof_ipc4_pipeline *pipeline; struct snd_sof_widget *swidget; struct snd_soc_dapm_widget *w; - int ret; + int ret = 0; w = snd_soc_dai_get_widget(cpu_dai, substream->stream); swidget = w->dobj.private; @@ -208,11 +208,11 @@ static int hda_ipc4_pre_trigger(struct snd_sof_dev *sdev, struct snd_soc_dai *cp break; default: dev_err(sdev->dev, "unknown trigger command %d\n", cmd); - return -EINVAL; + ret = -EINVAL; } out: mutex_unlock(&ipc4_data->pipeline_state_mutex); - return 0; + return ret; } static int hda_trigger(struct snd_sof_dev *sdev, struct snd_soc_dai *cpu_dai, -- 2.31.1

3 2

[PATCH -next] ASoC: SOF: ipc4-topology: Fix an unsigned comparison which can never be negative
by Yang Li 23 May '23

23 May '23

The return value from the call to sof_ipc4_get_valid_bits() is int. However, the return value is being assigned to an unsigned int variable 'out_ref_valid_bits', so making it an int. Eliminate the following warning: ./sound/soc/sof/ipc4-topology.c:1537:6-24: WARNING: Unsigned expression compared with zero: out_ref_valid_bits < 0 Reported-by: Abaci Robot <abaci(a)linux.alibaba.com> Link: https://bugzilla.openanolis.cn/show_bug.cgi?id=4985 Signed-off-by: Yang Li <yang.lee(a)linux.alibaba.com> --- sound/soc/sof/ipc4-topology.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/sound/soc/sof/ipc4-topology.c b/sound/soc/sof/ipc4-topology.c index dce2f8f7f518..d82ac5701eb2 100644 --- a/sound/soc/sof/ipc4-topology.c +++ b/sound/soc/sof/ipc4-topology.c @@ -1381,8 +1381,8 @@ sof_ipc4_prepare_copier_module(struct snd_sof_widget *swidget, void **ipc_config_data; int *ipc_config_size; u32 **data; - int ipc_size, ret; - u32 out_ref_rate, out_ref_channels, out_ref_valid_bits; + int ipc_size, ret, out_ref_valid_bits; + u32 out_ref_rate, out_ref_channels; u32 deep_buffer_dma_ms = 0; int output_fmt_index; -- 2.20.1.7.g153144c

3 2