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

[PATCH] ASoC: amd: acp: add ACP70 DMI override for new ASUS TUF platforms
by Syed Saba Kareem 14 Jul '26

14 Jul '26

From: Syed Saba Kareem <Syed.SabaKareem(a)amd.com> Some ASUS TUF ACP70-based systems expose ACP ACPI configuration flags that select a non-working fallback audio path, similar to previously affected ASUS platforms. Add DMI-based overrides in snd_amd_acp_find_config() for the following systems to skip ACP ACPI flag-based selection: - ASUS TUF Gaming Vivobook 18 - ASUS TUF Gaming A14 FA401EA This ensures the intended SoundWire-based machine driver is selected on these platforms. Signed-off-by: Syed Saba Kareem <Syed.SabaKareem(a)amd.com> --- sound/soc/amd/acp-config.c | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/sound/soc/amd/acp-config.c b/sound/soc/amd/acp-config.c index 93a2182d4e86..f4c1bae878c1 100644 --- a/sound/soc/amd/acp-config.c +++ b/sound/soc/amd/acp-config.c @@ -44,6 +44,18 @@ static const struct dmi_system_id acp70_acpi_flag_override_table[] = { DMI_MATCH(DMI_PRODUCT_NAME, "83W5"), }, }, + { + .matches = { + DMI_MATCH(DMI_BOARD_VENDOR, "ASUSTeK COMPUTER INC"), + DMI_MATCH(DMI_PRODUCT_NAME, "TUF Gaming A14 FA401EA"), + }, + }, + { + .matches = { + DMI_MATCH(DMI_BOARD_VENDOR, "ASUSTeK COMPUTER INC"), + DMI_MATCH(DMI_PRODUCT_NAME, "Vivobook 18 M1807GA"), + }, + }, {} }; -- 2.43.0

2 1

Direct TOSlink access
by Patrick 12 Jul '26

12 Jul '26

Hi All Is it possible to send data directly to the TOS-link connection? I mean without passing through the mixer. The goal is to design some electronic board and to receive data from the computer via an inexpensive link without too many cables restrictions. Does the alsa tools easy to modify to handle that?

1 0

ucm2: USB-Audio: Add RODECaster Duo
by GitHub pull_request - opened 12 Jul '26

12 Jul '26

alsa-project/alsa-ucm-conf pull request #809 was opened from parzival-space: This PR adds support for the RODECaster Duo Split PCM configuration. The RODECaster Duo is technically very similar to the RODECaster Pro II, they even share the same firmware, although channel mappings are sightly different. This profile has been successfully tested by @csanthiago in [parzival-space/rodecaster-pro-2-virtual-devices-pipewire #7](https://github.com/parzival-space/rodecaster-pro-2-virtual-devices-pipewire/issues/7). Request URL : https://github.com/alsa-project/alsa-ucm-conf/pull/809 Patch URL : https://github.com/alsa-project/alsa-ucm-conf/pull/809.patch Repository URL: https://github.com/alsa-project/alsa-ucm-conf

1 0

[GIT PULL] ASoC fixes for v7.2-rc2
by Mark Brown 10 Jul '26

10 Jul '26

