- Patch - mailman.alsa-project.org

Re: [ALSA patch] [PATCH v2] ASoC: Intel: catpt: select WANT_DEV_COREDUMP
by Rojewski, Cezary 17 Nov '20

17 Nov '20

On 2020-11-17 3:52 PM, Gustaw Lewandowski wrote: > From: Piotr Maziarz <piotrx.maziarz(a)linux.intel.com> > > Select WANT_DEV_COREDUMP for catpt driver. > > Signed-off-by: Piotr Maziarz <piotrx.maziarz(a)linux.intel.com> > Signed-off-by: Gustaw Lewandowski <gustaw.lewandowski(a)linux.intel.com> > Thanks for this update, Gustaw. Acked-by: Cezary Rojewski <cezary.rojewski(a)intel.com> > -- > Changes in v2: > - change should be added to catpt only > --- > sound/soc/intel/Kconfig | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/sound/soc/intel/Kconfig b/sound/soc/intel/Kconfig > index a5b446d5af19..52ae7c981f56 100644 > --- a/sound/soc/intel/Kconfig > +++ b/sound/soc/intel/Kconfig > @@ -24,6 +24,7 @@ config SND_SOC_INTEL_CATPT > depends on DMADEVICES && SND_DMA_SGBUF > select DW_DMAC_CORE > select SND_SOC_ACPI_INTEL_MATCH > + select WANT_DEV_COREDUMP > help > Enable support for Intel(R) Haswell and Broadwell platforms > with I2S codec present. This is a recommended option. >

1 0

Re: [ALSA patch] [PATCH v3 1/1] ALSA: hda: Refactor calculating SDnFMT according to specification
by Takashi Iwai 22 Sep '20

22 Sep '20

On Tue, 22 Sep 2020 17:33:32 +0200, Pawel Harlozinski wrote: > > Fix setting SDnFMT based on :wq > High Definition Audio Specification Rev. 1.0a page 48. > > Bits per Sample (BITS): > 000 = 8 bits. The data will be packed in memory in 8-bit containers on 16-bit boundaries. > 001 = 16 bits. The data will be packed in memory in 16-bit containers on 16-bit boundaries. > 010 = 20 bits. The data will be packed in memory in 32-bit containers on 32-bit boundaries. > 011 = 24 bits. The data will be packed in memory in 32-bit containers on 32-bit boundaries. > 100 = 32 bits. The data will be packed in memory in 32-bit containers on 32-bit boundaries. > 101-111 = Reserved > > Set SDnFMT depending on which format was given. > Henceforth split cases for formats 20, 24, 32 bits, > but leave constraints to maxbps. > > Signed-off-by: Pawel Harlozinski <pawel.harlozinski(a)linux.intel.com> As I repeatedly wrote, the bits 20 and 24 cases never hit practically, hence this "refactoring" doesn't give any change in reality. Your commit misses that point. That said, this can be taken as a complementary for the theoretical case, but the situation has to be clarified in the commit log, and the subject should be adjusted as well. thanks, Takashi > > --- > > v3: drop gerrit Change-Id > v2: leave constraints to maxbps > > sound/hda/hdac_device.c | 7 +++++++ > 1 file changed, 7 insertions(+) > > diff --git a/sound/hda/hdac_device.c b/sound/hda/hdac_device.c > index 3e9e9ac804f6..ccc47a10ba63 100644 > --- a/sound/hda/hdac_device.c > +++ b/sound/hda/hdac_device.c > @@ -764,7 +764,14 @@ unsigned int snd_hdac_calc_stream_format(unsigned int rate, > val |= AC_FMT_BITS_16; > break; > case 20: > + val |= AC_FMT_BITS_20; > + break; > case 24: > + if (maxbps >= 24) > + val |= AC_FMT_BITS_24; > + else > + val |= AC_FMT_BITS_20; > + break; > case 32: > if (maxbps >= 32 || format == SNDRV_PCM_FORMAT_FLOAT_LE) > val |= AC_FMT_BITS_32; > -- > 2.17.1 >

1 0

Re: [ALSA patch] [PATCH v2 1/1] ALSA: hda: Refactor calculating SDnFMT according to specification
by Takashi Iwai 21 Sep '20

21 Sep '20

