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

[PATCH v5 0/4] Add CS35L41 shared boost feature
by Lucas Tanure 21 Feb '23

21 Feb '23

Valve's Steam Deck uses CS35L41 in shared boost mode, where both speakers share the boost circuit. Add this support in the shared lib, but for now, shared boost is not supported in HDA systems as would require BIOS changes. Based on David Rhodes shared boost patches. Also, fix boost config overwriting in IRQ found in the review and do a small refactor of the code. Changes from V4: - Fix Document subject Changes from V3: - Fix wrong code sent - Fix ISO C90 mixed declarations and code Changes from V2: - Drop External boost without VSPK Documentation - Move Shared boost to use values 2 and 3 - Revert back to reg_sequence but reading the value first and only update the necessary bits - Fix bug found by Intel kernel Test Robot Changes from V1: - Fix Documentation patch subject - New patch for External boost without VSPK Documentation - New patch to fix boost IRQ overwriting issue - New patch to refactor IRQ release error code - reinit_completion on pcm_startup - fix DRE switch overwriting - return IRQ_HANDLED in PLL_LOCK case Lucas Tanure (4): ASoC: cs35l41: Only disable internal boost ASoC: cs35l41: Refactor error release code ALSA: cs35l41: Add shared boost feature ASoC: dt-bindings: cirrus,cs35l41: Document CS35l41 shared boost .../bindings/sound/cirrus,cs35l41.yaml | 10 +- include/sound/cs35l41.h | 13 +- sound/pci/hda/cs35l41_hda.c | 6 +- sound/soc/codecs/cs35l41-lib.c | 73 +++++++++- sound/soc/codecs/cs35l41.c | 125 +++++++++--------- sound/soc/codecs/cs35l41.h | 1 + 6 files changed, 157 insertions(+), 71 deletions(-) -- 2.39.1

4 14

[PATCH v2 0/3] ASoC: mchp-pdmc: fix poc noises when starting capture
by Claudiu Beznea 21 Feb '23

21 Feb '23

To start capture on Microchip PDMC the enable bits for each supported microphone need to be set. After this bit is set the PDMC starts to receive data from microphones and it considers this data as valid data. Thus if microphones are not ready the PDMC captures anyway data from its lines. This data is interpreted by the human ear as poc noises. To avoid this the following software workaround need to be applied when starting capture: 1/ enable PDMC channel 2/ wait 150ms 3/ execute 16 dummy reads from RHR 4/ clear interrupts 5/ enable interrupts 6/ enable DMA channel For this workaround to work step 6 need to be executed at the end. For step 6 was added patch 1/3 from this series. With this, component DAI driver sets its struct snd_soc_component_driver::start_dma_last = 1 and proper action is taken based on this flag when starting DAI trigger vs DMA. Thank you, Claudiu Beznea Changes in v2: - patch 1/3 from v1 is now "ASoC: soc-pcm: add option to start DMA after DAI" - pass start_dma_last from component DAI driver object (struct snd_soc_component_driver::start_dma_last); adapt patch 3/3 after this; - in patch 1/3 s/Do we need to start dma first/Do we need to start dma last in comment from soc_pcm_trigger() - collect review tag from Krzysztof Claudiu Beznea (3): ASoC: soc-pcm: add option to start DMA after DAI ASoC: dt-bindings: sama7g5-pdmc: add microchip,startup-delay-us binding ASoC: mchp-pdmc: fix poc noise at capture startup .../sound/microchip,sama7g5-pdmc.yaml | 6 ++ include/sound/soc-component.h | 2 + sound/soc/atmel/mchp-pdmc.c | 55 +++++++++++++++++-- sound/soc/soc-pcm.c | 27 +++++++-- 4 files changed, 80 insertions(+), 10 deletions(-) -- 2.34.1

6 10

alsa-devel mailing list - mailman upgrade
by Jaroslav Kysela 21 Feb '23

21 Feb '23

Hi all, I upgraded the mailman 2 to mailman 3 on the ALSA server. I hope that you do not see any differences, but there is a major change in the handling of the user logins to maintain your subscription using the web interface [1]. It means that you should create a new user account on the mailman server [2]. Do not request the password change for the first login. Although the subscriptions are migrated, the new system will send you a reply that your e-mail is not in the user database. Although it is technically correct, it is very confusing. Create a new account using identical e-mail as you are subscribed. Your subscription will be assigned to this account according your e-mail. You will be allowed to maintain all list subscriptions on the server then (not only one list subscription like before). Archive URLs are different, but I will keep the old archive (URLs), too. Enjoy new Postorius and HyperKitty frontends. If you have any issue, please, let me know. Thanks, Jaroslav [1] https://docs.mailman3.org/en/latest/faq-migration.html [2] https://mailman.alsa-project.org -- Jaroslav Kysela <perex(a)perex.cz> Linux Sound Maintainer; ALSA Project; Red Hat, Inc.

