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

Allow for an optional output in plugin multi
by GitHub issues - opened 22 Jan '24

22 Jan '24

alsa-project/alsa-lib issue #379 was opened from wonbinbk: Let's say I have 2 sound cards, card 0 and card 1. Card 1 is unplug-able from the system so it might not exist when applications read asound.conf. I think it makes sense to add ability to specify an optional pcm device which if it doesn't exist won't break alsa. ``` ALSA lib ../../alsa-lib-1.2.6.1/src/confmisc.c:165:(snd_config_get_card) Cannot get card index for 1 ``` Issue URL : https://github.com/alsa-project/alsa-lib/issues/379 Repository URL: https://github.com/alsa-project/alsa-lib

1 0

How to configure a pcm to write to it periodically?
by Philipp Stanner 21 Jan '24

21 Jan '24

Hi all, hope this is the right list. [1] stated that it's also intended for "application developers", so I ask here. I've got a program that uses timers to periodically read samples from a microphone and write to a sound device. The timer's period is, for example, 20ms. So I have a sample rate of r = 16000, frame sizes of 20ms, a bit depth of 16 and therefore 320 samples per 20ms. I try to write those 320 samples timer-controled every 20ms to the pcm device. That works fine when reading samples. When writing, however, it seems that snd_pcm_writei() blocks longer than the 20ms. Which it shouldn't do, as far as I understand snd_pcm_set_params() delay-parameter. I'll attach the example below. So, I'd have a number of questions: 1. Am I even using ALSA as it's intended? As far as I saw in the API, there's the possiblity to get poll()able file descriptors from the API. So should I, instead of using my own timers, configure the ALSA interface to become readable every 20ms? 2. Why does my example not work as I intended? What does the "latency" parameter in snd_pcm_set_params() actually do? 3. Is the 'size' parameter in the write functions [2] the size in bytes or in samples? So if I configured SND_PCM_S16_LE and pass size = 10, will it read 10 bytes or 160 bit? It seems to be that it's the number of samples, whose type has been set with snd_pcm_set_params(). The docu isn't super clear to me, though. It seems that the size parameter has changed a bit. At least the examples here [3] are faulting when I build them with -fsanitize=address Thx a lot! Philipp [1] https://www.alsa-project.org/wiki/Mailing-lists [2] https://www.alsa-project.org/alsa-doc/alsa-lib/group___p_c_m.html#gabc748a5… [3] http://equalarea.com/paul/alsa-audio.html Example: /* * This is a mini-example of the code I took for my draft ofa broader application. * The main difference is that I call snd_pcm_writei() when my timer fires. */ #include <alsa/asoundlib.h> static char *device = "default"; /* playback device */ unsigned char buffer[16*1024]; /* some random data */ int main(void) { int err; unsigned int i; snd_pcm_t *handle; snd_pcm_sframes_t frames; for (i = 0; i < sizeof(buffer); i++) buffer[i] = random() & 0xff; if ((err = snd_pcm_open(&handle, device, SND_PCM_STREAM_PLAYBACK, 0)) < 0) { printf("Playback open error: %s\n", snd_strerror(err)); exit(EXIT_FAILURE); } if ((err = snd_pcm_set_params(handle, SND_PCM_FORMAT_S16_LE, SND_PCM_ACCESS_RW_INTERLEAVED, 1, 16000, 1, 20000)) < 0) { printf("Playback open error: %s\n", snd_strerror(err)); exit(EXIT_FAILURE); } for (i = 0; i < 16; i++) { frames = snd_pcm_writei(handle, buffer, sizeof(buffer) / sizeof(short)); if (frames < 0) frames = snd_pcm_recover(handle, frames, 0); if (frames < 0) { printf("snd_pcm_writei failed: %s\n", snd_strerror(frames)); break; } if (frames > 0 && frames < (long)(sizeof(buffer) / sizeof(short))) printf("Short write (expected %li, wrote %li)\n", (long)(sizeof(buffer) / sizeof(short)), frames); } /* pass the remaining samples, otherwise they're dropped in close */ err = snd_pcm_drain(handle); if (err < 0) printf("snd_pcm_drain failed: %s\n", snd_strerror(err)); snd_pcm_close(handle); return 0; }

