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

config for Renoir APU
by GitHub pull_request - edited 07 Jun '20

07 Jun '20

alsa-project/alsa-ucm-conf pull request #31 was edited from perexg: This is just a test config (not for merge). BEWARE: This configuration is not intended for the broad use at the moment. It will broke other HDA Intel hardware. Request URL : https://github.com/alsa-project/alsa-ucm-conf/pull/31 Patch URL : https://github.com/alsa-project/alsa-ucm-conf/pull/31.patch Repository URL: https://github.com/alsa-project/alsa-ucm-conf

1 0

config for Renoir APU
by GitHub pull_request - opened 07 Jun '20

07 Jun '20

alsa-project/alsa-ucm-conf pull request #31 was opened from perexg: This is just a test config (not for merge). Request URL : https://github.com/alsa-project/alsa-ucm-conf/pull/31 Patch URL : https://github.com/alsa-project/alsa-ucm-conf/pull/31.patch Repository URL: https://github.com/alsa-project/alsa-ucm-conf

1 0

ALSA control service in user space
by Takashi Sakamoto 07 Jun '20

07 Jun '20

Hi, Today I released hinawa-rs[1], Rust bindings to libhinawa v2.0[2]. Aug 2018 I sent a message[3] about new releases of libhinawa/hinawa-utils. In the releases, I used Python 3 to write tools for audio and music units on IEEE 1394 bus, supported by ALSA firewire stack. The attempt is successful to make my understandings further about vendor-dependent protocols. Earlier the message, Nov 2016 I had a presentation about ALSA device control service in user space[4]. The idea requires server program to perform some tasks below in user space: * register control element set into ALSA control core for existent card instance * dispatch control event from ALSA control applications * communicate with device to operate its functions such as volume control * dispatch any event from the device. The registered control element set can be handled transparently by ALSA control applications such as amixer. When the application operates the added control element, events are delivered to the server program. Then the server program communicates with the device for the operation. Now instead of Python 3, I select Rust language to write the server programs for audio and music units on IEEE 1394 bus. The hinawa-rs helps the third and fourth of the above tasks. For the first and second task, I wrote some libraries in alsa-gobject project[5]. The demonstration by Python 3 is public[6]. I already write alsa-gobject-rs which includes Rust bindings for the libraries. It's not public yet since I make no official releases of alsa-gobject itself. At the same time, I already write the prototype of server programs itself and it works well in my local. The code base already reaches 28,000 lines even if it supports the limited number of devices. I realized again that it was a better decision not to implement them in kernel land. As IEEE 1394 bus becomes legacy, the audio and music units is outdated. One of my motivation to continue the development is the idea of control service in use space itself since the idea is also available for USB Audio as well. When developers work for devices with vendor-dependent protocol, the idea helps the developer because user space applications can communicate with the device via USB character device. For example, I recently saw an attempt by Guy Sherman for US-4x4 Utils[7]. As a quick glance to his repository[8], vendor-dependent command is used to operate the device. For this kind of work, the idea is available as well to produce transparent control element set. Anyway I'm going to make official release of alsa-gobject as a next step toward the idea. [1] https://github.com/takaswie/hinawa-rs [2] https://github.com/takaswie/libhinawa [3] https://www.alsa-project.org/pipermail/alsa-devel/2018-August/139448.html [4] https://github.com/takaswie/presentations/blob/master/20161101/content.md [5] https://github.com/alsa-project/alsa-gobject [6] 'self.open(card_id)' should be 'self.open(card_id, 0)' now https://mailman.alsa-project.org/pipermail/alsa-devel/2019-December/159339.… [7] https://lists.linuxaudio.org/archives/linux-audio-dev/2020-May/037774.html [8] https://github.com/guysherman/tascam-util Regards Takashi Sakamoto

2 3

alsa-gobject: seq: fulfill documentation for ALSASeq
by GitHub pull_request - opened 06 Jun '20

06 Jun '20

alsa-project/alsa-gobject pull request #24 was opened from takaswie: This patch fulfills documentation for ALSASeq. Request URL : https://github.com/alsa-project/alsa-gobject/pull/24 Patch URL : https://github.com/alsa-project/alsa-gobject/pull/24.patch Repository URL: https://github.com/alsa-project/alsa-gobject