1 0

[PATCH RFC 0/3] Add Versa3 clock generator support
by Biju Das 20 Feb '23

20 Feb '23

The 5P35023 is a VersaClock programmable clock generator and it provides 6 clk outputs {diff2, diff1, se3, se2, se1 and refin}. It has an internal OTP memory allows the user to store the configuration in the device. After power up, the user can change the device register settings through the I2C interface when I2C mode is selected. This driver is for overriding OTP default values during boot based on a full register map from DT, and also minimal support to change the parent of a output clock. The motivation for developing this driver is for supporting 48KHz playback/record with audio codec on RZ/G2L SMARC EVK. On RZ/G2L SMARC EVK, By default audio mclk is connected to 11.2896 MHz clk which is multiple of 44.1KHz. Please see the below default OTP configuration of Dividers connected to output clocks. DIV3 12.2880 MHz DIFF2--> Audio clk2 DIV5 11.2896 MHz SE1 --> Audio clk1 DIV5 11.2896 MHz SE2 --> Audio mck DIV4 12 MHz SE3 --> This clk Not used DIV1 25 MHz DIFF1-->Ethernet clk Ref1-> 24MHz With this setup, we won't be able to do 48KHz playback/record on audio codec, as mck is always connected to 11.2896MHz clk. But by programming the i2c, we can make use of DIV4 to generate 12.2880 MHz and make that as parent of SE2 and there by supporting 48KHz playback/record. A block diagram with modification can be find here[1] [1]https://paste.pics/a253ce7cdc8720c3b5eb6953b97b25ff DIV3 12.2880 MHz DIFF2--> Audio clk2 DIV5 11.2896 MHz SE1 --> Audio clk1 DIV5 11.2896 MHz | SE2 --> Audio mck DIV4 12.2880 MHz | DIV2 12 MHz SE3 --> This clk Not used DIV1 25 MHz DIFF1--> Ethernet clk Ref1-> 24MHz The driver can read a full register map from the DT, and will use that register map to initialize the clk generator when the system boots. and later, based on sampling rate, it switches the parent of SE2 and support both 44.1 and 48 KHz playback/record at run time. 48KHz playback 1f: f6 --> setting Div4 as clock source for se2 Read at address 0x10049C00 : 0x300B4022 --> Setting Audio clk2 in SSI pfd2 1 1 0 24000000 pll2 1 1 0 491519897 div4_mux 1 1 0 491519897 div4 1 1 0 12287998 se2_mux 1 1 0 12287998 se2 1 1 0 12287998 44.1KHz playback 1f: b6 --> setting Div5 as clock source for se2 Read at address 0x10049C00: 0x700B4022--> Setting Audio clk1 in SSI pfd3_mux 1 1 0 24000000 pfd3 1 1 0 960000 pll3 1 1 0 564480000 div5 1 1 0 11289600 se2_mux 1 1 0 11289600 se2 1 1 0 11289600 Please provide your valuable comment for this patch series. Biju Das (3): dt-bindings: clock: Add Renesas versa3 clock generator bindings drivers: clk: Add support for versa3 clock driver arm64: dts: renesas: rzg2l-smarc: Use versa3 clk for audio mclk .../bindings/clock/renesas,versaclock3.yaml | 135 ++ .../boot/dts/renesas/rz-smarc-common.dtsi | 7 - arch/arm64/boot/dts/renesas/rzg2l-smarc.dtsi | 35 + drivers/clk/Kconfig | 9 + drivers/clk/Makefile | 1 + drivers/clk/clk-versaclock3.c | 1134 +++++++++++++++++ 6 files changed, 1314 insertions(+), 7 deletions(-) create mode 100644 Documentation/devicetree/bindings/clock/renesas,versaclock3.yaml create mode 100644 drivers/clk/clk-versaclock3.c -- 2.25.1

1 1

[PATCH BACKPORT 5.4] ASoC: SOF: Intel: hda-dai: fix possible stream_tag leak
by Peter Ujfalusi 20 Feb '23

