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

alsaseq: Fix type check in set_time()
by GitHub pull_request - opened 06 Apr '25

06 Apr '25

alsa-project/alsa-python pull request #17 was opened from ernestask: SeqEvent_set_time() has fallen victim to the inverted get_long1() return value here, erroring out when called with actual integers. Request URL : https://github.com/alsa-project/alsa-python/pull/17 Patch URL : https://github.com/alsa-project/alsa-python/pull/17.patch Repository URL: https://github.com/alsa-project/alsa-python

1 0

envy24control: port to GTK 3
by GitHub pull_request - opened 05 Apr '25

05 Apr '25

alsa-project/alsa-tools pull request #35 was opened from andreas56: This is a port envy24control from GTK 2 to GTK 3. Note: There is another very similar port in #27, but that one isn't quite finished. I did my port before noticing that there already was one, but I have compared them now to check that I didn't miss anything. My version has more changes, as I wanted to avoid using deprecated GTK functions. It also fixes the rendering of the level meters and optimizes it a bit so the CPU load isn't much higher than it was in GTK 2. Note 2: the fix from #31 is included in this pull request, as it is necessary for the spin buttons to work in GTK 3. Note 3: my other envy24control pull requests are not included here, as they are not related to GTK 3. #29 will probably cause merge conflicts with this one, but I will fix them if you decide to merge any of the pull requests. Request URL : https://github.com/alsa-project/alsa-tools/pull/35 Patch URL : https://github.com/alsa-project/alsa-tools/pull/35.patch Repository URL: https://github.com/alsa-project/alsa-tools

1 0

ALC4080 - general discussion (driver support)
by GitHub issues - edited 04 Apr '25

04 Apr '25

alsa-project/alsa-ucm-conf issue #541 was edited from perexg: UCM cannot add basic functionalities when the driver does not expose them. I already explained situation in [kernel bugzilla](https://bugzilla.kernel.org/show_bug.cgi?id=218913). **Note** This issue is for the kernel driver related problems. If the driver works and something is missing in UCM configuration, please, create a new issue in this tracker. It may be difficult to distinguish the right place, but if the developers redirected you here, follow the instructions bellow. **For issues like** 1. jack functionality assignment is unstable (jack functionality is not fixed - e.g. changes on warm reboot from windows) 2. low microphone volume (which cannot be controlled using native ALSA mixer controls) 3. sound is activated only after some magic plug/unplug sequence **Further steps** Try to analyze the audio driver using direct ALSA API. See [DEBUG.md](https://github.com/alsa-project/alsa-ucm-conf/blob/master/ucm2/DE…. Very nice report is in #528. Please, use it as a reference what to do. Developers usually do not have exact hardware, so observations describing which ALSA PCM device, which ALSA Mixer control, which ALSA Jack control can be used for given playback/capture device are essential. If the functionality cannot be handled with current ALSA audio driver, go to paragraphs bellow. Reverse engineering of the Windows driver. Capture USB communication and save it to a file which can be replayed by [wireshark](https://www.wireshark.org). Try to write an explanation including timing (what happened in given time slots). Driver reports should go to [kernel bugzilla](https://bugzilla.kernel.org). Add a comment with a link here. You may also push hardware vendors to create USB device which fully follows the USB audio specification, so the ALSA driver will work out-of-box (without "quirks"). **Documentation links** The documentation is not complete. Realtek support is generally very limited to provide full specification to their codecs / audio chips those years. They are providing details only to hardware vendors with a contract. If you know more, please, let us know. - [ALC4080 block scheme](https://bugzilla.kernel.org/attachment.cgi?id=306370) - [ALC4080 datasheet](https://bugzilla.kernel.org/attachment.cgi?id=307224) **Some details** ALC4080 is USB codec, thus it exposes functionality through the USB bus. The block scheme is nice to know internals, but look to the MCU paragraph in the datasheet: ``` 2.1.2. Micro Controller Unit - On-chip high-performance and low-power MCU - Ultra-low power consumption when MCU is at idle state - MCU controls connection to USB bus for re-enumeration without hot-plug - Internal programmable memory support for customized audio function - Watchdog control for MCU reset and interrupt - Configurable VID (Vendor ID), PID (Product ID), and serial number string ``` This means, that the internal firmware for this MCU unit can change the behaviour of audio hardware. Usually, the firmware is vendor specific. The USB audio hardware should comply with the USB Audio specification (refer https://www.usb.org/). The control units parsed by the ALSA driver can be obtained using 'cat /proc/asound/cardX/usbmixer' command (replace X with the correct ALSA card number). Those units are mapped to the standard mixer controls. My guess is that the firmware is not complaint with the USB audio specification and some functionality is controlled using specific USB handshake (data blocks). Issue URL : https://github.com/alsa-project/alsa-ucm-conf/issues/541 Repository URL: https://github.com/alsa-project/alsa-ucm-conf

