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

[PATCH -next] ALSA: seq: oss: remove unused inline function snd_seq_oss_timer_is_realtime
by YueHaibing 29 Apr '20

29 Apr '20

There's no callers in-tree. Signed-off-by: YueHaibing <yuehaibing(a)huawei.com> --- sound/core/seq/oss/seq_oss_timer.h | 10 ---------- 1 file changed, 10 deletions(-) diff --git a/sound/core/seq/oss/seq_oss_timer.h b/sound/core/seq/oss/seq_oss_timer.h index 2d86125b5d0f..dee190b4ec6b 100644 --- a/sound/core/seq/oss/seq_oss_timer.h +++ b/sound/core/seq/oss/seq_oss_timer.h @@ -44,14 +44,4 @@ snd_seq_oss_timer_cur_tick(struct seq_oss_timer *timer) return timer->cur_tick; } - -/* - * is realtime event? - */ -static inline int -snd_seq_oss_timer_is_realtime(struct seq_oss_timer *timer) -{ - return timer->realtime; -} - #endif -- 2.17.1

2 1

[RFT PATCH 0/7] Add Allwinner H3/H5/A64 HDMI audio
by Clément Péron 29 Apr '20

29 Apr '20

Hi, This is some work done by Marcus Cooper and Jernej Škrabec. These patches are present in LibreElec kernel and have been tested by LE users. I have rework them to follow kernel rules but I can't test them as I don't have H3, H5 or A64 boards. If some sunxi users could confirm they worked as expected! This serie goes in top off "Add H6 I2S support"[0]. You can find a branch for testing here[1]. Thanks, Clement 0: https://lwn.net/Articles/817914/ 1: https://github.com/clementperon/linux/tree/allwinner_hdmi Marcus Cooper (7): arm: dts: sunxi: h3/h5: Add DAI node for HDMI arm: dts: sunxi: h3/h5: Add HDMI audio arm64: dts: allwinner: a64: Add DAI node for HDMI arm64: dts: allwinner: a64: Add HDMI audio arm: sun8i: h3: Add HDMI audio to Orange Pi 2 arm: sun8i: h3: Add HDMI audio to Beelink X2 arm64: dts: allwinner: a64: Add HDMI audio to Pine64 arch/arm/boot/dts/sun8i-h3-beelink-x2.dts | 8 +++++ arch/arm/boot/dts/sun8i-h3-orangepi-2.dts | 8 +++++ arch/arm/boot/dts/sunxi-h3-h5.dtsi | 34 ++++++++++++++++++ .../boot/dts/allwinner/sun50i-a64-pine64.dts | 8 +++++ arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 35 +++++++++++++++++++ 5 files changed, 93 insertions(+) -- 2.20.1

7 24

underrun problems after setting parameters with snd_pcm_set_params()
by robert rozee 29 Apr '20

29 Apr '20

hi, i'm having some problems using ALSA to stream simple sounds on one particular netbook running EasyOS, a cut-down 64-bit linux distro that is rather slow. the problem only occurs with SHORT sound clips. i found that clips longer than 1111ms played without flaw. clips less that 500ms generally failed to play to the end, but there was no error code returned. clips between 501ms and 1111ms generated the error message: "ALSA lib pcm.c:8424:(snd_pcm_recover) underrun occurred". my buffer size is equivalent to 500ms. the code essentially does the following: ----------------------------------------------------------------- snd_pcm_open(@handle, "default" , SND_PCM_STREAM_PLAYBACK, 0); snd_pcm_set_params(handle, SND_PCM_FORMAT_U8, SND_PCM_ACCESS_RW_INTERLEAVED, 1, // number of channels 48000, // bitrate (bps) 1, // resampling on/off min(500000, sample_length)); // latency while (frames_left_to_write>0) { // // CODE IN HERE TO: refill buffer, and set frames_to_write_now appropriately // // send out current buffer content frames=snd_pcm_writei(handle, @buffer, frames_to_write_now); if frames<0 then frames=snd_pcm_recover(handle, frames, 0); if frames<0 then break; } ----------------------------------------------------------------- ******************************************************************************** the problem, as far as i can tell, is with snd_pcm_writei() failing to play the portion of the sound clip in the buffer, but returning NO error code. the error -EFILE is only generated on the attempt to write a SECOND buffer load. the sound sample i'm using is a 440Hz sine wave tone, amplitude of +/-100, centred around 128. ends are feathered in/out, so any short playback is very obvious. after doing a bit of a search on similar problems, i'd like to speculate that snd_pcm_set_params() is choosing an inappropriate small period size. for low-end computers this is causing the underrun issue. if snd_pcm_set_params() is used for configuration, is there any way to change the period size after the call? can it be set between opening the handle and setting the other parameters? cheers, rob :-)

