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

[PATCH AUTOSEL 6.0 05/44] ASoC: Intel: soc-acpi: add ES83x6 support to IceLake
by Sasha Levin 23 Nov '22

23 Nov '22

From: Pierre-Louis Bossart <pierre-louis.bossart(a)linux.intel.com> [ Upstream commit 9a1d248bb4beaf1b43d17ba12481ee0629fa29b9 ] Missing entry to find a machine driver for ES83x6-based platforms. Link: https://github.com/thesofproject/linux/issues/3873 Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart(a)linux.intel.com> Reviewed-by: Bard Liao <yung-chuan.liao(a)linux.intel.com> Link: https://lore.kernel.org/r/20221031195836.250193-1-pierre-louis.bossart@linu… Signed-off-by: Mark Brown <broonie(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- sound/soc/intel/common/soc-acpi-intel-icl-match.c | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/sound/soc/intel/common/soc-acpi-intel-icl-match.c b/sound/soc/intel/common/soc-acpi-intel-icl-match.c index b032bc07de8b..d0062f2cd256 100644 --- a/sound/soc/intel/common/soc-acpi-intel-icl-match.c +++ b/sound/soc/intel/common/soc-acpi-intel-icl-match.c @@ -10,6 +10,11 @@ #include <sound/soc-acpi-intel-match.h> #include "../skylake/skl.h" +static const struct snd_soc_acpi_codecs essx_83x6 = { + .num_codecs = 3, + .codecs = { "ESSX8316", "ESSX8326", "ESSX8336"}, +}; + static struct skl_machine_pdata icl_pdata = { .use_tplg_pcm = true, }; @@ -27,6 +32,14 @@ struct snd_soc_acpi_mach snd_soc_acpi_intel_icl_machines[] = { .drv_name = "sof_rt5682", .sof_tplg_filename = "sof-icl-rt5682.tplg", }, + { + .comp_ids = &essx_83x6, + .drv_name = "sof-essx8336", + .sof_tplg_filename = "sof-icl-es8336", /* the tplg suffix is added at run time */ + .tplg_quirk_mask = SND_SOC_ACPI_TPLG_INTEL_SSP_NUMBER | + SND_SOC_ACPI_TPLG_INTEL_SSP_MSB | + SND_SOC_ACPI_TPLG_INTEL_DMIC_NUMBER, + }, {}, }; EXPORT_SYMBOL_GPL(snd_soc_acpi_intel_icl_machines); -- 2.35.1

1 0

[PATCH AUTOSEL 6.0 04/44] ASoC: Intel: bytcht_es8316: Add quirk for the Nanote UMPC-01
by Sasha Levin 23 Nov '22

23 Nov '22

From: Hans de Goede <hdegoede(a)redhat.com> [ Upstream commit 8bb0ac0e6f64ebdf15d963c26b028de391c9bcf9 ] The Nanote UMPC-01 mini laptop has stereo speakers, while the default bytcht_es8316 settings assume a mono speaker setup. Add a quirk for this. Signed-off-by: Hans de Goede <hdegoede(a)redhat.com> Acked-by: Pierre-Louis Bossart <pierre-louis.bossart(a)linux.intel.com> Link: https://lore.kernel.org/r/20221025140942.509066-1-hdegoede@redhat.com Signed-off-by: Mark Brown <broonie(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- sound/soc/intel/boards/bytcht_es8316.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/sound/soc/intel/boards/bytcht_es8316.c b/sound/soc/intel/boards/bytcht_es8316.c index 6432b83f616f..a935c5fd9edb 100644 --- a/sound/soc/intel/boards/bytcht_es8316.c +++ b/sound/soc/intel/boards/bytcht_es8316.c @@ -443,6 +443,13 @@ static const struct dmi_system_id byt_cht_es8316_quirk_table[] = { | BYT_CHT_ES8316_INTMIC_IN2_MAP | BYT_CHT_ES8316_JD_INVERTED), }, + { /* Nanote UMPC-01 */ + .matches = { + DMI_MATCH(DMI_SYS_VENDOR, "RWC CO.,LTD"), + DMI_MATCH(DMI_PRODUCT_NAME, "UMPC-01"), + }, + .driver_data = (void *)BYT_CHT_ES8316_INTMIC_IN1_MAP, + }, { /* Teclast X98 Plus II */ .matches = { DMI_MATCH(DMI_SYS_VENDOR, "TECLAST"), -- 2.35.1