1 0

ALC4080 - general discussion (driver support)
by GitHub issues - edited 04 Apr '25

04 Apr '25

alsa-project/alsa-ucm-conf issue #541 was edited from perexg: UCM cannot add basic functionalities when the driver does not expose them. I already explained situation in [kernel bugzilla](https://bugzilla.kernel.org/show_bug.cgi?id=218913). **Note** This issue is for the kernel driver related problems. If the driver works and something is missing in UCM configuration, please, create a new issue in this tracker. It may be difficult to distinguish the right place, but if the developers redirected you here, follow the instructions bellow. **For issues like** 1. jack functionality assignment is unstable (jack functionality is not fixed - e.g. changes on warm reboot from windows) 2. low microphone volume (which cannot be controlled using native ALSA mixer controls) 3. sound is activated only after some magic plug/unplug sequence **Further steps** Try to analyze the audio driver using direct ALSA API. See [DEBUG.md](https://github.com/alsa-project/alsa-ucm-conf/blob/master/ucm2/DE…. Very nice report is in #528. Please, use it as a reference what to do. Developers usually do not have exact hardware, so observations describing which ALSA PCM device, which ALSA Mixer control, which ALSA Jack control can be used for given playback/capture device are essential. Reverse engineering of the Windows driver. Capture USB communication and save it to a file which can be replayed by [wireshark](https://www.wireshark.org). Try to write an explanation including timing (what happened in given time slots). Driver reports should go to [kernel bugzilla](https://bugzilla.kernel.org). Add a comment with a link here. You may also push hardware vendors to create USB device which fully follows the USB audio specification, so the ALSA driver will work out-of-box (without "quirks"). **Documentation links** The documentation is not complete. Realtek support is generally very limited to provide full specification to their codecs / audio chips those years. They are providing details only to hardware vendors with a contract. If you know more, please, let us know. - [ALC4080 block scheme](https://bugzilla.kernel.org/attachment.cgi?id=306370) - [ALC4080 datasheet](https://bugzilla.kernel.org/attachment.cgi?id=307224) **Some details** ALC4080 is USB codec, thus it exposes functionality through the USB bus. The block scheme is nice to know internals, but look to the MCU paragraph in the datasheet: ``` 2.1.2. Micro Controller Unit - On-chip high-performance and low-power MCU - Ultra-low power consumption when MCU is at idle state - MCU controls connection to USB bus for re-enumeration without hot-plug - Internal programmable memory support for customized audio function - Watchdog control for MCU reset and interrupt - Configurable VID (Vendor ID), PID (Product ID), and serial number string ``` This means, that the internal firmware for this MCU unit can change the behaviour of audio hardware. Usually, the firmware is vendor specific. The USB audio hardware should comply with the USB Audio specification (refer https://www.usb.org/). The control units parsed by the ALSA driver can be obtained using 'cat /proc/asound/cardX/usbmixer' command (replace X with the correct ALSA card number). Those units are mapped to the standard mixer controls. My guess is that the firmware is not complaint with the USB audio specification and some functionality is controlled using specific USB handshake (data blocks). Issue URL : https://github.com/alsa-project/alsa-ucm-conf/issues/541 Repository URL: https://github.com/alsa-project/alsa-ucm-conf

