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

[PATCH AUTOSEL 5.12 020/116] ALSA: hdspm: don't disable if not enabled
by Sasha Levin 05 May '21

05 May '21

From: Tong Zhang <ztong0001(a)gmail.com> [ Upstream commit 790f5719b85e12e10c41753b864e74249585ed08 ] hdspm wants to disable a not enabled pci device, which makes kernel throw a warning. Make sure the device is enabled before calling disable. [ 1.786391] snd_hdspm 0000:00:03.0: disabling already-disabled device [ 1.786400] WARNING: CPU: 0 PID: 182 at drivers/pci/pci.c:2146 pci_disable_device+0x91/0xb0 [ 1.795181] Call Trace: [ 1.795320] snd_hdspm_card_free+0x58/0xa0 [snd_hdspm] [ 1.795595] release_card_device+0x4b/0x80 [snd] [ 1.795860] device_release+0x3b/0xa0 [ 1.796072] kobject_put+0x94/0x1b0 [ 1.796260] put_device+0x13/0x20 [ 1.796438] snd_card_free+0x61/0x90 [snd] [ 1.796659] snd_hdspm_probe+0x97b/0x1440 [snd_hdspm] Suggested-by: Takashi Iwai <tiwai(a)suse.de> Signed-off-by: Tong Zhang <ztong0001(a)gmail.com> Link: https://lore.kernel.org/r/20210321153840.378226-3-ztong0001@gmail.com Signed-off-by: Takashi Iwai <tiwai(a)suse.de> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- sound/pci/rme9652/hdspm.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/sound/pci/rme9652/hdspm.c b/sound/pci/rme9652/hdspm.c index 8d900c132f0f..97a0bff96b28 100644 --- a/sound/pci/rme9652/hdspm.c +++ b/sound/pci/rme9652/hdspm.c @@ -6883,7 +6883,8 @@ static int snd_hdspm_free(struct hdspm * hdspm) if (hdspm->port) pci_release_regions(hdspm->pci); - pci_disable_device(hdspm->pci); + if (pci_is_enabled(hdspm->pci)) + pci_disable_device(hdspm->pci); return 0; } -- 2.30.2

1 0

[PATCH AUTOSEL 5.12 019/116] ALSA: hdsp: don't disable if not enabled
by Sasha Levin 05 May '21

05 May '21

From: Tong Zhang <ztong0001(a)gmail.com> [ Upstream commit 507cdb9adba006a7798c358456426e1aea3d9c4f ] hdsp wants to disable a not enabled pci device, which makes kernel throw a warning. Make sure the device is enabled before calling disable. [ 1.758292] snd_hdsp 0000:00:03.0: disabling already-disabled device [ 1.758327] WARNING: CPU: 0 PID: 180 at drivers/pci/pci.c:2146 pci_disable_device+0x91/0xb0 [ 1.766985] Call Trace: [ 1.767121] snd_hdsp_card_free+0x94/0xf0 [snd_hdsp] [ 1.767388] release_card_device+0x4b/0x80 [snd] [ 1.767639] device_release+0x3b/0xa0 [ 1.767838] kobject_put+0x94/0x1b0 [ 1.768027] put_device+0x13/0x20 [ 1.768207] snd_card_free+0x61/0x90 [snd] [ 1.768430] snd_hdsp_probe+0x524/0x5e0 [snd_hdsp] Suggested-by: Takashi Iwai <tiwai(a)suse.de> Signed-off-by: Tong Zhang <ztong0001(a)gmail.com> Link: https://lore.kernel.org/r/20210321153840.378226-2-ztong0001@gmail.com Signed-off-by: Takashi Iwai <tiwai(a)suse.de> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- sound/pci/rme9652/hdsp.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/sound/pci/rme9652/hdsp.c b/sound/pci/rme9652/hdsp.c index 4cf879c42dc4..720297cbdf87 100644 --- a/sound/pci/rme9652/hdsp.c +++ b/sound/pci/rme9652/hdsp.c @@ -5390,7 +5390,8 @@ static int snd_hdsp_free(struct hdsp *hdsp) if (hdsp->port) pci_release_regions(hdsp->pci); - pci_disable_device(hdsp->pci); + if (pci_is_enabled(hdsp->pci)) + pci_disable_device(hdsp->pci); return 0; } -- 2.30.2