1 0

alsa-gobject: hwdep/timer/rawmidi: fulfill documentation for ALSAHwdep/ALSATimer/ALSARawmidi
by GitHub pull_request - opened 06 Jun '20

06 Jun '20

alsa-project/alsa-gobject pull request #23 was opened from takaswie: This patchset fulfills documentation for ALSAHwdep/ALSATimer/ALSARawmidi, except for ALSASeq, including some documentation improvements for ALSACtl. Request URL : https://github.com/alsa-project/alsa-gobject/pull/23 Patch URL : https://github.com/alsa-project/alsa-gobject/pull/23.patch Repository URL: https://github.com/alsa-project/alsa-gobject

1 0

detailed documentation for plug plugin?
by D. R. Evans 06 Jun '20

06 Jun '20

This is a follow-on to the topic started in e-mail <62e4a031-f175-70bc-099f-441fa0623a9f(a)gmail.com> on the alsa-users reflector; I also posted this e-mail on that reflector, but I suspect that there are more people here who would immediately understand the behaviour described below, and can point me to the right documentation. -------- I have a machine on which the following works for reading audio: device: default [which is actually hw:0,0,0] rate: 44100 [which is all that the raw device supports] And the following does not work: device: plug:default rate: 8000 Everything else is identical in the two scenarios. So I am trying to find detailed documentation about the "plug" plugin, to see why it doesn't seem to do what the minimal description I've been able to find suggests. That is, from what little I've been able to find, it seemed like the second scenario should work if the first one does: behind the scenes it would take the 44100 output from the default device and downsample to 8000, and make that available to the snd_pcm_readX() functions. But that is not what's happening, since the second scenario fails: snd_pcm_readX() blocks (even in non-blocking mode). Somewhere there has to be a detailed, technical description of precisely what the plug plugin does; can someone please provide a suggestion where to look? Doc -- Web: http://enginehousebooks.com/drevans

1 0

[RFC][PATCH] slimbus: core: Set fwnode for a device when setting of_node
by John Stultz 06 Jun '20

06 Jun '20

