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

[PATCH] sound:fix typo in rt5663.c
by mateng 15 Mar '21

15 Mar '21

From: mateng <mateng(a)yulong.com> interrput -> interrupt Signed-off-by: mateng <mateng(a)yulong.com> --- sound/soc/codecs/rt5663.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/soc/codecs/rt5663.c b/sound/soc/codecs/rt5663.c index 619fb9a..411ff30 100644 --- a/sound/soc/codecs/rt5663.c +++ b/sound/soc/codecs/rt5663.c @@ -1967,7 +1967,7 @@ static void rt5663_jack_detect_work(struct work_struct *work) btn_type); break; } - /* button release or spurious interrput*/ + /* button release or spurious interrupt*/ if (btn_type == 0) { report = rt5663->jack_type; cancel_delayed_work_sync( -- 1.9.1

1 0

[PATCH 0/7] ASoC: codecs: add wcd938x support
by Srinivas Kandagatla 15 Mar '21

15 Mar '21

This patchset adds support for Qualcomm WCD938X codec. Qualcomm WCD9380/WCD9385 Codec is a standalone Hi-Fi audio codec IC connected over SoundWire. This device has two SoundWire devices, RX and TX respectively supporting 4 x ADCs, ClassH, Ear, Aux PA, 2xHPH, 7 x TX diff inputs, 8 DMICs and MBHC. Even though this device has two SoundWire devices, only tx device has access to main codec Control/Status Registers! This patchset along with other SoundWire patches on the list have been tested on SM8250 MTP device. Am planning to send support for MBHC once this driver gets accepted! Thanks, srini Srinivas Kandagatla (7): ASoC: dt-bindings: wcd938x: add bindings for wcd938x ASoC: codecs: wcd-clsh: add new version support ASoC: codecs: wcd938x: add basic driver ASoC: codecs: wcd938x: add basic controls ASoC: codecs: wcd938x: add playback dapm widgets ASoC: codecs: wcd938x: add capture dapm widgets ASoC: codecs: wcd938x: add audio routing .../bindings/sound/qcom,wcd938x.yaml | 127 + sound/soc/codecs/Kconfig | 9 + sound/soc/codecs/Makefile | 2 + sound/soc/codecs/wcd-clsh-v2.c | 350 +- sound/soc/codecs/wcd-clsh-v2.h | 16 + sound/soc/codecs/wcd938x-sdw.c | 294 ++ sound/soc/codecs/wcd938x.c | 3688 +++++++++++++++++ sound/soc/codecs/wcd938x.h | 675 +++ 8 files changed, 5151 insertions(+), 10 deletions(-) create mode 100644 Documentation/devicetree/bindings/sound/qcom,wcd938x.yaml create mode 100644 sound/soc/codecs/wcd938x-sdw.c create mode 100644 sound/soc/codecs/wcd938x.c create mode 100644 sound/soc/codecs/wcd938x.h -- 2.21.0

2 13

kernel branch for submitting patches
by Mikhail Durnev 15 Mar '21

15 Mar '21

Dear All, I am new to ALSA development in Linux kernel. Is my understanding correct that new patches should be created against the for-next branch in https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git ? When I tried to create a patch on top of the master branch of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git and send it to linux-kernel(a)vger.kernel.org, my patch was ignored. Reading docs from www.alsa-project.org did not help much. In this mailing list I found that patches should probably go to broonie/sound.git for-next first. Looking forward to receiving your help. Thanks, Mikhail

2 1

Wrong description in emu0404_netlist.h
by GitHub issues - reopened 15 Mar '21

15 Mar '21

alsa-project/alsa-firmware issue #4 was reopened from Usr666x: It says: > This is the FPGA firmware for EMU Systems's Audio Dock, > Present in the EMU1820 and EMU1820m products. > It is nicknamed "audio_dock". This is a mistake because it's a description taken from audio_dock_netlist.h. emu0404 should have its own description. Issue URL : https://github.com/alsa-project/alsa-firmware/issues/4 Repository URL: https://github.com/alsa-project/alsa-firmware

1 0

Wrong description in emu0404_netlist.h
by GitHub issues - edited 15 Mar '21

15 Mar '21

alsa-project/alsa-firmware issue #4 was edited from Usr666x: It says: > This is the FPGA firmware for EMU Systems's Audio Dock, > Present in the EMU1820 and EMU1820m products. > It is nicknamed "audio_dock". This is a mistake because it's a description taken from audio_dock_netlist.h. emu0404 should have its own description. Issue URL : https://github.com/alsa-project/alsa-firmware/issues/4 Repository URL: https://github.com/alsa-project/alsa-firmware

1 0

Wrong description in emu0404_netlist.h
by GitHub issues - opened 15 Mar '21

15 Mar '21

alsa-project/alsa-firmware issue #4 was opened from Usr666x: It says: /* This is the FPGA firmware for EMU Systems's Audio Dock, * Present in the EMU1820 and EMU1820m products. * It is nicknamed "audio_dock". */ This is a mistake because it's a description taken from audio_dock_netlist.h. emu0404 should have its own description. Issue URL : https://github.com/alsa-project/alsa-firmware/issues/4 Repository URL: https://github.com/alsa-project/alsa-firmware

1 0

Midi timestamps
by David Henningsson 14 Mar '21

14 Mar '21

Hi, When writing an application that records midi (and e g saves it to disk), ultra-low latency isn't really needed, all we need to know is exactly when the midi message came in. The application can then wake up once a second or so, to write the incoming data, including an accurate timestamp for every event, to disk. As far as I can see, the rawmidi interface does not support such a feature at all. There is a snd_rawmidi_status syscall, but its timestamp field is not even filled by the kernel (!). But even if that was fixed, it would not fix the problem as there could be several midi events in the buffer with different timestamps. You could use the seq interface, it does support timestamps, but I can see at least two potential problems with this: First, the seq code runs in a work queue, not in the actual IRQ. This means that midi event is timestamped too late, especially so if the work is delayed for some reason. Second, seq hard-codes the timestamp type to monotonic - there is no monotonic_raw, so the timestamp would be affected by NTP changes. Also, the timespec uses 32-bit for sec and nsec, but I suspect this is less of a problem (unless people constantly record midi for sixty years or so...). It seems like it could be useful to have a rawmidi mode which automatically prefixes every incoming message with a timestamp. This would replace the current "raw" midi buffer with some type of header "length, timestamp, data" or so. Arguably this would make the rawmidi slightly less raw, but anyway. Does this make sense? Should I attempt to write something? Or would it be better to try to use (and potentially improve) the seq code? // David

1 0

[PATCH] speaker-test: add support for S24_LE and S24_BE
by Pierre-Louis Bossart 14 Mar '21

14 Mar '21

These formats are sometimes advertised by drivers, e.g. SOF. The format is 3 bytes packed in 32-bit container, with the MSB zeroed out. sample: 0x00123456 S24_LE format: b0 56 b1 34 b2 12 b3 00 S24_BE format: b0 00 b1 12 b2 34 b3 56 I only tested the S24_LE format with the SOF driver, S24_BE was added for symmetry only. Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart(a)linux.intel.com> --- speaker-test/speaker-test.c | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) diff --git a/speaker-test/speaker-test.c b/speaker-test/speaker-test.c index 773af0a..fd13d88 100644 --- a/speaker-test/speaker-test.c +++ b/speaker-test/speaker-test.c @@ -285,6 +285,8 @@ static const int supported_formats[] = { SND_PCM_FORMAT_FLOAT_LE, SND_PCM_FORMAT_S24_3LE, SND_PCM_FORMAT_S24_3BE, + SND_PCM_FORMAT_S24_LE, + SND_PCM_FORMAT_S24_BE, SND_PCM_FORMAT_S32_LE, SND_PCM_FORMAT_S32_BE, -1 @@ -338,6 +340,20 @@ static void do_generate(uint8_t *frames, int channel, int count, *samp8++ = BE_INT(res.i) >> 8; *samp8++ = BE_INT(res.i) >> 16; break; + case SND_PCM_FORMAT_S24_LE: + res.i >>= 8; + *samp8++ = LE_INT(res.i); + *samp8++ = LE_INT(res.i) >> 8; + *samp8++ = LE_INT(res.i) >> 16; + *samp8++ = 0; + break; + case SND_PCM_FORMAT_S24_BE: + res.i >>= 8; + *samp8++ = 0; + *samp8++ = BE_INT(res.i); + *samp8++ = BE_INT(res.i) >> 8; + *samp8++ = BE_INT(res.i) >> 16; + break; case SND_PCM_FORMAT_S32_LE: *samp32++ = LE_INT(res.i); break; -- 2.25.1

2 1

alsa-lib's new API issue (snd_ctl_elem_id_compare)
by Takashi Sakamoto 14 Mar '21

14 Mar '21

Hi Jaroslav, I have some concern about your commit 2cfe6addaef6[1] for alsa-lib, It adds new library API, 'snd_ctl_elem_id_compare()', to compare a pair of IDs for control element. In the implementation, the API call returns 0 if they are the same, else negative or positive numeric value according to contents of the IDs. My concerns are: 1. evaluation of numid field is not covered. This is not preferable since ALSA control core implementation covers two types of comparison; numid only, and the combination iface, device, subdevice, name, and index fields. If the API is produced for general use cases, it should correctly handle the numid-only case, in my opinion. 2. tri-state return value is semantically inconsistent The ID structure includes three types of values; integer, enumeration, and string. In my opinion, tri-state return value from them has different meaning each other. It's better just to return comparison result by boolean value, in my opinion. The reason I post this message instead of posting any fix is that the fix to the API affects to alsa-utils, in which the API is used by a patch you applied a few days ago[2]. The patch also includes change to 'AM_PATH_ALSA' declaration in configure.ac with bumped-up version to '1.2.5', and it disables to rebuild alsa-utils on the latest toolchain. (alsa-lib 1.2.5 is not released yet.) I'd like to drop the usage of API from alsa-utils with equivalent alternative codes in alsa-utils side at first, apart from the new API in alsa-lib so that alsa-utils can be still build on the latest toolchains to avoid any confusion in user side. Then I'd fix the issued API carefully so that it can be used so long as exposed API without any issue. [1] https://github.com/alsa-project/alsa-lib/commit/2cfe6addaef6a0afa72699ec07a… [2] https://github.com/alsa-project/alsa-utils/commit/17b4129e6c89d1a96d4d86dab… Regards Takashi Sakamoto

2 8

[PATCH] sound: soc: fsl: Remove unnecessary THIS_MODULE
by Wang Qing 13 Mar '21

13 Mar '21

As THIS_MODULE has been set in module_platform_driver(), so remove it. Signed-off-by: Wang Qing <wangqing(a)vivo.com> --- sound/soc/fsl/imx-hdmi.c | 1 - 1 file changed, 1 deletion(-) diff --git a/sound/soc/fsl/imx-hdmi.c b/sound/soc/fsl/imx-hdmi.c index dbbb761..cd0235a --- a/sound/soc/fsl/imx-hdmi.c +++ b/sound/soc/fsl/imx-hdmi.c @@ -223,7 +223,6 @@ MODULE_DEVICE_TABLE(of, imx_hdmi_dt_ids); static struct platform_driver imx_hdmi_driver = { .driver = { .name = "imx-hdmi", - .owner = THIS_MODULE, .pm = &snd_soc_pm_ops, .of_match_table = imx_hdmi_dt_ids, }, -- 2.7.4

2 1