1 0

ALC4080 - general discussion (driver support)
by GitHub issues - edited 04 Apr '25

04 Apr '25

alsa-project/alsa-ucm-conf issue #541 was edited from perexg: UCM cannot add basic functionalities when the driver does not expose them. I already explained situation in [kernel bugzilla](https://bugzilla.kernel.org/show_bug.cgi?id=218913). **Note** This issue is for the kernel driver related problems. If the driver works and something is missing in UCM configuration, please, create a new issue in this tracker. It may be difficult to distinguish the right place, but if the developers redirected you here, follow the instructions bellow. **For issues like** 1. jack functionality assignment is unstable (jack functionality is not fixed - e.g. changes on warm reboot from windows) 2. low microphone volume (which cannot be controlled using native ALSA mixer controls) 3. sound is activated only after some magic plug/unplug sequence **Further steps** Try to analyze the audio driver using direct ALSA API. See [DEBUG.md](https://github.com/alsa-project/alsa-ucm-conf/blob/master/ucm2/DE…. Very nice report is in #528. Please, use it as a reference what to do. Developers usually do not have exact hardware, so observations describing which ALSA PCM device, which ALSA Mixer control, which ALSA Jack control can be used for given playback/capture device is essential. Reverse engineering of the Windows driver. Capture USB communication and save it to a file which can be replayed by [wireshark](https://www.wireshark.org). Try to write an explanation including timing (what happened in given time slots). Driver reports should go to [kernel bugzilla](https://bugzilla.kernel.org). Add a comment with a link here. You may also push hardware vendors to create USB device which fully follows the USB audio specification, so the ALSA driver will work out-of-box (without "quirks"). **Documentation links** The documentation is not complete. Realtek support is generally very limited to provide full specification to their codecs / audio chips those years. They are providing details only to hardware vendors with a contract. If you know more, please, let us know. - [ALC4080 block scheme](https://bugzilla.kernel.org/attachment.cgi?id=306370) - [ALC4080 datasheet](https://bugzilla.kernel.org/attachment.cgi?id=307224) **Some details** ALC4080 is USB codec, thus it exposes functionality through the USB bus. The block scheme is nice to know internals, but look to the MCU paragraph in the datasheet: ``` 2.1.2. Micro Controller Unit - On-chip high-performance and low-power MCU - Ultra-low power consumption when MCU is at idle state - MCU controls connection to USB bus for re-enumeration without hot-plug - Internal programmable memory support for customized audio function - Watchdog control for MCU reset and interrupt - Configurable VID (Vendor ID), PID (Product ID), and serial number string ``` This means, that the internal firmware for this MCU unit can change the behaviour of audio hardware. Usually, the firmware is vendor specific. The USB audio hardware should comply with the USB Audio specification (refer https://www.usb.org/). The control units parsed by the ALSA driver can be obtained using 'cat /proc/asound/cardX/usbmixer' command (replace X with the correct ALSA card number). Those units are mapped to the standard mixer controls. My guess is that the firmware is not complaint with the USB audio specification and some functionality is controlled using specific USB handshake (data blocks). Issue URL : https://github.com/alsa-project/alsa-ucm-conf/issues/541 Repository URL: https://github.com/alsa-project/alsa-ucm-conf

1 0

ucm2: sof-soundwire: Correct include file path for dsp.conf
by GitHub pull_request - opened 04 Apr '25

04 Apr '25