1 0

[PATCH AUTOSEL 5.12 015/116] ASoC: rsnd: core: Check convert rate in rsnd_hw_params
by Sasha Levin 05 May '21

05 May '21

From: Mikhail Durnev <mikhail_durnev(a)mentor.com> [ Upstream commit 19c6a63ced5e07e40f3a5255cb1f0fe0d3be7b14 ] snd_pcm_hw_params_set_rate_near can return incorrect sample rate in some cases, e.g. when the backend output rate is set to some value higher than 48000 Hz and the input rate is 8000 Hz. So passing the value returned by snd_pcm_hw_params_set_rate_near to snd_pcm_hw_params will result in "FSO/FSI ratio error" and playing no audio at all while the userland is not properly notified about the issue. If SRC is unable to convert the requested sample rate to the sample rate the backend is using, then the requested sample rate should be adjusted in rsnd_hw_params. The userland will be notified about that change in the returned hw_params structure. Signed-off-by: Mikhail Durnev <mikhail_durnev(a)mentor.com> Link: https://lore.kernel.org/r/1615870055-13954-1-git-send-email-mikhail_durnev@… Signed-off-by: Mark Brown <broonie(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- sound/soc/sh/rcar/core.c | 69 +++++++++++++++++++++++++++++++++++++++- 1 file changed, 68 insertions(+), 1 deletion(-) diff --git a/sound/soc/sh/rcar/core.c b/sound/soc/sh/rcar/core.c index 1029d8d9d800..d2b4632d9c2a 100644 --- a/sound/soc/sh/rcar/core.c +++ b/sound/soc/sh/rcar/core.c @@ -1428,8 +1428,75 @@ static int rsnd_hw_params(struct snd_soc_component *component, } if (io->converted_chan) dev_dbg(dev, "convert channels = %d\n", io->converted_chan); - if (io->converted_rate) + if (io->converted_rate) { + /* + * SRC supports convert rates from params_rate(hw_params)/k_down + * to params_rate(hw_params)*k_up, where k_up is always 6, and + * k_down depends on number of channels and SRC unit. + * So all SRC units can upsample audio up to 6 times regardless + * its number of channels. And all SRC units can downsample + * 2 channel audio up to 6 times too. + */ + int k_up = 6; + int k_down = 6; + int channel; + struct rsnd_mod *src_mod = rsnd_io_to_mod_src(io); + dev_dbg(dev, "convert rate = %d\n", io->converted_rate); + + channel = io->converted_chan ? io->converted_chan : + params_channels(hw_params); + + switch (rsnd_mod_id(src_mod)) { + /* + * SRC0 can downsample 4, 6 and 8 channel audio up to 4 times. + * SRC1, SRC3 and SRC4 can downsample 4 channel audio + * up to 4 times. + * SRC1, SRC3 and SRC4 can downsample 6 and 8 channel audio + * no more than twice. + */ + case 1: + case 3: + case 4: + if (channel > 4) { + k_down = 2; + break; + } + fallthrough; + case 0: + if (channel > 2) + k_down = 4; + break; + + /* Other SRC units do not support more than 2 channels */ + default: + if (channel > 2) + return -EINVAL; + } + + if (params_rate(hw_params) > io->converted_rate * k_down) { + hw_param_interval(hw_params, SNDRV_PCM_HW_PARAM_RATE)->min = + io->converted_rate * k_down; + hw_param_interval(hw_params, SNDRV_PCM_HW_PARAM_RATE)->max = + io->converted_rate * k_down; + hw_params->cmask |= SNDRV_PCM_HW_PARAM_RATE; + } else if (params_rate(hw_params) * k_up < io->converted_rate) { + hw_param_interval(hw_params, SNDRV_PCM_HW_PARAM_RATE)->min = + (io->converted_rate + k_up - 1) / k_up; + hw_param_interval(hw_params, SNDRV_PCM_HW_PARAM_RATE)->max = + (io->converted_rate + k_up - 1) / k_up; + hw_params->cmask |= SNDRV_PCM_HW_PARAM_RATE; + } + + /* + * TBD: Max SRC input and output rates also depend on number + * of channels and SRC unit: + * SRC1, SRC3 and SRC4 do not support more than 128kHz + * for 6 channel and 96kHz for 8 channel audio. + * Perhaps this function should return EINVAL if the input or + * the output rate exceeds the limitation. + */ + } } return rsnd_dai_call(hw_params, io, substream, hw_params); -- 2.30.2