1 0

[PATCH AUTOSEL 6.0 03/44] ASoC: amd: yc: Add Alienware m17 R5 AMD into DMI table
by Sasha Levin 23 Nov '22

23 Nov '22

From: Brent Mendelsohn <mendiebm(a)gmail.com> [ Upstream commit d40b6529c6269cd5afddb1116a383cab9f126694 ] This model requires an additional detection quirk to enable the internal microphone - BIOS doesn't seem to support AcpDmicConnected (nothing in acpidump output). Link: https://bugzilla.kernel.org/show_bug.cgi?id=216590 Signed-off-by: Brent Mendelsohn <mendiebm(a)gmail.com> Reviewed-by: Mario Limonciello <mario.limonciello(a)amd.com> Link: https://lore.kernel.org/r/20221024174227.4160-1-mendiebm@gmail.com Signed-off-by: Mark Brown <broonie(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- sound/soc/amd/yc/acp6x-mach.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/sound/soc/amd/yc/acp6x-mach.c b/sound/soc/amd/yc/acp6x-mach.c index 2cb50d5cf1a9..a868a890f00c 100644 --- a/sound/soc/amd/yc/acp6x-mach.c +++ b/sound/soc/amd/yc/acp6x-mach.c @@ -185,6 +185,13 @@ static const struct dmi_system_id yc_acp_quirk_table[] = { DMI_MATCH(DMI_PRODUCT_NAME, "UM5302TA"), } }, + { + .driver_data = &acp6x_card, + .matches = { + DMI_MATCH(DMI_BOARD_VENDOR, "Alienware"), + DMI_MATCH(DMI_PRODUCT_NAME, "Alienware m17 R5 AMD"), + } + }, {} }; -- 2.35.1

1 0

[PATCH] ASoC: Intel: avs: Add missing audio amplifier for KBL
by Alicja Michalska 23 Nov '22

23 Nov '22