alsa-project/alsa-ucm-conf pull request #542 was opened from ujfalusi: The file path must be given as absolut and not relative, otherwise the dsp.conf file will not be found: $ alsaucm dump text ALSA lib utils.c:364:(uc_mgr_config_load_into) could not open configuration file /usr/share/alsa/ucm2/conf.d/sof-soundwire/../Intel/sof-hda-dsp/dsp.conf ALSA lib parser.c:78:(uc_mgr_config_load_file) error: failed to open file /usr/share/alsa/ucm2/conf.d/sof-soundwire/../Intel/sof-hda-dsp/dsp.conf: -2 ALSA lib main.c:1554:(snd_use_case_mgr_open) error: failed to import hw:0 use case configuration -2 alsaucm: error failed to open sound card hw:0: No such file or directory Fixes: c9d1f7eafa6c ("UCM2: sof-soundwire: Enable DRC and equalizers for") Request URL : https://github.com/alsa-project/alsa-ucm-conf/pull/542 Patch URL : https://github.com/alsa-project/alsa-ucm-conf/pull/542.patch Repository URL: https://github.com/alsa-project/alsa-ucm-conf

1 0

USB-Audio: Add Roland BridgeCast One | adapted
by GitHub pull_request - edited 03 Apr '25

03 Apr '25

alsa-project/alsa-ucm-conf pull request #536 was edited from Simon99de: Add Roland BridgeCast One uses the same config as the bridge cast v2 as it has the same outputs and it worked in my test. 0582:030d Request URL : https://github.com/alsa-project/alsa-ucm-conf/pull/536 Patch URL : https://github.com/alsa-project/alsa-ucm-conf/pull/536.patch Repository URL: https://github.com/alsa-project/alsa-ucm-conf

1 0

Alsa lib is not able to find the UCM .conf files
by GitHub issues - opened 03 Apr '25

03 Apr '25

alsa-project/alsa-lib issue #449 was opened from 3bitbrain: Note : the sound card is a Xonar DX ( AV200 ) The alsa UCM files are installed at PATH=/usr/share/alsa When I try to start alsasound, I get this error == ` alsa-lib-1.2.11/src/umc/main.c:1554: (snd_use_case_mgr_open) error : failed to import hw:1 use case configuration -2 ` The CMD alsaucm listcards gets this response : list is empty. [alsa-info.txt](https://github.com/alsa-project/alsa-ucm-conf/files/15455180… [aplay-info.txt](https://github.com/alsa-project/alsa-ucm-conf/files/1545518… Issue URL : https://github.com/alsa-project/alsa-lib/issues/449 Repository URL: https://github.com/alsa-project/alsa-lib

1 0

ALC4080 - general discussion (driver support)
by GitHub issues - edited 03 Apr '25

03 Apr '25

alsa-project/alsa-ucm-conf issue #541 was edited from perexg: UCM cannot add basic functionalities when the driver does not expose them. I already explained situation in [kernel bugzilla](https://bugzilla.kernel.org/show_bug.cgi?id=218913). **Note** This issue is for the kernel driver related problems. If the driver works and something is missing in UCM configuration, please, create a new issue in this tracker. It may be difficult to distinguish the right place, but if the developers redirected you here, follow the instructions bellow. **For issues like** 1. jack functionality assignment is unstable (jack functionality is not fixed - e.g. changes on warm reboot from windows) 2. low microphone volume (which cannot be controlled using native ALSA mixer controls) 3. sound is activated only after some magic plug/unplug sequence **Further steps** Try to analyze the audio driver using direct ALSA API. See [DEBUG.md](https://github.com/alsa-project/alsa-ucm-conf/blob/master/ucm2/DE…. Very nice report is in #528. Please, use it as a reference what to do. Reverse engineering of the Windows driver. Capture USB communication and save it to a file which can be replayed by [wireshark](https://www.wireshark.org). Try to write an explanation including timing (what happened in given time slots). Driver reports should go to [kernel bugzilla](https://bugzilla.kernel.org). Add a comment with a link here. You may also push hardware vendors to create USB device which fully follows the USB audio specification, so the ALSA driver will work out-of-box (without "quirks"). **Documentation links** The documentation is not complete. Realtek support is generally very limited to provide full specification to their codecs / audio chips those years. They are providing details only to hardware vendors with a contract. If you know more, please, let us know. - [ALC4080 block scheme](https://bugzilla.kernel.org/attachment.cgi?id=306370) - [ALC4080 datasheet](https://bugzilla.kernel.org/attachment.cgi?id=307224) **Some details** ALC4080 is USB codec, thus it exposes functionality through the USB bus. The block scheme is nice to know internals, but look to the MCU paragraph in the datasheet: ``` 2.1.2. Micro Controller Unit - On-chip high-performance and low-power MCU - Ultra-low power consumption when MCU is at idle state - MCU controls connection to USB bus for re-enumeration without hot-plug - Internal programmable memory support for customized audio function - Watchdog control for MCU reset and interrupt - Configurable VID (Vendor ID), PID (Product ID), and serial number string ``` This means, that the internal firmware for this MCU unit can change the behaviour of audio hardware. Usually, the firmware is vendor specific. The USB audio hardware should comply with the USB Audio specification (refer https://www.usb.org/). The control units parsed by the ALSA driver can be obtained using 'cat /proc/asound/cardX/usbmixer' command (replace X with the correct ALSA card number). Those units are mapped to the standard mixer controls. My guess is that the firmware is not complaint with the USB audio specification and some functionality is controlled using specific USB handshake (data blocks). Issue URL : https://github.com/alsa-project/alsa-ucm-conf/issues/541 Repository URL: https://github.com/alsa-project/alsa-ucm-conf