1 0

[PATCH AUTOSEL 5.12 012/116] ASoC: Intel: bytcr_rt5640: Enable jack-detect support on Asus T100TAF
by Sasha Levin 05 May '21

05 May '21

From: Hans de Goede <hdegoede(a)redhat.com> [ Upstream commit b7c7203a1f751348f35fc4bcb157572d303f7573 ] The Asus T100TAF uses the same jack-detect settings as the T100TA, this has been confirmed on actual hardware. Add these settings to the T100TAF quirks to enable jack-detect support on the T100TAF. Signed-off-by: Hans de Goede <hdegoede(a)redhat.com> Acked-by: Pierre-Louis Bossart <pierre-louis.bossart(a)linux.intel.com> Link: https://lore.kernel.org/r/20210312114850.13832-1-hdegoede@redhat.com Signed-off-by: Mark Brown <broonie(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- sound/soc/intel/boards/bytcr_rt5640.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/sound/soc/intel/boards/bytcr_rt5640.c b/sound/soc/intel/boards/bytcr_rt5640.c index 5d48cc359c3d..19faababb78d 100644 --- a/sound/soc/intel/boards/bytcr_rt5640.c +++ b/sound/soc/intel/boards/bytcr_rt5640.c @@ -482,6 +482,9 @@ static const struct dmi_system_id byt_rt5640_quirk_table[] = { DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "T100TAF"), }, .driver_data = (void *)(BYT_RT5640_IN1_MAP | + BYT_RT5640_JD_SRC_JD2_IN4N | + BYT_RT5640_OVCD_TH_2000UA | + BYT_RT5640_OVCD_SF_0P75 | BYT_RT5640_MONO_SPEAKER | BYT_RT5640_DIFF_MIC | BYT_RT5640_SSP0_AIF2 | -- 2.30.2

1 0

[PATCH AUTOSEL 5.12 002/116] ALSA: usb-audio: Add Pioneer DJM-850 to quirks-table
by Sasha Levin 05 May '21

05 May '21