The following changes since commit 8cdeaa50eae8dad34885515f62559ee83e7e8dda: Linux 7.2-rc2 (2026-07-05 14:44:06 -1000) are available in the Git repository at: https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git tags/asoc-fix-v7.2-rc2 for you to fetch changes up to 3238c634725afbb2a137fdda762208510828f71d: ASoC: tas2562: fix deprecated 'shut-down' GPIO always cleared after lookup (2026-07-09 00:33:20 +0100) ---------------------------------------------------------------- ASoC: Fixes for v7.2 A fairly standard set of device specific fixes and quriks for new devices, nothing too remarkable here. ---------------------------------------------------------------- Baojun Xu (1): ASoC: amd: acp: amd-acp70-acpi-match: Add tas2783 support Charles Keepax (1): ASoC: cs42l43: Correct report for forced microphone jack Christian Hewitt (1): ASoC: meson: aiu: fifo-spdif: soft reset the S/PDIF datapath on start/stop Maciej Strozek (1): ASoC: sof_sdw: Add a quirk for 0x17aa383c laptop using sidecar amps with cs42l43 Mark Brown (2): Vijendar Mukunda <Vijendar.Mukunda(a)amd.com> says: ASoC: qcom: Add Eliza audio support Ravi Hothi (3): ASoC: dt-bindings: qcom: Add Eliza LPASS macro codecs ASoC: dt-bindings: qcom,sm8250: Add Eliza sound card ASoC: qcom: sc8280xp: Add support for Eliza Syed Saba Kareem (1): ASoC: amd: acp: Fix linker error with SDCA quirks Tianze Shao (1): ASoC: rt712-sdca: reset codec at io_init to fix silent headphone Uday Khare (1): ASoC: tas2562: fix deprecated 'shut-down' GPIO always cleared after lookup Vijendar Mukunda (3): ASoC: amd: ps: disable MSI on resume in ACP PCI driver ASoC: amd: ps: fix wrong ACP version string in pci_request_regions() ASoC: amd: ps: replace bitwise OR with logical OR in IRQ return check .../bindings/sound/qcom,lpass-rx-macro.yaml | 1 + .../bindings/sound/qcom,lpass-tx-macro.yaml | 1 + .../bindings/sound/qcom,lpass-va-macro.yaml | 1 + .../bindings/sound/qcom,lpass-wsa-macro.yaml | 1 + .../devicetree/bindings/sound/qcom,sm8250.yaml | 1 + sound/soc/amd/acp/Kconfig | 10 +++-- sound/soc/amd/acp/Makefile | 3 +- sound/soc/amd/acp/amd-acp70-acpi-match.c | 47 +++++++++++++++++++++- sound/soc/amd/acp/soc-acpi-amd-sdca-quirks.c | 4 -- sound/soc/amd/ps/pci-ps.c | 33 ++++++++++++++- sound/soc/codecs/cs42l43-jack.c | 3 +- sound/soc/codecs/rt712-sdca.c | 11 +++++ sound/soc/codecs/tas2562.c | 5 ++- sound/soc/intel/boards/sof_sdw.c | 1 + sound/soc/meson/aiu-fifo-spdif.c | 5 +++ sound/soc/qcom/sc8280xp.c | 1 + 16 files changed, 113 insertions(+), 15 deletions(-)

2 1

[PATCH v6 0/2] ASoC: codecs: Add Nuvoton NAU83G60 audio codec driver
by Neo Chang 10 Jul '26

10 Jul '26