2 2

[PATCH v2] soc: imx8m: Make imx8m_dsp_ops static
by ChenTao 29 Apr '20

29 Apr '20

Fix the following warning: sound/soc/sof/imx/imx8m.c:95:20: warning: symbol 'imx8m_dsp_ops' was not declared. Should it be static? Reported-by: Hulk Robot <hulkci(a)huawei.com> Signed-off-by: ChenTao <chentao107(a)huawei.com> Acked-by: Kai Vehmanen <kai.vehmanen(a)linux.intel.com> Reviewed-by: Daniel Baluta <daniel.baluta(a)nxp.com> --- v1->v2: - add recipient broonie(a)kernel.org alsa-devel(a)alsa-project.org sound/soc/sof/imx/imx8m.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/soc/sof/imx/imx8m.c b/sound/soc/sof/imx/imx8m.c index 07451ba4efae..1a5b0f9ebac1 100644 --- a/sound/soc/sof/imx/imx8m.c +++ b/sound/soc/sof/imx/imx8m.c @@ -92,7 +92,7 @@ static void imx8m_dsp_handle_request(struct imx_dsp_ipc *ipc) snd_sof_ipc_msgs_rx(priv->sdev); } -struct imx_dsp_ops imx8m_dsp_ops = { +static struct imx_dsp_ops imx8m_dsp_ops = { .handle_reply = imx8m_dsp_handle_reply, .handle_request = imx8m_dsp_handle_request, }; -- 2.22.0

1 0

[PATCH v2 0/3] add channel constraint for BDW machine drivers
by Brent Lu 28 Apr '20

28 Apr '20

The machine driver bdw-rt5650 (for Google buddy) supports 2 or 4-channel recording while other two drivers support only 2-channel recording. HW constraints are implemented to reflect the hardware limitation on BDW platform. Changes since v1: - Change the patch title. - Remove the DUAL_CHANNEL and QUAD_CHANNEL macros which are too obvious. - Follow the naming convertion, using 'bdw_rt5650_' and 'bdw_rt5677_' to name startup functions. - Refine the comments in startup functions. - Redesign the bdw_rt5650_fe_startup() function for readability. - Add an assignment to initialize runtime->hw.channels_max variable. Brent Lu (3): ASoC: bdw-rt5677: add channel constraint ASoC: bdw-rt5650: add channel constraint ASoC: broadwell: add channel constraint sound/soc/intel/boards/bdw-rt5650.c | 29 +++++++++++++++++++++++++++++ sound/soc/intel/boards/bdw-rt5677.c | 26 ++++++++++++++++++++++++++ sound/soc/intel/boards/broadwell.c | 26 ++++++++++++++++++++++++++ 3 files changed, 81 insertions(+) -- 2.7.4

4 6

[PATCH -next] ASoC: tegra: tegra_wm8903: Use devm_snd_soc_register_card()
by Wei Yongjun 28 Apr '20

28 Apr '20

Using devm_snd_soc_register_card() can make the code shorter and cleaner. Signed-off-by: Wei Yongjun <weiyongjun1(a)huawei.com> --- sound/soc/tegra/tegra_wm8903.c | 14 ++------------ 1 file changed, 2 insertions(+), 12 deletions(-) diff --git a/sound/soc/tegra/tegra_wm8903.c b/sound/soc/tegra/tegra_wm8903.c index 7bf159965c4d..d3ead0213cef 100644 --- a/sound/soc/tegra/tegra_wm8903.c +++ b/sound/soc/tegra/tegra_wm8903.c @@ -351,9 +351,9 @@ static int tegra_wm8903_driver_probe(struct platform_device *pdev) if (ret) return ret; - ret = snd_soc_register_card(card); + ret = devm_snd_soc_register_card(&pdev->dev, card); if (ret) { - dev_err(&pdev->dev, "snd_soc_register_card failed (%d)\n", + dev_err(&pdev->dev, "devm_snd_soc_register_card failed (%d)\n", ret); return ret; } @@ -361,15 +361,6 @@ static int tegra_wm8903_driver_probe(struct platform_device *pdev) return 0; } -static int tegra_wm8903_driver_remove(struct platform_device *pdev) -{ - struct snd_soc_card *card = platform_get_drvdata(pdev); - - snd_soc_unregister_card(card); - - return 0; -} - static const struct of_device_id tegra_wm8903_of_match[] = { { .compatible = "nvidia,tegra-audio-wm8903", }, {}, @@ -382,7 +373,6 @@ static struct platform_driver tegra_wm8903_driver = { .of_match_table = tegra_wm8903_of_match, }, .probe = tegra_wm8903_driver_probe, - .remove = tegra_wm8903_driver_remove, }; module_platform_driver(tegra_wm8903_driver);

2 1

[PATCH] ASoC: davinci-mcasp: Fix dma_chan refcnt leak when getting dma type
by Xiyu Yang 28 Apr '20

28 Apr '20

davinci_mcasp_get_dma_type() invokes dma_request_chan(), which returns a reference of the specified dma_chan object to "chan" with increased refcnt. When davinci_mcasp_get_dma_type() returns, local variable "chan" becomes invalid, so the refcount should be decreased to keep refcount balanced. The reference counting issue happens in one exception handling path of davinci_mcasp_get_dma_type(). When chan device is NULL, the function forgets to decrease the refcnt increased by dma_request_chan(), causing a refcnt leak. Fix this issue by calling dma_release_channel() when chan device is NULL. Signed-off-by: Xiyu Yang <xiyuyang19(a)fudan.edu.cn> Signed-off-by: Xin Tan <tanxin.ctf(a)gmail.com> --- sound/soc/ti/davinci-mcasp.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/sound/soc/ti/davinci-mcasp.c b/sound/soc/ti/davinci-mcasp.c index 734ffe925c4d..7a7db743dc5b 100644 --- a/sound/soc/ti/davinci-mcasp.c +++ b/sound/soc/ti/davinci-mcasp.c @@ -1896,8 +1896,10 @@ static int davinci_mcasp_get_dma_type(struct davinci_mcasp *mcasp) PTR_ERR(chan)); return PTR_ERR(chan); } - if (WARN_ON(!chan->device || !chan->device->dev)) + if (WARN_ON(!chan->device || !chan->device->dev)) { + dma_release_channel(chan); return -EINVAL; + } if (chan->device->dev->of_node) ret = of_property_read_string(chan->device->dev->of_node, -- 2.7.4

3 2

[PATCH] ASoC: tlv320adcx140: Fix mic gain registers
by Dan Murphy 28 Apr '20

28 Apr '20

Fix the mic gain registers for channels 2-4. The incorret register was being set as it was touching the CH1 config registers. Fixes: 37bde5acf040 ("ASoC: tlv320adcx140: Add the tlv320adcx140 codec driver family") Cc: stable(a)vger.kernel.org Signed-off-by: Dan Murphy <dmurphy(a)ti.com> --- sound/soc/codecs/tlv320adcx140.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/sound/soc/codecs/tlv320adcx140.c b/sound/soc/codecs/tlv320adcx140.c index 38897568ee96..0f713efde046 100644 --- a/sound/soc/codecs/tlv320adcx140.c +++ b/sound/soc/codecs/tlv320adcx140.c @@ -511,11 +511,11 @@ static const struct snd_soc_dapm_route adcx140_audio_map[] = { static const struct snd_kcontrol_new adcx140_snd_controls[] = { SOC_SINGLE_TLV("Analog CH1 Mic Gain Volume", ADCX140_CH1_CFG1, 2, 42, 0, adc_tlv), - SOC_SINGLE_TLV("Analog CH2 Mic Gain Volume", ADCX140_CH1_CFG2, 2, 42, 0, + SOC_SINGLE_TLV("Analog CH2 Mic Gain Volume", ADCX140_CH2_CFG1, 2, 42, 0, adc_tlv), - SOC_SINGLE_TLV("Analog CH3 Mic Gain Volume", ADCX140_CH1_CFG3, 2, 42, 0, + SOC_SINGLE_TLV("Analog CH3 Mic Gain Volume", ADCX140_CH3_CFG1, 2, 42, 0, adc_tlv), - SOC_SINGLE_TLV("Analog CH4 Mic Gain Volume", ADCX140_CH1_CFG4, 2, 42, 0, + SOC_SINGLE_TLV("Analog CH4 Mic Gain Volume", ADCX140_CH4_CFG1, 2, 42, 0, adc_tlv), SOC_SINGLE_TLV("DRE Threshold", ADCX140_DRE_CFG0, 4, 9, 0, -- 2.25.1

2 1

[PATCH] ALSA: hda/hdmi: fix race in monitor detection during probe
by Kai Vehmanen 28 Apr '20

28 Apr '20

A race exists between build_pcms() and build_controls() phases of codec setup. Build_pcms() sets up notifier for jack events. If a monitor event is received before build_controls() is run, the initial jack state is lost and never reported via mixer controls. The problem can be hit at least with SOF as the controller driver. SOF calls snd_hda_codec_build_controls() in its workqueue-based probe and this can be delayed enough to hit the race condition. Fix the issue by invalidating the per-pin ELD information when build_controls() is called. The existing call to hdmi_present_sense() will update the ELD contents. This ensures initial monitor state is correctly reflected via mixer controls. BugLink: https://github.com/thesofproject/linux/issues/1687 Signed-off-by: Kai Vehmanen <kai.vehmanen(a)linux.intel.com> --- sound/pci/hda/patch_hdmi.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/patch_hdmi.c index 403baca89452..e8f0ae5af3d8 100644 --- a/sound/pci/hda/patch_hdmi.c +++ b/sound/pci/hda/patch_hdmi.c @@ -2194,7 +2194,9 @@ static int generic_hdmi_build_controls(struct hda_codec *codec) for (pin_idx = 0; pin_idx < spec->num_pins; pin_idx++) { struct hdmi_spec_per_pin *per_pin = get_pin(spec, pin_idx); + struct hdmi_eld *pin_eld = &per_pin->sink_eld; + pin_eld->eld_valid = false; hdmi_present_sense(per_pin, 0); } -- 2.26.0

2 1

documentation incomplete for *avail_min, *avail_max
by GitHub issues - opened 28 Apr '20

28 Apr '20

alsa-project/alsa-lib issue #44 was opened from archenemies: The following documentation is incomplete. It doesn't explain what "avail min" or "avail max" means. It's like asking someone you just met "what is your maximum age?". We need more context for the phrase "maximum number of frames available" to be meaningful. Is it maximum allowed before frames start getting dropped? Is it the maximum that we've seen over the course of operating the device? https://www.alsa-project.org/alsa-doc/alsa-lib/group___p_c_m___s_w___params… snd_pcm_sw_params_get_avail_min() Get avail min from a software configuration container. https://www.alsa-project.org/alsa-doc/alsa-lib/group___p_c_m___status.html#… snd_pcm_status_get_avail_max() Get maximum number of frames available from a PCM status container after last snd_pcm_status call. Returns Maximum number of frames ready to be read/written The following is less important, but it still should be fixed. We need to explain what a "software configuration container" is. The phrase is used all over the place; it only needs to be defined once: https://www.alsa-project.org/alsa-doc/alsa-lib/group___p_c_m.html#ga7e082d9… snd_pcm_sw_params_t typedef struct _snd_pcm_sw_params snd_pcm_sw_params_t PCM software configuration container Issue URL : https://github.com/alsa-project/alsa-lib/issues/44 Repository URL: https://github.com/alsa-project/alsa-lib

1 0