From: Nicolas MURE <nicolas.mure2019(a)gmail.com> [ Upstream commit a3c30b0cb6d05f5bf66d1a5d42e876f31753a447 ] Declare the Pioneer DJM-850 interfaces for capture and playback. See https://github.com/nm2107/Pioneer-DJM-850-driver-reverse-engineering/blob/1… for the complete device spec. Signed-off-by: Nicolas MURE <nicolas.mure2019(a)gmail.com> Link: https://lore.kernel.org/r/20210301152729.18094-2-nicolas.mure2019@gmail.com Signed-off-by: Takashi Iwai <tiwai(a)suse.de> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- sound/usb/quirks-table.h | 63 ++++++++++++++++++++++++++++++++++++++++ 1 file changed, 63 insertions(+) diff --git a/sound/usb/quirks-table.h b/sound/usb/quirks-table.h index 1165a5ac60f2..9716a9f7c095 100644 --- a/sound/usb/quirks-table.h +++ b/sound/usb/quirks-table.h @@ -3817,6 +3817,69 @@ AU0828_DEVICE(0x2040, 0x7270, "Hauppauge", "HVR-950Q"), } } }, +{ + /* + * Pioneer DJ DJM-850 + * 8 channels playback and 8 channels capture @ 44.1/48/96kHz S24LE + * Playback on EP 0x05 + * Capture on EP 0x86 + */ + USB_DEVICE_VENDOR_SPEC(0x08e4, 0x0163), + .driver_info = (unsigned long) &(const struct snd_usb_audio_quirk) { + .ifnum = QUIRK_ANY_INTERFACE, + .type = QUIRK_COMPOSITE, + .data = (const struct snd_usb_audio_quirk[]) { + { + .ifnum = 0, + .type = QUIRK_AUDIO_FIXED_ENDPOINT, + .data = &(const struct audioformat) { + .formats = SNDRV_PCM_FMTBIT_S24_3LE, + .channels = 8, + .iface = 0, + .altsetting = 1, + .altset_idx = 1, + .endpoint = 0x05, + .ep_attr = USB_ENDPOINT_XFER_ISOC| + USB_ENDPOINT_SYNC_ASYNC| + USB_ENDPOINT_USAGE_DATA, + .rates = SNDRV_PCM_RATE_44100| + SNDRV_PCM_RATE_48000| + SNDRV_PCM_RATE_96000, + .rate_min = 44100, + .rate_max = 96000, + .nr_rates = 3, + .rate_table = (unsigned int[]) { 44100, 48000, 96000 } + } + }, + { + .ifnum = 0, + .type = QUIRK_AUDIO_FIXED_ENDPOINT, + .data = &(const struct audioformat) { + .formats = SNDRV_PCM_FMTBIT_S24_3LE, + .channels = 8, + .iface = 0, + .altsetting = 1, + .altset_idx = 1, + .endpoint = 0x86, + .ep_idx = 1, + .ep_attr = USB_ENDPOINT_XFER_ISOC| + USB_ENDPOINT_SYNC_ASYNC| + USB_ENDPOINT_USAGE_DATA, + .rates = SNDRV_PCM_RATE_44100| + SNDRV_PCM_RATE_48000| + SNDRV_PCM_RATE_96000, + .rate_min = 44100, + .rate_max = 96000, + .nr_rates = 3, + .rate_table = (unsigned int[]) { 44100, 48000, 96000 } + } + }, + { + .ifnum = -1 + } + } + } +}, { /* * Pioneer DJ DJM-450 -- 2.30.2

1 0

Setting volume of headphones seems to apply to Speakers as well
by GitHub issues - edited 05 May '21

05 May '21

alsa-project/alsa-utils issue #87 was edited from roboknight: When using amixer in the following way: amixer -c 1 set Headphone 0% mute I receive the following partial output from scontents: Simple mixer control 'Headphone',0 Capabilities: pvolume pswitch Playback channels: Front Left - Front Right Limits: Playback 0 - 87 Mono: Front Left: Playback 0 [0%] [-65.25dB] [off] Front Right: Playback 0 [0%] [-65.25dB] [off] Simple mixer control 'Speaker',0 Capabilities: pvolume pswitch Playback channels: Front Left - Front Right Limits: Playback 0 - 87 Mono: Front Left: Playback 87 [100%] [0.00dB] [on] Front Right: Playback 87 [100%] [0.00dB] [on] which looks good. However, it appears that the volume is applied across both the Headphone control and Speaker control (or maybe even just the Master volume) as there is no output from the speakers after this even though it would appear they should have full volume and are not muted. I am using the Ubuntu Groovy Gorilla update, so Linux kernel 5.11. The default installation uses pulseaudio, but I've switched things to pipewire and both cause the same issue presumably because both use ALSA. I started here because amixer seems to at least allow me to identify the problem. When I change the Volume for the Headphones to 100% using the following: amixer -c 1 set Headphone 100% mute the audio from the speakers is then fine. amixer appears to be showing the correct information (as per above) according to the audio, but the Headphone volume seems to be applying to the Speakers as well. Maybe someone can point me in a direction that I can find a solution to this, as it would appear that anytime headphones are plugged in, removing the headphones causes the same situation: no sound. I suspect amixer is working fine, but wherever the volume from amixer is applied, it does not appear to be set appropriately. Issue URL : https://github.com/alsa-project/alsa-utils/issues/87 Repository URL: https://github.com/alsa-project/alsa-utils

