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

[PATCH AUTOSEL 5.15 14/25] ASoC: kirkwood: Iterate over array indexes instead of using pointer math
by Sasha Levin 27 Feb '23

27 Feb '23

From: Kees Cook <keescook(a)chromium.org> [ Upstream commit b3bcedc0402fcdc5c8624c433562d9d1882749d8 ] Walking the dram->cs array was seen as accesses beyond the first array item by the compiler. Instead, use the array index directly. This allows for run-time bounds checking under CONFIG_UBSAN_BOUNDS as well. Seen with GCC 13 with -fstrict-flex-arrays: ../sound/soc/kirkwood/kirkwood-dma.c: In function 'kirkwood_dma_conf_mbus_windows.constprop': ../sound/soc/kirkwood/kirkwood-dma.c:90:24: warning: array subscript 0 is outside array bounds of 'const struct mbus_dram_window[0]' [-Warray-bounds=] 90 | if ((cs->base & 0xffff0000) < (dma & 0xffff0000)) { | ~~^~~~~~ Cc: Liam Girdwood <lgirdwood(a)gmail.com> Cc: Mark Brown <broonie(a)kernel.org> Cc: Jaroslav Kysela <perex(a)perex.cz> Cc: Takashi Iwai <tiwai(a)suse.com> Cc: alsa-devel(a)alsa-project.org Signed-off-by: Kees Cook <keescook(a)chromium.org> Link: https://lore.kernel.org/r/20230127224128.never.410-kees@kernel.org Signed-off-by: Mark Brown <broonie(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- sound/soc/kirkwood/kirkwood-dma.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/soc/kirkwood/kirkwood-dma.c b/sound/soc/kirkwood/kirkwood-dma.c index 700a18561a940..640cebd2983e2 100644 --- a/sound/soc/kirkwood/kirkwood-dma.c +++ b/sound/soc/kirkwood/kirkwood-dma.c @@ -86,7 +86,7 @@ kirkwood_dma_conf_mbus_windows(void __iomem *base, int win, /* try to find matching cs for current dma address */ for (i = 0; i < dram->num_cs; i++) { - const struct mbus_dram_window *cs = dram->cs + i; + const struct mbus_dram_window *cs = &dram->cs[i]; if ((cs->base & 0xffff0000) < (dma & 0xffff0000)) { writel(cs->base & 0xffff0000, base + KIRKWOOD_AUDIO_WIN_BASE_REG(win)); -- 2.39.0

1 0

[PATCH AUTOSEL 5.15 13/25] ASoC: soc-compress: Reposition and add pcm_mutex
by Sasha Levin 27 Feb '23

27 Feb '23

From: 강신형 <s47.kang(a)samsung.com> [ Upstream commit aa9ff6a4955fdba02b54fbc4386db876603703b7 ] If panic_on_warn is set and compress stream(DPCM) is started, then kernel panic occurred because card->pcm_mutex isn't held appropriately. In the following functions, warning were issued at this line "snd_soc_dpcm_mutex_assert_held". static int dpcm_be_connect(struct snd_soc_pcm_runtime *fe, struct snd_soc_pcm_runtime *be, int stream) { ... snd_soc_dpcm_mutex_assert_held(fe); ... } void dpcm_be_disconnect(struct snd_soc_pcm_runtime *fe, int stream) { ... snd_soc_dpcm_mutex_assert_held(fe); ... } void snd_soc_runtime_action(struct snd_soc_pcm_runtime *rtd, int stream, int action) { ... snd_soc_dpcm_mutex_assert_held(rtd); ... } int dpcm_dapm_stream_event(struct snd_soc_pcm_runtime *fe, int dir, int event) { ... snd_soc_dpcm_mutex_assert_held(fe); ... } These functions are called by soc_compr_set_params_fe, soc_compr_open_fe and soc_compr_free_fe without pcm_mutex locking. And this is call stack. [ 414.527841][ T2179] pc : dpcm_process_paths+0x5a4/0x750 [ 414.527848][ T2179] lr : dpcm_process_paths+0x37c/0x750 [ 414.527945][ T2179] Call trace: [ 414.527949][ T2179] dpcm_process_paths+0x5a4/0x750 [ 414.527955][ T2179] soc_compr_open_fe+0xb0/0x2cc [ 414.527972][ T2179] snd_compr_open+0x180/0x248 [ 414.527981][ T2179] snd_open+0x15c/0x194 [ 414.528003][ T2179] chrdev_open+0x1b0/0x220 [ 414.528023][ T2179] do_dentry_open+0x30c/0x594 [ 414.528045][ T2179] vfs_open+0x34/0x44 [ 414.528053][ T2179] path_openat+0x914/0xb08 [ 414.528062][ T2179] do_filp_open+0xc0/0x170 [ 414.528068][ T2179] do_sys_openat2+0x94/0x18c [ 414.528076][ T2179] __arm64_sys_openat+0x78/0xa4 [ 414.528084][ T2179] invoke_syscall+0x48/0x10c [ 414.528094][ T2179] el0_svc_common+0xbc/0x104 [ 414.528099][ T2179] do_el0_svc+0x34/0xd8 [ 414.528103][ T2179] el0_svc+0x34/0xc4 [ 414.528125][ T2179] el0t_64_sync_handler+0x8c/0xfc [ 414.528133][ T2179] el0t_64_sync+0x1a0/0x1a4 [ 414.528142][ T2179] Kernel panic - not syncing: panic_on_warn set ... So, I reposition and add pcm_mutex to resolve lockdep error. Signed-off-by: Shinhyung Kang <s47.kang(a)samsung.com> Link: https://lore.kernel.org/r/016401d90ac4$7b6848c0$7238da40$@samsung.com Signed-off-by: Mark Brown <broonie(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- sound/soc/soc-compress.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/sound/soc/soc-compress.c b/sound/soc/soc-compress.c index 2050728063a15..9146bec146c1e 100644 --- a/sound/soc/soc-compress.c +++ b/sound/soc/soc-compress.c @@ -116,6 +116,8 @@ static int soc_compr_open_fe(struct snd_compr_stream *cstream) if (ret < 0) goto be_err; + mutex_lock_nested(&fe->card->pcm_mutex, fe->card->pcm_subclass); + /* calculate valid and active FE <-> BE dpcms */ dpcm_process_paths(fe, stream, &list, 1); fe->dpcm[stream].runtime = fe_substream->runtime; @@ -151,7 +153,6 @@ static int soc_compr_open_fe(struct snd_compr_stream *cstream) fe->dpcm[stream].state = SND_SOC_DPCM_STATE_OPEN; fe->dpcm[stream].runtime_update = SND_SOC_DPCM_UPDATE_NO; - mutex_lock_nested(&fe->card->pcm_mutex, fe->card->pcm_subclass); snd_soc_runtime_activate(fe, stream); mutex_unlock(&fe->card->pcm_mutex); @@ -182,7 +183,6 @@ static int soc_compr_free_fe(struct snd_compr_stream *cstream) mutex_lock_nested(&fe->card->pcm_mutex, fe->card->pcm_subclass); snd_soc_runtime_deactivate(fe, stream); - mutex_unlock(&fe->card->pcm_mutex); fe->dpcm[stream].runtime_update = SND_SOC_DPCM_UPDATE_FE; @@ -201,6 +201,8 @@ static int soc_compr_free_fe(struct snd_compr_stream *cstream) dpcm_be_disconnect(fe, stream); + mutex_unlock(&fe->card->pcm_mutex); + fe->dpcm[stream].runtime = NULL; snd_soc_link_compr_shutdown(cstream, 0); @@ -376,8 +378,9 @@ static int soc_compr_set_params_fe(struct snd_compr_stream *cstream, ret = snd_soc_link_compr_set_params(cstream); if (ret < 0) goto out; - + mutex_lock_nested(&fe->card->pcm_mutex, fe->card->pcm_subclass); dpcm_dapm_stream_event(fe, stream, SND_SOC_DAPM_STREAM_START); + mutex_unlock(&fe->card->pcm_mutex); fe->dpcm[stream].state = SND_SOC_DPCM_STATE_PREPARE; out: -- 2.39.0

1 0

[PATCH AUTOSEL 6.1 34/58] ASoC: kirkwood: Iterate over array indexes instead of using pointer math
by Sasha Levin 27 Feb '23

27 Feb '23

From: Kees Cook <keescook(a)chromium.org> [ Upstream commit b3bcedc0402fcdc5c8624c433562d9d1882749d8 ] Walking the dram->cs array was seen as accesses beyond the first array item by the compiler. Instead, use the array index directly. This allows for run-time bounds checking under CONFIG_UBSAN_BOUNDS as well. Seen with GCC 13 with -fstrict-flex-arrays: ../sound/soc/kirkwood/kirkwood-dma.c: In function 'kirkwood_dma_conf_mbus_windows.constprop': ../sound/soc/kirkwood/kirkwood-dma.c:90:24: warning: array subscript 0 is outside array bounds of 'const struct mbus_dram_window[0]' [-Warray-bounds=] 90 | if ((cs->base & 0xffff0000) < (dma & 0xffff0000)) { | ~~^~~~~~ Cc: Liam Girdwood <lgirdwood(a)gmail.com> Cc: Mark Brown <broonie(a)kernel.org> Cc: Jaroslav Kysela <perex(a)perex.cz> Cc: Takashi Iwai <tiwai(a)suse.com> Cc: alsa-devel(a)alsa-project.org Signed-off-by: Kees Cook <keescook(a)chromium.org> Link: https://lore.kernel.org/r/20230127224128.never.410-kees@kernel.org Signed-off-by: Mark Brown <broonie(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- sound/soc/kirkwood/kirkwood-dma.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/soc/kirkwood/kirkwood-dma.c b/sound/soc/kirkwood/kirkwood-dma.c index 700a18561a940..640cebd2983e2 100644 --- a/sound/soc/kirkwood/kirkwood-dma.c +++ b/sound/soc/kirkwood/kirkwood-dma.c @@ -86,7 +86,7 @@ kirkwood_dma_conf_mbus_windows(void __iomem *base, int win, /* try to find matching cs for current dma address */ for (i = 0; i < dram->num_cs; i++) { - const struct mbus_dram_window *cs = dram->cs + i; + const struct mbus_dram_window *cs = &dram->cs[i]; if ((cs->base & 0xffff0000) < (dma & 0xffff0000)) { writel(cs->base & 0xffff0000, base + KIRKWOOD_AUDIO_WIN_BASE_REG(win)); -- 2.39.0

1 0

[PATCH AUTOSEL 6.1 33/58] ASoC: soc-compress: Reposition and add pcm_mutex
by Sasha Levin 27 Feb '23

27 Feb '23

From: 강신형 <s47.kang(a)samsung.com> [ Upstream commit aa9ff6a4955fdba02b54fbc4386db876603703b7 ] If panic_on_warn is set and compress stream(DPCM) is started, then kernel panic occurred because card->pcm_mutex isn't held appropriately. In the following functions, warning were issued at this line "snd_soc_dpcm_mutex_assert_held". static int dpcm_be_connect(struct snd_soc_pcm_runtime *fe, struct snd_soc_pcm_runtime *be, int stream) { ... snd_soc_dpcm_mutex_assert_held(fe); ... } void dpcm_be_disconnect(struct snd_soc_pcm_runtime *fe, int stream) { ... snd_soc_dpcm_mutex_assert_held(fe); ... } void snd_soc_runtime_action(struct snd_soc_pcm_runtime *rtd, int stream, int action) { ... snd_soc_dpcm_mutex_assert_held(rtd); ... } int dpcm_dapm_stream_event(struct snd_soc_pcm_runtime *fe, int dir, int event) { ... snd_soc_dpcm_mutex_assert_held(fe); ... } These functions are called by soc_compr_set_params_fe, soc_compr_open_fe and soc_compr_free_fe without pcm_mutex locking. And this is call stack. [ 414.527841][ T2179] pc : dpcm_process_paths+0x5a4/0x750 [ 414.527848][ T2179] lr : dpcm_process_paths+0x37c/0x750 [ 414.527945][ T2179] Call trace: [ 414.527949][ T2179] dpcm_process_paths+0x5a4/0x750 [ 414.527955][ T2179] soc_compr_open_fe+0xb0/0x2cc [ 414.527972][ T2179] snd_compr_open+0x180/0x248 [ 414.527981][ T2179] snd_open+0x15c/0x194 [ 414.528003][ T2179] chrdev_open+0x1b0/0x220 [ 414.528023][ T2179] do_dentry_open+0x30c/0x594 [ 414.528045][ T2179] vfs_open+0x34/0x44 [ 414.528053][ T2179] path_openat+0x914/0xb08 [ 414.528062][ T2179] do_filp_open+0xc0/0x170 [ 414.528068][ T2179] do_sys_openat2+0x94/0x18c [ 414.528076][ T2179] __arm64_sys_openat+0x78/0xa4 [ 414.528084][ T2179] invoke_syscall+0x48/0x10c [ 414.528094][ T2179] el0_svc_common+0xbc/0x104 [ 414.528099][ T2179] do_el0_svc+0x34/0xd8 [ 414.528103][ T2179] el0_svc+0x34/0xc4 [ 414.528125][ T2179] el0t_64_sync_handler+0x8c/0xfc [ 414.528133][ T2179] el0t_64_sync+0x1a0/0x1a4 [ 414.528142][ T2179] Kernel panic - not syncing: panic_on_warn set ... So, I reposition and add pcm_mutex to resolve lockdep error. Signed-off-by: Shinhyung Kang <s47.kang(a)samsung.com> Link: https://lore.kernel.org/r/016401d90ac4$7b6848c0$7238da40$@samsung.com Signed-off-by: Mark Brown <broonie(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- sound/soc/soc-compress.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/sound/soc/soc-compress.c b/sound/soc/soc-compress.c index 870f13e1d389c..7bce5088b4554 100644 --- a/sound/soc/soc-compress.c +++ b/sound/soc/soc-compress.c @@ -149,6 +149,8 @@ static int soc_compr_open_fe(struct snd_compr_stream *cstream) if (ret < 0) goto be_err; + mutex_lock_nested(&fe->card->pcm_mutex, fe->card->pcm_subclass); + /* calculate valid and active FE <-> BE dpcms */ dpcm_process_paths(fe, stream, &list, 1); fe->dpcm[stream].runtime = fe_substream->runtime; @@ -184,7 +186,6 @@ static int soc_compr_open_fe(struct snd_compr_stream *cstream) fe->dpcm[stream].state = SND_SOC_DPCM_STATE_OPEN; fe->dpcm[stream].runtime_update = SND_SOC_DPCM_UPDATE_NO; - mutex_lock_nested(&fe->card->pcm_mutex, fe->card->pcm_subclass); snd_soc_runtime_activate(fe, stream); mutex_unlock(&fe->card->pcm_mutex); @@ -215,7 +216,6 @@ static int soc_compr_free_fe(struct snd_compr_stream *cstream) mutex_lock_nested(&fe->card->pcm_mutex, fe->card->pcm_subclass); snd_soc_runtime_deactivate(fe, stream); - mutex_unlock(&fe->card->pcm_mutex); fe->dpcm[stream].runtime_update = SND_SOC_DPCM_UPDATE_FE; @@ -234,6 +234,8 @@ static int soc_compr_free_fe(struct snd_compr_stream *cstream) dpcm_be_disconnect(fe, stream); + mutex_unlock(&fe->card->pcm_mutex); + fe->dpcm[stream].runtime = NULL; snd_soc_link_compr_shutdown(cstream, 0); @@ -409,8 +411,9 @@ static int soc_compr_set_params_fe(struct snd_compr_stream *cstream, ret = snd_soc_link_compr_set_params(cstream); if (ret < 0) goto out; - + mutex_lock_nested(&fe->card->pcm_mutex, fe->card->pcm_subclass); dpcm_dapm_stream_event(fe, stream, SND_SOC_DAPM_STREAM_START); + mutex_unlock(&fe->card->pcm_mutex); fe->dpcm[stream].state = SND_SOC_DPCM_STATE_PREPARE; out: -- 2.39.0

1 0

[PATCH AUTOSEL 6.2 35/60] ASoC: kirkwood: Iterate over array indexes instead of using pointer math
by Sasha Levin 27 Feb '23

27 Feb '23

From: Kees Cook <keescook(a)chromium.org> [ Upstream commit b3bcedc0402fcdc5c8624c433562d9d1882749d8 ] Walking the dram->cs array was seen as accesses beyond the first array item by the compiler. Instead, use the array index directly. This allows for run-time bounds checking under CONFIG_UBSAN_BOUNDS as well. Seen with GCC 13 with -fstrict-flex-arrays: ../sound/soc/kirkwood/kirkwood-dma.c: In function 'kirkwood_dma_conf_mbus_windows.constprop': ../sound/soc/kirkwood/kirkwood-dma.c:90:24: warning: array subscript 0 is outside array bounds of 'const struct mbus_dram_window[0]' [-Warray-bounds=] 90 | if ((cs->base & 0xffff0000) < (dma & 0xffff0000)) { | ~~^~~~~~ Cc: Liam Girdwood <lgirdwood(a)gmail.com> Cc: Mark Brown <broonie(a)kernel.org> Cc: Jaroslav Kysela <perex(a)perex.cz> Cc: Takashi Iwai <tiwai(a)suse.com> Cc: alsa-devel(a)alsa-project.org Signed-off-by: Kees Cook <keescook(a)chromium.org> Link: https://lore.kernel.org/r/20230127224128.never.410-kees@kernel.org Signed-off-by: Mark Brown <broonie(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- sound/soc/kirkwood/kirkwood-dma.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/soc/kirkwood/kirkwood-dma.c b/sound/soc/kirkwood/kirkwood-dma.c index 700a18561a940..640cebd2983e2 100644 --- a/sound/soc/kirkwood/kirkwood-dma.c +++ b/sound/soc/kirkwood/kirkwood-dma.c @@ -86,7 +86,7 @@ kirkwood_dma_conf_mbus_windows(void __iomem *base, int win, /* try to find matching cs for current dma address */ for (i = 0; i < dram->num_cs; i++) { - const struct mbus_dram_window *cs = dram->cs + i; + const struct mbus_dram_window *cs = &dram->cs[i]; if ((cs->base & 0xffff0000) < (dma & 0xffff0000)) { writel(cs->base & 0xffff0000, base + KIRKWOOD_AUDIO_WIN_BASE_REG(win)); -- 2.39.0

1 0

[PATCH AUTOSEL 6.2 34/60] ASoC: soc-compress: Reposition and add pcm_mutex
by Sasha Levin 27 Feb '23

27 Feb '23

From: 강신형 <s47.kang(a)samsung.com> [ Upstream commit aa9ff6a4955fdba02b54fbc4386db876603703b7 ] If panic_on_warn is set and compress stream(DPCM) is started, then kernel panic occurred because card->pcm_mutex isn't held appropriately. In the following functions, warning were issued at this line "snd_soc_dpcm_mutex_assert_held". static int dpcm_be_connect(struct snd_soc_pcm_runtime *fe, struct snd_soc_pcm_runtime *be, int stream) { ... snd_soc_dpcm_mutex_assert_held(fe); ... } void dpcm_be_disconnect(struct snd_soc_pcm_runtime *fe, int stream) { ... snd_soc_dpcm_mutex_assert_held(fe); ... } void snd_soc_runtime_action(struct snd_soc_pcm_runtime *rtd, int stream, int action) { ... snd_soc_dpcm_mutex_assert_held(rtd); ... } int dpcm_dapm_stream_event(struct snd_soc_pcm_runtime *fe, int dir, int event) { ... snd_soc_dpcm_mutex_assert_held(fe); ... } These functions are called by soc_compr_set_params_fe, soc_compr_open_fe and soc_compr_free_fe without pcm_mutex locking. And this is call stack. [ 414.527841][ T2179] pc : dpcm_process_paths+0x5a4/0x750 [ 414.527848][ T2179] lr : dpcm_process_paths+0x37c/0x750 [ 414.527945][ T2179] Call trace: [ 414.527949][ T2179] dpcm_process_paths+0x5a4/0x750 [ 414.527955][ T2179] soc_compr_open_fe+0xb0/0x2cc [ 414.527972][ T2179] snd_compr_open+0x180/0x248 [ 414.527981][ T2179] snd_open+0x15c/0x194 [ 414.528003][ T2179] chrdev_open+0x1b0/0x220 [ 414.528023][ T2179] do_dentry_open+0x30c/0x594 [ 414.528045][ T2179] vfs_open+0x34/0x44 [ 414.528053][ T2179] path_openat+0x914/0xb08 [ 414.528062][ T2179] do_filp_open+0xc0/0x170 [ 414.528068][ T2179] do_sys_openat2+0x94/0x18c [ 414.528076][ T2179] __arm64_sys_openat+0x78/0xa4 [ 414.528084][ T2179] invoke_syscall+0x48/0x10c [ 414.528094][ T2179] el0_svc_common+0xbc/0x104 [ 414.528099][ T2179] do_el0_svc+0x34/0xd8 [ 414.528103][ T2179] el0_svc+0x34/0xc4 [ 414.528125][ T2179] el0t_64_sync_handler+0x8c/0xfc [ 414.528133][ T2179] el0t_64_sync+0x1a0/0x1a4 [ 414.528142][ T2179] Kernel panic - not syncing: panic_on_warn set ... So, I reposition and add pcm_mutex to resolve lockdep error. Signed-off-by: Shinhyung Kang <s47.kang(a)samsung.com> Link: https://lore.kernel.org/r/016401d90ac4$7b6848c0$7238da40$@samsung.com Signed-off-by: Mark Brown <broonie(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- sound/soc/soc-compress.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/sound/soc/soc-compress.c b/sound/soc/soc-compress.c index 870f13e1d389c..7bce5088b4554 100644 --- a/sound/soc/soc-compress.c +++ b/sound/soc/soc-compress.c @@ -149,6 +149,8 @@ static int soc_compr_open_fe(struct snd_compr_stream *cstream) if (ret < 0) goto be_err; + mutex_lock_nested(&fe->card->pcm_mutex, fe->card->pcm_subclass); + /* calculate valid and active FE <-> BE dpcms */ dpcm_process_paths(fe, stream, &list, 1); fe->dpcm[stream].runtime = fe_substream->runtime; @@ -184,7 +186,6 @@ static int soc_compr_open_fe(struct snd_compr_stream *cstream) fe->dpcm[stream].state = SND_SOC_DPCM_STATE_OPEN; fe->dpcm[stream].runtime_update = SND_SOC_DPCM_UPDATE_NO; - mutex_lock_nested(&fe->card->pcm_mutex, fe->card->pcm_subclass); snd_soc_runtime_activate(fe, stream); mutex_unlock(&fe->card->pcm_mutex); @@ -215,7 +216,6 @@ static int soc_compr_free_fe(struct snd_compr_stream *cstream) mutex_lock_nested(&fe->card->pcm_mutex, fe->card->pcm_subclass); snd_soc_runtime_deactivate(fe, stream); - mutex_unlock(&fe->card->pcm_mutex); fe->dpcm[stream].runtime_update = SND_SOC_DPCM_UPDATE_FE; @@ -234,6 +234,8 @@ static int soc_compr_free_fe(struct snd_compr_stream *cstream) dpcm_be_disconnect(fe, stream); + mutex_unlock(&fe->card->pcm_mutex); + fe->dpcm[stream].runtime = NULL; snd_soc_link_compr_shutdown(cstream, 0); @@ -409,8 +411,9 @@ static int soc_compr_set_params_fe(struct snd_compr_stream *cstream, ret = snd_soc_link_compr_set_params(cstream); if (ret < 0) goto out; - + mutex_lock_nested(&fe->card->pcm_mutex, fe->card->pcm_subclass); dpcm_dapm_stream_event(fe, stream, SND_SOC_DAPM_STREAM_START); + mutex_unlock(&fe->card->pcm_mutex); fe->dpcm[stream].state = SND_SOC_DPCM_STATE_PREPARE; out: -- 2.39.0

1 0

Alsamixer not detecting headphones
by GitHub issues - opened 27 Feb '23

27 Feb '23

alsa-project/alsa-ucm-conf issue #283 was opened from lgmventura: I'm using the motherboard ASUS ROG Strix B760-f Gaming Wifi, which has 7.1 audio channels on the back side and connectors for an audio panel at the front of the case - a microphone and a headphones jack. When I plug my headphones into the front channels connector (at the back of the PC case) there is normal sound. When I plug it into the headphones jack (at the front of the case), it gets automatically detected by `pavucontrol`, which switches to the headphones as output, as it should be: ![image](https://user-images.githubusercontent.com/16710238/221439991-903fd90b-43b2-41a0-af7f-1ed02085238e.png) However, there is no sound. When I open `alsamixer` and choose the respective soundcard, which is weirdly called "USB audio" there, I see no volume control for the headphones, as there should be. All it shows is this: ![image](https://user-images.githubusercontent.com/16710238/221440193-381eadfb-fed9-48ad-807b-05c736b65b24.png) The only way I got to get audio output from the headphones jack is by running `aplay` and choosing the hardware directly from there `aplay -D plughw:1,1 /usr/share/sounds/alsa/Front_Center.wav` or on Audacity by selecting "USB Audio 1: (hw:1,1)" as playback device. I also tried to use JACK Audio Connection Kit, but found no configuration there that routes the audio to the headphones jack, even trying all 4 possible analogue outputs. System: - Motherboard ASUS ROG Strix B760-f Gaming Wifi - Intel core i7-13700K - Ubuntu 22.04 (freshly installed) Issue URL : https://github.com/alsa-project/alsa-ucm-conf/issues/283 Repository URL: https://github.com/alsa-project/alsa-ucm-conf

1 0

Alsamixer not detecting headphones
by GitHub issues - edited 27 Feb '23

27 Feb '23

alsa-project/alsa-ucm-conf issue #283 was edited from lgmventura: I'm using the motherboard ASUS ROG Strix B760-f Gaming Wifi, which has 7.1 audio channels on the back side and connectors for an audio panel at the front of the case - a microphone and a headphones jack. When I plug my headphones into the front channels connector (at the back of the PC case) there is normal sound. When I plug it into the headphones jack (at the front of the case), it gets automatically detected by `pavucontrol`, which switches to the headphones as output, as it should be: ![image](https://user-images.githubusercontent.com/16710238/221439991-903fd90b-43b2-41a0-af7f-1ed02085238e.png) However, there is no sound. When I open `alsamixer` and choose the respective soundcard, which is weirdly called "USB audio" there, I see no volume control for the headphones, as there should be. All it shows is this: ![image](https://user-images.githubusercontent.com/16710238/221440193-381eadfb-fed9-48ad-807b-05c736b65b24.png) The only way I got to get audio output from the headphones jack is by running `aplay` and choosing the hardware directly from there `aplay -D plughw:1,1 /usr/share/sounds/alsa/Front_Center.wav` or on Audacity by selecting "USB Audio 1: (hw:1,1)" as playback device. I also tried to use JACK Audio Connection Kit, but found no configuration there that routes the audio to the headphones jack, even trying all 4 possible analogue outputs. System: - Motherboard ASUS ROG Strix B760-f Gaming Wifi - Intel core i7-13700K - Ubuntu 22.04 (freshly installed) Issue URL : https://github.com/alsa-project/alsa-ucm-conf/issues/283 Repository URL: https://github.com/alsa-project/alsa-ucm-conf

1 0

Alsamixer not detecting headphones
by GitHub issues - opened 27 Feb '23

27 Feb '23

alsa-project/alsa-lib issue #304 was opened from lgmventura: I'm using the motherboard ASUS ROG Strix B760-f Gaming Wifi, which has 7.1 audio channels on the back side and connectors for an audio panel at the front of the case - a microphone and a headphones jack. When I plug my headphones into the front channels connector (at the back of the PC case) there is normal sound. When I plug it into the headphones jack (at the front of the case), it gets automatically detected by `pavucontrol`, which switches to the headphones as output, as it should be: ![image](https://user-images.githubusercontent.com/16710238/221439991-903fd90b-43b2-41a0-af7f-1ed02085238e.png) However, there is no sound. When I open `alsamixer` and choose the respective soundcard, which is weirdly called "USB audio" there, I see no volume control for the headphones, as there should be. All it shows is this: ![image](https://user-images.githubusercontent.com/16710238/221440193-381eadfb-fed9-48ad-807b-05c736b65b24.png) The only way I got to get audio output from the headphones jack is by running `aplay` and choosing the hardware directly from there `aplay -D plughw:1,1 /usr/share/sounds/alsa/Front_Center.wav` or on Audacity by selecting "USB Audio 1: (hw:1,1)" as playback device. I also tried to use JACK Audio Connection Kit, but found no configuration there that routes the audio to the headphones jack, even trying all 4 possible analogue outputs. System: - Motherboard ASUS ROG Strix B760-f Gaming Wifi - Intel core i7-13700K - Ubuntu 22.04 (freshly installed) Issue URL : https://github.com/alsa-project/alsa-lib/issues/304 Repository URL: https://github.com/alsa-project/alsa-lib

1 0

infinite loop in src/pcm/pcm_params.c function snd_pcm_sw_params_default()
by bumpelo＠gmail.com 25 Feb '23

25 Feb '23

I found this infinite loop while playing with the test/latency.c function. When I specify too small of a minimum latency (in my case -m 256 or smaller) it winds up: at line line 2337: params->boundary = pcm->buffer_size; while (params->boundary * 2 <= LONG_MAX - pcm->buffer_size) params->boundary *= 2; return 0; but when pcm->buffer_size is zero this is an infinite loop. It does this *after* setting the scheduling to round-robin which makes the infinite loop so much more painful. The return value from this function is ignored where it's called so I'm not sure what the best fix is. I'm guessing it's a rare case since it's not been previously reported but it deserves fixing anyway.

2 1