1 0

ALC4080 - general discussion (driver support)
by GitHub issues - edited 03 Apr '25

03 Apr '25

alsa-project/alsa-ucm-conf issue #541 was edited from perexg: UCM cannot add basic functionalities when the driver does not expose them. I already explained situation in [kernel bugzilla](https://bugzilla.kernel.org/show_bug.cgi?id=218913). **Note** This issue is for the kernel driver related problems. If the driver works and something is missing in UCM configuration, please, create a new issue in this tracker. It may be difficult to distinguish the right place, but if the developers redirected you here, follow the instructions bellow. **For issues like** 1. jack functionality assignment is unstable (jack functionality is not fixed - e.g. changes on warm reboot from windows) 2. low microphone volume (which cannot be controlled using native ALSA mixer controls) 3. sound is activated only after some magic plug/unplug sequence **Further steps** Try to analyze the audio driver using direct ALSA API. See [DEBUG.md](https://github.com/alsa-project/alsa-ucm-conf/blob/master/ucm2/DE…. Very nice report is in #528. Please, use it as a reference what to do. Reverse engineering of the Windows driver. Capture USB communication and save it to a file which can be replayed by [wireshark] (https://www.wireshark.org). Try to write an explanation including timing (what happened in given time slots). Driver reports should go to [kernel bugzilla](https://bugzilla.kernel.org). Add a comment with a link here. You may also push hardware vendors to create USB device which fully follows the USB audio specification, so the ALSA driver will work out-of-box (without "quirks"). **Documentation links** The documentation is not complete. Realtek support is generally very limited to provide full specification to their codecs / audio chips those years. They are providing details only to hardware vendors with a contract. If you know more, please, let us know. - [ALC4080 block scheme](https://bugzilla.kernel.org/attachment.cgi?id=306370) - [ALC4080 datasheet](https://bugzilla.kernel.org/attachment.cgi?id=307224) **Some details** ALC4080 is USB codec, thus it exposes functionality through the USB bus. The block scheme is nice to know internals, but look to the MCU paragraph in the datasheet: ``` 2.1.2. Micro Controller Unit - On-chip high-performance and low-power MCU - Ultra-low power consumption when MCU is at idle state - MCU controls connection to USB bus for re-enumeration without hot-plug - Internal programmable memory support for customized audio function - Watchdog control for MCU reset and interrupt - Configurable VID (Vendor ID), PID (Product ID), and serial number string ``` This means, that the internal firmware for this MCU unit can change the behaviour of audio hardware. Usually, the firmware is vendor specific. The USB audio hardware should comply with the USB Audio specification (refer https://www.usb.org/). The control units parsed by the ALSA driver can be obtained using 'cat /proc/asound/cardX/usbmixer' command (replace X with the correct ALSA card number). Those units are mapped to the standard mixer controls. My guess is that the firmware is not complaint with the USB audio specification and some functionality is controlled using specific USB handshake (data blocks). Issue URL : https://github.com/alsa-project/alsa-ucm-conf/issues/541 Repository URL: https://github.com/alsa-project/alsa-ucm-conf

