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

[PATCH] ALSA: ice1724: Remove superfluous loop over model table
by Takashi Iwai 12 Jul '21

12 Jul '21

The ice1724 driver looks for the matching card_info entry twice, once at reading EEPROM and another for the rest tasks in the probe call. Reduce the second one by referring to the already assigned card_info entry. Signed-off-by: Takashi Iwai <tiwai(a)suse.de> --- sound/pci/ice1712/ice1724.c | 42 +++++++++++++------------------------ 1 file changed, 14 insertions(+), 28 deletions(-) diff --git a/sound/pci/ice1712/ice1724.c b/sound/pci/ice1712/ice1724.c index ef2367d86148..8052d7cb8925 100644 --- a/sound/pci/ice1712/ice1724.c +++ b/sound/pci/ice1712/ice1724.c @@ -2150,13 +2150,6 @@ static const struct snd_kcontrol_new snd_vt1724_mixer_pro_peak = { .get = snd_vt1724_pro_peak_get }; -/* - * - */ - -static const struct snd_ice1712_card_info no_matched; - - /* ooAoo cards with no controls */ @@ -2574,7 +2567,7 @@ static int snd_vt1724_probe(struct pci_dev *pci, struct snd_card *card; struct snd_ice1712 *ice; int pcm_dev = 0, err; - const struct snd_ice1712_card_info * const *tbl, *c; + const struct snd_ice1712_card_info *c; if (dev >= SNDRV_CARDS) return -ENODEV; @@ -2600,27 +2593,20 @@ static int snd_vt1724_probe(struct pci_dev *pci, /* field init before calling chip_init */ ice->ext_clock_count = 0; - for (tbl = card_tables; *tbl; tbl++) { - for (c = *tbl; c->name; c++) { - if ((model[dev] && c->model && - !strcmp(model[dev], c->model)) || - (c->subvendor == ice->eeprom.subvendor)) { - strcpy(card->shortname, c->name); - if (c->driver) /* specific driver? */ - strcpy(card->driver, c->driver); - if (c->chip_init) { - err = c->chip_init(ice); - if (err < 0) { - snd_card_free(card); - return err; - } - } - goto __found; + c = ice->card_info; + if (c) { + strcpy(card->shortname, c->name); + if (c->driver) /* specific driver? */ + strcpy(card->driver, c->driver); + if (c->chip_init) { + err = c->chip_init(ice); + if (err < 0) { + snd_card_free(card); + return err; } } } - c = &no_matched; -__found: + /* * VT1724 has separate DMAs for the analog and the SPDIF streams while * ICE1712 has only one for both (mixed up). @@ -2688,7 +2674,7 @@ static int snd_vt1724_probe(struct pci_dev *pci, } } - if (c->build_controls) { + if (c && c->build_controls) { err = c->build_controls(ice); if (err < 0) { snd_card_free(card); @@ -2696,7 +2682,7 @@ static int snd_vt1724_probe(struct pci_dev *pci, } } - if (!c->no_mpu401) { + if (!c || !c->no_mpu401) { if (ice->eeprom.data[ICE_EEP2_SYSCONF] & VT1724_CFG_MPU401) { struct snd_rawmidi *rmidi; -- 2.26.2

1 0

[PATCH] ALSA: hda/ca0132: remove redundant initialization of variable status
by Colin King 12 Jul '21

12 Jul '21

From: Colin Ian King <colin.king(a)canonical.com> The variable status is being initialized with a value that is never read, the assignment is redundant and can be removed. Addresses-Coverity: ("Unused value") Signed-off-by: Colin Ian King <colin.king(a)canonical.com> --- sound/pci/hda/patch_ca0132.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/pci/hda/patch_ca0132.c b/sound/pci/hda/patch_ca0132.c index b66e7bdbf483..50ca72ee586e 100644 --- a/sound/pci/hda/patch_ca0132.c +++ b/sound/pci/hda/patch_ca0132.c @@ -2270,7 +2270,7 @@ static int dspio_send_scp_message(struct hda_codec *codec, unsigned int *bytes_returned) { struct ca0132_spec *spec = codec->spec; - int status = -1; + int status; unsigned int scp_send_size = 0; unsigned int total_size; bool waiting_for_resp = false; -- 2.31.1

2 1

[PATCH] ALSA: core: Call substream ack() method upon compat mmap, commit
by Alan Young 12 Jul '21

12 Jul '21

If a 32-bit application is being used with a 64-bit kernel and is using the mmap mechanism to write data, then the SNDRV_PCM_IOCTL_SYNC_PTR ioctl results in calling snd_pcm_ioctl_sync_ptr_compat(). Make this use pcm_lib_apply_appl_ptr() so that the substream's ack() method, if defined, is called. The snd_pcm_sync_ptr() function, used in the 64-bit ioctl case, already uses snd_pcm_ioctl_sync_ptr_compat(). Signed-off-by: Alan Young <consult.awy(a)gmail.com> --- sound/core/pcm_native.c | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-) diff --git a/sound/core/pcm_native.c b/sound/core/pcm_native.c index 17a85f4815d5..91a749835ca1 100644 --- a/sound/core/pcm_native.c +++ b/sound/core/pcm_native.c @@ -3057,9 +3057,14 @@ static int snd_pcm_ioctl_sync_ptr_compat(struct snd_pcm_substream *substream, boundary = 0x7fffffff; snd_pcm_stream_lock_irq(substream); /* FIXME: we should consider the boundary for the sync from app */ - if (!(sflags & SNDRV_PCM_SYNC_PTR_APPL)) - control->appl_ptr = scontrol.appl_ptr; - else + if (!(sflags & SNDRV_PCM_SYNC_PTR_APPL)) { + err = pcm_lib_apply_appl_ptr(substream, + scontrol.appl_ptr); + if (err < 0) { + snd_pcm_stream_unlock_irq(substream); + return err; + } + } else scontrol.appl_ptr = control->appl_ptr % boundary; if (!(sflags & SNDRV_PCM_SYNC_PTR_AVAIL_MIN)) control->avail_min = scontrol.avail_min; -- 2.31.1

2 1

[PATCH v2 0/2] Cirrus Logic CS35L41 Amplifier
by David Rhodes 12 Jul '21

12 Jul '21

ASoC driver and devicetree documentation for a new Cirrus Logic amplifier CS35L41 v2 changes: Reduced regmap defaults to avoid collisions with patched registers Fixed SPI setup for OTP read to avoid setting freq higher than original Fixed entry to device_property parsing function for ACPI systems Replaced ASP Slot Position controls with set_channel_map callback David Rhodes (2): ASoC: cs35l41: CS35L41 Boosted Smart Amplifier ASoC: cs35l41: Add bindings for CS35L41 .../devicetree/bindings/sound/cs35l41.yaml | 395 ++++ include/sound/cs35l41.h | 83 + sound/soc/codecs/Kconfig | 12 + sound/soc/codecs/Makefile | 4 + sound/soc/codecs/cs35l41-i2c.c | 126 ++ sound/soc/codecs/cs35l41-spi.c | 152 ++ sound/soc/codecs/cs35l41-tables.c | 617 ++++++ sound/soc/codecs/cs35l41.c | 1770 +++++++++++++++++ sound/soc/codecs/cs35l41.h | 755 +++++++ 9 files changed, 3914 insertions(+) create mode 100644 Documentation/devicetree/bindings/sound/cs35l41.yaml create mode 100644 include/sound/cs35l41.h create mode 100644 sound/soc/codecs/cs35l41-i2c.c create mode 100644 sound/soc/codecs/cs35l41-spi.c create mode 100644 sound/soc/codecs/cs35l41-tables.c create mode 100644 sound/soc/codecs/cs35l41.c create mode 100644 sound/soc/codecs/cs35l41.h -- 2.25.1

4 11

[RFC PATCH 00/13] ASoC: qcom: Add AudioReach support
by Srinivas Kandagatla 12 Jul '21

12 Jul '21

This patchset adds ASoC driver support to configure signal processing framework ("AudioReach") which is integral part of Qualcomm next generation audio SDK and will be deployed on upcoming Qualcomm chipsets. It makes use of ASoC Topology to load graphs on to the DSP which is then managed by APM (Audio Processing Manager) service to prepare/start/stop. Here is simpified high-level block diagram of AudioReach: ___________________________________________________________ | CPU (Application Processor) | | +---------+ +---------+ +---------+ | | | q6apm | | q6apm | | q6afe | | | | dais | <------> | | <-----> | bedais | | | +---------+ +---------+ +---------+ | | ^ ^ | | | | +---------+ | | +---------+ v +---------->|topology | | | | q6prm | +---------+ | | | | | |<-------->| GPR | +---------+ | | +---------+ +---------+ | | ^ | |____________________________|______________________________| | | RPMSG (IPC over GLINK) ____________________________|______________________________ | | | | +-----------------------+ | | | | | | v v q6 (Audio DSP) | |+-----+ +----------------------------------+ | || PRM | | APM (Audio Processing Manager) | | |+-----+ | . Graph Management | | | | . Command Handing | | | | . Event Management | | | | ... | | | +----------------------------------+ | | ^ | |____________________________|______________________________| | | LPASS AIF ____________________________|______________________________ | | Audio I/O | | v | | +--------------------------------------------------+ | | | Audio devices | | | | CODEC | HDMI-TX | PCM | SLIMBUS | I2S |MI2S |...| | | | | | | +--------------------------------------------------+ | |___________________________________________________________| AudioReach has constructs of sub-graph, container and modules. Each sub-graph can have N containers and each Container can have N Modules and connections between them can be linear or non-linear. An audio function can be realized with one or many connected sub-graphs. There are also control/event paths between modules that can be wired up while building graph to achieve various control mechanism between modules. These concepts of Sub-Graph, Containers and Modules are represented in ASoC topology. Here is simple I2S graph with a Write Shared Memory and a Volume control module within a single Subgraph (1) with one Container (1) and 5 modules. ____________________________________________________________ | Sub-Graph [1] | | _______________________________________________________ | | | Container [1] | | | | [WR_SH] -> [PCM DEC] -> [PCM CONV] -> [VOL]-> [I2S-EP]| | | |_______________________________________________________| | |____________________________________________________________| For now this graph is split into two subgraphs to achieve dpcm like below: ________________________________________________ _________________ | Sub-Graph [1] | | Sub-Graph [2] | | ____________________________________________ | | _____________ | | | Container [1] | | | |Container [2]| | | | [WR_SH] -> [PCM DEC] -> [PCM CONV] -> [VOL]| | | | [I2S-EP] | | | |____________________________________________| | | |_____________| | |________________________________________________| |_________________| _________________ | Sub-Graph [3] | | _____________ | | |Container [3]| | | | [DMA-EP] | | | |_____________| | |_________________| This patchset adds very minimal support for AudioReach which includes supporting sub-graphs containing CODEC DMA ports and simple PCM Decoder/Encoder and Logger Modules. Additional capabilities will be built over time to expose features offered by AudioReach. This patchset is Tested on SM8250 SoC based Qualcomm Robotics Platform RB5 and SM9250 MTP with WSA881X Smart Speaker Amplifiers, DMICs connected via VA Macro and WCD938x Codec connected via TX and RX Macro. Sample WIP ASoC graphs are available at https://git.linaro.org/people/srinivas.kandagatla/audioreach-topology.git/ Thanks, srini Srinivas Kandagatla (13): soc: dt-bindings: qcom: add gpr bindings soc: qcom: add gpr driver support ASoC: qcom: dt-bindings: add bindings Audio Processing manager ASoC: qcom: audioreach: add basic pkt alloc support ASoC: qcom: audioreach: add q6apm support ASoC: qcom: audioreach: add module configuration command helpers ASoC: qcom: audioreach: add topology support ASoC: qcom: audioreach: add q6apm-dai support ASoC: qcom: audioreach: add bedai support ASoC: qcom: dt-bindings: add bindings for Proxy Resource Manager ASoC: qcom: audioreach: add q6prm support ASoC: qcom: dt-bindings: add audioreach soundcard compatibles ASoC: qcom: sm8250: Add audioreach support .../bindings/soc/qcom/qcom,gpr.yaml | 74 ++ .../devicetree/bindings/sound/qcom,q6apm.yaml | 72 ++ .../devicetree/bindings/sound/qcom,q6prm.yaml | 43 + .../bindings/sound/qcom,sm8250.yaml | 43 + drivers/soc/qcom/Kconfig | 9 + drivers/soc/qcom/Makefile | 1 + drivers/soc/qcom/gpr.c | 487 ++++++++ include/dt-bindings/soc/qcom,gpr.h | 18 + include/dt-bindings/sound/qcom,q6apm.h | 215 ++++ include/dt-bindings/sound/qcom,q6prm.h | 205 ++++ include/linux/soc/qcom/gpr.h | 127 ++ include/uapi/sound/snd_ar_tokens.h | 200 +++ sound/soc/qcom/Kconfig | 20 + sound/soc/qcom/Makefile | 1 + sound/soc/qcom/audioreach/Makefile | 12 + sound/soc/qcom/audioreach/audioreach.c | 1082 +++++++++++++++++ sound/soc/qcom/audioreach/audioreach.h | 649 ++++++++++ sound/soc/qcom/audioreach/q6apm-bedai.c | 377 ++++++ sound/soc/qcom/audioreach/q6apm-dai.c | 494 ++++++++ sound/soc/qcom/audioreach/q6apm.c | 962 +++++++++++++++ sound/soc/qcom/audioreach/q6apm.h | 171 +++ sound/soc/qcom/audioreach/q6prm.c | 412 +++++++ sound/soc/qcom/audioreach/topology.c | 848 +++++++++++++ sound/soc/qcom/sm8250.c | 144 ++- 24 files changed, 6665 insertions(+), 1 deletion(-) create mode 100644 Documentation/devicetree/bindings/soc/qcom/qcom,gpr.yaml create mode 100644 Documentation/devicetree/bindings/sound/qcom,q6apm.yaml create mode 100644 Documentation/devicetree/bindings/sound/qcom,q6prm.yaml create mode 100644 drivers/soc/qcom/gpr.c create mode 100644 include/dt-bindings/soc/qcom,gpr.h create mode 100644 include/dt-bindings/sound/qcom,q6apm.h create mode 100644 include/dt-bindings/sound/qcom,q6prm.h create mode 100644 include/linux/soc/qcom/gpr.h create mode 100644 include/uapi/sound/snd_ar_tokens.h create mode 100644 sound/soc/qcom/audioreach/Makefile create mode 100644 sound/soc/qcom/audioreach/audioreach.c create mode 100644 sound/soc/qcom/audioreach/audioreach.h create mode 100644 sound/soc/qcom/audioreach/q6apm-bedai.c create mode 100644 sound/soc/qcom/audioreach/q6apm-dai.c create mode 100644 sound/soc/qcom/audioreach/q6apm.c create mode 100644 sound/soc/qcom/audioreach/q6apm.h create mode 100644 sound/soc/qcom/audioreach/q6prm.c create mode 100644 sound/soc/qcom/audioreach/topology.c -- 2.21.0

2 19

Realtek analog audio output limited to 48 kHz, chips support up to 192kHz
by GitHub issues - edited 11 Jul '21

11 Jul '21

alsa-project/alsa-lib issue #163 was edited from markojurkovic: There seems to be an issue with ALSA and some onboard Realtek laptop audio chips, in my case Realtek ALC233 (but I've seen some reports online of people with other Realtek chips facing this issue). Namely, I've noticed that I cannot make use of all the sampling rates that the chip supports in GNU/Linux using ALSA. The chip supports up to 24-bit/192kHz analog stereo output, but in the three Linux distributions I've tried (Ubuntu, Fedora, Manjaro) I can only get either 44.1 or 48 kHz. The problem manifests itself by throwing the following error when attempting to play, for example, a 96kHz file in Audacious: "ALSA error: snd_pcm_hw_params_set_rate failed: Invalid argument." If I attempt to play such a file using PulseAudio, I am able to play the file, but it gets resampled to 48kHz (which I've verified by running "cat /proc/asound/card0/pcm0p/sub0/hw_params") In Windows, I can get up to 192kHz without problems using both WASAPI Exclusive and ASIO modes, meaning modes that directly communicate with hardware, just like ALSA. Following is the output of running "cat /proc/asound/card0/codec#0". This output indicates that the only supported sample rates for the sound card are 44100 and 48000 (for the analog outputs), whereas this Realtek chip supports also 96000 and 192000. Node 0x02 [Audio Output] wcaps 0x41d: Stereo Amp-Out Control: name="Speaker Playback Volume", index=0, device=0 ControlAmp: chs=3, dir=Out, idx=0, ofs=0 Amp-Out caps: ofs=0x57, nsteps=0x57, stepsize=0x02, mute=0 Amp-Out vals: [0x44 0x44] Converter: stream=1, channel=0 PCM: rates [0x60]: 44100 48000 bits [0xe]: 16 20 24 formats [0x1]: PCM Power states: D0 D1 D2 D3 EPSS Power: setting=D0, actual=D0 Node 0x03 [Audio Output] wcaps 0x41d: Stereo Amp-Out Control: name="Headphone Playback Volume", index=0, device=0 ControlAmp: chs=3, dir=Out, idx=0, ofs=0 Device: name="ALC233 Analog", type="Audio", device=0 Amp-Out caps: ofs=0x57, nsteps=0x57, stepsize=0x02, mute=0 Amp-Out vals: [0x00 0x00] Converter: stream=1, channel=0 PCM: rates [0x60]: 44100 48000 bits [0xe]: 16 20 24 formats [0x1]: PCM Power states: D0 D1 D2 D3 EPSS Power: setting=D0, actual=D0 Following is also the output of the alsa-info script: [alsa-debug.txt](https://github.com/alsa-project/alsa-lib/files/6797358/alsa… I tried different kernel versions, both generic/mainline and custom, including the latest one (5.13.1) on distros ranging from Ubuntu 19.04, Ubuntu 21.04, Pop OS 20.04 and 21.04, Fedora 32... Issue URL : https://github.com/alsa-project/alsa-lib/issues/163 Repository URL: https://github.com/alsa-project/alsa-lib

1 0

Realtek analog audio output limited to 48 kHz, chips support up to 192kHz
by GitHub issues - edited 11 Jul '21

11 Jul '21

alsa-project/alsa-lib issue #163 was edited from markojurkovic: There seems to be an issue with ALSA and some onboard Realtek laptop audio chips, in my case Realtek ALC233 (but I've seen some reports online of people with other Realtek chips facing this issue). Namely, I've noticed that I cannot make use of all the sampling rates that the chip supports in GNU/Linux using ALSA. The chip supports up to 24-bit/192kHz analog stereo output, but in the three Linux distributions I've tried (Ubuntu, Fedora, Manjaro) I can only get either 44.1 or 48 kHz. The problem manifests itself by throwing the following error when attempting to play, for example, a 96kHz file in Audacious: "ALSA error: snd_pcm_hw_params_set_rate failed: Invalid argument." If I attempt to play such a file using PulseAudio, I am able to play the file, but it gets resampled to 48kHz (which I've verified by running "cat /proc/asound/card0/pcm0p/sub0/hw_params") In Windows, I can get up to 192kHz without problems using both WASAPI Exclusive and ASIO modes, meaning modes that directly communicate with hardware, just like ALSA. Following is the output of running "cat /proc/asound/card0/codec#0". This output indicates that the only supported sample rates for the sound card are 44100 and 48000 (for the analog outputs), whereas this Realtek chip supports also 96000 and 192000. Node 0x02 [Audio Output] wcaps 0x41d: Stereo Amp-Out Control: name="Speaker Playback Volume", index=0, device=0 ControlAmp: chs=3, dir=Out, idx=0, ofs=0 Amp-Out caps: ofs=0x57, nsteps=0x57, stepsize=0x02, mute=0 Amp-Out vals: [0x44 0x44] Converter: stream=1, channel=0 PCM: rates [0x60]: 44100 48000 bits [0xe]: 16 20 24 formats [0x1]: PCM Power states: D0 D1 D2 D3 EPSS Power: setting=D0, actual=D0 Node 0x03 [Audio Output] wcaps 0x41d: Stereo Amp-Out Control: name="Headphone Playback Volume", index=0, device=0 ControlAmp: chs=3, dir=Out, idx=0, ofs=0 Device: name="ALC233 Analog", type="Audio", device=0 Amp-Out caps: ofs=0x57, nsteps=0x57, stepsize=0x02, mute=0 Amp-Out vals: [0x00 0x00] Converter: stream=1, channel=0 PCM: rates [0x60]: 44100 48000 bits [0xe]: 16 20 24 formats [0x1]: PCM Power states: D0 D1 D2 D3 EPSS Power: setting=D0, actual=D0 Following is also the output of the alsa-info script: [alsa-debug.txt](https://github.com/alsa-project/alsa-lib/files/6797358/alsa… I tried different kernel versions, both generic/mainline and custom, on distros ranging from Ubuntu 19.04, Ubuntu 21.04, Pop OS 20.04 and 21.04, Fedora 32... Issue URL : https://github.com/alsa-project/alsa-lib/issues/163 Repository URL: https://github.com/alsa-project/alsa-lib

1 0

Realtek analog audio output limited to 48 kHz, chips support up to 192kHz
by GitHub issues - edited 11 Jul '21

11 Jul '21

alsa-project/alsa-lib issue #163 was edited from markojurkovic: There seems to be an issue with ALSA and some onboard Realtek laptop audio chips, in my case Realtek ALC233 (but I've seen some reports online of people with other Realtek chips facing this issue). Namely, I've noticed that I cannot make use of all the sampling rates that the chip supports in GNU/Linux using ALSA. The chip supports up to 24-bit/192kHz analog stereo output, but in the three Linux distributions I've tried (Ubuntu, Fedora, Manjaro) I can only get either 44.1 or 48 kHz. The problem manifests itself by throwing the following error when attempting to play, for example, a 96kHz file in Audacious: "ALSA error: snd_pcm_hw_params_set_rate failed: Invalid argument." If I attempt to play such a file using PulseAudio, I am able to play the file, but it gets resampled to 48kHz (which I've verified by running "cat /proc/asound/card0/pcm0p/sub0/hw_params") In Windows, I can get up to 192kHz without problems using both WASAPI Exclusive and ASIO modes, meaning modes that directly communicate with hardware, just like ALSA. Following is the output of running "cat /proc/asound/card0/codec#0". This output indicates that the only supported sample rates for the sound card are 44100 and 48000 (for the analog outputs), whereas this Realtek chip supports also 96000 and 192000. Node 0x02 [Audio Output] wcaps 0x41d: Stereo Amp-Out Control: name="Speaker Playback Volume", index=0, device=0 ControlAmp: chs=3, dir=Out, idx=0, ofs=0 Amp-Out caps: ofs=0x57, nsteps=0x57, stepsize=0x02, mute=0 Amp-Out vals: [0x44 0x44] Converter: stream=1, channel=0 PCM: rates [0x60]: 44100 48000 bits [0xe]: 16 20 24 formats [0x1]: PCM Power states: D0 D1 D2 D3 EPSS Power: setting=D0, actual=D0 Node 0x03 [Audio Output] wcaps 0x41d: Stereo Amp-Out Control: name="Headphone Playback Volume", index=0, device=0 ControlAmp: chs=3, dir=Out, idx=0, ofs=0 Device: name="ALC233 Analog", type="Audio", device=0 Amp-Out caps: ofs=0x57, nsteps=0x57, stepsize=0x02, mute=0 Amp-Out vals: [0x00 0x00] Converter: stream=1, channel=0 PCM: rates [0x60]: 44100 48000 bits [0xe]: 16 20 24 formats [0x1]: PCM Power states: D0 D1 D2 D3 EPSS Power: setting=D0, actual=D0 Following is also the output of the alsa-info script: [alsa-debug.txt](https://github.com/alsa-project/alsa-lib/files/6797358/alsa… I tried different kernel versions, both generic and custom, on distros ranging from Ubuntu 19.04, Ubuntu 21.04, Pop OS 20.04 and 21.04, Fedora 32... Issue URL : https://github.com/alsa-project/alsa-lib/issues/163 Repository URL: https://github.com/alsa-project/alsa-lib

1 0

Realtek analog audio output limited to 48 kHz, chips support up to 192kHz
by GitHub issues - edited 11 Jul '21

11 Jul '21

alsa-project/alsa-lib issue #163 was edited from markojurkovic: There seems to be an issue with ALSA and some onboard Realtek laptop audio chips, in my case Realtek ALC233 (but I've seen some reports online of people with other Realtek chips facing this issue). Namely, I've noticed that I cannot make use of all the sampling rates that the chip supports in GNU/Linux using ALSA. The chip supports up to 24-bit/192kHz analog stereo output, but in the three Linux distributions I've tried (Ubuntu, Fedora, Manjaro) I can only get either 44.1 or 48 kHz. The problem manifests itself by throwing the following error when attempting to play, for example, a 96kHz file in Audacious: "ALSA error: snd_pcm_hw_params_set_rate failed: Invalid argument." If I attempt to play such a file using PulseAudio, I am able to play the file, but it gets resampled to 48kHz (which I've verified by running "cat /proc/asound/card0/pcm0p/sub0/hw_params") In Windows, I can get up to 192kHz without problems using both WASAPI Exclusive and ASIO modes, meaning modes that directly communicate with hardware, just like ALSA. Following is the output of running "cat /proc/asound/card0/codec#0". This output indicates that the only supported sample rates for the sound card are 44100 and 48000 (for the analog outputs), whereas this Realtek chip supports also 96000 and 192000. Node 0x02 [Audio Output] wcaps 0x41d: Stereo Amp-Out Control: name="Speaker Playback Volume", index=0, device=0 ControlAmp: chs=3, dir=Out, idx=0, ofs=0 Amp-Out caps: ofs=0x57, nsteps=0x57, stepsize=0x02, mute=0 Amp-Out vals: [0x44 0x44] Converter: stream=1, channel=0 PCM: rates [0x60]: 44100 48000 bits [0xe]: 16 20 24 formats [0x1]: PCM Power states: D0 D1 D2 D3 EPSS Power: setting=D0, actual=D0 Node 0x03 [Audio Output] wcaps 0x41d: Stereo Amp-Out Control: name="Headphone Playback Volume", index=0, device=0 ControlAmp: chs=3, dir=Out, idx=0, ofs=0 Device: name="ALC233 Analog", type="Audio", device=0 Amp-Out caps: ofs=0x57, nsteps=0x57, stepsize=0x02, mute=0 Amp-Out vals: [0x00 0x00] Converter: stream=1, channel=0 PCM: rates [0x60]: 44100 48000 bits [0xe]: 16 20 24 formats [0x1]: PCM Power states: D0 D1 D2 D3 EPSS Power: setting=D0, actual=D0 Attached to this post is also the output of the alsa-info script. [alsa-debug.txt](https://github.com/alsa-project/alsa-lib/files/6797358/alsa… I tried different kernel versions, both generic and custom, on distros ranging from Ubuntu 19.04, Ubuntu 21.04, Pop OS 20.04 and 21.04, Fedora 32... Issue URL : https://github.com/alsa-project/alsa-lib/issues/163 Repository URL: https://github.com/alsa-project/alsa-lib

1 0

Realtek analog audio output limited to 48 kHz, chips support up to 192kHz
by GitHub issues - opened 11 Jul '21

11 Jul '21

alsa-project/alsa-lib issue #163 was opened from markojurkovic: There seems to be an issue with ALSA and some onboard Realtek laptop audio chips, in my case Realtek ALC233 (but I've seen some reports online of people with other Realtek chips facing this issue). Namely, I've noticed that I cannot make use of all the sampling rates that the chip supports in GNU/Linux using ALSA. The chip supports up to 24-bit/192kHz analog stereo output, but in the three Linux distributions I've tried (Ubuntu, Fedora, Manjaro) I can only get either 44.1 or 48 kHz. The problem manifests itself by throwing the following error when attempting to play, for example, a 96kHz file in Audacious: "ALSA error: snd_pcm_hw_params_set_rate failed: Invalid argument." If I attempt to play such a file using PulseAudio, I am able to play the file, but it gets resampled to 48kHz (which I've verified by running "cat /proc/asound/card0/pcm0p/sub0/hw_params") In Windows, I can get up to 192kHz without problems using both WASAPI Exclusive and ASIO modes, meaning modes that directly communicate with hardware, just like ALSA. Following is the output of running "cat /proc/asound/card0/codec#0". This output indicates that the only supported sample rates for the sound card are 44100 and 48000, whereas this Realtek chip supports also 96000 and 192000. Node 0x02 [Audio Output] wcaps 0x41d: Stereo Amp-Out Control: name="Speaker Playback Volume", index=0, device=0 ControlAmp: chs=3, dir=Out, idx=0, ofs=0 Amp-Out caps: ofs=0x57, nsteps=0x57, stepsize=0x02, mute=0 Amp-Out vals: [0x44 0x44] Converter: stream=1, channel=0 PCM: rates [0x60]: 44100 48000 bits [0xe]: 16 20 24 formats [0x1]: PCM Power states: D0 D1 D2 D3 EPSS Power: setting=D0, actual=D0 Node 0x03 [Audio Output] wcaps 0x41d: Stereo Amp-Out Control: name="Headphone Playback Volume", index=0, device=0 ControlAmp: chs=3, dir=Out, idx=0, ofs=0 Device: name="ALC233 Analog", type="Audio", device=0 Amp-Out caps: ofs=0x57, nsteps=0x57, stepsize=0x02, mute=0 Amp-Out vals: [0x00 0x00] Converter: stream=1, channel=0 PCM: rates [0x60]: 44100 48000 bits [0xe]: 16 20 24 formats [0x1]: PCM Power states: D0 D1 D2 D3 EPSS Power: setting=D0, actual=D0 Attached to this post is also the output of the alsa-info script. [alsa-debug.txt](https://github.com/alsa-project/alsa-lib/files/6797358/alsa… I tried different kernel versions, both generic and custom, on distros ranging from Ubuntu 19.04, Ubuntu 21.04, Pop OS 20.04 and 21.04, Fedora 32... Issue URL : https://github.com/alsa-project/alsa-lib/issues/163 Repository URL: https://github.com/alsa-project/alsa-lib

1 0