1 1

RE: [PATCH 3/5] ASoC: codecs: ES8326: Adding new volume kcontrols
by Zhu Ning 20 Jan '24

20 Jan '24

> Volumes should be standard volume controls with TLV information rather > than enumerations. I see that you can't just use a standard volume > control here since there's an invalid value that needs to be skipped > over, and it doesn't help that there's no ordering to the values either. > I think the best thing would probably be to open code a custom volume > control - this feels weird enough that it's probably not worrying about > trying for reuse. Just have put and get functions that map 0..6 into > the register values for the volumes in ascending order, then you can > have a control that looks normal to userspace. I'll try your mentioned method in a new version of the same patch.

1 0

RE: [PATCH 3/5] ASoC: codecs: ES8326: Adding new volume kcontrols
by Zhu Ning 20 Jan '24

20 Jan '24

> kernel test robot noticed the following build errors: > [auto build test ERROR on broonie-sound/for-next] > [also build test ERROR on tiwai-sound/for-next tiwai-sound/for-linus linus/master next-20240119] > [cannot apply to v6.7] > [If your patch is applied to the wrong git tree, kindly drop us a note. > And when submitting patch, we suggest to use '--base' as documented in > https://git-scm.com/docs/git-format-patch#_base_tree_information] > url: https://github.com/intel-lab-lkp/linux/commits/Zhu-Ning/ASoC-codecs-ES8326-… > base: https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next > patch link: https://lore.kernel.org/r/20240119112858.2982-4-zhuning0077%40gmail.com > patch subject: [PATCH 3/5] ASoC: codecs: ES8326: Adding new volume kcontrols > config: m68k-allmodconfig (https://download.01.org/0day-ci/archive/20240120/202401201033.SJS8Mtlr-lkp@…) > compiler: m68k-linux-gcc (GCC) 13.2.0 > reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240120/202401201033.SJS8Mtlr-lkp@…) > If you fix the issue in a separate patch/commit (i.e. not just a new version of > the same patch/commit), kindly add following tags > | Reported-by: kernel test robot <lkp(a)intel.com> > | Closes: https://lore.kernel.org/oe-kbuild-all/202401201033.SJS8Mtlr-lkp@intel.com/ I'm so sorry for my mistake.I'll fix it in the new version of the same patch/commit.

1 0

[PATCH 0/5] ASoC: codecs: fix ES8326 performance and pop noise
by Zhu Ning 20 Jan '24

20 Jan '24

Hi , 5 patches here for the es8326 driver... We get some issues regarding crosstalk, THD+N performance and pop noise from customer's project. Five patches are used to fix these issues. We did tests with the new driver. The test results form test department met our expectations. Thanks, Michael. Zhu Ning (5): ASoC: codecs: ES8326: improving crosstalk performance ASoC: codecs: ES8326: Improving the THD+N performance ASoC: codecs: ES8326: Adding new volume kcontrols ASoC: codecs: ES8326: Minimize the pop noise on headphone ASoC: codecs: ES8326: fix the capture noise issue sound/soc/codecs/es8326.c | 216 +++++++++++++++++++++++++++++--------- sound/soc/codecs/es8326.h | 8 +- 2 files changed, 175 insertions(+), 49 deletions(-) -- 2.17.1

3 7

Dmic mute button is not working with SOF based acp-dmic solution
by GitHub issues - opened 19 Jan '24

19 Jan '24

alsa-project/alsa-ucm-conf issue #385 was opened from Venkata-Prasad-Potturu: Hi, We have enabled ACP-DMIC endpoint support using SOF stack, and created mixer controls for capture switch and volume. Trying to link Mic mute button with amixer controls in the UCM config file, but unable to invoke the enable/disable sequence when we press mic mute button. Please find the below ucm configuration, amixer controls and pactl list. [pactl_list.txt](https://github.com/alsa-project/alsa-ucm-conf/files/1398821… Could anyone help on this. **AMIXER CONTROLS:-** _**root@systemc-Mayan-RMB:/usr/share/alsa/ucm2#**_ arecord -l **** List of CAPTURE Hardware Devices **** card 1: sofrmbdsp [sof-rmb-dsp], device 6: DMIC (*) [] Subdevices: 0/1 Subdevice #0: subdevice #0 **_root@systemc-Mayan-RMB:/usr/share/alsa/ucm2#_** **amixer -c 1 contents** numid=2,iface=MIXER,name='PGA4.0 4 Master Capture Switch' ; type=BOOLEAN,access=rw------,values=2 : values=on,on numid=1,iface=MIXER,name='PGA4.0 4 Master Capture Volume' ; type=INTEGER,access=rw---R--,values=2,min=0,max=80,step=0 : values=44,44 | dBscale-min=-50.00dB,step=1.00dB,mute=1 **_root@systemc-Mayan-RMB:/usr/share/alsa/ucm2#_** **UCM Configuration:-** SectionDevice."dmic" { Comment "Digital Microphone" EnableSequence [ exec "echo DMIC EnableSequence" cset "name='PGA4.0 4 Master Capture Switch' 1" cset "name='PGA4.0 4 Master Capture Volume' 44" ] DisableSequence [ exec "echo DMIC DisableSequence" cset "name='PGA4.0 4 Master Capture Switch' 0" cset "name='PGA4.0 4 Master Capture Volume' 33" ] Value { CapturePriority 100 CapturePCM "hw:${CardId},6" } } Issue URL : https://github.com/alsa-project/alsa-ucm-conf/issues/385 Repository URL: https://github.com/alsa-project/alsa-ucm-conf

1 0

[PATCH v3 0/5] ASoC: qcom: volume fixes and codec cleanups
by Johan Hovold 19 Jan '24

19 Jan '24

To reduce the risk of speaker damage the PA gain needs to be limited on machines like the Lenovo Thinkpad X13s until we have active speaker protection in place. Limit the gain to the current default setting provided by the UCM configuration which most user have so far been using (due to a bug in the configuration files which prevented hardware volume control [1]). The wsa883x PA volume control also turned out to be broken, which meant that the default setting used by UCM configuration is actually the lowest level (-3 dB). With the codec driver fixed, hardware volume control also works as expected once we lift the PA volume limit. Note that the new wsa884x driver most likely suffers from a similar bug, I'll send a fix for that once I've got that confirmed. Included is also a related fix for the LPASS WSA macro driver, which was changing the digital gain setting behind the back of user space and which can result in excessive (or too low) digital gain. There are further Qualcomm codec drivers that similarly appear to manipulate various gain settings, but on closer inspection it turns out that they only write back the current settings. Tests reveal that these writes are indeed needed for any prior updates to take effect (at least for the WSA and RX macros). Johan [1] https://github.com/alsa-project/alsa-ucm-conf/pull/382 Changes in v3 - fix the wsa883x PA volume control and update the machine limits accordingly Changes in v2 - keep the volume register write on power-on in lpass-wsa-macro - drop the other patches removing volume register writes on DAPM events - only drop the constant-zero gain offsets in wcd9335 Johan Hovold (5): ASoC: codecs: wsa883x: fix PA volume control ASoC: codecs: wsa883x: lower default PA gain ASoC: qcom: sc8280xp: limit speaker volumes ASoC: codecs: lpass-wsa-macro: fix compander volume hack ASoC: codecs: wcd9335: drop unused gain hack remnant sound/soc/codecs/lpass-wsa-macro.c | 7 ------- sound/soc/codecs/wcd9335.c | 4 ---- sound/soc/codecs/wsa883x.c | 6 +++--- sound/soc/qcom/sc8280xp.c | 8 +++++--- 4 files changed, 8 insertions(+), 17 deletions(-) -- 2.41.0

4 18

Clarify snd_pcm_hw_params_set_drain_silence documentation
by GitHub issues - opened 18 Jan '24

18 Jan '24

alsa-project/alsa-lib issue #378 was opened from z-s-e: The API documentation states that drain silence is enabled by default. But since this is a hardware parameter, is it possible that some hardware does not support this? Or is this always available (and will cause alsa-lib internal software workarounds for hardware that doesn't have perfect drain)? Also, the documentation mentions the sw_params silencing mechanism as usable for a manual emulation of this, but the documentation of the sw_params silence_size/silence_threshold imply they only affect the silencing behavior in case of underrun, not in case of draining. I can create a patch for the documentation if you'd like, as soon as I get the needed info. Issue URL : https://github.com/alsa-project/alsa-lib/issues/378 Repository URL: https://github.com/alsa-project/alsa-lib

1 0

[PATCH v11 00/15] Add audio support in v4l2 framework
by Shengjiu Wang 18 Jan '24

18 Jan '24

Audio signal processing also has the requirement for memory to memory similar as Video. This asrc memory to memory (memory ->asrc->memory) case is a non real time use case. User fills the input buffer to the asrc module, after conversion, then asrc sends back the output buffer to user. So it is not a traditional ALSA playback and capture case. It is a specific use case, there is no reference in current kernel. v4l2 memory to memory is the closed implementation, v4l2 current support video, image, radio, tuner, touch devices, so it is not complicated to add support for this specific audio case. Because we had implemented the "memory -> asrc ->i2s device-> codec" use case in ALSA. Now the "memory->asrc->memory" needs to reuse the code in asrc driver, so the first 3 patches is for refining the code to make it can be shared by the "memory->asrc->memory" driver. The main change is in the v4l2 side, A /dev/vl4-audioX will be created, user applications only use the ioctl of v4l2 framework. Other change is to add memory to memory support for two kinds of i.MX ASRC module. changes in v11 - add add-fixed-point-test-controls in vivid. - add v4l2_ctrl_fp_compose() helper function for min and max changes in v10 - remove FIXED_POINT type - change code base on media: v4l2-ctrls: add support for fraction_bits - fix issue reported by kernel test robot - remove module_alias changes in v9: - add MEDIA_ENT_F_PROC_AUDIO_RESAMPLER. - add MEDIA_INTF_T_V4L_AUDIO - add media controller support - refine the vim2m-audio to support 8k<->16k conversion. changes in v8: - refine V4L2_CAP_AUDIO_M2M to be 0x00000008 - update doc for FIXED_POINT - address comments for imx-asrc changes in v7: - add acked-by from Mark - separate commit for fixed point, m2m audio class, audio rate controls - use INTEGER_MENU for rate, FIXED_POINT for rate offset - remove used fmts - address other comments for Hans changes in v6: - use m2m_prepare/m2m_unprepare/m2m_start/m2m_stop to replace m2m_start_part_one/m2m_stop_part_one, m2m_start_part_two/m2m_stop_part_two. - change V4L2_CTRL_TYPE_ASRC_RATE to V4L2_CTRL_TYPE_FIXED_POINT - fix warning by kernel test rebot - remove some unused format V4L2_AUDIO_FMT_XX - Get SNDRV_PCM_FORMAT from V4L2_AUDIO_FMT in driver. - rename audm2m to viaudm2m. changes in v5: - remove V4L2_AUDIO_FMT_LPCM - define audio pixel format like V4L2_AUDIO_FMT_S8... - remove rate and format in struct v4l2_audio_format. - Add V4L2_CID_ASRC_SOURCE_RATE and V4L2_CID_ASRC_DEST_RATE controls - updata document accordingly. changes in v4: - update document style - separate V4L2_AUDIO_FMT_LPCM and V4L2_CAP_AUDIO_M2M in separate commit changes in v3: - Modify documents for adding audio m2m support - Add audio virtual m2m driver - Defined V4L2_AUDIO_FMT_LPCM format type for audio. - Defined V4L2_CAP_AUDIO_M2M capability type for audio m2m case. - with modification in v4l-utils, pass v4l2-compliance test. changes in v2: - decouple the implementation in v4l2 and ALSA - implement the memory to memory driver as a platfrom driver and move it to driver/media - move fsl_asrc_common.h to include/sound folder Shengjiu Wang (15): ASoC: fsl_asrc: define functions for memory to memory usage ASoC: fsl_easrc: define functions for memory to memory usage ASoC: fsl_asrc: move fsl_asrc_common.h to include/sound ASoC: fsl_asrc: register m2m platform device ASoC: fsl_easrc: register m2m platform device media: uapi: Add V4L2_CAP_AUDIO_M2M capability flag media: v4l2: Add audio capture and output support media: uapi: Define audio sample format fourcc type media: uapi: Add V4L2_CTRL_CLASS_M2M_AUDIO media: uapi: Add audio rate controls support media: uapi: Declare interface types for Audio media: uapi: Add an entity type for audio resampler media: vivid: add fixed point test controls media: imx-asrc: Add memory to memory driver media: vim2m-audio: add virtual driver for audio memory to memory .../media/mediactl/media-types.rst | 11 + .../userspace-api/media/v4l/buffer.rst | 6 + .../userspace-api/media/v4l/common.rst | 1 + .../media/v4l/dev-audio-mem2mem.rst | 71 + .../userspace-api/media/v4l/devices.rst | 1 + .../media/v4l/ext-ctrls-audio-m2m.rst | 41 + .../userspace-api/media/v4l/pixfmt-audio.rst | 87 ++ .../userspace-api/media/v4l/pixfmt.rst | 1 + .../media/v4l/vidioc-enum-fmt.rst | 2 + .../media/v4l/vidioc-g-ext-ctrls.rst | 4 + .../userspace-api/media/v4l/vidioc-g-fmt.rst | 4 + .../media/v4l/vidioc-querycap.rst | 3 + .../media/videodev2.h.rst.exceptions | 3 + .../media/common/videobuf2/videobuf2-v4l2.c | 4 + drivers/media/platform/nxp/Kconfig | 13 + drivers/media/platform/nxp/Makefile | 1 + drivers/media/platform/nxp/imx-asrc.c | 1264 +++++++++++++++++ drivers/media/test-drivers/Kconfig | 11 + drivers/media/test-drivers/Makefile | 1 + drivers/media/test-drivers/vim2m-audio.c | 799 +++++++++++ drivers/media/test-drivers/vivid/vivid-core.h | 2 + .../media/test-drivers/vivid/vivid-ctrls.c | 26 + drivers/media/v4l2-core/v4l2-compat-ioctl32.c | 9 + drivers/media/v4l2-core/v4l2-ctrls-defs.c | 10 + drivers/media/v4l2-core/v4l2-dev.c | 21 + drivers/media/v4l2-core/v4l2-ioctl.c | 66 + drivers/media/v4l2-core/v4l2-mem2mem.c | 13 +- include/media/v4l2-ctrls.h | 3 + include/media/v4l2-dev.h | 2 + include/media/v4l2-ioctl.h | 34 + .../fsl => include/sound}/fsl_asrc_common.h | 60 + include/uapi/linux/media.h | 2 + include/uapi/linux/v4l2-controls.h | 9 + include/uapi/linux/videodev2.h | 41 + sound/soc/fsl/fsl_asrc.c | 144 ++ sound/soc/fsl/fsl_asrc.h | 4 +- sound/soc/fsl/fsl_asrc_dma.c | 2 +- sound/soc/fsl/fsl_easrc.c | 233 +++ sound/soc/fsl/fsl_easrc.h | 6 +- 39 files changed, 3008 insertions(+), 7 deletions(-) create mode 100644 Documentation/userspace-api/media/v4l/dev-audio-mem2mem.rst create mode 100644 Documentation/userspace-api/media/v4l/ext-ctrls-audio-m2m.rst create mode 100644 Documentation/userspace-api/media/v4l/pixfmt-audio.rst create mode 100644 drivers/media/platform/nxp/imx-asrc.c create mode 100644 drivers/media/test-drivers/vim2m-audio.c rename {sound/soc/fsl => include/sound}/fsl_asrc_common.h (60%) -- 2.34.1