1 0

ALC4080 - general discussion (driver support)
by GitHub issues - opened 03 Apr '25

03 Apr '25

alsa-project/alsa-ucm-conf issue #541 was opened from perexg: UCM cannot add basic functionalities when the driver does not expose them. I already explained situation in [kernel bugzilla](https://bugzilla.kernel.org/show_bug.cgi?id=218913). **For issues like** 1. jack functionality assignment is unstable (jack functionality is not fixed - e.g. changes on warm reboot from windows) 2. low microphone volume (which cannot be controlled using native ALSA mixer controls) 3. sound is activated only after some magic plug/unplug sequence **Further steps** Try to analyze the audio driver using direct ALSA API. See [DEBUG.md](https://github.com/alsa-project/alsa-ucm-conf/blob/master/ucm2/DE…. Very nice report is in #528. Please, use it as a reference what to do. Reverse engineering of the Windows driver. Capture USB communication and save it to a file which can be replayed by [wireshark] (https://www.wireshark.org). Try to write an explanation including timing (what happened in given time slots). Driver reports should go to [kernel bugzilla](https://bugzilla.kernel.org). Add a comment with a link here. You may also push hardware vendors to create USB device which fully follows the USB audio specification, so the ALSA driver will work out-of-box (without "quirks"). **Documentation links** The documentation is not complete. Realtek support is generally very limited to provide full specification to their codecs / audio chips those years. They are providing details only to hardware vendors with a contract. If you know more, please, let us know. - [ALC4080 block scheme](https://bugzilla.kernel.org/attachment.cgi?id=306370) - [ALC4080 datasheet](https://bugzilla.kernel.org/attachment.cgi?id=307224) **Some details** ALC4080 is USB codec, thus it exposes functionality through the USB bus. The block scheme is nice to know internals, but look to the MCU paragraph in the datasheet: ``` 2.1.2. Micro Controller Unit - On-chip high-performance and low-power MCU - Ultra-low power consumption when MCU is at idle state - MCU controls connection to USB bus for re-enumeration without hot-plug - Internal programmable memory support for customized audio function - Watchdog control for MCU reset and interrupt - Configurable VID (Vendor ID), PID (Product ID), and serial number string ``` This means, that the internal firmware for this MCU unit can change the behaviour of audio hardware. Usually, the firmware is vendor specific. The USB audio hardware should comply with the USB Audio specification (refer https://www.usb.org/). The control units parsed by the ALSA driver can be obtained using 'cat /proc/asound/cardX/usbmixer' command (replace X with the correct ALSA card number). Those units are mapped to the standard mixer controls. My guess is that the firmware is not complaint with the USB audio specification and some functionality is controlled using specific USB handshake (data blocks). Issue URL : https://github.com/alsa-project/alsa-ucm-conf/issues/541 Repository URL: https://github.com/alsa-project/alsa-ucm-conf

1 0

Delete alsalisp code
by GitHub pull_request - opened 02 Apr '25

02 Apr '25

alsa-project/alsa-lib pull request #448 was opened from fragglet: Install of the alsalisp binary has been disabled since 2006 (in commit 8d382ccd), and building of it was disabled by default in 2018 (in commit 32ceab21), so it is reasonable to assume that nobody is using it. Use within the alsa-lib project is limited to an aliases file that looks like it is intended as an example, plus some very small .alisp files associated with the SiS SI7018 PCI sound card which has not been manufactured in years. These too have not been installed since 2018 when commit 32ceab21 disabled building of the alsalisp binary. In preparing this change, I searched the Github issue tracker for "lisp", "alisp" and "alsalisp", and found no complaints about the above changes. I also did a Github code search for projects that might be including the `alisp.h` header and found none. Therefore I think this code can be safely deleted and nobody is likely to object. Request URL : https://github.com/alsa-project/alsa-lib/pull/448 Patch URL : https://github.com/alsa-project/alsa-lib/pull/448.patch Repository URL: https://github.com/alsa-project/alsa-lib