20 Feb '23

[ Upstream commit 1f810d2b6b2fbdc5279644d8b2c140b1f7c9d43d ] There were just too many code changes since 5.4 stable to prevent clean picking the fix from mainline. The HDaudio stream allocation is done first, and in a second step the LOSIDV parameter is programmed for the multi-link used by a codec. This leads to a possible stream_tag leak, e.g. if a DisplayAudio link is not used. This would happen when a non-Intel graphics card is used and userspace unconditionally uses the Intel Display Audio PCMs without checking if they are connected to a receiver with jack controls. We should first check that there is a valid multi-link entry to configure before allocating a stream_tag. This change aligns the dma_assign and dma_cleanup phases. Cc: stable(a)vger.kernel.org # 5.4.x Complements: b0cd60f3e9f5 ("ALSA/ASoC: hda: clarify bus_get_link() and bus_link_get() helpers") Link: https://github.com/thesofproject/linux/issues/4151 Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart(a)linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan(a)linux.intel.com> Reviewed-by: Rander Wang <rander.wang(a)intel.com> Reviewed-by: Bard Liao <yung-chuan.liao(a)linux.intel.com> Signed-off-by: Peter Ujfalusi <peter.ujfalusi(a)linux.intel.com> Link: https://lore.kernel.org/r/20230216162340.19480-1-peter.ujfalusi@linux.intel… Signed-off-by: Mark Brown <broonie(a)kernel.org> --- sound/soc/sof/intel/hda-dai.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/sound/soc/sof/intel/hda-dai.c b/sound/soc/sof/intel/hda-dai.c index b3cdd10c83ae..c30e450fa970 100644 --- a/sound/soc/sof/intel/hda-dai.c +++ b/sound/soc/sof/intel/hda-dai.c @@ -211,6 +211,10 @@ static int hda_link_hw_params(struct snd_pcm_substream *substream, int stream_tag; int ret; + link = snd_hdac_ext_bus_get_link(bus, codec_dai->component->name); + if (!link) + return -EINVAL; + /* get stored dma data if resuming from system suspend */ link_dev = snd_soc_dai_get_dma_data(dai, substream); if (!link_dev) { @@ -231,10 +235,6 @@ static int hda_link_hw_params(struct snd_pcm_substream *substream, if (ret < 0) return ret; - link = snd_hdac_ext_bus_get_link(bus, codec_dai->component->name); - if (!link) - return -EINVAL; - /* set the stream tag in the codec dai dma params */ if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) snd_soc_dai_set_tdm_slot(codec_dai, stream_tag, 0, 0, 0); -- 2.39.2

2 1

[PATCH BACKPORT 5.10, 5.15] ASoC: SOF: Intel: hda-dai: fix possible stream_tag leak
by Peter Ujfalusi 20 Feb '23

20 Feb '23

[ Upstream commit 1f810d2b6b2fbdc5279644d8b2c140b1f7c9d43d ] There were just too many code changes since 5.10/5.15 stable to prevent clean picking the fix from mainline. The HDaudio stream allocation is done first, and in a second step the LOSIDV parameter is programmed for the multi-link used by a codec. This leads to a possible stream_tag leak, e.g. if a DisplayAudio link is not used. This would happen when a non-Intel graphics card is used and userspace unconditionally uses the Intel Display Audio PCMs without checking if they are connected to a receiver with jack controls. We should first check that there is a valid multi-link entry to configure before allocating a stream_tag. This change aligns the dma_assign and dma_cleanup phases. Cc: stable(a)vger.kernel.org # 5.15.x 5.10.x Complements: b0cd60f3e9f5 ("ALSA/ASoC: hda: clarify bus_get_link() and bus_link_get() helpers") Link: https://github.com/thesofproject/linux/issues/4151 Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart(a)linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan(a)linux.intel.com> Reviewed-by: Rander Wang <rander.wang(a)intel.com> Reviewed-by: Bard Liao <yung-chuan.liao(a)linux.intel.com> Signed-off-by: Peter Ujfalusi <peter.ujfalusi(a)linux.intel.com> Link: https://lore.kernel.org/r/20230216162340.19480-1-peter.ujfalusi@linux.intel… Signed-off-by: Mark Brown <broonie(a)kernel.org> --- sound/soc/sof/intel/hda-dai.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/sound/soc/sof/intel/hda-dai.c b/sound/soc/sof/intel/hda-dai.c index de80f1b3d7f2..a6275cc92a40 100644 --- a/sound/soc/sof/intel/hda-dai.c +++ b/sound/soc/sof/intel/hda-dai.c @@ -212,6 +212,10 @@ static int hda_link_hw_params(struct snd_pcm_substream *substream, int stream_tag; int ret; + link = snd_hdac_ext_bus_get_link(bus, codec_dai->component->name); + if (!link) + return -EINVAL; + /* get stored dma data if resuming from system suspend */ link_dev = snd_soc_dai_get_dma_data(dai, substream); if (!link_dev) { @@ -232,10 +236,6 @@ static int hda_link_hw_params(struct snd_pcm_substream *substream, if (ret < 0) return ret; - link = snd_hdac_ext_bus_get_link(bus, codec_dai->component->name); - if (!link) - return -EINVAL; - /* set the hdac_stream in the codec dai */ snd_soc_dai_set_stream(codec_dai, hdac_stream(link_dev), substream->stream); -- 2.39.2