1 0

Setting volume of headphones seems to apply to Speakers as well
by GitHub issues - opened 05 May '21

05 May '21

alsa-project/alsa-utils issue #87 was opened from roboknight: When using amixer in the following way: amixer -c 1 set Headphone 0% mute I receive the following partial output from scontents: Simple mixer control 'Headphone',0 Capabilities: pvolume pswitch Playback channels: Front Left - Front Right Limits: Playback 0 - 87 Mono: Front Left: Playback 0 [0%] [-65.25dB] [off] Front Right: Playback 0 [0%] [-65.25dB] [off] Simple mixer control 'Speaker',0 Capabilities: pvolume pswitch Playback channels: Front Left - Front Right Limits: Playback 0 - 87 Mono: Front Left: Playback 87 [100%] [0.00dB] [on] Front Right: Playback 87 [100%] [0.00dB] [on] which looks good. However, it appears that the volume is applied across both the Headphone control and Speaker control (or maybe even just the Master volume) as there is no output from the speakers after this even though it would appear they should have full volume and are not muted. I am using the Ubuntu Groovy Gorilla update, so Linux kernel 5.11. The default installation uses pulseaudio, but I've switched things to pipewire and both cause the same issue presumable because both use ALSA. I started here because amixer seems to at least allow me to identify the problem. When I change the Volume for the Headphones to 100% using the following: amixer -c 1 set Headphone 100% mute the audio from the speakers is then fine. amixer appears to be showing the correct information (as per above) according to the audio, but the Headphone volume seems to be applying to the Speakers as well. Maybe someone can point me in a direction that I can find a solution to this, as it would appear that anytime headphones are plugged in, removing the headphones causes the same situation: no sound. I suspect amixer is working fine, but wherever the volume from amixer is applied, it does not appear to be set appropriately. Issue URL : https://github.com/alsa-project/alsa-utils/issues/87 Repository URL: https://github.com/alsa-project/alsa-utils

1 0

[a52] Strange behavior with 5.1 surround on ALC1220
by GitHub issues - edited 05 May '21

05 May '21

alsa-project/alsa-plugins issue #21 was edited from davidebeatrici: I originally encountered the issue ~1 year ago, when I started using a motherboard with an ALC1220 on it. The out-of-box experience was flawless: I simply connected the optical SPDIF cable to my amplifier/receiver and stereo sound immediately worked. Once I switched to 5.1 surround, audio output became extremely fast; even videos were affected by it, to the point that they were being reproduced in seconds instead of minutes. After a few days of research and experiments I managed to workaround the issue by replacing the content of `60-a52-encoder.conf` with: ``` pcm.a52 { @args [CARD] @args.CARD { type string } type rate slave { pcm { type a52 card $CARD } rate 48000 } } pcm.pulse { type pulse } ctl.pulse { type pulse } pcm.!default { type pulse } ctl.!default { type pulse } ``` Based on https://help.ubuntu.com/community/DigitalAC-3Pulseaudio#Configuring_asound.…. After that, I wanted to investigate the cause and report my findings to either ALSA or PulseAudio (depending on the results). Unfortunately that never happened and I kinda forgot about it, as [libasound2-plugins](https://packages.debian.org/bullseye/libasound2-plugins) was updated a single time in the past year and thus I only had to replace the file's content once more. Fast-forward to today: I switch from PulseAudio to PipeWire and while troubleshooting https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/1143 I decided to try to restore the original file. Interestingly, the behavior is different compared to PulseAudio: audio, instead of being fast, is crackling. It's basically as if a frame every two is being skipped. Unfortunately PipeWire reports no errors whatsoever. Issue URL : https://github.com/alsa-project/alsa-plugins/issues/21 Repository URL: https://github.com/alsa-project/alsa-plugins

