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

[alsa-devel] Applied "ASoC: rt5514: Fix the issue of the delay volume applied again" to the asoc tree
by Mark Brown 20 Aug '18

20 Aug '18

The patch ASoC: rt5514: Fix the issue of the delay volume applied again has been applied to the asoc tree at https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark >From 6f0a256253f48095ba2e5bcdfbed41f21643c105 Mon Sep 17 00:00:00 2001 From: Oder Chiou <oder_chiou(a)realtek.com> Date: Wed, 15 Aug 2018 14:47:49 +0800 Subject: [PATCH] ASoC: rt5514: Fix the issue of the delay volume applied again After our evaluation, we need to modify the default values to make sure the volume applied immediately. Signed-off-by: Oder Chiou <oder_chiou(a)realtek.com> Signed-off-by: Mark Brown <broonie(a)kernel.org> --- sound/soc/codecs/rt5514.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/sound/soc/codecs/rt5514.c b/sound/soc/codecs/rt5514.c index dca82dd6e3bf..32fe76c3134a 100644 --- a/sound/soc/codecs/rt5514.c +++ b/sound/soc/codecs/rt5514.c @@ -64,8 +64,8 @@ static const struct reg_sequence rt5514_patch[] = { {RT5514_ANA_CTRL_LDO10, 0x00028604}, {RT5514_ANA_CTRL_ADCFED, 0x00000800}, {RT5514_ASRC_IN_CTRL1, 0x00000003}, - {RT5514_DOWNFILTER0_CTRL3, 0x10000352}, - {RT5514_DOWNFILTER1_CTRL3, 0x10000352}, + {RT5514_DOWNFILTER0_CTRL3, 0x10000342}, + {RT5514_DOWNFILTER1_CTRL3, 0x10000342}, }; static const struct reg_default rt5514_reg[] = { @@ -92,10 +92,10 @@ static const struct reg_default rt5514_reg[] = { {RT5514_ASRC_IN_CTRL1, 0x00000003}, {RT5514_DOWNFILTER0_CTRL1, 0x00020c2f}, {RT5514_DOWNFILTER0_CTRL2, 0x00020c2f}, - {RT5514_DOWNFILTER0_CTRL3, 0x10000352}, + {RT5514_DOWNFILTER0_CTRL3, 0x10000342}, {RT5514_DOWNFILTER1_CTRL1, 0x00020c2f}, {RT5514_DOWNFILTER1_CTRL2, 0x00020c2f}, - {RT5514_DOWNFILTER1_CTRL3, 0x10000352}, + {RT5514_DOWNFILTER1_CTRL3, 0x10000342}, {RT5514_ANA_CTRL_LDO10, 0x00028604}, {RT5514_ANA_CTRL_LDO18_16, 0x02000345}, {RT5514_ANA_CTRL_ADC12, 0x0000a2a8}, -- 2.18.0

1 0

[alsa-devel] [PATCH] slimbus: ngd: mark PM functions as __maybe_unused
by Arnd Bergmann 20 Aug '18

20 Aug '18

qcom_slim_ngd_runtime_suspend is protected by an #ifdef, qcom_slim_ngd_runtime_idle is now, which causes a build time warning: drivers/slimbus/qcom-ngd-ctrl.c:1470:12: error: 'qcom_slim_ngd_runtime_idle' defined but not used [-Werror=unused-function] Marking both as __maybe_unused lets us get rid of the warning as well as the #ifdef. Fixes: 917809e2280b ("slimbus: ngd: Add qcom SLIMBus NGD driver") Signed-off-by: Arnd Bergmann <arnd(a)arndb.de> --- drivers/slimbus/qcom-ngd-ctrl.c | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/drivers/slimbus/qcom-ngd-ctrl.c b/drivers/slimbus/qcom-ngd-ctrl.c index 8be4d6786c61..14a9d18306cb 100644 --- a/drivers/slimbus/qcom-ngd-ctrl.c +++ b/drivers/slimbus/qcom-ngd-ctrl.c @@ -1467,7 +1467,7 @@ static int qcom_slim_ngd_remove(struct platform_device *pdev) return 0; } -static int qcom_slim_ngd_runtime_idle(struct device *dev) +static int __maybe_unused qcom_slim_ngd_runtime_idle(struct device *dev) { struct qcom_slim_ngd_ctrl *ctrl = dev_get_drvdata(dev); @@ -1477,8 +1477,7 @@ static int qcom_slim_ngd_runtime_idle(struct device *dev) return -EAGAIN; } -#ifdef CONFIG_PM -static int qcom_slim_ngd_runtime_suspend(struct device *dev) +static int __maybe_unused qcom_slim_ngd_runtime_suspend(struct device *dev) { struct qcom_slim_ngd_ctrl *ctrl = dev_get_drvdata(dev); int ret = 0; @@ -1491,7 +1490,6 @@ static int qcom_slim_ngd_runtime_suspend(struct device *dev) return ret; } -#endif static const struct dev_pm_ops qcom_slim_ngd_dev_pm_ops = { SET_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend, -- 2.18.0

1 0

[alsa-devel] [PATCH v2] ASoC: wm9712: fix replace codec to component
by Marcel Ziswiler 20 Aug '18

20 Aug '18

From: Marcel Ziswiler <marcel.ziswiler(a)toradex.com> Since commit 143b44845d87 ("ASoC: wm9712: replace codec to component") "wm9712-codec" got renamed to "wm9712-component", however, this change never got propagated down to the actual board/platform drivers. E.g. on Colibri T20 this lead to the following spew upon boot with sound/touch being broken: [ 2.214121] tegra-snd-wm9712 sound: ASoC: CODEC DAI wm9712-hifi not registered [ 2.222137] tegra-snd-wm9712 sound: snd_soc_register_card failed (-517) ... [ 2.344384] tegra-snd-wm9712 sound: ASoC: CODEC DAI wm9712-hifi not registered [ 2.351885] tegra-snd-wm9712 sound: snd_soc_register_card failed (-517) ... [ 2.668339] tegra-snd-wm9712 sound: ASoC: CODEC DAI wm9712-hifi not registered [ 2.675811] tegra-snd-wm9712 sound: snd_soc_register_card failed (-517) ... [ 3.208408] tegra-snd-wm9712 sound: ASoC: CODEC DAI wm9712-hifi not registered [ 3.216312] tegra-snd-wm9712 sound: snd_soc_register_card failed (-517) ... [ 3.235397] tegra-snd-wm9712 sound: ASoC: CODEC DAI wm9712-hifi not registered [ 3.248938] tegra-snd-wm9712 sound: snd_soc_register_card failed (-517) ... [ 14.970443] ALSA device list: [ 14.996628] No soundcards found. This commit finally fixes this again. Signed-off-by: Marcel Ziswiler <marcel.ziswiler(a)toradex.com> --- Changes in v2: - Simply rename "wm9712-component" back to "wm9712-codec" as suggested by Kuninori and Charles. sound/soc/codecs/wm9712.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/soc/codecs/wm9712.c b/sound/soc/codecs/wm9712.c index 953d94d50586..ade34c26ad2f 100644 --- a/sound/soc/codecs/wm9712.c +++ b/sound/soc/codecs/wm9712.c @@ -719,7 +719,7 @@ static int wm9712_probe(struct platform_device *pdev) static struct platform_driver wm9712_component_driver = { .driver = { - .name = "wm9712-component", + .name = "wm9712-codec", }, .probe = wm9712_probe, -- 2.14.4

4 3

[alsa-devel] revisiting system timer sound application wake up
by Ricardo Biehl Pasquali 20 Aug '18

20 Aug '18

08/08/2018 (ignore this date) PulseAudio tsched ================= Around December 2007 to February 2009 Lennart Poettering has asked some questions in alsa-devel mailing list in order to implement the timer based audio scheduling for PulseAudio. In 2008 he wrote an article named "What's Cooking in PulseAudio's glitch-free Branch". I have not found detailed documentation about PulseAudio timer wake up and I'm not sure about some implementation details. By using the emails from Lennart and his article a Documentation can start to grow. Do PulseAudio synchronize to sound device by adjusting the timer or the amount committed (application pointer)? The nice thing about the second case is that the period time (in application's view) is bonded to system clock instead of sound device's. What timer interface does PulseAudio use? timerfd? POSIX timers? Hardware issues =============== How the deviation of system and sound device clock is today? Perhaps someone that works with sound cards or SoCs can answer this. Do the most of today's hardware has the same clock for sound device and system? How sound devices deal with random accesses to their ring buffer. Do most of them allow writing/reading anywhere and anytime? How is the acurracy and precision of the hardware pointer returned by sound devices? Does SNDRV_PCM_INFO_BATCH flag reveals something about the above one? As PulseAudio runs in many Linux distributions today, it seems an interesting idea to implement an utility to collect some information regarding the above issues. Then make it available to the public. E.g. it would be possible to know the pointer acurracy for specific devices. SCHED_DEADLINE and timerfd ========================== There are a few works over there about SCHED_DEADLINE and audio: - This paper presented in Linux Audio Conference 2011: BAGNOLI, Giacomo; CUCINOTTA, Tommaso; FAGGIOLI, Dario. 2011. Low-Latency Audio on Linux by Means of Real-Time Scheduling. Dario Faggioli is one of the authors of SCHED_DEADLINE. - This presentation of Alessio Balsini: "Experimenting with the Android Audio Pipeline and SCHED_DEADLINE". OSPM 2018. Here is an overview: <https://lwn.net/Articles/754923/>. In SCHED_DEADLINE I assume there is no way to accurately adjust the timer. As well as there is no way to adjust when the first expiration will be. I think this is because of Constant Bandwidth Server algorithm. Must ask to some developer of this. Having this in mind, the only way to synchronize to sound device is by adjusting the amount read/written (application pointer). Timerfd on the other hand is fully adjustable. However, it can be preempted by a high priority task. Anyway I don't see that as a problem as it should ralely happen. Perhaps SCHED_DEADLINE is suitable for professional environment (aiming almost-zero glitches). Thoughts on this? Is there someone planning to implement SCHED_DEADLINE in PulseAudio? I'm currently working on both implementations (not for PulseAudio). See <https://github.com/ricardobiehl/simplesound>. Take a look at 'Documentation/timer_wakeup.rst', 'tools/timer_wakeup.c' and 'tools/deadline_wakeup.c'. 'tools/waveplay.c' play .wav files using the application wakeup method specified in 'tools/Makefile'. Documentation ============= Many of the points I've mentioned should get well covered by some documentation (e.g. ALSA, PulseAudio). Also, I think ALSA's internal (kernel-level) documentation needs to grow. I'm actually working on that, documenting some stuff as I'm developing a small sound library that interacts directly to ALSA in kernel, and the application wakeup using timerfd and SCHED_DEADLINE. Cheers!

1 0

[alsa-devel] [PATCH 1/2] ALSA: ac97: fix check of pm_runtime_get_sync failure
by ylhuajnu＠163.com 19 Aug '18

19 Aug '18

From: Lihua Yao <ylhuajnu(a)163.com> pm_runtime_get_sync returns negative on failure. Fixes: 74426fbff66e ("ALSA: ac97: add an ac97 bus") Signed-off-by: Lihua Yao <ylhuajnu(a)163.com> --- sound/ac97/bus.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/ac97/bus.c b/sound/ac97/bus.c index 31f858eceffc..c267e44fefa0 100644 --- a/sound/ac97/bus.c +++ b/sound/ac97/bus.c @@ -503,7 +503,7 @@ static int ac97_bus_remove(struct device *dev) int ret; ret = pm_runtime_get_sync(dev); - if (ret) + if (ret < 0) return ret; ret = adrv->remove(adev); -- 2.17.1

2 3

[alsa-devel] [PATCH v2] control_hw: Fix issue when applying seccomp policy
by Hsin-Yu Chao 19 Aug '18

19 Aug '18

When seccomp policy is applied to filter ioctl syscall with SNDRV_CTL_IOCTL_TLV_COMMAND, SNDRV_CTL_IOCTL_TLV_READ and SNDRV_CTL_IOCTL_TLV_WRITE in whiltelist, alsa-lib still breaks in at snd_ctl_hw_elem_tlv(). The problem behind is because ioctl() takes unsigned long cmd argument, and the signed bit of local int variable could cause 0xff bytes appended after casted to unsigned long. In kernel, seccomp data struct takes 64 bits argument to check against seccomp rules, these unexpected 0xff bytes could make the rule check fail. Fix the problem by passing unsigned int to ioctl. Signed-off-by: Hsin-Yu Chao <hychao(a)chromium.org> --- src/control/control_hw.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/control/control_hw.c b/src/control/control_hw.c index 68eca522..b54d65f2 100644 --- a/src/control/control_hw.c +++ b/src/control/control_hw.c @@ -215,7 +215,7 @@ static int snd_ctl_hw_elem_tlv(snd_ctl_t *handle, int op_flag, unsigned int numid, unsigned int *tlv, unsigned int tlv_size) { - int inum; + unsigned int inum; snd_ctl_hw_t *hw = handle->private_data; struct snd_ctl_tlv *xtlv; -- 2.18.0.865.gffc8e1a3cd6-goog

2 1

[alsa-devel] Fwd: [PATCH 1/2] ALSA: hda - Turn CX8200 into D3 as well upon reboot
by Ju Hyung Park 19 Aug '18

19 Aug '18

Hi, It's commit d77a4b4a5b0b2ebcbc9840995d91311ef28302ab and f59cf9a0551dd954ad8b752461cf19d9789f4b1d, both which are already merged in Linus's tree. I can't think of a reason why you would have missed this other than the fact that I've used "Cc: <stable(a)vger.kernel.org>" instead of "Cc: stable(a)vger.kernel.org". I doubt it, but would this be the reason? Thanks, On Sat, Aug 18, 2018 at 11:38 PM Greg KH <gregkh(a)linuxfoundation.org> wrote: > > On Sat, Aug 18, 2018 at 11:29:11PM +0900, Ju Hyung Park wrote: > > Hi, Greg. > > > > I'd like to know if there's a reason on why these ALSA patches(2 in > > total) aren't brought to linux-stable yet. > > What specific patches are you referring to here? I do not see anything > in this email :( > > What is the git commit id in Linus's tree? What stable tree(s) do you > want them applied to? > > > I see a lot of patches merged to linux-stable and stable-queue that > > are much newer than those patches. > > > > I'd appreciate it if you can merge those ASAP. > > Have you read: > https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html > for how to do this properly? > > If not, please do so. > > thanks, > > greg k-h

2 1

[alsa-devel] Fwd: [PATCH 1/2] ALSA: hda - Turn CX8200 into D3 as well upon reboot
by Ju Hyung Park 18 Aug '18

18 Aug '18

Oh, and I forgot to add: this would better be applied to every stable trees, if applicable (probably by checking if the commit f6b28e4ded45bb91bc4cd115d55e35badedfce5f is already merged). Thanks again. On Sat, Aug 18, 2018 at 11:38 PM Greg KH <gregkh(a)linuxfoundation.org> wrote: > > On Sat, Aug 18, 2018 at 11:29:11PM +0900, Ju Hyung Park wrote: > > Hi, Greg. > > > > I'd like to know if there's a reason on why these ALSA patches(2 in > > total) aren't brought to linux-stable yet. > > What specific patches are you referring to here? I do not see anything > in this email :( > > What is the git commit id in Linus's tree? What stable tree(s) do you > want them applied to? > > > I see a lot of patches merged to linux-stable and stable-queue that > > are much newer than those patches. > > > > I'd appreciate it if you can merge those ASAP. > > Have you read: > https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html > for how to do this properly? > > If not, please do so. > > thanks, > > greg k-h

1 0

[alsa-devel] [PATCH v2] ASoC: tegra: probe deferral error reporting
by Marcel Ziswiler 18 Aug '18

18 Aug '18

From: Marcel Ziswiler <marcel.ziswiler(a)toradex.com> Actually report the error codes from of_get_named_gpio() resp. devm_gpio_request_one() upon trying to get the codec reset resp. sync GPIOs unless it is just a probe deferral. Signed-off-by: Marcel Ziswiler <marcel.ziswiler(a)toradex.com> --- Changes in v2: - Silence probe deferral as suggested by Stefan. - Fix line over 80 characters as reported by checkpatch. sound/soc/tegra/tegra20_ac97.c | 19 ++++++++++++++++--- 1 file changed, 16 insertions(+), 3 deletions(-) diff --git a/sound/soc/tegra/tegra20_ac97.c b/sound/soc/tegra/tegra20_ac97.c index 682ef33afb5f..2ac6b2d73980 100644 --- a/sound/soc/tegra/tegra20_ac97.c +++ b/sound/soc/tegra/tegra20_ac97.c @@ -351,18 +351,31 @@ static int tegra20_ac97_platform_probe(struct platform_device *pdev) ret = devm_gpio_request_one(&pdev->dev, ac97->reset_gpio, GPIOF_OUT_INIT_HIGH, "codec-reset"); if (ret) { - dev_err(&pdev->dev, "could not get codec-reset GPIO\n"); + if (ret != -EPROBE_DEFER) + dev_err(&pdev->dev, + "could not get codec-reset GPIO: %d\n", + ret); + goto err_clk_put; } } else { - dev_err(&pdev->dev, "no codec-reset GPIO supplied\n"); + ret = ac97->reset_gpio; + if (ret != -EPROBE_DEFER) + dev_err(&pdev->dev, + "no codec-reset GPIO supplied: %d\n", + ret); + goto err_clk_put; } ac97->sync_gpio = of_get_named_gpio(pdev->dev.of_node, "nvidia,codec-sync-gpio", 0); if (!gpio_is_valid(ac97->sync_gpio)) { - dev_err(&pdev->dev, "no codec-sync GPIO supplied\n"); + ret = ac97->sync_gpio; + if (ret != -EPROBE_DEFER) + dev_err(&pdev->dev, "no codec-sync GPIO supplied: %d\n", + ret); + goto err_clk_put; } -- 2.14.4

3 2

[alsa-devel] hinawa-utils v0.1.0 and libhinawa v1.0.0 release
by Takashi Sakamoto 18 Aug '18

18 Aug '18

Hi, Today I released hinawa-utils v0.1.0[1]. This package consists of Python 3 modules and scripts to control elements such as output volume in Audio and Music units on IEEE 1394 bus, handled by ALSA firewire stack. At present, all of the scripts are designed to work as CUI, without any server applications. They're listed below: * hinawa-alesis-io-cui * CUI tool for Alesis iO|14 and iO|26 * hinawa-bebob-parser * Plug structure parser for BeBoB firmware * hinawa-config-rom-printer * A lexer/parser of configuration ROM on IEEE 1394 bus * hinawa-dg00x-cui * CUI tool for Digidesign Digi 00x family * hinawa-dice-common-cui * CUI tool for Dice common functionalities * hinawa-dice-extension-cui * CUI tool for Dice extended functionalities a.k.a EAP * hinawa-fireworks-cui * CUI tool for Echo Audio Fireworks module * hinawa-focusrite-saffirepro-io-cui * CUI tool for Focusrite SaffirePro IO series * hinawa-griffin-firewave-cui * CUI tool for Griffin Firewave * hinawa-lacie-speakers-cui * CUI tool for Lacie FireWire speakers * hinawa-motu-common-cui * CUI tool for common functionalities of MOTU FireWire series * hinawa-maudio-bebob-cui * CUI tool for M-Audio FireWire series based on BeBoB platform * hinawa-oxfw-generic-cui * CUI tool for OXFW generic functionalities * hinawa-tascam-fireone-cui * CUI tool for Tascam FireOne * hinawa-tascam-fw-rack-cui * CUI tool for rack models of Tascam FireWire series (FW1804) * hinawa-tascam-fw-console-cui * CUI tool for console models of Tascam FireWire series (FW1082/1884) * hinawa-yamaha-terratec-cui * CUI tool for Yamaha GO series and Terratec PHASE series They're written by Python 3 language, with a help of PyGObject[2] for gobject-introspection[3] to libhinawa API. At the same time, I released libhinawa v1.0.0[4]. This I/O library is designed for asynchronous transactions on IEEE 1394 bus via ioctl commands defined by Linux FireWire subsystem. Additionally, this library is also an application of ALSA HwDep interface supported by ALSA firewire stack. An overview of its design is illustrated[5]. I firstly introduced this library three years ago[6]. This v1.0.0 release loses backward compatibility to a part of public APIs against v0 releases in these three years, and now becomes stable with updated major version. Python 3 modules and scripts in hinawa-utils work with libhinawa v1 APIs. If you'd like to use them, please install libhinawa v1 release instead of v0 releases. I note that modules in hinawa-utils are not stable yet, as its version means. This library has already been packaged to Debian distribution[7] and available in it and its derivatives such as Ubuntu. The v1.0.0 release is already available in their repositories[8][9]. For hinawa-utils, I already start packaging to Debian distribution and get a help of Debian contributer, Kentaro Hayashi, again. We already registered ITP[10] and RFS[11] and wait for sponsors of debian developers to publish. If you find bugs, or have wishes, I suggest to file them as issues in each project on github.com. Of course, I welcome your Pull Requests. I note that these projects are heavily based on vendor-dependent functionalities, thus all of filed issues can not be solved because what I can do is for devices I own. # Off the subject, Kentaro is currently on a process to be Debian # Maintainer(DM)[12]. I greatly appreciate his care and contribution to # libhinawa/hinawa-utils. I hope he will get good experiences from his # next great journey as DM. [1] Release version 0.1.0 release · takaswie/hinawa-utils https://github.com/takaswie/hinawa-utils/releases/tag/v0.1.0 [2] Overview — PyGObject https://pygobject.readthedocs.io/en/latest/ [3] Overview — GObject Introspection https://gi.readthedocs.io/en/latest/ [4] Release version 1.0.0 release · takaswie/libhinawa https://github.com/takaswie/libhinawa/releases/tag/1.0.0 [5] libhinawa/doc/overview.png https://github.com/takaswie/libhinawa/blob/master/doc/overview.png [6] [alsa-devel] [RFC][PATCH 00/13] alsa-tools: libhinawa for control applications of FireWire devices http://mailman.alsa-project.org/pipermail/alsa-devel/2015-January/086969.ht… [7] [alsa-devel] About planning of libhinawa ITP to debian project http://mailman.alsa-project.org/pipermail/alsa-devel/2016-January/103693.ht… [8] Debian Package Tracker - libhinawa https://tracker.debian.org/pkg/libhinawa [9] libhinawa package : Ubuntu https://launchpad.net/ubuntu/+source/libhinawa [10] #905840 - ITP: hinawa-utils - Utility tools for libhinawa - Debian Bug report logs https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=905840 [11] #905906 - RFS: hinawa-utils/0.0.99-1 [ITP] - Debian Bug report logs https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=905906 [12] Debian New Member Process https://nm.debian.org/process/531 Regards Takashi Sakamoto

1 0