On Mon, 21 Sep 2020 11:42:00 +0200, Pawel Harlozinski wrote: > > Fix setting SDnFMT based on High Definition Audio Specification Rev. 1.0a page 48. > > Bits per Sample (BITS): > 000 = 8 bits. The data will be packed in memory in 8-bit containers on 16-bit boundaries. > 001 = 16 bits. The data will be packed in memory in 16-bit containers on 16-bit boundaries. > 010 = 20 bits. The data will be packed in memory in 32-bit containers on 32-bit boundaries. > 011 = 24 bits. The data will be packed in memory in 32-bit containers on 32-bit boundaries. > 100 = 32 bits. The data will be packed in memory in 32-bit containers on 32-bit boundaries. > 101-111 = Reserved > > Set SDnFMT depending on which format was given. > Henceforth split cases for formats 20, 24, 32 bits, > but leave constraints to maxbps. As mentioned in the previous thread, practically seen, case 20 and 24 are never met, since HD-audio doesn't accept the SNDRV_PCM_FORMAT_20* or _24* due to the 32bit container. So this change is superfluous. I can take the change, but it has to be clarified that it won't affect the behavior on the real hardware but pure theoretical. > Change-Id: I97771b16da14e85b7f35372f5dfc87bb13bb5ce0 Please drop change-id. It's not useful for others. thanks, Takashi > Signed-off-by: Pawel Harlozinski <pawel.harlozinski(a)linux.intel.com> > --- > sound/hda/hdac_device.c | 7 +++++++ > 1 file changed, 7 insertions(+) > > diff --git a/sound/hda/hdac_device.c b/sound/hda/hdac_device.c > index 3e9e9ac804f6..ccc47a10ba63 100644 > --- a/sound/hda/hdac_device.c > +++ b/sound/hda/hdac_device.c > @@ -764,7 +764,14 @@ unsigned int snd_hdac_calc_stream_format(unsigned int rate, > val |= AC_FMT_BITS_16; > break; > case 20: > + val |= AC_FMT_BITS_20; > + break; > case 24: > + if (maxbps >= 24) > + val |= AC_FMT_BITS_24; > + else > + val |= AC_FMT_BITS_20; > + break; > case 32: > if (maxbps >= 32 || format == SNDRV_PCM_FORMAT_FLOAT_LE) > val |= AC_FMT_BITS_32; > -- > 2.17.1 >

1 0

Re: [ALSA patch] [PATCH v2 1/1] ALSA: hda: Refactor calculating SDnFMT according to specification
by Rojewski, Cezary 21 Sep '20

21 Sep '20