1 0

sof-soundwire: cs42l43: Switch mixer based on output volume
by GitHub pull_request - opened 02 Apr '25

02 Apr '25

alsa-project/alsa-ucm-conf pull request #540 was opened from mstrozek: Hardware volume control in cs42l43 can go up to +31.5dB which can cause audio degradation. For best results, limit hardware volume to 0dB. Link: https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/4622 Request URL : https://github.com/alsa-project/alsa-ucm-conf/pull/540 Patch URL : https://github.com/alsa-project/alsa-ucm-conf/pull/540.patch Repository URL: https://github.com/alsa-project/alsa-ucm-conf

1 0

[GIT PULL] ASoC fixes for v6.15-merge-window
by Mark Brown 02 Apr '25

02 Apr '25

The following changes since commit 9ef52d529bb75071e03cf85078f724d69c4abe89: ASoC: SDCA: Correct handling of selected mode DisCo property (2025-03-21 15:45:25 +0000) are available in the Git repository at: https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git tags/asoc-fix-v6.15-merge-window for you to fetch changes up to 93d34608fd162f725172e780b1c60cc93a920719: ASoC: imx-card: Add NULL check in imx_card_probe() (2025-04-01 17:01:10 +0100) ---------------------------------------------------------------- ASoC: Fixes for v6.15 A relatively large set of fixes that came in since the release, mostly for Qualcomm platforms. The biggest block of fixes is the set from Srini which fixes various quality and glitching issues on AudioReach systems. ---------------------------------------------------------------- Alexey Klimov (1): ASoC: qdsp6: q6asm-dai: fix q6asm_dai_compr_set_params error path Christophe JAILLET (1): ASoC: codecs: rt5665: Fix some error handling paths in rt5665_probe() Dan Carpenter (1): ASoC: sma1307: Fix error handling in sma1307_setting_loaded() Henry Martin (1): ASoC: imx-card: Add NULL check in imx_card_probe() Krzysztof Kozlowski (2): ASoC: codecs: wsa883x: Correct VI sense channel mask ASoC: codecs: wsa884x: Correct VI sense channel mask Mark Brown (2): ASoC: codecs: wsa88xx: Correct VI sense channel mask ASoC: q6apm: fix under runs and fragment sizes Peter Ujfalusi (1): ASoC: SOF: hda/ptl: Move mic privacy change notification sending to a work Richard Fitzgerald (1): firmware: cs_dsp: Ensure cs_dsp_load[_coeff]() returns 0 on success Srinivas Kandagatla (5): ASoC: q6apm-dai: schedule all available frames to avoid dsp under-runs ASoC: q6apm: add q6apm_get_hw_pointer helper ASoC: qdsp6: q6apm-dai: set 10 ms period and buffer alignment. ASoC: qdsp6: q6apm-dai: fix capture pipeline overruns. ASoC: q6apm-dai: make use of q6apm_get_hw_pointer drivers/firmware/cirrus/cs_dsp.c | 2 ++ sound/soc/codecs/rt5665.c | 24 +++------------- sound/soc/codecs/sma1307.c | 11 ++------ sound/soc/codecs/wsa883x.c | 2 +- sound/soc/codecs/wsa884x.c | 2 +- sound/soc/fsl/imx-card.c | 4 +++ sound/soc/qcom/qdsp6/q6apm-dai.c | 60 +++++++++++++++++++++------------------- sound/soc/qcom/qdsp6/q6apm.c | 18 +++++++++++- sound/soc/qcom/qdsp6/q6apm.h | 3 ++ sound/soc/qcom/qdsp6/q6asm-dai.c | 19 +++++++++---- sound/soc/sof/intel/hda-dsp.c | 8 ++++++ sound/soc/sof/intel/hda.c | 4 +++ sound/soc/sof/intel/hda.h | 8 ++++++ sound/soc/sof/intel/ptl.c | 33 +++++++++++++++++++--- 14 files changed, 128 insertions(+), 70 deletions(-)