3 25

[PATCH v3 0/5] reset: gpio: ASoC: shared GPIO resets
by Krzysztof Kozlowski 17 Jan '24

17 Jan '24

Hi, Changes in v3 ============= 1. reset-gpio.c: - Add reset_gpio_of_xlate (Philipp). - reset_gpio_of_args_put->reset_gpio_of_node_put (Philipp). - Expect via platdata of_phandle_args. - Do not call device_set_node() to attach itself to reset consumer (the final device). This was questionable idea in the first place. Bartosz suggested to use GPIO_LOOKUP to solve this. 2. reset/core.c, implement Philipp's feedback. That was a lot: - Commit msg fixes. - Add new platform_device earlier, when reset core found "reset-gpios" but not "resets". - Do not overwrite of_phandle_args. - Expect matching .of_reset_n_cells. - Pass of_phandle_args as platdata to reset-gpio. - Rename reset_gpio_device->reset_gpio_lookup and others. Fix few comments and code cleanup pointed on review. - From Bartosz: Use GPIO_LOOKUP and a lot of cleanup.h in __reset_add_reset_gpio_lookup(). 3. Include here Chris' patch: "i2c: muxes: pca954x: Allow sharing reset GPIO". Changes in v2 ============= 1. wsa884x.c: add missing return in wsa884x_get_reset(), correct comment. 2. qcom,wsa8840.yaml: fix oneOf syntax. 3. reset-gpio.c: - Fix smatch warning on platdata evaluation. - Parse GPIO args and store them in rc.of_args. 4. reset/core.c: - Revise approach based on Bartosz comments: parse the reset-gpios phandle with arguments, do not use deprecated API and do not rely on gpio_desc pointer. - Create a list of instantiated platform devices to avoid any duplicates. - After creating reset-gpio platform device, try to get new reset controller or return EPROBE_DEFER. - Drop the "cookie" member and add new "of_args" to "struct reset_controller_dev". Description =========== We have at least few cases where hardware engineers decided to use one powerdown/shutdown/reset GPIO line for multiple devices: 1. WSA884x (this and previous patch): https://lore.kernel.org/all/b7aeda24-d638-45b7-8e30-80d287f498f8@sirena.org… 2. https://lore.kernel.org/all/20231027033104.1348921-1-chris.packham@alliedte… 3. https://lore.kernel.org/lkml/20191030120440.3699-1-peter.ujfalusi@ti.com/ 4. https://lore.kernel.org/all/20211018234923.1769028-1-sean.anderson@seco.com/ 5. https://social.treehouse.systems/@marcan/111268780311634160 I try to solve my case, hopefuly Chris' (2), partially Sean's (4) and maybe Hectors (5), using Rob's suggestion: https://lore.kernel.org/all/YXi5CUCEi7YmNxXM@robh.at.kernel.org/ Best regards, Krzysztof Cc: Chris Packham <chris.packham(a)alliedtelesis.co.nz> Cc: Bartosz Golaszewski <brgl(a)bgdev.pl> Cc: Sean Anderson <sean.anderson(a)seco.com> Chris Packham (1): i2c: muxes: pca954x: Allow sharing reset GPIO Krzysztof Kozlowski (4): reset: gpio: Add GPIO-based reset controller reset: Instantiate reset GPIO controller for shared reset-gpios ASoC: dt-bindings: qcom,wsa8840: Add reset-gpios for shared line ASoC: codecs: wsa884x: Allow sharing reset GPIO .../bindings/sound/qcom,wsa8840.yaml | 11 +- MAINTAINERS | 5 + drivers/i2c/muxes/i2c-mux-pca954x.c | 46 +++- drivers/reset/Kconfig | 9 + drivers/reset/Makefile | 1 + drivers/reset/core.c | 227 ++++++++++++++++-- drivers/reset/reset-gpio.c | 121 ++++++++++ include/linux/reset-controller.h | 4 + sound/soc/codecs/wsa884x.c | 53 +++- 9 files changed, 444 insertions(+), 33 deletions(-) create mode 100644 drivers/reset/reset-gpio.c -- 2.34.1

5 19