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

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

broadwell-rt286, bdw-rt5677: Fix inconsistency in card detection
by GitHub pull_request - edited 13 Mar '21

13 Mar '21

alsa-project/alsa-ucm-conf pull request #85 was edited from dpward: This conveniently provides a workaround for a bug in kernel 5.10: https://bugzilla.kernel.org/show_bug.cgi?id=211985 Request URL : https://github.com/alsa-project/alsa-ucm-conf/pull/85 Patch URL : https://github.com/alsa-project/alsa-ucm-conf/pull/85.patch Repository URL: https://github.com/alsa-project/alsa-ucm-conf

1 0

[PATCH alsa-ucm-conf v2 0/7] codecs/rt5640: Cleanup + HW volume control support
by Hans de Goede 13 Mar '21

13 Mar '21

Hi All, Here is v2 of my patch series consisting of some codecs/rt5640 cleanups and addition of HW volume control support to the rt5640 .conf snippets. This new version has been updated to deal with the "[PATCH 3/5] ASoC: rt5640: Add emulated 'DAC1 Playback Switch' control" kernel-patch being dropped. Note patch 7 depends on a new "aif:%d" part being added to the components string, the kernel patches for this are pending upstream in the "[PATCH resend 0/2] AsoC: rt5640/rt5651: Volume control fixes" patch-series. As such patch 7 should probably not be merged until the kernel patches have landed, because theoretically the new component string part could change as part of the review of the kernel patches. Patches 1-6 are ready to be merged now. Regards, Hans Hans de Goede (7): codecs/rt5640: Cleanup: unify Stereo / Mono ADC handling codecs/rt5640: Cleanup: Initially disable all inputs and outputs codecs/rt5640: Cleanup: Move 'SPK MIX' setup to main EnableSequene codecs/rt5640: Drop bogus 'DIG MIXL DAC L2 Switch' setting codecs/rt5640: Unify capture volume for AIF1 and AIF2 recording paths codecs/rt5640: Add hardware volume-control support codecs/rt5640: Specify Playback/CaptureMasterElem for HW volume-control ucm2/bytcr-rt5640/HiFi.conf | 21 +++++++++++ ucm2/codecs/rt5640/DigitalMics.conf | 18 ++++++++- ucm2/codecs/rt5640/EnableSeq.conf | 50 ++++++++++++++++++++----- ucm2/codecs/rt5640/HeadPhones.conf | 15 +++++++- ucm2/codecs/rt5640/HeadsetMic.conf | 24 ++++++++---- ucm2/codecs/rt5640/IN1-InternalMic.conf | 27 +++++++------ ucm2/codecs/rt5640/IN3-InternalMic.conf | 27 +++++++------ ucm2/codecs/rt5640/MonoSpeaker.conf | 17 +++++++-- ucm2/codecs/rt5640/Speaker.conf | 17 +++++++-- 9 files changed, 167 insertions(+), 49 deletions(-) -- 2.30.1

2 10

[PATCH alsa-ucm-conf 1/2] codecs/rt5672: Move +12dB input boost from 'STO1 ADC Boost Gain' to 'ADC Capture Volume'
by Hans de Goede 13 Mar '21

13 Mar '21

Both the 'STO1 ADC Boost Gain' and the 'ADC Capture Volume' controls are digital and the 'ADC Capture Volume' control goes up to +30dB. When adding hw-volume-control support adding the +12dB boost gain on to of the max +30dB of 'ADC Capture Volume' is a bit too much. So move the +12dB from the 'STO1 ADC Boost Gain' control to the 'ADC Capture Volume' control. This way we keep the same setting for userspace which does not support hw-volume-control, while getting a better range when we start using 'ADC Capture Volume' as hw-volume-control. Signed-off-by: Hans de Goede <hdegoede(a)redhat.com> --- ucm2/codecs/rt5672/EnableSeq.conf | 13 ++++++------- 1 file changed, 6 insertions(+), 7 deletions(-) diff --git a/ucm2/codecs/rt5672/EnableSeq.conf b/ucm2/codecs/rt5672/EnableSeq.conf index ddfb1c7..e373275 100644 --- a/ucm2/codecs/rt5672/EnableSeq.conf +++ b/ucm2/codecs/rt5672/EnableSeq.conf @@ -26,14 +26,13 @@ EnableSequence [ # cset "name='LOUT MIX OUTMIX L Switch' on" # cset "name='LOUT MIX OUTMIX R Switch' on" - # 47=0dB, 0.375 dB/step - cset "name='ADC Capture Volume' 47" + # Both the DMICs and the headset mic (even with the 20dB boost below) + # are quite soft, set the default capture volume to +12dB + # 47=0dB, 0.375dB/step, 79=+12dB + cset "name='ADC Capture Volume' 79" cset "name='ADC Capture Switch' on" - - # Both the DMICs and the headset mic (even with the 20 dB boost below) - # are quite soft, set the ADC Boost gain (range 0-3) to 1 = 12 dB the - # next step is 24 dB which is a bit too much - cset "name='STO1 ADC Boost Gain Volume' 1" + # 0=0dB + cset "name='STO1 ADC Boost Gain Volume' 0" # Headset mic is quite soft, boost it a bit, 1 = 20dB which is the first # available boost step -- 2.30.1

2 3