This patch series adds support for the Nuvoton NAU83G60 audio codec. The NAU83G60 is a stereo Class-D amplifier with an integrated DSP and I/V-sense capabilities. The driver supports I2C register access through regmap, DAPM widgets and routes, TDM interface configuration, and DSP firmware loading. The series is structured as follows: - Patch 1: Adds the YAML device tree bindings documentation. - Patch 2: Adds the ASoC codec driver implementation. Changes in v6: [dt-bindings] - Removed '|' from descriptions. - Add firmware-name in required. - Add "nuvoton,dsp-tx-slot-mapping" and "nuvoton,dsp-rx-slot-mapping" properties. [codec driver] - Fix Use-After-Free during device unbind by properly synchronizing asynchronous firmware loading. - Fallback to default firmware names if the "firmware-name" property is missing. - Parse "nuvoton,dsp-tx-slot-mapping" and "nuvoton,dsp-rx-slot-mapping" properties for static TDM routing. - Drop dynamic TDM slot mapping via ALSA kcontrols. - Replace cached tdm_chan_len with direct register reads via nau8360_get_tdm_chan_len(). Changes in v5: [dt-bindings] - Remove detailed datasheet information, keeping only the valid I2C address enum. - Simplify the `firmware-name` items definition by removing redundant minItems/maxItems and moving channel descriptions directly into individual item entries. [codec driver] - Add FW_LOADER dependency to prevent silent probe failure. - Fix uninitialized return variables and add error checks for underlying I2C reads. - Replace stack-allocated buffers in I2C transfers with heap-allocated memory. - Eliminate potential Use-After-Free by synchronizing firmware loading. - Protect PEQ memory control operations with mutex locks to ensure thread-safe register updates. - Resolve TDM slot configuration races using mutex protection. - Correct mathematically invalid TDM TX slot offsets during channel length changes. - Ensure TDM streams are explicitly disabled when slots or slot_width is zero. - Fix DSP protocol corruption due to missing locking in the DAPM clock event handler. - Use FIELD_PREP() in protocol packing functions to replace manual bit-shifting. - Replace deprecated of_property_count_strings() with device_property_read_string(). - Remove unnecessary CONFIG_ACPI ifdefs as struct acpi_device_id is universally available. - Refactor repetitive DAPM event handlers (adacl/adacr/dacl/dacr). - Simplify code flow by removing redundant gotos, variables, debug messages, and dev_get_platdata(). - Standardize driver style using switch-cases, positive logic checks, and reduced conditional nesting. Changes in v4: [dt-bindings] - Refine the firmware-name description to clarify the loading order (Left then Right) and the PBTL mode behavior. - Remove the "dsp bypass" option description. - Update the example node to follow devicetree coding styles. [codec driver] - Clean up unused DSP state flags (dsp_enable, dsp_created, dsp_fws_num). - Fixed the use of an uninitialized stack variable. - Fixed unhandled failures in nau8360_dsp_init() that caused duplicated DAPM widgets to leak. - Add mutex protection for PEQ memory and TDM slot caches. - Restored the missing hardware memory access bit during suspend/resume to prevent PEQ coefficients from being silently lost. - Handled regmap_read() failure in nau8360_vbat_level() to prevent the usage of uninitialized stack memory. - Removed improper dynamic creation of DAPM widgets and routes within ALSA kcontrol `put` handlers, using proper static instantiation instead. - Moved RX enable logic to startup() for consistent stream state. - Replaced synchronous request_firmware() with request_firmware_nowait() to prevent deadlocks and avoid blocking the kernel during firmware I/O. - Explicitly disable TDM RX/TX when slots or slot_width is zero. Changes in v2/v3: - v3: Resolved YAML build warnings, added Kconfig/Makefile entries, fixed stack buffer overflows in DSP parsing, and refactored TDM slot validation logic. - v2: Migrated software/runtime configurations from DT properties to ALSA kcontrols, refactored TDM routing, and improved firmware path handling. Neo Chang (2): ASoC: dt-bindings: nuvoton,nau8360: Add NAU83G60 ASoC: codecs: nau8360: Add support for NAU83G60 amplifier .../bindings/sound/nuvoton,nau8360.yaml | 113 + sound/soc/codecs/Kconfig | 11 + sound/soc/codecs/Makefile | 2 + sound/soc/codecs/nau8360-dsp.c | 665 +++++ sound/soc/codecs/nau8360-dsp.h | 122 + sound/soc/codecs/nau8360.c | 2241 +++++++++++++++++ sound/soc/codecs/nau8360.h | 913 +++++++ 7 files changed, 4067 insertions(+) create mode 100644 Documentation/devicetree/bindings/sound/nuvoton,nau8360.yaml create mode 100644 sound/soc/codecs/nau8360-dsp.c create mode 100644 sound/soc/codecs/nau8360-dsp.h create mode 100644 sound/soc/codecs/nau8360.c create mode 100644 sound/soc/codecs/nau8360.h -- 2.25.1

3 4

Re: [REGRESSION] snd-usb-audio: commit da3a7efff64e ("ALSA: usb-audio: Update for native DSD support quirks") breaks DSD playback on Musical Fidelity M6s DAC (2772:0502), plays ~8.8% fast
by Jussi Laako 09 Jul '26

09 Jul '26