KBL platform is missing the definition of 'max98357a' audio amplifier. This amplifier is used on many KBL Chromebooks, for instance variant 'nami' of 'Google/poppy' baseboard. Reported-by: CoolStar <coolstarorganization(a)gmail.com> Signed-off-by: Alicja Michalska <ahplka19(a)gmail.com> diff --git a/sound/soc/intel/avs/board_selection.c b/sound/soc/intel/avs/board_selection.c index 87f9c18be238..650faebb33ef 100644 --- a/sound/soc/intel/avs/board_selection.c +++ b/sound/soc/intel/avs/board_selection.c @@ -129,6 +129,14 @@ static struct snd_soc_acpi_mach avs_kbl_i2s_machines[] = { }, .tplg_filename = "max98373-tplg.bin", }, + { + .id = "MX98357A", + .drv_name = "avs_max98357a", + .mach_params = { + .i2s_link_mask = AVS_SSP(0), + }, + .tplg_filename = "max98357a-tplg.bin", + }, { .id = "DLGS7219", .drv_name = "avs_da7219", --- sound/soc/intel/avs/board_selection.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/sound/soc/intel/avs/board_selection.c b/sound/soc/intel/avs/board_selection.c index 87f9c18be238..650faebb33ef 100644 --- a/sound/soc/intel/avs/board_selection.c +++ b/sound/soc/intel/avs/board_selection.c @@ -129,6 +129,14 @@ static struct snd_soc_acpi_mach avs_kbl_i2s_machines[] = { }, .tplg_filename = "max98373-tplg.bin", }, + { + .id = "MX98357A", + .drv_name = "avs_max98357a", + .mach_params = { + .i2s_link_mask = AVS_SSP(0), + }, + .tplg_filename = "max98357a-tplg.bin", + }, { .id = "DLGS7219", .drv_name = "avs_da7219", -- 2.38.1

4 5

[PATCH v2] ASoC: soc-pcm: Add NULL check in BE reparenting
by Srinivasa Rao Mandadapu 23 Nov '22

23 Nov '22

Add NULL check in dpcm_be_reparent API, to handle kernel NULL pointer dereference error. The issue occurred in fuzzing test. Signed-off-by: Srinivasa Rao Mandadapu <quic_srivasam(a)quicinc.com> --- Changes Since V1: -- Update commit title. sound/soc/soc-pcm.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/sound/soc/soc-pcm.c b/sound/soc/soc-pcm.c index 493f003..a7810c7 100644 --- a/sound/soc/soc-pcm.c +++ b/sound/soc/soc-pcm.c @@ -1247,6 +1247,8 @@ static void dpcm_be_reparent(struct snd_soc_pcm_runtime *fe, return; be_substream = snd_soc_dpcm_get_substream(be, stream); + if (!be_substream) + return; for_each_dpcm_fe(be, stream, dpcm) { if (dpcm->fe == fe) -- 2.7.4

3 2

starting from kernel 5.10.x latency test fails systematically on multiple platforms
by GitHub issues - edited 23 Nov '22

23 Nov '22

alsa-project/alsa-lib issue #285 was edited from bondagit: If I try the latency test application ([test/latency.c](https://github.com/alsa-project/alsa-lib/blob/master/test/l…) using a **Linux Kernel 5.9.x** with alsa-lib v1.2.4 on the following audio card: _PCH [HDA Intel PCH], device 1: ALC269VC Analog [ALC269VC Analog]_ (for example) I get the following result: ``` sudo ./latency -C hw:1 -P hw:1 -f S16_LE -r 48000 -c 2 -s 10 -m 128 -M 128 Scheduler set to Round Robin with priority 99... Playback device is hw:1 Capture device is hw:1 Parameters are 48000Hz, S16_LE, 2 channels, non-blocking mode Poll mode: no Loop limit is 480000 frames, minimum latency = 128, maximum latency = 128 Hardware PCM card 1 'HDA Intel PCH' device 0 subdevice 0 Its setup is: stream : PLAYBACK access : RW_INTERLEAVED format : S16_LE subformat : STD channels : 2 rate : 48000 exact rate : 48000 (48000/1) msbits : 16 buffer_size : 128 period_size : 64 period_time : 1333 tstamp_mode : NONE tstamp_type : MONOTONIC period_step : 1 avail_min : 64 period_event : 0 start_threshold : 2147483647 stop_threshold : 128 silence_threshold: 0 silence_size : 0 boundary : 4611686018427387904 appl_ptr : 0 hw_ptr : 0 Hardware PCM card 1 'HDA Intel PCH' device 0 subdevice 0 Its setup is: stream : CAPTURE access : RW_INTERLEAVED format : S16_LE subformat : STD channels : 2 rate : 48000 exact rate : 48000 (48000/1) msbits : 16 buffer_size : 128 period_size : 64 period_time : 1333 tstamp_mode : NONE tstamp_type : MONOTONIC period_step : 1 avail_min : 64 period_event : 0 start_threshold : 2147483647 stop_threshold : 128 silence_threshold: 0 silence_size : 0 boundary : 4611686018427387904 appl_ptr : 0 hw_ptr : 0 Trying latency 128 frames, 2666.667us, 2.666667ms (375.0000Hz) Success Playback: *** frames = 480128 *** state : RUNNING trigger_time: 1907393.672215 tstamp : 0.000000 delay : 80 avail : 48 avail_max : 64 Capture: *** frames = 480000 *** state : RUNNING trigger_time: 1907393.672215 tstamp : 0.000000 delay : 0 avail : 0 avail_max : 16 Maximum read: 16 frames Maximum read latency: 333.333us, 0.333333ms (3000.0000Hz) Hardware sync Playback time = 1907393.672215, Record time = 1907393.672215, diff = 0 ``` The tests succeeded and final state is **RUNNING** If I try the same tests on the same audio device and distribution but with a **Linux Kernel >= 5.10.x** it fails systematically and I get: ``` sudo ./lantency -C hw:1 -P hw:1 -f S16_LE -r 48000 -c 2 -s 10 -m 128 -M 128 Scheduler set to Round Robin with priority 99... Playback device is hw:0 Capture device is hw:0 Parameters are 48000Hz, S16_LE, 2 channels, non-blocking mode Poll mode: no Loop limit is 480000 frames, minimum latency = 128, maximum latency = 128 Hardware PCM card 0 'HDA Intel PCH' device 0 subdevice 0 Its setup is: stream : PLAYBACK access : RW_INTERLEAVED format : S16_LE subformat : STD channels : 2 rate : 48000 exact rate : 48000 (48000/1) msbits : 16 buffer_size : 128 period_size : 64 period_time : 1333 tstamp_mode : NONE tstamp_type : MONOTONIC period_step : 1 avail_min : 64 period_event : 0 start_threshold : 2147483647 stop_threshold : 128 silence_threshold: 0 silence_size : 0 boundary : 4611686018427387904 appl_ptr : 0 hw_ptr : 0 Hardware PCM card 0 'HDA Intel PCH' device 0 subdevice 0 Its setup is: stream : CAPTURE access : RW_INTERLEAVED format : S16_LE subformat : STD channels : 2 rate : 48000 exact rate : 48000 (48000/1) msbits : 16 buffer_size : 128 period_size : 64 period_time : 1333 tstamp_mode : NONE tstamp_type : MONOTONIC period_step : 1 avail_min : 64 period_event : 0 start_threshold : 2147483647 stop_threshold : 128 silence_threshold: 0 silence_size : 0 boundary : 4611686018427387904 appl_ptr : 0 hw_ptr : 0 Trying latency 128 frames, 2666.667us, 2.666667ms (375.0000Hz) Failure Playback: *** frames = 90720 *** state : XRUN trigger_time: 967.658489 tstamp : 0.000000 delay : 0 avail : 216 avail_max : 216 Capture: *** frames = 90592 *** state : XRUN trigger_time: 967.658489 tstamp : 0.000000 delay : 0 avail : 88 avail_max : 88 Maximum read: 16 frames Maximum read latency: 333.333us, 0.333333ms (3000.0000Hz) Hardware sync ``` I get an **XRUN** during the test execution. I can reproduce the same error on multiple boards for multiple audio cards and on different Linux distribution just changing the Linux kernel version. The problem was originally reported at: [AES67 Linux daemon: Latency test fails with Linux kernel starting from 5.10.0x](https://github.com/bondagit/aes67-linux-daemon/issues/79) I am interested in testing with low latency (-m 128 -M 128). My guess is that something changed in the Linux audio core and the latency application has to be adapted. Any idea ? Issue URL : https://github.com/alsa-project/alsa-lib/issues/285 Repository URL: https://github.com/alsa-project/alsa-lib

1 0

starting from kernel 5.10.x latency test fails systematically on multiple platforms
by GitHub issues - edited 23 Nov '22

23 Nov '22

alsa-project/alsa-lib issue #285 was edited from bondagit: If I try the latency test application ([test/latency.c](https://github.com/alsa-project/alsa-lib/blob/master/test/l…) using a **Linux Kernel 5.9.x** with alsa-lib v1.2.4 on the following audio card: _PCH [HDA Intel PCH], device 1: ALC269VC Analog [ALC269VC Analog]_ (for example) I get the following result: ``` sudo ./latency -C hw:1 -P hw:1 -f S16_LE -r 48000 -c 2 -s 10 -m 128 -M 128 Scheduler set to Round Robin with priority 99... Playback device is hw:1 Capture device is hw:1 Parameters are 48000Hz, S16_LE, 2 channels, non-blocking mode Poll mode: no Loop limit is 480000 frames, minimum latency = 128, maximum latency = 128 Hardware PCM card 1 'HDA Intel PCH' device 0 subdevice 0 Its setup is: stream : PLAYBACK access : RW_INTERLEAVED format : S16_LE subformat : STD channels : 2 rate : 48000 exact rate : 48000 (48000/1) msbits : 16 buffer_size : 128 period_size : 64 period_time : 1333 tstamp_mode : NONE tstamp_type : MONOTONIC period_step : 1 avail_min : 64 period_event : 0 start_threshold : 2147483647 stop_threshold : 128 silence_threshold: 0 silence_size : 0 boundary : 4611686018427387904 appl_ptr : 0 hw_ptr : 0 Hardware PCM card 1 'HDA Intel PCH' device 0 subdevice 0 Its setup is: stream : CAPTURE access : RW_INTERLEAVED format : S16_LE subformat : STD channels : 2 rate : 48000 exact rate : 48000 (48000/1) msbits : 16 buffer_size : 128 period_size : 64 period_time : 1333 tstamp_mode : NONE tstamp_type : MONOTONIC period_step : 1 avail_min : 64 period_event : 0 start_threshold : 2147483647 stop_threshold : 128 silence_threshold: 0 silence_size : 0 boundary : 4611686018427387904 appl_ptr : 0 hw_ptr : 0 Trying latency 128 frames, 2666.667us, 2.666667ms (375.0000Hz) Success Playback: *** frames = 480128 *** state : RUNNING trigger_time: 1907393.672215 tstamp : 0.000000 delay : 80 avail : 48 avail_max : 64 Capture: *** frames = 480000 *** state : RUNNING trigger_time: 1907393.672215 tstamp : 0.000000 delay : 0 avail : 0 avail_max : 16 Maximum read: 16 frames Maximum read latency: 333.333us, 0.333333ms (3000.0000Hz) Hardware sync Playback time = 1907393.672215, Record time = 1907393.672215, diff = 0 ``` The tests succeeded and final state is **RUNNING** If I try the same tests on the same audio device and distribution but with a **Linux Kernel >= 5.10.x** it fails systematically and I get: ``` sudo ./lantency -C hw:1 -P hw:1 -f S16_LE -r 48000 -c 2 -s 10 -m 128 -M 128 Scheduler set to Round Robin with priority 99... Playback device is hw:0 Capture device is hw:0 Parameters are 48000Hz, S16_LE, 2 channels, non-blocking mode Poll mode: no Loop limit is 480000 frames, minimum latency = 128, maximum latency = 128 Hardware PCM card 0 'HDA Intel PCH' device 0 subdevice 0 Its setup is: stream : PLAYBACK access : RW_INTERLEAVED format : S16_LE subformat : STD channels : 2 rate : 48000 exact rate : 48000 (48000/1) msbits : 16 buffer_size : 128 period_size : 64 period_time : 1333 tstamp_mode : NONE tstamp_type : MONOTONIC period_step : 1 avail_min : 64 period_event : 0 start_threshold : 2147483647 stop_threshold : 128 silence_threshold: 0 silence_size : 0 boundary : 4611686018427387904 appl_ptr : 0 hw_ptr : 0 Hardware PCM card 0 'HDA Intel PCH' device 0 subdevice 0 Its setup is: stream : CAPTURE access : RW_INTERLEAVED format : S16_LE subformat : STD channels : 2 rate : 48000 exact rate : 48000 (48000/1) msbits : 16 buffer_size : 128 period_size : 64 period_time : 1333 tstamp_mode : NONE tstamp_type : MONOTONIC period_step : 1 avail_min : 64 period_event : 0 start_threshold : 2147483647 stop_threshold : 128 silence_threshold: 0 silence_size : 0 boundary : 4611686018427387904 appl_ptr : 0 hw_ptr : 0 Trying latency 128 frames, 2666.667us, 2.666667ms (375.0000Hz) Failure Playback: *** frames = 90720 *** state : XRUN trigger_time: 967.658489 tstamp : 0.000000 delay : 0 avail : 216 avail_max : 216 Capture: *** frames = 90592 *** state : XRUN trigger_time: 967.658489 tstamp : 0.000000 delay : 0 avail : 88 avail_max : 88 Maximum read: 16 frames Maximum read latency: 333.333us, 0.333333ms (3000.0000Hz) Hardware sync ``` I get an **XRUN** during the test execution. I can reproduce the same error on multiple boards for multiple audio cards and on different Linux distribution just changing the Linux kernel version. The problem was originally reported at: [AES67 Linux daemon: Latency test fails with Linux kernel starting from 5.10.0x](https://github.com/bondagit/aes67-linux-daemon/issues/79) I am interested in testing a with low latency (-m 128 -M 128). My guess is that something changed in the Linux audio core and the latency application has to be adapted. Any idea ? Issue URL : https://github.com/alsa-project/alsa-lib/issues/285 Repository URL: https://github.com/alsa-project/alsa-lib

1 0

starting from kernel 5.10.x latency test fails systematically on multiple platforms
by GitHub issues - opened 23 Nov '22

23 Nov '22

alsa-project/alsa-lib issue #285 was opened from bondagit: If I try the latency test application ([test/latency.c](https://github.com/alsa-project/alsa-lib/blob/master/test/l…) using a **Linux Kernel 5.9.x** with alsa-lib v1.2.4 on the following audio card: _PCH [HDA Intel PCH], device 1: ALC269VC Analog [ALC269VC Analog]_ (for example) I get the following result: ``` sudo ./latency -C hw:1 -P hw:1 -f S16_LE -r 48000 -c 2 -s 10 -m 128 -M 128 Scheduler set to Round Robin with priority 99... Playback device is hw:1 Capture device is hw:1 Parameters are 48000Hz, S16_LE, 2 channels, non-blocking mode Poll mode: no Loop limit is 480000 frames, minimum latency = 128, maximum latency = 128 Hardware PCM card 1 'HDA Intel PCH' device 0 subdevice 0 Its setup is: stream : PLAYBACK access : RW_INTERLEAVED format : S16_LE subformat : STD channels : 2 rate : 48000 exact rate : 48000 (48000/1) msbits : 16 buffer_size : 128 period_size : 64 period_time : 1333 tstamp_mode : NONE tstamp_type : MONOTONIC period_step : 1 avail_min : 64 period_event : 0 start_threshold : 2147483647 stop_threshold : 128 silence_threshold: 0 silence_size : 0 boundary : 4611686018427387904 appl_ptr : 0 hw_ptr : 0 Hardware PCM card 1 'HDA Intel PCH' device 0 subdevice 0 Its setup is: stream : CAPTURE access : RW_INTERLEAVED format : S16_LE subformat : STD channels : 2 rate : 48000 exact rate : 48000 (48000/1) msbits : 16 buffer_size : 128 period_size : 64 period_time : 1333 tstamp_mode : NONE tstamp_type : MONOTONIC period_step : 1 avail_min : 64 period_event : 0 start_threshold : 2147483647 stop_threshold : 128 silence_threshold: 0 silence_size : 0 boundary : 4611686018427387904 appl_ptr : 0 hw_ptr : 0 Trying latency 128 frames, 2666.667us, 2.666667ms (375.0000Hz) Success Playback: *** frames = 480128 *** state : RUNNING trigger_time: 1907393.672215 tstamp : 0.000000 delay : 80 avail : 48 avail_max : 64 Capture: *** frames = 480000 *** state : RUNNING trigger_time: 1907393.672215 tstamp : 0.000000 delay : 0 avail : 0 avail_max : 16 Maximum read: 16 frames Maximum read latency: 333.333us, 0.333333ms (3000.0000Hz) Hardware sync Playback time = 1907393.672215, Record time = 1907393.672215, diff = 0 ``` The tests succeeded and final state is **RUNNING** If I try the same tests on the same audio device and distribution but with a **Linux Kernel >= 5.10.x** it fails systematically and I get: ``` sudo ./lantency -C hw:1 -P hw:1 -f S16_LE -r 48000 -c 2 -s 10 -m 128 -M 128 Scheduler set to Round Robin with priority 99... Playback device is hw:0 Capture device is hw:0 Parameters are 48000Hz, S16_LE, 2 channels, non-blocking mode Poll mode: no Loop limit is 480000 frames, minimum latency = 128, maximum latency = 128 Hardware PCM card 0 'HDA Intel PCH' device 0 subdevice 0 Its setup is: stream : PLAYBACK access : RW_INTERLEAVED format : S16_LE subformat : STD channels : 2 rate : 48000 exact rate : 48000 (48000/1) msbits : 16 buffer_size : 128 period_size : 64 period_time : 1333 tstamp_mode : NONE tstamp_type : MONOTONIC period_step : 1 avail_min : 64 period_event : 0 start_threshold : 2147483647 stop_threshold : 128 silence_threshold: 0 silence_size : 0 boundary : 4611686018427387904 appl_ptr : 0 hw_ptr : 0 Hardware PCM card 0 'HDA Intel PCH' device 0 subdevice 0 Its setup is: stream : CAPTURE access : RW_INTERLEAVED format : S16_LE subformat : STD channels : 2 rate : 48000 exact rate : 48000 (48000/1) msbits : 16 buffer_size : 128 period_size : 64 period_time : 1333 tstamp_mode : NONE tstamp_type : MONOTONIC period_step : 1 avail_min : 64 period_event : 0 start_threshold : 2147483647 stop_threshold : 128 silence_threshold: 0 silence_size : 0 boundary : 4611686018427387904 appl_ptr : 0 hw_ptr : 0 Trying latency 128 frames, 2666.667us, 2.666667ms (375.0000Hz) Failure Playback: *** frames = 90720 *** state : XRUN trigger_time: 967.658489 tstamp : 0.000000 delay : 0 avail : 216 avail_max : 216 Capture: *** frames = 90592 *** state : XRUN trigger_time: 967.658489 tstamp : 0.000000 delay : 0 avail : 88 avail_max : 88 Maximum read: 16 frames Maximum read latency: 333.333us, 0.333333ms (3000.0000Hz) Hardware sync ``` I get an **XRUN** during the test execution. I can reproduce the same error on multiple boards for multiple audio cards and on different Linux distribution just changing the Linux kernel version. The problem was originally reported at: [AES67 Linux daemon: Latency test fails with Linux kernel starting from 5.10.0x](https://github.com/bondagit/aes67-linux-daemon/issues/79) My guess is that something changed in the Linux audio core and the latency application has to be adapted. Any idea ? Issue URL : https://github.com/alsa-project/alsa-lib/issues/285 Repository URL: https://github.com/alsa-project/alsa-lib

1 0

[RESEND PATCH] ALSA: rawmidi: fix infoleak in snd_rawmidi_ioctl_status_compat64
by Xiaolong Huang 23 Nov '22

23 Nov '22

The compat_status is declared off of the stack, so it needs to be zeroed out before copied back to userspace to prevent any unintentional data leakage. Fixes: d9e5582c4bb2 ("ALSA: Avoid using timespec for struct snd_rawmidi_status") Signed-off-by: Xiaolong Huang <butterflyhuangxx(a)gmail.com> --- Reason for resend: 1. add Fixes line. --- sound/core/rawmidi_compat.c | 1 + 1 file changed, 1 insertion(+) diff --git a/sound/core/rawmidi_compat.c b/sound/core/rawmidi_compat.c index 68a93443583c..6afa68165b17 100644 --- a/sound/core/rawmidi_compat.c +++ b/sound/core/rawmidi_compat.c @@ -80,6 +80,7 @@ static int snd_rawmidi_ioctl_status_compat64(struct snd_rawmidi_file *rfile, if (err < 0) return err; + memset(&compat_status, 0, sizeof(compat_status)); compat_status = (struct compat_snd_rawmidi_status64) { .stream = status.stream, .tstamp_sec = status.tstamp_sec, base-commit: eb7081409f94a9a8608593d0fb63a1aa3d6f95d8 -- 2.25.1

3 3

[PATCH -next v2] ALSA: seq: fix undefined behavior in bit shift for SNDRV_SEQ_FILTER_USE_EVENT
by Baisong Zhong 23 Nov '22

23 Nov '22

Shifting signed 32-bit value by 31 bits is undefined, so changing significant bit to unsigned. The UBSAN warning calltrace like below: UBSAN: shift-out-of-bounds in sound/core/seq/seq_clientmgr.c:509:22 left shift of 1 by 31 places cannot be represented in type 'int' ... Call Trace: <TASK> dump_stack_lvl+0x8d/0xcf ubsan_epilogue+0xa/0x44 __ubsan_handle_shift_out_of_bounds+0x1e7/0x208 snd_seq_deliver_single_event.constprop.21+0x191/0x2f0 snd_seq_deliver_event+0x1a2/0x350 snd_seq_kernel_client_dispatch+0x8b/0xb0 snd_seq_client_notify_subscription+0x72/0xa0 snd_seq_ioctl_subscribe_port+0x128/0x160 snd_seq_kernel_client_ctl+0xce/0xf0 snd_seq_oss_create_client+0x109/0x15b alsa_seq_oss_init+0x11c/0x1aa do_one_initcall+0x80/0x440 kernel_init_freeable+0x370/0x3c3 kernel_init+0x1b/0x190 ret_from_fork+0x1f/0x30 </TASK> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Baisong Zhong <zhongbaisong(a)huawei.com> --- v2: update all SNDRV_SEQ_FILTER_* to 1U to keep consistent --- include/uapi/sound/asequencer.h | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/include/uapi/sound/asequencer.h b/include/uapi/sound/asequencer.h index 6d4a2c60808d..00d2703e8fca 100644 --- a/include/uapi/sound/asequencer.h +++ b/include/uapi/sound/asequencer.h @@ -328,10 +328,10 @@ typedef int __bitwise snd_seq_client_type_t; #define KERNEL_CLIENT ((__force snd_seq_client_type_t) 2) /* event filter flags */ -#define SNDRV_SEQ_FILTER_BROADCAST (1<<0) /* accept broadcast messages */ -#define SNDRV_SEQ_FILTER_MULTICAST (1<<1) /* accept multicast messages */ -#define SNDRV_SEQ_FILTER_BOUNCE (1<<2) /* accept bounce event in error */ -#define SNDRV_SEQ_FILTER_USE_EVENT (1<<31) /* use event filter */ +#define SNDRV_SEQ_FILTER_BROADCAST (1U<<0) /* accept broadcast messages */ +#define SNDRV_SEQ_FILTER_MULTICAST (1U<<1) /* accept multicast messages */ +#define SNDRV_SEQ_FILTER_BOUNCE (1U<<2) /* accept bounce event in error */ +#define SNDRV_SEQ_FILTER_USE_EVENT (1U<<31) /* use event filter */ struct snd_seq_client_info { int client; /* client number to inquire */ -- 2.25.1

2 1