2 1

Support mute led function for HP platform
by Kailang 02 Apr '25

02 Apr '25

Hi Takashi, Attach was fixed mute led no function with HP platform. Many Thanks. BR, Kailang

2 1

aplay: add support for G.711 A_LAW enconding in AU file format
by GitHub pull_request - opened 02 Apr '25

02 Apr '25

alsa-project/alsa-utils pull request #297 was opened from chleroy: At the time being, aplay only supports G.711 µ-law, 8-bits PCM and 16-bits PCM encodings for the AU format while the AU format supports many more. In Europe the most G.711 used encoding is the A-law, which is also part of the encodings supported by the AU file format. Add support for that encoding in aplay. Request URL : https://github.com/alsa-project/alsa-utils/pull/297 Patch URL : https://github.com/alsa-project/alsa-utils/pull/297.patch Repository URL: https://github.com/alsa-project/alsa-utils

1 0

[PATCH alsa-ucm-conf 1/2] sof-soundwire: cs42l43: Drop headset mic from mic mute LED
by Maciej Strozek 01 Apr '25

01 Apr '25

As per conversation in [1], let headsets be dropped from LED bindings. Also remove turning off the mics on device disable since they are now not needed. [1]: https://github.com/alsa-project/alsa-ucm-conf/pull/512 Signed-off-by: Maciej Strozek <mstrozek(a)opensource.cirrus.com> --- ucm2/codecs/cs42l43/init.conf | 6 ------ ucm2/sof-soundwire/cs42l43-dmic.conf | 2 -- ucm2/sof-soundwire/cs42l43.conf | 1 - 3 files changed, 9 deletions(-) diff --git a/ucm2/codecs/cs42l43/init.conf b/ucm2/codecs/cs42l43/init.conf index 0e987c21..c0fa863c 100644 --- a/ucm2/codecs/cs42l43/init.conf +++ b/ucm2/codecs/cs42l43/init.conf @@ -10,9 +10,3 @@ LibraryConfig.remap.Config { } } } - -BootSequence [ - cset "name='cs42l43 Decimator 1 Switch' 0" -] - -Macro [{ SetLED { LED="mic" Action="attach" CtlId="cs42l43 Decimator 1 Switch" } }] diff --git a/ucm2/sof-soundwire/cs42l43-dmic.conf b/ucm2/sof-soundwire/cs42l43-dmic.conf index 70ce40ff..b68a70d1 100644 --- a/ucm2/sof-soundwire/cs42l43-dmic.conf +++ b/ucm2/sof-soundwire/cs42l43-dmic.conf @@ -13,8 +13,6 @@ SectionDevice."Mic" { ] DisableSequence [ - cset "name='cs42l43 Decimator 3 Switch' 0" - cset "name='cs42l43 Decimator 4 Switch' 0" cset "name='cs42l43 DP1TX1 Input' 'None'" cset "name='cs42l43 DP1TX2 Input' 'None'" ] diff --git a/ucm2/sof-soundwire/cs42l43.conf b/ucm2/sof-soundwire/cs42l43.conf index 4b4e1187..51832126 100644 --- a/ucm2/sof-soundwire/cs42l43.conf +++ b/ucm2/sof-soundwire/cs42l43.conf @@ -33,7 +33,6 @@ SectionDevice."Headset" { ] DisableSequence [ - cset "name='cs42l43 Decimator 1 Switch' 0" cset "name='cs42l43 DP2TX1 Input' 'None'" cset "name='cs42l43 DP2TX2 Input' 'None'" ] -- 2.39.5

2 6