Hi, I don’t think we currently have exclusion method for devices with buggy firmware, which claim to support native DSD, but do it incorrectly. And reverting with device specific white-listing is not a good approach for future maintenance. Having to device-specific white-list each new device appearing on the market from the manufacturer just because some old device is broken is not really a sustainable model. So I would just suggest using PCM with the device if it’s DSD implementation is buggy/broken, while it claims to have such. Or alternatively update the firmware with a fixed one. Newer MuFi devices work fine though, like for example the M3x DAC I have for testing this, and the M6x you mention. Additional challenge is that many manufacturers use the same USB interface implementation with same VID:PID on multiple different products. So it is not even necessarily possible to distinguish a particular problematic product. Best regards, - Jussi > On 8. Jul 2026, at 19.33, Salvador Blaya <tiniebla6(a)gmail.com> wrote: > > To: alsa-devel(a)alsa-project.org > Cc: tiwai(a)suse.de, jussi(a)sonarnerd.net, regressions(a)lists.linux.dev > Subject: [REGRESSION] snd-usb-audio: commit da3a7ef ("ALSA: usb-audio: > Update for native DSD support quirks") breaks DSD playback on Musical > Fidelity M6s DAC (2772:0502), plays ~8.8% fast > > Hi, > > Commit da3a7efff64e ("ALSA: usb-audio: Update for native DSD support > quirks") added VENDOR_FLG(0x2772) with QUIRK_FLAG_DSD_RAW for Musical > Fidelity devices. This vendor-wide match also catches the (older, > discontinued) Musical Fidelity M6s DAC, USB ID 2772:0502, which exposes > a UAC2 altsetting with bmFormats 0x80000000 (RAW_DATA, 32-bit) but > whose firmware cannot actually clock DSD playback correctly in any > mode. As a result, since this commit, applications like MPD prefer the > newly offered native DSD over DSD-to-PCM conversion and playback is > audibly broken (runs ~8.8% fast, raised pitch), where kernels without > the commit (e.g. 6.12.x) play correctly. > > Could 2772:0502 be excluded from the vendor flag (or the vendor flag > be narrowed to the specific products that support native DSD, such as > the newer M6x DAC)? > > Evidence gathered on Debian trixie, MPD, direct hw: access, no > resampling: > > 1) Native DSD (observed on 7.0.7 through 7.0.12): host side is correct > - hw_params shows format DSD_U32_BE, rate 88200 (correct for DSD64) > - but playback runs ~8.8% fast with raised pitch. A 4:41 track > finishes in ~4:15, matching a 48 kHz-family clock (3.072 MHz) > applied to a 2.8224 MHz DSD64 stream (ratio 1.0884). > > 2) DoP (6.12.9, MPD dop=yes): host side again correct - hw_params > shows S32_LE, rate 176400 - same ~8.8% fast playback. So the DAC's > internal DSD decoding path is misclocked regardless of transport. > > 3) Control test: the same DSD64 track converted to PCM FLAC at > 176400 Hz plays at correct speed/pitch through the exact same path > (S32_LE @ 176400). The 44.1 kHz rate family is fine for PCM; only > DSD decoding inside the DAC is broken. This rules out any host-side > rate issue. > > 4) The same fault has long been reported for this DAC on Windows 10 > with the official ASIO driver ("DSD via DoP plays noticeably > faster"): > https://community.roonlabs.com/t/musical-fidelity-m6-sdac-dsd-issues/39450 > including a follow-up for the successor model (M6sR). This is an > OS-independent firmware defect that the manufacturer never fixed, > which is presumably why this model was specified as DoP-only. > > Working configuration for reference (correct playback): MPD with > dop "no", MPD's dsd2pcm conversion to 352800 Hz - i.e. the behaviour > kernels without the commit provide by default for this device. > > Since these quirk updates tend to be backported to stable/LTS trees, > please consider the fix for stable as well, so that currently working > LTS kernels (e.g. 6.12.y) don't regress. > > Full lsusb -v output attached. Happy to test patches. > > #regzbot introduced: da3a7efff64ec0d63af4499eea3a46a2e13b5797 > > Please CC me on replies, I'm not subscribed to the list. > > Best regards, > > S. Blaya > <m6sdac-lsusb.txt>

2 3

[BUG] snd-usb-audio: incorrect PCM volume scaling on Edifier R19U USB speaker (0001:0201)
by Miguel Mário Nápoli 09 Jul '26

09 Jul '26