1 0

[a52] Strange behavior with 5.1 surround on ALC1220
by GitHub issues - edited 05 May '21

05 May '21

alsa-project/alsa-plugins issue #21 was edited from davidebeatrici: I originally encountered the issue ~1 year ago, when I started using a motherboard with an ALC1120 on it. The out-of-box experience was flawless: I simply connected the optical SPDIF cable to my amplifier/receiver and stereo sound immediately worked. Once I switched to 5.1 surround, audio output became extremely fast; even videos were affected by it, to the point that they were being reproduced in seconds instead of minutes. After a few days of research and experiments I managed to workaround the issue by replacing the content of `60-a52-encoder.conf` with: ``` pcm.a52 { @args [CARD] @args.CARD { type string } type rate slave { pcm { type a52 card $CARD } rate 48000 } } pcm.pulse { type pulse } ctl.pulse { type pulse } pcm.!default { type pulse } ctl.!default { type pulse } ``` Based on https://help.ubuntu.com/community/DigitalAC-3Pulseaudio#Configuring_asound.…. After that, I wanted to investigate the cause and report my findings to either ALSA or PulseAudio (depending on the results). Unfortunately that never happened and I kinda forgot about it, as [libasound2-plugins](https://packages.debian.org/bullseye/libasound2-plugins) was updated a single time in the past year and thus I only had to replace the file's content once more. Fast-forward to today: I switch from PulseAudio to PipeWire and while troubleshooting https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/1143 I decided to try to restore the original file. Interestingly, the behavior is different compared to PulseAudio: audio, instead of being fast, is crackling. It's basically as if a frame every two is being skipped. Unfortunately PipeWire reports no errors whatsoever. Issue URL : https://github.com/alsa-project/alsa-plugins/issues/21 Repository URL: https://github.com/alsa-project/alsa-plugins

1 0

[a52] Strange behavior with 5.1 surround on ALC1120
by GitHub issues - opened 05 May '21

05 May '21

alsa-project/alsa-plugins issue #21 was opened from davidebeatrici: I originally encountered the issue ~1 year ago, when I started using a motherboard with an ALC1120 on it. The out-of-box experience was flawless: I simply connected the optical SPDIF cable to my amplifier/receiver and stereo sound immediately worked. Once I switched to 5.1 surround, audio output became extremely fast; even videos were affected by it, to the point that they were being reproduced in seconds instead of minutes. After a few days of research and experiments I managed to workaround the issue by replacing the content of `60-a52-encoder.conf` with: ``` pcm.a52 { @args [CARD] @args.CARD { type string } type rate slave { pcm { type a52 card $CARD } rate 48000 } } pcm.pulse { type pulse } ctl.pulse { type pulse } pcm.!default { type pulse } ctl.!default { type pulse } ``` Based on https://help.ubuntu.com/community/DigitalAC-3Pulseaudio#Configuring_asound.…. After that, I wanted to investigate the cause and report my findings to either ALSA or PulseAudio (depending on the results). Unfortunately that never happened and I kinda forgot about it, as [libasound2-plugins](https://packages.debian.org/bullseye/libasound2-plugins) was updated a single time in the past year and thus I only had to replace the file's content once more. Fast-forward to today: I switch from PulseAudio to PipeWire and while troubleshooting https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/1143 I decided to try to restore the original file. Interestingly, the behavior is different compared to PulseAudio: audio, instead of being fast, is crackling. It's basically as if a frame every two is being skipped. Unfortunately PipeWire reports no errors whatsoever. Issue URL : https://github.com/alsa-project/alsa-plugins/issues/21 Repository URL: https://github.com/alsa-project/alsa-plugins

1 0