1 0

[PATCH BACKPORT 6.0, 6.1] ASoC: SOF: Intel: hda-dai: fix possible stream_tag leak
by Peter Ujfalusi 20 Feb '23

20 Feb '23

[ Upstream commit 1f810d2b6b2fbdc5279644d8b2c140b1f7c9d43d ] The reason for manual backport is that in 6.2 there were a naming cleanup around hdac, link, hlink, for example snd_hdac_ext_bus_get_link is renamed to snd_hdac_ext_bus_get_hlink_by_name in 6.2. The HDaudio stream allocation is done first, and in a second step the LOSIDV parameter is programmed for the multi-link used by a codec. This leads to a possible stream_tag leak, e.g. if a DisplayAudio link is not used. This would happen when a non-Intel graphics card is used and userspace unconditionally uses the Intel Display Audio PCMs without checking if they are connected to a receiver with jack controls. We should first check that there is a valid multi-link entry to configure before allocating a stream_tag. This change aligns the dma_assign and dma_cleanup phases. Cc: stable(a)vger.kernel.org # 6.1.x 6.0.x Complements: b0cd60f3e9f5 ("ALSA/ASoC: hda: clarify bus_get_link() and bus_link_get() helpers") Link: https://github.com/thesofproject/linux/issues/4151 Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart(a)linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan(a)linux.intel.com> Reviewed-by: Rander Wang <rander.wang(a)intel.com> Reviewed-by: Bard Liao <yung-chuan.liao(a)linux.intel.com> Signed-off-by: Peter Ujfalusi <peter.ujfalusi(a)linux.intel.com> Link: https://lore.kernel.org/r/20230216162340.19480-1-peter.ujfalusi@linux.intel… Signed-off-by: Mark Brown <broonie(a)kernel.org> --- sound/soc/sof/intel/hda-dai.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/sound/soc/sof/intel/hda-dai.c b/sound/soc/sof/intel/hda-dai.c index 556e883a32ed..5f03ee390d54 100644 --- a/sound/soc/sof/intel/hda-dai.c +++ b/sound/soc/sof/intel/hda-dai.c @@ -216,6 +216,10 @@ static int hda_link_dma_hw_params(struct snd_pcm_substream *substream, struct hdac_bus *bus = hstream->bus; struct hdac_ext_link *link; + link = snd_hdac_ext_bus_get_link(bus, codec_dai->component->name); + if (!link) + return -EINVAL; + hext_stream = snd_soc_dai_get_dma_data(cpu_dai, substream); if (!hext_stream) { hext_stream = hda_link_stream_assign(bus, substream); @@ -225,10 +229,6 @@ static int hda_link_dma_hw_params(struct snd_pcm_substream *substream, snd_soc_dai_set_dma_data(cpu_dai, substream, (void *)hext_stream); } - link = snd_hdac_ext_bus_get_link(bus, codec_dai->component->name); - if (!link) - return -EINVAL; - /* set the hdac_stream in the codec dai */ snd_soc_dai_set_stream(codec_dai, hdac_stream(hext_stream), substream->stream); -- 2.39.2

1 0

[PATCH] ASoC: Intel: sof_rt5682: Add quirk for Rex board with mx98360a amplifier
by Peter Ujfalusi 20 Feb '23

20 Feb '23