Hello, I'd like to report an issue with USB audio volume scaling on a cheapUSB-powered speaker set, in case it's useful for a mixer quirk fix. Device: Edifier R19U USB speakers (MVSILICON.INC. controller chip)lsusb: Bus 001 Device 010: ID 0001:0201 Fry's Electronics EDIFIER R19U (Note: idVendor 0001 is an unofficial/reused ID ("Fry's Electronics" placeholder), so it may be shared by unrelated devices from other vendors -- please take that into account if considering a quirk based on VID/PID matching alone.) System: Zorin OS 18 (Ubuntu-based), fresh install (< 1 week old)Kernel: 6.17.0-35-genericPipeWire: 1.0.5 Problem description:On connection, the kernel logs a warning about an unusually largevolume range for this device's PCM control: usb 1-2: New USB device found, idVendor=0001, idProduct=0201, bcdDevice=0.10 usb 1-2: Product: EDIFIER R19U usb 1-2: Manufacturer: MVSILICON.INC. usb 1-2: Warning! Unlikely big volume range (=999), cval->res is probably wrong. usb 1-2: [9] FU [PCM Playback Volume] ch = 2, val = 0/999/1 As a result, userspace volume controls (tested via PipeWire/WirePlumberand GNOME Sound Settings) display a normal-looking volume percentage(e.g. 69%), while the actual underlying ALSA mixer value stays at 0,producing no audible output at all -- with no mute indicator anywherein the UI. Confirmed via amixer while PipeWire reported ~69%: Simple mixer control 'PCM',0 Capabilities: pvolume pswitch pswitch-joined Playback channels: Front Left - Front Right Limits: Playback 0 - 999 Front Left: Playback 0 [0%] [0.00dB] [on] Front Right: Playback 0 [0%] [0.00dB] [on] Manually forcing the raw ALSA control resolves it immediately: amixer -c <card> sset PCM 999 After this, audio plays correctly and the volume responds normally tofurther adjustments, confirming the hardware/DAC path itself is fine --this looks like a resolution/step (cval->res) miscalculation for thisdevice's 0-999 range, similar to past quirk fixes for other USB audiochips with non-standard volume ranges (e.g. the Logitech c270 webcamfix in sound/usb/mixer.c, volume_control_quirks()). This was not an issue on a previous Ubuntu installation with an olderkernel/PipeWire stack on the same hardware, suggesting this may be aregression in how a newer kernel or PipeWire handles this specificrange, or simply a device that was never covered by an existing quirk. Current workaround in use (userspace, not a real fix):A udev rule triggers `amixer -c <card> sset PCM 999` whenever thedevice is connected (matched by idVendor=0001/idProduct=0201), forcingthe ALSA control to maximum so PipeWire's own volume slider can thenattenuate correctly from there. Happy to test a patch or provide more logs/output if needed. Thanks,Miguel Mario NapoliCriciuma/Brazil

2 1

Re: [PATCH] ALSA: hda/realtek: Add quirk for HP Elite Dragonfly Folio G3 speakers
by Takashi Iwai 09 Jul '26

09 Jul '26

On Wed, 08 Jul 2026 22:04:31 +0200, Michael Diesen wrote: > > The HP Elite Dragonfly Folio G3 (PCI SSID 103c:8a05) has 4 CS35L41 > amplifiers on SPI, identical to the non-Folio Dragonfly G3 (103c:8981). > Without this quirk the amps are never registered and speakers stay > silent. > > I've been carrying this as a local out-of-tree patch and would like > to get it merged. Note there is a related, recently merged quirk for > a neighboring SSID on what appears to be a sibling board variant: > > 0a10faad5ca5 ("ALSA: hda/realtek: add quirk for HP Dragonfly Folio > G3 2-in-1", 103c:8a06), which uses the SPI4 + GPIO LED fixup > variant rather than plain SPI4. > > My hardware (103c:8a05, "HP Elite Dragonfly Folio G3", non-2-in-1 > SKU) works correctly with the plain ALC245_FIXUP_CS35L41_SPI_4 > fixup and does not need the GPIO LED handling. Happy to re-test > against SPI_4_HP_GPIO_LED if you think that's actually the more > correct fixup for this board too ― let me know. > > Signed-off-by: Michael Diesen <michael.diesen(a)posteo.de> > --- > sound/hda/codecs/realtek/alc269.c | 1 + > 1 file changed, 1 insertion(+) > > --- a/sound/hda/codecs/realtek/alc269.c > +++ b/sound/hda/codecs/realtek/alc269.c > @@ -6817,6 +6817,7 @@ > SND_PCI_QUIRK(0x103c, 0x89d3, "HP EliteBook 645 G9 (MB 89D2)", > ALC236_FIXUP_HP_MUTE_LED_MICMUTE_VREF), > SND_PCI_QUIRK(0x103c, 0x89da, "HP Spectre x360 14t-ea100", > ALC245_FIXUP_HP_SPECTRE_X360_EU0XXX), > SND_PCI_QUIRK(0x103c, 0x89e7, "HP Elite x2 G9", > ALC245_FIXUP_CS35L41_SPI_2_HP_GPIO_LED), > + SND_PCI_QUIRK(0x103c, 0x8a05, "HP Elite Dragonfly Folio G3", > ALC245_FIXUP_CS35L41_SPI_4), > SND_PCI_QUIRK(0x103c, 0x8a0f, "HP Pavilion 14-ec1xxx", > ALC287_FIXUP_HP_GPIO_LED), > SND_PCI_QUIRK(0x103c, 0x8a1f, "HP Laptop 14s-dr5xxx", > ALC236_FIXUP_HP_MUTE_LED_COEFBIT2), > SND_PCI_QUIRK(0x103c, 0x8a20, "HP Laptop 15s-fq5xxx", > ALC236_FIXUP_HP_MUTE_LED_COEFBIT2), The patch can't be applied cleanly via git-am, unfortunately, likely because your mailer broke the space and lines. Please fix your mailer setup and resubmit. At best, try to send to yourself and test whether you can apply it via git-am before the resubmission. thanks, Takashi