From: Saravana Kannan <saravanak(a)google.com> When setting the of_node for a newly created device, also set the fwnode. This allows fw_devlink to work for slimbus devices. Cc: Srinivas Kandagatla <srinivas.kandagatla(a)linaro.org> Cc: alsa-devel(a)alsa-project.org Signed-off-by: Saravana Kannan <saravanak(a)google.com> Signed-off-by: John Stultz <john.stultz(a)linaro.org> --- drivers/slimbus/core.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/slimbus/core.c b/drivers/slimbus/core.c index 526e3215d8fe..44228a5b246d 100644 --- a/drivers/slimbus/core.c +++ b/drivers/slimbus/core.c @@ -163,8 +163,10 @@ static int slim_add_device(struct slim_controller *ctrl, INIT_LIST_HEAD(&sbdev->stream_list); spin_lock_init(&sbdev->stream_list_lock); - if (node) + if (node) { sbdev->dev.of_node = of_node_get(node); + sbdev->dev.fwnode = of_fwnode_handle(node); + } dev_set_name(&sbdev->dev, "%x:%x:%x:%x", sbdev->e_addr.manf_id, -- 2.17.1

2 2

[PATCH] ALSA: emu10k1: delete an unnecessary condition
by Dan Carpenter 05 Jun '20

05 Jun '20

The "val" variable is an unsigned int so it's always <= UINT_MAX. This check is always true so it can be removed. Signed-off-by: Dan Carpenter <dan.carpenter(a)oracle.com> --- sound/pci/emu10k1/emu10k1x.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/pci/emu10k1/emu10k1x.c b/sound/pci/emu10k1/emu10k1x.c index ddb7c2ce3f7c9..def8161cde4c2 100644 --- a/sound/pci/emu10k1/emu10k1x.c +++ b/sound/pci/emu10k1/emu10k1x.c @@ -1040,7 +1040,7 @@ static void snd_emu10k1x_proc_reg_write(struct snd_info_entry *entry, if (sscanf(line, "%x %x %x", &reg, &channel_id, &val) != 3) continue; - if (reg < 0x49 && val <= 0xffffffff && channel_id <= 2) + if (reg < 0x49 && channel_id <= 2) snd_emu10k1x_ptr_write(emu, reg, channel_id, val); } } -- 2.26.2

2 1

[PATCH 0/2] alsa-lib: -ENODATA documentation
by Kai Vehmanen 05 Jun '20

05 Jun '20

Hello all, here's patch to document -ENODATA error as a PCM error code. We have recently merged patches to SOF firmware to use this error code: https://github.com/thesofproject/sof/pull/2918 Some additional background on the use-case: https://github.com/thesofproject/sof/issues/2564 In thread "Functionality of pcm_notify in snd-aloop?" https://mailman.alsa-project.org/pipermail/alsa-devel/2020-April/166974.html .. we discussed the possibility for ALSA to provide a mechanism for application to wait for the condition to change, but at least for the currently known usages, the synchronization responsibility will be in user-space (UCM file will describe the PCM dependencies). Anyways, this is orthogonal to documenting -ENODATA, so sending this now. Kai Vehmanen (2): pcm: add documentation for -ENODATA error code pcm: fix spelling in documentation for -EBADFD src/pcm/pcm.c | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) -- 2.26.2

2 3

[v2, 1/2] ASoC: mediatek: mt6358: support DMIC one-wire mode
by Jiaxin Yu 05 Jun '20

05 Jun '20

Supports DMIC one-wire mode. Uses a DT property "dmic-mode" to select. Signed-off-by: Jiaxin Yu <jiaxin.yu(a)mediatek.com> --- sound/soc/codecs/mt6358.c | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/sound/soc/codecs/mt6358.c b/sound/soc/codecs/mt6358.c index 1b830ea..1f39d59 100644 --- a/sound/soc/codecs/mt6358.c +++ b/sound/soc/codecs/mt6358.c @@ -95,6 +95,8 @@ struct mt6358_priv { struct regulator *avdd_reg; int wov_enabled; + + unsigned int dmic_one_wire_mode; }; int mt6358_set_mtkaif_protocol(struct snd_soc_component *cmpnt, @@ -1831,7 +1833,10 @@ static int mt6358_dmic_enable(struct mt6358_priv *priv) mt6358_mtkaif_tx_enable(priv); /* UL dmic setting */ - regmap_write(priv->regmap, MT6358_AFE_UL_SRC_CON0_H, 0x0080); + if (priv->dmic_one_wire_mode) + regmap_write(priv->regmap, MT6358_AFE_UL_SRC_CON0_H, 0x0400); + else + regmap_write(priv->regmap, MT6358_AFE_UL_SRC_CON0_H, 0x0080); /* UL turn on */ regmap_write(priv->regmap, MT6358_AFE_UL_SRC_CON0_L, 0x0003); @@ -2426,6 +2431,20 @@ static int mt6358_codec_probe(struct snd_soc_component *cmpnt) .num_dapm_routes = ARRAY_SIZE(mt6358_dapm_routes), }; +static void mt6358_parse_dt(struct mt6358_priv *priv) +{ + int ret; + struct device *dev = priv->dev; + + ret = of_property_read_u32(dev->of_node, "mediatek,dmic-mode", + &priv->dmic_one_wire_mode); + if (ret) { + dev_warn(priv->dev, "%s() failed to read dmic-mode\n", + __func__); + priv->dmic_one_wire_mode = 0; + } +} + static int mt6358_platform_driver_probe(struct platform_device *pdev) { struct mt6358_priv *priv; @@ -2445,6 +2464,8 @@ static int mt6358_platform_driver_probe(struct platform_device *pdev) if (IS_ERR(priv->regmap)) return PTR_ERR(priv->regmap); + mt6358_parse_dt(priv); + dev_info(priv->dev, "%s(), dev name %s\n", __func__, dev_name(&pdev->dev)); -- 1.8.1.1.dirty

1 1