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

[PATCH][next] ASoC: SOF: ipc4/intel: Fix spelling mistake "schduler" -> "scheduler"
by Colin Ian King 23 Mar '23

23 Mar '23

There are two spelling mistakes in dev_warn messages. Fix them. Signed-off-by: Colin Ian King <colin.i.king(a)gmail.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 12775fcb6b54..de7213237b27 100644 --- a/sound/soc/sof/ipc4-topology.c +++ b/sound/soc/sof/ipc4-topology.c @@ -1990,7 +1990,7 @@ static int sof_ipc4_widget_setup(struct snd_sof_dev *sdev, struct snd_sof_widget pipeline = swidget->private; if (pipeline->use_chain_dma) { - dev_warn(sdev->dev, "use_chain_dma set for schduler %s", + dev_warn(sdev->dev, "use_chain_dma set for scheduler %s", swidget->widget->name); return 0; } @@ -2149,7 +2149,7 @@ static int sof_ipc4_widget_free(struct snd_sof_dev *sdev, struct snd_sof_widget u32 header; if (pipeline->use_chain_dma) { - dev_warn(sdev->dev, "use_chain_dma set for schduler %s", + dev_warn(sdev->dev, "use_chain_dma set for scheduler %s", swidget->widget->name); mutex_unlock(&ipc4_data->pipeline_state_mutex); return 0; -- 2.30.2

2 1

Re: [PATCH 3/4] ASoC: amd: acp: Add machine driver that enables sound for systems with a ES8336 codec
by 沈一超 23 Mar '23

23 Mar '23

> > Regarding playing the speaker and headphone simultaneously, is not > > something I took into account. Is this even a valid usecase? The intel driver > > for es8336 doesn't seem to support it. > > Yes, for example consider a critical notification - the system > may wish to ensure it is audible even if the user has taken off > their headphones for some reason. In practice the speaker and the headphone are conflicting devices, see https://github.com/alsa-project/alsa-ucm-conf/blob/master/ucm2/Intel/sof-es… There is no such situation, and the system doesn't produce sound from speaker when headphones are plugged in. The user may manually open speaker using amixer sset 'Speaker' on or pavucontrol. The GPIO thing on Huawei Intel platform is too complicated, they use two GPIOs for headphone and speaker, and the headphone GPIO is inverted, which means low means on and high means off. Luckily there should be only one hardware config for the AMD acp3x platform GPIO and you may just choose the correct one.

2 1

[PATCH v2] ASoC: SOF: ipc4-control: Return on error in sof_ipc4_widget_kcontrol_setup()
by Peter Ujfalusi 23 Mar '23

23 Mar '23

The patch adding the bytes control support moved the error check outside of the list_for_each_entry() which was not correct as at the end of the list_for_each_entry() the scontrol will no longer point where the error happened, but it to the list head. Restore the original logic and return on the first error with the error code. Fixes: a062c8899fed ("ASoC: SOF: ipc4-control: Add support for bytes control get and put") Reported-by: Dan Carpenter <error27(a)gmail.com> Link: https://lore.kernel.org/alsa-devel/6be945d2-40cb-46fb-67ba-ed3a19cddfa4@lin… Signed-off-by: Peter Ujfalusi <peter.ujfalusi(a)linux.intel.com> --- sound/soc/sof/ipc4-control.c | 13 ++++++++----- 1 file changed, 8 insertions(+), 5 deletions(-) diff --git a/sound/soc/sof/ipc4-control.c b/sound/soc/sof/ipc4-control.c index d26ed2a6029f..6f0698be9451 100644 --- a/sound/soc/sof/ipc4-control.c +++ b/sound/soc/sof/ipc4-control.c @@ -429,14 +429,17 @@ static int sof_ipc4_widget_kcontrol_setup(struct snd_sof_dev *sdev, struct snd_s default: break; } + + if (ret < 0) { + dev_err(sdev->dev, + "kcontrol %d set up failed for widget %s\n", + scontrol->comp_id, swidget->widget->name); + return ret; + } } } - if (ret < 0) - dev_err(sdev->dev, "kcontrol %d set up failed for widget %s\n", - scontrol->comp_id, swidget->widget->name); - - return ret; + return 0; } static int -- 2.40.0

3 2

[PATCH] ASoC: SOF: ipc4-control: Return on error in sof_ipc4_widget_kcontrol_setup()
by Peter Ujfalusi 23 Mar '23

23 Mar '23

The patch adding the bytes control support moved the error check outside of the list_for_each_entry() which will cause issues when we will have support for multiple controls per widgets. Restore the original logic and return on the first error with the error code. Fixes: a062c8899fed ("ASoC: SOF: ipc4-control: Add support for bytes control get and put") Reported-by: Dan Carpenter <error27(a)gmail.com> Link: https://lore.kernel.org/alsa-devel/6be945d2-40cb-46fb-67ba-ed3a19cddfa4@lin… Signed-off-by: Peter Ujfalusi <peter.ujfalusi(a)linux.intel.com> --- sound/soc/sof/ipc4-control.c | 13 ++++++++----- 1 file changed, 8 insertions(+), 5 deletions(-) diff --git a/sound/soc/sof/ipc4-control.c b/sound/soc/sof/ipc4-control.c index d26ed2a6029f..6f0698be9451 100644 --- a/sound/soc/sof/ipc4-control.c +++ b/sound/soc/sof/ipc4-control.c @@ -429,14 +429,17 @@ static int sof_ipc4_widget_kcontrol_setup(struct snd_sof_dev *sdev, struct snd_s default: break; } + + if (ret < 0) { + dev_err(sdev->dev, + "kcontrol %d set up failed for widget %s\n", + scontrol->comp_id, swidget->widget->name); + return ret; + } } } - if (ret < 0) - dev_err(sdev->dev, "kcontrol %d set up failed for widget %s\n", - scontrol->comp_id, swidget->widget->name); - - return ret; + return 0; } static int -- 2.40.0

3 6

[PATCH 0/3] ASoC: SOF: ipc4/intel: Support for ChainDMA
by Peter Ujfalusi 23 Mar '23

23 Mar '23

Hi, On a platform when the DSP is in use, we cannot select individual links to use or not use the DSP, it is either all or none. On some audio endpoint, like HDMI/DP, it is preferred to not use any processing in DSP to reduce the latency and to allow bytestream pass-through (DTS, DD, etc) IPC4 introduces a new type of end-to-end connection within the DSP which is using the host DMA and link DMA in a single buffer, working back-to-back, passing the received data without looking at it or trying to understand the format, content. This mode reduces the latency and allows non PCM streams to be sent from userspace. The feature is enabled per PCM bases, signalled in topology. Regards, Peter --- Jyri Sarha (2): ASoC: SOF: ipc4: Add macros for chain-dma message bits ASoC: SOF: ipc4/intel: Add support for chained DMA Ranjani Sridharan (1): ASoC: SOF: topology: Set pipeline widget before updating IPC structures include/sound/sof/ipc4/header.h | 29 +++++++ include/uapi/sound/sof/tokens.h | 1 + sound/soc/sof/intel/hda-dai-ops.c | 18 ++++- sound/soc/sof/ipc4-pcm.c | 122 +++++++++++++++++++++++++++++- sound/soc/sof/ipc4-topology.c | 120 ++++++++++++++++++++++++++++- sound/soc/sof/ipc4-topology.h | 2 + sound/soc/sof/topology.c | 48 ++++++------ 7 files changed, 308 insertions(+), 32 deletions(-) -- 2.40.0

2 6

[PATCH] ALSA: usb-audio: Fix recursive locking at XRUN during syncing
by Takashi Iwai 23 Mar '23

23 Mar '23

The recent support of low latency playback in USB-audio driver made the snd_usb_queue_pending_output_urbs() function to be called via PCM ack ops. In the new code path, the function is performed alread in the PCM stream lock. The problem is that, when an XRUN is detected, the function calls snd_pcm_xrun() to notify, but snd_pcm_xrun() is supposed to be called only outside the stream lock. As a result, it leads to a deadlock of PCM stream locking. For avoiding such a recursive locking, this patch adds an additional check to the code paths in PCM core that call the ack callback; now it checks the error code from the callback, and if it's -EPIPE, the XRUN is handled in the PCM core side gracefully. Along with it, the USB-audio driver code is changed to follow that, i.e. -EPIPE is returned instead of the explicit snd_pcm_xrun() call when the function is performed already in the stream lock. Fixes: d5f871f89e21 ("ALSA: usb-audio: Improved lowlatency playback support") Reported-and-tested-by: John Keeping <john(a)metanate.com> Link: https://lore.kernel.org/r/20230317195128.3911155-1-john@metanate.com Cc: Takashi Sakamoto <o-takashi(a)sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai(a)suse.de> --- sound/core/pcm_lib.c | 2 ++ sound/usb/endpoint.c | 22 ++++++++++++++-------- sound/usb/endpoint.h | 4 ++-- sound/usb/pcm.c | 2 +- 4 files changed, 19 insertions(+), 11 deletions(-) diff --git a/sound/core/pcm_lib.c b/sound/core/pcm_lib.c index 8b6aeb8a78f7..02fd65993e7e 100644 --- a/sound/core/pcm_lib.c +++ b/sound/core/pcm_lib.c @@ -2155,6 +2155,8 @@ int pcm_lib_apply_appl_ptr(struct snd_pcm_substream *substream, ret = substream->ops->ack(substream); if (ret < 0) { runtime->control->appl_ptr = old_appl_ptr; + if (ret == -EPIPE) + __snd_pcm_xrun(substream); return ret; } } diff --git a/sound/usb/endpoint.c b/sound/usb/endpoint.c index 419302e2057e..647fa054d8b1 100644 --- a/sound/usb/endpoint.c +++ b/sound/usb/endpoint.c @@ -455,8 +455,8 @@ static void push_back_to_ready_list(struct snd_usb_endpoint *ep, * This function is used both for implicit feedback endpoints and in low- * latency playback mode. */ -void snd_usb_queue_pending_output_urbs(struct snd_usb_endpoint *ep, - bool in_stream_lock) +int snd_usb_queue_pending_output_urbs(struct snd_usb_endpoint *ep, + bool in_stream_lock) { bool implicit_fb = snd_usb_endpoint_implicit_feedback_sink(ep); @@ -480,7 +480,7 @@ void snd_usb_queue_pending_output_urbs(struct snd_usb_endpoint *ep, spin_unlock_irqrestore(&ep->lock, flags); if (ctx == NULL) - return; + break; /* copy over the length information */ if (implicit_fb) { @@ -495,11 +495,14 @@ void snd_usb_queue_pending_output_urbs(struct snd_usb_endpoint *ep, break; if (err < 0) { /* push back to ready list again for -EAGAIN */ - if (err == -EAGAIN) + if (err == -EAGAIN) { push_back_to_ready_list(ep, ctx); - else + break; + } + + if (!in_stream_lock) notify_xrun(ep); - return; + return -EPIPE; } err = usb_submit_urb(ctx->urb, GFP_ATOMIC); @@ -507,13 +510,16 @@ void snd_usb_queue_pending_output_urbs(struct snd_usb_endpoint *ep, usb_audio_err(ep->chip, "Unable to submit urb #%d: %d at %s\n", ctx->index, err, __func__); - notify_xrun(ep); - return; + if (!in_stream_lock) + notify_xrun(ep); + return -EPIPE; } set_bit(ctx->index, &ep->active_mask); atomic_inc(&ep->submitted_urbs); } + + return 0; } /* diff --git a/sound/usb/endpoint.h b/sound/usb/endpoint.h index 924f4351588c..c09f68ce08b1 100644 --- a/sound/usb/endpoint.h +++ b/sound/usb/endpoint.h @@ -52,7 +52,7 @@ int snd_usb_endpoint_implicit_feedback_sink(struct snd_usb_endpoint *ep); int snd_usb_endpoint_next_packet_size(struct snd_usb_endpoint *ep, struct snd_urb_ctx *ctx, int idx, unsigned int avail); -void snd_usb_queue_pending_output_urbs(struct snd_usb_endpoint *ep, - bool in_stream_lock); +int snd_usb_queue_pending_output_urbs(struct snd_usb_endpoint *ep, + bool in_stream_lock); #endif /* __USBAUDIO_ENDPOINT_H */ diff --git a/sound/usb/pcm.c b/sound/usb/pcm.c index d959da7a1afb..eec5232f9fb2 100644 --- a/sound/usb/pcm.c +++ b/sound/usb/pcm.c @@ -1639,7 +1639,7 @@ static int snd_usb_pcm_playback_ack(struct snd_pcm_substream *substream) * outputs here */ if (!ep->active_mask) - snd_usb_queue_pending_output_urbs(ep, true); + return snd_usb_queue_pending_output_urbs(ep, true); return 0; } -- 2.35.3

3 6

ALC4082 - Asus Crosshair x670E Hero
by GitHub issues - edited 23 Mar '23

23 Mar '23

alsa-project/alsa-ucm-conf issue #295 was edited from nitin88: Hi, I am using frontend Mic and Output of x670E Hero board. Issues: 1. The mic volume is too low that I have to literally shout to record something. 2. Attached screenshot of Alsamixer (set everything to high) ![image](https://user-images.githubusercontent.com/4945664/227216525-095810ad-273c-4941-b881-b3b2467cdd86.png) 3. Copied latest master configurations Was closely following this thread https://github.com/alsa-project/alsa-ucm-conf/issues/229 as this board uses same ALC4082 but from Asrock I can help you debug/test every possible configuration with this board, any help to fix "sound recording" is appreciated. Attaching the `alsaucm -c hw:Audio dump text` [dump.txt](https://github.com/alsa-project/alsa-ucm-conf/files/11051278/dump… Issue URL : https://github.com/alsa-project/alsa-ucm-conf/issues/295 Repository URL: https://github.com/alsa-project/alsa-ucm-conf

1 0

ALC4082 - Asus Crosshair x670E Hero
by GitHub issues - opened 23 Mar '23

23 Mar '23

alsa-project/alsa-ucm-conf issue #295 was opened from nitin88: Hi, I am using frontend Mic and Output of x670E Hero board. Issues: 1. The mic volume is too low that I have to literally shout to record something. 2. Attached screenshot of Alsamixer (set everything to high) ![image](https://user-images.githubusercontent.com/4945664/227216525-095810ad-273c-4941-b881-b3b2467cdd86.png) 3. Copied latest master configurations Was closely following this thread https://github.com/alsa-project/alsa-ucm-conf/issues/229 as this board uses same ALC4082 but from Asrock I can help you debug/test every possible configuration with this board, any help to fix "sound recording" is appreciated. Issue URL : https://github.com/alsa-project/alsa-ucm-conf/issues/295 Repository URL: https://github.com/alsa-project/alsa-ucm-conf

1 0

Re: [REGRESSION] kbl-r5514-5663-max hdmi no longer working
by Linux regression tracking (Thorsten Leemhuis) 23 Mar '23

23 Mar '23

[adding a push of people and lists to the recipients that dealt with the culprit; leaving the stable list in CC for now, even if this is a mainline issue (apart from the backport of the culprit to 5.10.y Takashi asked for a while ago)] On 13.03.23 17:34, Jason Montleon wrote: > It looks like HDMI audio stopped working in 5.17-rc1. I ran a bisect > which points to 636110411ca726f19ef8e87b0be51bb9a4cdef06. FWIW, that's "ASoC: Intel/SOF: use set_stream() instead of set_tdm_slots() for HDAudio" from Pierre-Louis Bossart. > I built > 5.17.14 with it reverted and it restored HDMI output, but it doesn't > revert cleanly from 5.18 onward. > >>From what I can tell it looks like -ENOTSUPP is returned from > snd_soc_dai_set_stream for hdmi1 and hdmi2 now. I'm not sure if that's > expected, but I made the following change and I have working HDMI > audio now. https://gist.github.com/jmontleon/4780154c309f956d97ca9a304a00da3f Thanks for the report and the patch. I CCed the relevant people for this. [TLDR For the rest of the mail: : I'm adding this report to the list of tracked Linux kernel regressions; the text you find below is based on a few templates paragraphs you might have encountered already in similar form. See link in footer if these mails annoy you.] To be sure the issue doesn't fall through the cracks unnoticed, I'm adding it to regzbot, the Linux kernel regression tracking bot: #regzbot ^introduced 636110411ca726f19ef8e87b0be51bb9a4cdef06 #regzbot title alsa/asoc: kbl-r5514-5663-max hdmi stopped working #regzbot ignore-activity This isn't a regression? This issue or a fix for it are already discussed somewhere else? It was fixed already? You want to clarify when the regression started to happen? Or point out I got the title or something else totally wrong? Then just reply and tell me -- ideally while also telling regzbot about it, as explained by the page listed in the footer of this mail. Developers: When fixing the issue, remember to add 'Link:' tags pointing to the report (the parent of this mail). See page linked in footer for details. Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat) -- Everything you wanna know about Linux kernel regression tracking: https://linux-regtracking.leemhuis.info/about/#tldr That page also explains what to do if mails like this annoy you.

2 1

ucm2: codecs: va-macro: fix dmic1 mux setting
by GitHub pull_request - opened 23 Mar '23

23 Mar '23

alsa-project/alsa-ucm-conf pull request #294 was opened from Srinivas-Kandagatla: Looks like there was a typo in setting up dmic1 mux. Without this dmic01 selection would only do single channel record instead of 2 channel recording. Request URL : https://github.com/alsa-project/alsa-ucm-conf/pull/294 Patch URL : https://github.com/alsa-project/alsa-ucm-conf/pull/294.patch Repository URL: https://github.com/alsa-project/alsa-ucm-conf

1 0