1 0

Fixed Headphone noise issue for Dell QCM1255
by Kailang 09 Jul '26

09 Jul '26

Hi Takashi, This platform booted with Ubuntu 24.04 with Pipewire audio server. So, it has pop noise with headphone. But it's normal with Pulseaudio server. This patch was the workaround. Connect the headphones to DAC 0x2. The popping sound will disappear. This solution was approved by Dell. Thanks. Kailang

2 1

Re: [REGRESSION] snd-usb-audio: commit da3a7efff64e ("ALSA: usb-audio: Update for native DSD support quirks") breaks DSD playback on Musical Fidelity M6s DAC (2772:0502), plays ~8.8% fast
by Jussi Laako 09 Jul '26

09 Jul '26

Hi Salvador, No, native DSD with the M3x and M6x for example didn’t work before I added the vendor flag. That is precisely why I added it. By the way, you can also just convert everything to 48k-base DSD during playback and then the playback speed is correct. It is common that DACs play 48k-base DSD with 44.1k-base clock (or just go silent or play noise), but in this case it seems to be another way around. Best regards, - Jussi > On 9. Jul 2026, at 10.54, Salvador Blaya <tiniebla6(a)gmail.com> wrote: > > Hi Takashi, > > Thank you - that approach would fit this case well, and the risks you > mention are fortunately minimal here: > > - The M6s DAC has been discontinued for years and the defect was first > reported to the vendor (via their Windows ASIO driver users) back in > 2018, with no firmware fix ever published. I have an inquiry open > with Musical Fidelity about firmware and will report back if > anything changes. > > - The only other model possibly sharing this ID, the M6sR successor, > exhibits the same defect per the Roon thread in my original report, > so an empty entry for 2772:0502 cannot break a working device. The > current MF models known to work with native DSD (M3x, M6x) already > worked before the vendor flag was added, so they use different IDs. > > I'm happy to test the patch on my unit - both that native DSD is no > longer offered (MPD falling back to dsd2pcm as on 6.12.y) and that > normal PCM playback is unaffected. Just let me know. > > Best regards, > > Salvador > > El jue, 9 jul 2026 a las 9:33, Takashi Iwai (<tiwai(a)suse.de>) escribió: >> >> On Thu, 09 Jul 2026 00:28:00 +0200, >> Jussi Laako wrote: >>> >>> Hi, >>> >>> I don’t think we currently have exclusion method for devices with buggy firmware, which claim to support native DSD, but do it incorrectly. And reverting with device specific white-listing is not a good approach for future maintenance. Having to device-specific white-list each new device appearing on the market from the manufacturer just because some old device is broken is not really a sustainable model. >> >> While I fully agree that white-listing all needed devices won't scale, >> blacklisting the broken device might work. We can an empty quirk >> entry for 2772:0502 for skipping the vendor match, something like >> below, as an ad hoc fix. >> >> Though, this blindly assumes that there aren't so many broken devices, >> and there will be no firmware fix or another model that works with the >> same ID. If a model is relatively new and/or the vendor often updates >> the firmware, such an entry can be risky, too. >> >> >> thanks, >> >> Takashi >> >> -- 8< -- >> --- a/sound/usb/quirks.c >> +++ b/sound/usb/quirks.c >> @@ -2463,6 +2463,8 @@ static const struct usb_audio_quirk_flags_table quirk_flags_table[] = { >> QUIRK_FLAG_DSD_RAW), >> DEVICE_FLG(0x2708, 0x0002, /* Audient iD14 */ >> QUIRK_FLAG_IGNORE_CTL_ERROR), >> + DEVICE_FLG(0x2772, 0x0502, /* Musical Fidelity M6s DAC */ >> + 0), /* for avoiding QUIRK_FLAG_DSD_RAW with vendor match */ >> DEVICE_FLG(0x2912, 0x30c8, /* Audioengine D1 */ >> QUIRK_FLAG_GET_SAMPLE_RATE), >> DEVICE_FLG(0x2a70, 0x1881, /* OnePlus Technology (Shenzhen) Co., Ltd. BE02T */

1 0