From: "Dharageswari.R" <dharageswari.r(a)intel.com> Add mtl_mx98360a_rt5682 driver data for Chrome Rex board support. Signed-off-by: Dharageswari.R <dharageswari.r(a)intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart(a)linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan(a)linux.intel.com> Signed-off-by: Peter Ujfalusi <peter.ujfalusi(a)linux.intel.com> --- sound/soc/intel/boards/sof_rt5682.c | 23 +++++++++++++++++++ .../intel/common/soc-acpi-intel-mtl-match.c | 12 ++++++++++ 2 files changed, 35 insertions(+) diff --git a/sound/soc/intel/boards/sof_rt5682.c b/sound/soc/intel/boards/sof_rt5682.c index 71a11d747622..4fe448295a90 100644 --- a/sound/soc/intel/boards/sof_rt5682.c +++ b/sound/soc/intel/boards/sof_rt5682.c @@ -223,6 +223,20 @@ static const struct dmi_system_id sof_rt5682_quirk_table[] = { SOF_RT5682_SSP_AMP(2) | SOF_RT5682_NUM_HDMIDEV(4)), }, + { + .callback = sof_rt5682_quirk_cb, + .matches = { + DMI_MATCH(DMI_PRODUCT_FAMILY, "Google_Rex"), + DMI_MATCH(DMI_OEM_STRING, "AUDIO-MAX98360_ALC5682I_I2S"), + }, + .driver_data = (void *)(SOF_RT5682_MCLK_EN | + SOF_RT5682_SSP_CODEC(2) | + SOF_SPEAKER_AMP_PRESENT | + SOF_MAX98360A_SPEAKER_AMP_PRESENT | + SOF_RT5682_SSP_AMP(0) | + SOF_RT5682_NUM_HDMIDEV(4) + ), + }, { .callback = sof_rt5682_quirk_cb, .matches = { @@ -1105,6 +1119,15 @@ static const struct platform_device_id board_ids[] = { SOF_RT5682_SSP_AMP(1) | SOF_RT5682_NUM_HDMIDEV(4)), }, + { + .name = "mtl_mx98360_rt5682", + .driver_data = (kernel_ulong_t)(SOF_RT5682_MCLK_EN | + SOF_RT5682_SSP_CODEC(0) | + SOF_SPEAKER_AMP_PRESENT | + SOF_MAX98360A_SPEAKER_AMP_PRESENT | + SOF_RT5682_SSP_AMP(1) | + SOF_RT5682_NUM_HDMIDEV(4)), + }, { .name = "jsl_rt5682", .driver_data = (kernel_ulong_t)(SOF_RT5682_MCLK_EN | diff --git a/sound/soc/intel/common/soc-acpi-intel-mtl-match.c b/sound/soc/intel/common/soc-acpi-intel-mtl-match.c index b1a66a0f6818..7911c3af8071 100644 --- a/sound/soc/intel/common/soc-acpi-intel-mtl-match.c +++ b/sound/soc/intel/common/soc-acpi-intel-mtl-match.c @@ -15,6 +15,11 @@ static const struct snd_soc_acpi_codecs mtl_max98357a_amp = { .codecs = {"MX98357A"} }; +static const struct snd_soc_acpi_codecs mtl_max98360a_amp = { + .num_codecs = 1, + .codecs = {"MX98360A"} +}; + static const struct snd_soc_acpi_codecs mtl_rt5682_rt5682s_hp = { .num_codecs = 2, .codecs = {"10EC5682", "RTL5682"}, @@ -28,6 +33,13 @@ struct snd_soc_acpi_mach snd_soc_acpi_intel_mtl_machines[] = { .quirk_data = &mtl_max98357a_amp, .sof_tplg_filename = "sof-mtl-max98357a-rt5682.tplg", }, + { + .comp_ids = &mtl_rt5682_rt5682s_hp, + .drv_name = "mtl_mx98360_rt5682", + .machine_quirk = snd_soc_acpi_codec_list, + .quirk_data = &mtl_max98360a_amp, + .sof_tplg_filename = "sof-mtl-max98360a-rt5682.tplg", + }, {}, }; EXPORT_SYMBOL_GPL(snd_soc_acpi_intel_mtl_machines); -- 2.39.2

1 0

[PATCH 0/3] SoC: SOF: Intel: hda/mtl: Improve and enable DMI L1 haldling
by Peter Ujfalusi 20 Feb '23

20 Feb '23

Hi, The first patch will improve the managing of DMI L1 by tracking it's enabled/disabled state to avoid unconditional changes to it's state. The remaining two patch will enable the DMI L1 for MTL platforms (ACE 1.0) Regards, Peter --- Ranjani Sridharan (3): ASoC: SOF: Intel: hda: Do not re-enable L1 if disabled before suspend ASoC: SOF: Intel: hda: Restrict DMI L1 disable workaround ASoC: SOF: Intel: MTL: Enable DMI L1 sound/soc/sof/intel/hda-ctrl.c | 8 +++++--- sound/soc/sof/intel/hda-dsp.c | 10 ++++------ sound/soc/sof/intel/hda-stream.c | 15 ++++++++++++--- sound/soc/sof/intel/hda.h | 2 +- sound/soc/sof/intel/mtl.c | 3 +++ sound/soc/sof/intel/mtl.h | 2 ++ 6 files changed, 27 insertions(+), 13 deletions(-) -- 2.39.2

1 3

[regression] Bug 216909 - Avantree Leaf USB audio device does not play sound in applications run via wine
by Linux kernel regression tracking (Thorsten Leemhuis) 19 Feb '23

19 Feb '23

Hi, this is your Linux kernel regression tracker. I noticed a regression report in bugzilla.kernel.org. As many (most?) kernel developer don't keep an eye on it, I decided to forward it by mail. Quoting from https://bugzilla.kernel.org/show_bug.cgi?id=216909 : > Bernd Steinhauser 2023-01-10 14:45:18 UTC > > Created attachment 303568 [details] > lsusb -v -d 0a12:1004 > > On my second PC, I'm using a USB audio device called "Avantree Leaf" to pass audio via bluetooth to a receiver. About 1-2 months ago, I noticed that I have no audio with this device when playing sounds via wine applications (e.g. foobar2000 or any kind of game via proton/wine), neither via the pulseaudio output, nor alsa. > Native Linux applications work fine (or at least I haven't found one yet that doesn't work) via both pulse or alsa output. > If I select another audio device (e.g. the speakers of the screen via HDMI) in winecfg for the respective wine prefix, then the audio does work. > Also, if I "prime" the device by playing audio via a native application and then the audio works. > > I'm using pipewire-0.3.63 with pipewire-pulse as an audio server, but I've also tried with recent pulseaudio and they are both affected. > For pipewire, I played a bit with the settings and found: > Brings back audio: > clock.min-quantum 512 (lower values don't work) > > Doesn't change the outcome: > ["api.alsa.period-size"] = 16 up to 1024 > ["api.alsa.disable-batch"] = true/false (in combination with the above) > ["api.alsa.headroom"] = 64 up to 1024 > > The output I get from `cat /proc/asound/Leaf/pcm0p/sub0/hw_params`: > Native application: > access: MMAP_INTERLEAVED > format: S16_LE > subformat: STD > channels: 2 > rate: 48000 (48000/1) > period_size: 256 > buffer_size: 32768 > > foobar2000 via wine: > access: MMAP_INTERLEAVED > format: S16_LE > subformat: STD > channels: 2 > rate: 48000 (48000/1) > period_size: 128 > buffer_size: 32768 > > So they are the same, except for the period_size. > > Yesterday, I finally made some effort to track this down and I had to go back all the way to v5.14 to find the commit that is responsible: > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… > > If I test the revision before that commit, everything works as expected. If I test this revision, then the audio fails. > Of course with such an old commit, I'm not 100% sure that this is the only thing, as I can't simply revert it on a newer kernel. Too much change happened in sound/usb since then. > I did however test every mainline kernel version since 5.10 and the behavior was consistent. > Please let me know if you need any further information. See the ticket for more details. BTW, let me use this mail to also add the report to the list of tracked regressions to ensure it's doesn't fall through the cracks: #regzbot introduced: 307cc9baac5c07b23d https://bugzilla.kernel.org/show_bug.cgi?id=216909 #regzbot title: sound: avantree Leaf USB audio device stopped playing sound in applications run via wine #regzbot ignore-activity This isn't a regression? This issue or a fix for it are already discussed somewhere else? It was fixed already? You want to clarify when the regression started to happen? Or point out I got the title or something else totally wrong? Then just reply and tell me -- ideally while also telling regzbot about it, as explained by the page listed in the footer of this mail. Developers: When fixing the issue, remember to add 'Link:' tags pointing to the report (e.g. the buzgzilla ticket and maybe this mail as well, if this thread sees some discussion). See page linked in footer for details. Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat) -- Everything you wanna know about Linux kernel regression tracking: https://linux-regtracking.leemhuis.info/about/#tldr If I did something stupid, please tell me, as explained on that page.

2 1