On 2020-09-21 11:42 AM, Pawel Harlozinski wrote: > Fix setting SDnFMT based on High Definition Audio Specification Rev. 1.0a page 48. > > Bits per Sample (BITS): > 000 = 8 bits. The data will be packed in memory in 8-bit containers on 16-bit boundaries. > 001 = 16 bits. The data will be packed in memory in 16-bit containers on 16-bit boundaries. > 010 = 20 bits. The data will be packed in memory in 32-bit containers on 32-bit boundaries. > 011 = 24 bits. The data will be packed in memory in 32-bit containers on 32-bit boundaries. > 100 = 32 bits. The data will be packed in memory in 32-bit containers on 32-bit boundaries. > 101-111 = Reserved > > Set SDnFMT depending on which format was given. > Henceforth split cases for formats 20, 24, 32 bits, > but leave constraints to maxbps. > > Change-Id: I97771b16da14e85b7f35372f5dfc87bb13bb5ce0 Hello, checkpatch script should have notified you about need for removing Change-Id. Please remove for the next version. Has there been any explanation for why v2 is sent and what changes have been made between v1 and v2? Czarek > Signed-off-by: Pawel Harlozinski <pawel.harlozinski(a)linux.intel.com> > --- > sound/hda/hdac_device.c | 7 +++++++ > 1 file changed, 7 insertions(+) > > diff --git a/sound/hda/hdac_device.c b/sound/hda/hdac_device.c > index 3e9e9ac804f6..ccc47a10ba63 100644 > --- a/sound/hda/hdac_device.c > +++ b/sound/hda/hdac_device.c > @@ -764,7 +764,14 @@ unsigned int snd_hdac_calc_stream_format(unsigned int rate, > val |= AC_FMT_BITS_16; > break; > case 20: > + val |= AC_FMT_BITS_20; > + break; > case 24: > + if (maxbps >= 24) > + val |= AC_FMT_BITS_24; > + else > + val |= AC_FMT_BITS_20; > + break; > case 32: > if (maxbps >= 32 || format == SNDRV_PCM_FORMAT_FLOAT_LE) > val |= AC_FMT_BITS_32; >

1 0

Re: [ALSA patch] [PATCH] ALSA: hda: Refactor calculating SDnFMT according to specification
by Takashi Iwai 02 Sep '20

02 Sep '20

On Mon, 24 Aug 2020 14:16:26 +0200, Kai Vehmanen wrote: > > Hey, > > On Mon, 24 Aug 2020, Pawel Harlozinski wrote: > > > Set SDnFMT depending on which format was given, as maxbps only describes container size. > > hmm, I'm not entirely sure that is correct. Usage may be a bit varied, but > most places in existing code, "maxbps" is treated as number of significant > bits, not the container size. E.g. in hdac_hda.c: > > » if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) > » » maxbps = dai->driver->playback.sig_bits; > » else > » » maxbps = dai->driver->capture.sig_bits; > > It would seem "maxbps" is a bit superfluous given the same information can > be relayed in "format" as well. But currently it's still used. E.g. if you > look at snd_hdac_query_supported_pcm(), if codec reports 24bit support, > format is always set to SNDRV_PCM_FMTBIT_S32_LE, even if only 24bit are > valid. So snd_pcm_format_width() will not return the expected significant > bits info, but you have to use "maxbps". So original code seems correct > (or at least you'd need to update both places). Hm, we need to check the call pattern, then. The maxbps passed to this function was supposed to be the value obtained from snd_hdac_query_supported_pcm(), i.e. the codec capability. But, basically this patch wouldn't change any practical behavior. In the current code, snd_pcm_format_width() can be never 20 or 24, because the 24 and 24bit supports are also with SNDRV_PCM_FMT_S32_LE. That is, the cases 20 and 24 there are superfluous from the beginning (although the checks of maxbps are still needed). Instead, what we could improve is: - Set up the proper msbits hw_constraint to reflect the maxbps value - Choose the right AC_FMT_BITS_* depending on the hw_params msbits We may change the query function not to return a single maxbps value but rather storing the raw PCM parameter value (AC_SUPPCM_*), and pass it at re-encoding the format value, too, if we want to make things perfect. thanks, Takashi

2 2

[PATCH] ALSA: hda: Refactor calculating SDnFMT according to specification
by Pawel Harlozinski 24 Aug '20

24 Aug '20

Fix setting SDnFMT based on High Definition Audio Specification Rev. 1.0a page 48. Bits per Sample (BITS): 000 = 8 bits. The data will be packed in memory in 8-bit containers on 16-bit boundaries. 001 = 16 bits. The data will be packed in memory in 16-bit containers on 16-bit boundaries. 010 = 20 bits. The data will be packed in memory in 32-bit containers on 32-bit boundaries. 011 = 24 bits. The data will be packed in memory in 32-bit containers on 32-bit boundaries. 100 = 32 bits. The data will be packed in memory in 32-bit containers on 32-bit boundaries. 101-111 = Reserved Set SDnFMT depending on which format was given, as maxbps only describes container size. Henceforth split cases for formats 20, 24, 32 bits. For format SNDRV_PCM_FORMAT_FLOAT_LE width is equal 32 so as previously it will end up with mask for 32 bits. Signed-off-by: Pawel Harlozinski <pawel.harlozinski(a)linux.intel.com> --- sound/hda/hdac_device.c | 11 +++++------ 1 file changed, 5 insertions(+), 6 deletions(-) diff --git a/sound/hda/hdac_device.c b/sound/hda/hdac_device.c index 333220f0f8af..2ccf79866f99 100644 --- a/sound/hda/hdac_device.c +++ b/sound/hda/hdac_device.c @@ -762,14 +762,13 @@ unsigned int snd_hdac_calc_stream_format(unsigned int rate, val |= AC_FMT_BITS_16; break; case 20: + val |= AC_FMT_BITS_20; + break; case 24: + val |= AC_FMT_BITS_24; + break; case 32: - if (maxbps >= 32 || format == SNDRV_PCM_FORMAT_FLOAT_LE) - val |= AC_FMT_BITS_32; - else if (maxbps >= 24) - val |= AC_FMT_BITS_24; - else - val |= AC_FMT_BITS_20; + val |= AC_FMT_BITS_32; break; default: return 0; -- 2.17.1

1 0

[PATCH] ALSA: usb-audio: ignore broken processing/extension unit
by tom.ty89＠gmail.com 17 Aug '20

17 Aug '20

From: Tom Yan <tom.ty89(a)gmail.com> Some devices have broken extension unit where getting current value doesn't work. Attempt that once when creating mixer control for it. If it fails, just ignore it, so that it won't cripple the device entirely (and/or make the error floods). Signed-off-by: Tom Yan <tom.ty89(a)gmail.com> --- sound/usb/mixer.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/sound/usb/mixer.c b/sound/usb/mixer.c index eab0fd4fd7c3..e0b7174c1043 100644 --- a/sound/usb/mixer.c +++ b/sound/usb/mixer.c @@ -2367,7 +2367,7 @@ static int build_audio_procunit(struct mixer_build *state, int unitid, int num_ins; struct usb_mixer_elem_info *cval; struct snd_kcontrol *kctl; - int i, err, nameid, type, len; + int i, err, nameid, type, len, val; const struct procunit_info *info; const struct procunit_value_info *valinfo; const struct usbmix_name_map *map; @@ -2470,6 +2470,12 @@ static int build_audio_procunit(struct mixer_build *state, int unitid, break; } + err = get_cur_ctl_value(cval, cval->control << 8, &val); + if (err < 0) { + usb_mixer_elem_info_free(cval); + return -EINVAL; + } + kctl = snd_ctl_new1(&mixer_procunit_ctl, cval); if (!kctl) { usb_mixer_elem_info_free(cval); -- 2.28.0

2 1

[PATCH] ALSA: usb-audio: ignore broken processing/extension unit
by tom.ty89＠gmail.com 16 Aug '20

16 Aug '20

From: Tom Yan <tom.ty89(a)gmail.com> Some devices have broken extension unit where getting current value doesn't work. Attempt that once when creating mixer control for it. If it fails, just ignore it, so that it won't cripple the device entirely (and/or make the error floods). --- sound/usb/mixer.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/sound/usb/mixer.c b/sound/usb/mixer.c index eab0fd4fd7c3..e0b7174c1043 100644 --- a/sound/usb/mixer.c +++ b/sound/usb/mixer.c @@ -2367,7 +2367,7 @@ static int build_audio_procunit(struct mixer_build *state, int unitid, int num_ins; struct usb_mixer_elem_info *cval; struct snd_kcontrol *kctl; - int i, err, nameid, type, len; + int i, err, nameid, type, len, val; const struct procunit_info *info; const struct procunit_value_info *valinfo; const struct usbmix_name_map *map; @@ -2470,6 +2470,12 @@ static int build_audio_procunit(struct mixer_build *state, int unitid, break; } + err = get_cur_ctl_value(cval, cval->control << 8, &val); + if (err < 0) { + usb_mixer_elem_info_free(cval); + return -EINVAL; + } + kctl = snd_ctl_new1(&mixer_procunit_ctl, cval); if (!kctl) { usb_mixer_elem_info_free(cval); -- 2.28.0

1 0

Re: [ALSA patch] [PATCH] pcm: dmix: fix access to sum-buffer in non-interleaved mixing mode
by Takashi Iwai 13 Aug '20

13 Aug '20

On Wed, 12 Aug 2020 08:18:25 +0200, Vijay Palaniswamy (RBEI/ECF3) wrote: > > Hi All, > > When dmix uses non-interleaved mixing mode the offset and step width to > sum_buffer was calculated by using the dmix channels instead of the slave > channels. This leads to audio distortions due to frame corruption. > > Issue happens while doing channel wise mixing of src and destination buffers. > > Attached the patch to fix the offset and step width calculation based on slave > channels for sum buffer. So mixed data will be saved in respective channels of > sum buffer. > > Steps to reproduce the issue: > > With below configuratio, Do aplay on both device in parallel for audio > distortion > > pcm.dmix_2_channels { > > type dmix > > ipc_key 5678293 > > ipc_perm 0660 > > ipc_gid audio > > bindings [0 1] > > slave { > > pcm "hardware" > > channels 2 > > periods 4 > > period_time 40000 > > } > > } > > pcm.dmix_1_channels { > > type dmix > > ipc_key 5678293 > > ipc_perm 0660 > > ipc_gid audio > > bindings [0] > > slave { > > pcm "hardware" > > channels 1 > > periods 4 > > period_time 40000 > > } > > } > > pcm.hardware { > > type hw > > card 0 > > channels 2 > > rate 48000 > > format S16_LE > > } > > Best regards > > Palaniswamy Vijay Applied now. Thanks. Takashi

1 0

Re: [ALSA patch] [PATCH 1/1] ALSA: hda/realtek - Fix silent output on Gigabyte X570 Aorus Xtreme
by Takashi Iwai 18 May '20

18 May '20

On Mon, 18 May 2020 07:38:44 +0200, Christian Lachner wrote: > > The Gigabyte X570 Aorus Xtreme motherboard with ALC1220 codec > requires a similar workaround for Clevo laptops to enforce the > DAC/mixer connection path. Set up a quirk entry for that. > > BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=205275 > Signed-off-by: Christian Lachner <gladiac(a)gmail.com> Applied now. thanks, Takashi

1 0

2023

2022

2021

2020

2019

Patch