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

Re: [alsa-devel] BOSS GT-1 USB audio and implicit feedback&In-Reply-To=<a3588f5f-b9b2-b622-7f9e-b9d472d88907@jensverwiebe.de>
by Mike Oliphant 21 Jan '20

21 Jan '20

Jens - actually, I think we have pretty much the same issue. I get no playback when forcing an implicit feedback endpoint, or when letting the Roland quirk handle it automatically. If I disable implicit feedback, it works but I get pops/clicks. Coincidentally, I just came across this post of yours on the Line6 forums about manually tweaking the sample rate: https://line6.com/support/topic/4426-line-6-with-linux/?tab=comments#commen… I gave it a try today, and by forcing a sample rate of 44105 instead of 44100 I now have largely clean playback! I get the odd dropout, but it is much less frequent (on the order of once every few minutes instead of several times a second). This is obviously an non-ideal workaround for the problem. Playback should be synchronized to the capture stream, but this doesn't seem to be getting configured correctly for our devices. Why, I'm not sure - I'm gradually gaining a better understanding of the USB audio kernel code, but I'm not there yet. Mike

1 0

[alsa-devel] BOSS GT-1 USB audio and implicit feedback
by Mike Oliphant 20 Jan '20

20 Jan '20

I've been digging around in the USB audio section of the kernel for the past month or so trying unsuccessfully to get audio on my BOSS GT-1 pedalboard to work in Linux. The device is recognized by the current kernel, but aplay just hangs when trying to output to it. My searches led me to this now-resolved issue with implicit feedback quirk handling on BOSS Katana amplifiers: https://bugzilla.kernel.org/show_bug.cgi?id=195223 I have patched pcm.c with a similar fix for the GT-1 in set_sync_ep_implicit_fb_quirk(): case USB_ID(0x0582, 0x01d6): /* BOSS GT-1 */ return 0; This results in successful playback, but with frequent pops/clicks in the audio - even with high buffer sizes under very low load - likely attributable to the lack of implicit feedback. The GT-1 has come up on the mailing list before - some good information is here, but no resolution: https://mailman.alsa-project.org/pipermail/alsa-devel/2018-January/130957.h… My understanding from what I think I know about implicit feedback and the output of lsusb, is that the device is designed to operate with simultaneous capture/playback, with feedback being provided in the capture stream to be used to sync both capture and playback. It seems like this is what the feedback quirk might be trying to do, since this is what I see from dmesg when trying to play audio with aplay on the stock kernel: [ 218.530738] usb 1-1.1: setting usb interface 1:1 [ 218.530753] Creating new playback data endpoint #d [ 218.530772] Creating new capture data endpoint #8e [ 218.531687] usb 1-1.1: Setting params for ep #d (type 0, 12 urbs), ret=0 [ 218.531706] usb 1-1.1: match_endpoint_audioformats: (fmt @ed1fbd45) score 2 [ 218.531840] usb 1-1.1: Setting params for ep #8e (type 0, 12 urbs), ret=0 [ 218.531855] usb 1-1.1: Starting data EP @f114d201 [ 218.532514] usb 1-1.1: Starting sync EP @984e9cce I have also tried to manually set the feedback endpoint in set_sync_ep_implicit_fb_quirk(): case USB_ID(0x0582, 0x01d6): /* BOSS GT-1 */ ep = 0x8e; ifnum = 2; goto add_sync_ep_from_ifnum; but this results in the same behavior. Any suggestions on what else to try would be much appreciated. It seems like the device is *very* close to working properly. Output from lsusb for the interface follows. Thanks! Mike --- Output from lsusb: Bus 001 Device 003: ID 0582:01d6 Roland Corp. Couldn't open device, some information will be missing Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 255 Vendor Specific Class bDeviceSubClass 0 bDeviceProtocol 255 bMaxPacketSize0 64 idVendor 0x0582 Roland Corp. idProduct 0x01d6 bcdDevice 0.00 iManufacturer 1 iProduct 2 iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 0x00bc bNumInterfaces 4 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xc0 Self Powered MaxPower 0mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 0 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 255 Vendor Specific Subclass bInterfaceProtocol 0 iInterface 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 1 bAlternateSetting 0 bNumEndpoints 0 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 2 bInterfaceProtocol 2 iInterface 0 ** UNRECOGNIZED: 06 24 f1 01 00 00 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 1 bAlternateSetting 1 bNumEndpoints 1 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 2 bInterfaceProtocol 2 iInterface 0 ** UNRECOGNIZED: 07 24 01 01 00 01 00 ** UNRECOGNIZED: 0b 24 02 01 02 04 18 01 44 ac 00 ** UNRECOGNIZED: 06 24 f1 04 16 00 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x0d EP 13 OUT bmAttributes 5 Transfer Type Isochronous Synch Type Asynchronous Usage Type Data wMaxPacketSize 0x0038 1x 56 bytes bInterval 1 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 2 bAlternateSetting 0 bNumEndpoints 0 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 2 bInterfaceProtocol 1 iInterface 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 2 bAlternateSetting 1 bNumEndpoints 1 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 2 bInterfaceProtocol 1 iInterface 0 ** UNRECOGNIZED: 07 24 01 07 00 01 00 ** UNRECOGNIZED: 0b 24 02 01 02 04 18 01 44 ac 00 ** UNRECOGNIZED: 06 24 f1 04 16 00 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x8e EP 14 IN bmAttributes 37 Transfer Type Isochronous Synch Type Asynchronous Usage Type Implicit feedback Data wMaxPacketSize 0x0038 1x 56 bytes bInterval 1 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 3 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 3 bInterfaceProtocol 0 iInterface 0 ** UNRECOGNIZED: 06 24 f1 02 01 01 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x03 EP 3 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x84 EP 4 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 3 bAlternateSetting 1 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 3 bInterfaceProtocol 0 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x03 EP 3 OUT bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 4 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x85 EP 5 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 4

2 1

[alsa-devel] [PATCH v1 5/8] x86/quirks: Add a DMI quirk for Microsoft Surface 3
by Andy Shevchenko 20 Jan '20

20 Jan '20

Add a DMI quirk for Microsoft Surface 3 which will be utilized by few drivers. Cc: Cezary Rojewski <cezary.rojewski(a)intel.com> Cc: Pierre-Louis Bossart <pierre-louis.bossart(a)linux.intel.com> Cc: Liam Girdwood <liam.r.girdwood(a)linux.intel.com> Cc: Jie Yang <yang.jie(a)linux.intel.com> Cc: Mark Brown <broonie(a)kernel.org> Cc: alsa-devel(a)alsa-project.org Signed-off-by: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com> --- arch/x86/kernel/quirks.c | 16 ++++++++++++++++ include/linux/platform_data/x86/machine.h | 5 +++++ 2 files changed, 21 insertions(+) diff --git a/arch/x86/kernel/quirks.c b/arch/x86/kernel/quirks.c index 447d4fba8516..9574ef7eaa66 100644 --- a/arch/x86/kernel/quirks.c +++ b/arch/x86/kernel/quirks.c @@ -673,6 +673,15 @@ static int apple_machine_cb(const struct dmi_system_id *id) return 1; } +bool x86_microsoft_surface_3_machine; +EXPORT_SYMBOL(x86_microsoft_surface_3_machine); + +static int microsoft_surface_3_machine_cb(const struct dmi_system_id *id) +{ + x86_microsoft_surface_3_machine = true; + return 1; +} + static const struct dmi_system_id x86_machine_table[] = { { .ident = "x86 Apple Macintosh", @@ -688,6 +697,13 @@ static const struct dmi_system_id x86_machine_table[] = { }, .callback = apple_machine_cb, }, + { + .ident = "Microsoft Surface 3", + .matches = { + DMI_MATCH(DMI_PRODUCT_NAME, "Surface 3"), + }, + .callback = microsoft_surface_3_machine_cb, + }, {} }; diff --git a/include/linux/platform_data/x86/machine.h b/include/linux/platform_data/x86/machine.h index b1e7a560a046..9bdf5a06b490 100644 --- a/include/linux/platform_data/x86/machine.h +++ b/include/linux/platform_data/x86/machine.h @@ -8,8 +8,13 @@ * x86_apple_machine - whether the machine is an x86 Apple Macintosh */ extern bool x86_apple_machine; +/** + * x86_microsoft_surface_3_machine - whether the machine is Microsoft Surface 3 + */ +extern bool x86_microsoft_surface_3_machine; #else #define x86_apple_machine false +#define x86_microsoft_surface_3_machine false #endif #endif /* PLATFORM_DATA_X86_MACHINE_H */ -- 2.24.1

2 2

[alsa-devel] [PATCH RFC v3 0/4] ASoC: Add Multi CPU DAI support
by Bard liao 20 Jan '20

20 Jan '20

As discussed in [1], ASoC core supports multi codec DAIs on a DAI link. However it does not do so for CPU DAIs. So, add support for multi CPU DAIs on a DAI Link by adding multi CPU DAI in Card instantiation, suspend and resume functions, PCM ops, stream handling functions and DAPM. [1]: https://www.spinics.net/lists/alsa-devel/msg71369.html changes in v3: - Return error if the function doesn't support multi cpu instead of just showing a warning message. - Revert changes for FE dai and compress device since we don't support multi cpu for FE dai and compress device yet. Bard liao (1): ASoC: return error if the function is not support multi cpu yet. Shreyas NC (3): ASoC: Add initial support for multiple CPU DAIs ASoC: Add multiple CPU DAI support for PCM ops ASoC: Add multiple CPU DAI support in DAPM include/sound/soc.h | 15 + sound/soc/soc-compress.c | 5 +- sound/soc/soc-core.c | 205 +++++----- sound/soc/soc-dapm.c | 131 ++++--- sound/soc/soc-generic-dmaengine-pcm.c | 18 + sound/soc/soc-pcm.c | 539 +++++++++++++++++--------- 6 files changed, 591 insertions(+), 322 deletions(-) -- 2.17.1

3 9

[alsa-devel] [PATCH] ALSA: hda: Apply aligned MMIO access only conditionally
by Takashi Iwai 20 Jan '20

20 Jan '20

It turned out that the recent simplification of HD-audio bus access helpers caused a regression on the virtual HD-audio device on QEMU with ARM platforms. The driver got a CORB/RIRB timeout and couldn't probe any codecs. The essential difference that caused a problem was the enforced aligned MMIO accesses by simplification. Since snd-hda-tegra driver is enabled on ARM, it enables CONFIG_SND_HDA_ALIGNED_MMIO, which makes the all HD-audio drivers using the aligned MMIO accesses. While this is mandatory for snd-hda-tegra, it seems that snd-hda-intel on ARM gets broken by this access pattern. For addressing the regression, this patch introduces a new flag, aligned_mmio, to hdac_bus object, and applies the aligned MMIO only when this flag is set. This change affects only platforms with CONFIG_SND_HDA_ALIGNED_MMIO set, i.e. mostly only for ARM platforms. Unfortunately the patch became a big bigger than it should be, just because the former calls didn't take hdac_bus object in the argument, hence we had to extend the call patterns. Fixes: 19abfefd4c76 ("ALSA: hda: Direct MMIO accesses") BugLink: https://bugzilla.opensuse.org/show_bug.cgi?id=1161152 Cc: <stable(a)vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai(a)suse.de> --- include/sound/hdaudio.h | 77 ++++++++++++++++++++++++++++++++--------------- sound/pci/hda/hda_tegra.c | 1 + 2 files changed, 54 insertions(+), 24 deletions(-) diff --git a/include/sound/hdaudio.h b/include/sound/hdaudio.h index e05b95e83d5a..fb9dce4c6928 100644 --- a/include/sound/hdaudio.h +++ b/include/sound/hdaudio.h @@ -8,6 +8,7 @@ #include <linux/device.h> #include <linux/interrupt.h> +#include <linux/io.h> #include <linux/pm_runtime.h> #include <linux/timecounter.h> #include <sound/core.h> @@ -330,6 +331,7 @@ struct hdac_bus { bool chip_init:1; /* h/w initialized */ /* behavior flags */ + bool aligned_mmio:1; /* aligned MMIO access */ bool sync_write:1; /* sync after verb write */ bool use_posbuf:1; /* use position buffer */ bool snoop:1; /* enable snooping */ @@ -405,34 +407,61 @@ void snd_hdac_bus_free_stream_pages(struct hdac_bus *bus); unsigned int snd_hdac_aligned_read(void __iomem *addr, unsigned int mask); void snd_hdac_aligned_write(unsigned int val, void __iomem *addr, unsigned int mask); -#define snd_hdac_reg_writeb(v, addr) snd_hdac_aligned_write(v, addr, 0xff) -#define snd_hdac_reg_writew(v, addr) snd_hdac_aligned_write(v, addr, 0xffff) -#define snd_hdac_reg_readb(addr) snd_hdac_aligned_read(addr, 0xff) -#define snd_hdac_reg_readw(addr) snd_hdac_aligned_read(addr, 0xffff) -#else /* CONFIG_SND_HDA_ALIGNED_MMIO */ -#define snd_hdac_reg_writeb(val, addr) writeb(val, addr) -#define snd_hdac_reg_writew(val, addr) writew(val, addr) -#define snd_hdac_reg_readb(addr) readb(addr) -#define snd_hdac_reg_readw(addr) readw(addr) -#endif /* CONFIG_SND_HDA_ALIGNED_MMIO */ -#define snd_hdac_reg_writel(val, addr) writel(val, addr) -#define snd_hdac_reg_readl(addr) readl(addr) +#define snd_hdac_aligned_mmio(bus) (bus)->aligned_mmio +#else +#define snd_hdac_aligned_mmio(bus) false +#define snd_hdac_aligned_read(addr, mask) 0 +#define snd_hdac_aligned_write(val, addr, mask) do {} while (0) +#endif + +static inline void snd_hdac_reg_writeb(struct hdac_bus *bus, void __iomem *addr, + u8 val) +{ + if (snd_hdac_aligned_mmio(bus)) + snd_hdac_aligned_write(val, addr, 0xff); + else + writeb(val, addr); +} + +static inline void snd_hdac_reg_writew(struct hdac_bus *bus, void __iomem *addr, + u16 val) +{ + if (snd_hdac_aligned_mmio(bus)) + snd_hdac_aligned_write(val, addr, 0xffff); + else + writew(val, addr); +} + +static inline u8 snd_hdac_reg_readb(struct hdac_bus *bus, void __iomem *addr) +{ + return snd_hdac_aligned_mmio(bus) ? + snd_hdac_aligned_read(addr, 0xff) : readb(addr); +} + +static inline u16 snd_hdac_reg_readw(struct hdac_bus *bus, void __iomem *addr) +{ + return snd_hdac_aligned_mmio(bus) ? + snd_hdac_aligned_read(addr, 0xffff) : readw(addr); +} + +#define snd_hdac_reg_writel(bus, addr, val) writel(val, addr) +#define snd_hdac_reg_readl(bus, addr) readl(addr) /* * macros for easy use */ #define _snd_hdac_chip_writeb(chip, reg, value) \ - snd_hdac_reg_writeb(value, (chip)->remap_addr + (reg)) + snd_hdac_reg_writeb(chip, (chip)->remap_addr + (reg), value) #define _snd_hdac_chip_readb(chip, reg) \ - snd_hdac_reg_readb((chip)->remap_addr + (reg)) + snd_hdac_reg_readb(chip, (chip)->remap_addr + (reg)) #define _snd_hdac_chip_writew(chip, reg, value) \ - snd_hdac_reg_writew(value, (chip)->remap_addr + (reg)) + snd_hdac_reg_writew(chip, (chip)->remap_addr + (reg), value) #define _snd_hdac_chip_readw(chip, reg) \ - snd_hdac_reg_readw((chip)->remap_addr + (reg)) + snd_hdac_reg_readw(chip, (chip)->remap_addr + (reg)) #define _snd_hdac_chip_writel(chip, reg, value) \ - snd_hdac_reg_writel(value, (chip)->remap_addr + (reg)) + snd_hdac_reg_writel(chip, (chip)->remap_addr + (reg), value) #define _snd_hdac_chip_readl(chip, reg) \ - snd_hdac_reg_readl((chip)->remap_addr + (reg)) + snd_hdac_reg_readl(chip, (chip)->remap_addr + (reg)) /* read/write a register, pass without AZX_REG_ prefix */ #define snd_hdac_chip_writel(chip, reg, value) \ @@ -540,17 +569,17 @@ int snd_hdac_get_stream_stripe_ctl(struct hdac_bus *bus, */ /* read/write a register, pass without AZX_REG_ prefix */ #define snd_hdac_stream_writel(dev, reg, value) \ - snd_hdac_reg_writel(value, (dev)->sd_addr + AZX_REG_ ## reg) + snd_hdac_reg_writel((dev)->bus, (dev)->sd_addr + AZX_REG_ ## reg, value) #define snd_hdac_stream_writew(dev, reg, value) \ - snd_hdac_reg_writew(value, (dev)->sd_addr + AZX_REG_ ## reg) + snd_hdac_reg_writew((dev)->bus, (dev)->sd_addr + AZX_REG_ ## reg, value) #define snd_hdac_stream_writeb(dev, reg, value) \ - snd_hdac_reg_writeb(value, (dev)->sd_addr + AZX_REG_ ## reg) + snd_hdac_reg_writeb((dev)->bus, (dev)->sd_addr + AZX_REG_ ## reg, value) #define snd_hdac_stream_readl(dev, reg) \ - snd_hdac_reg_readl((dev)->sd_addr + AZX_REG_ ## reg) + snd_hdac_reg_readl((dev)->bus, (dev)->sd_addr + AZX_REG_ ## reg) #define snd_hdac_stream_readw(dev, reg) \ - snd_hdac_reg_readw((dev)->sd_addr + AZX_REG_ ## reg) + snd_hdac_reg_readw((dev)->bus, (dev)->sd_addr + AZX_REG_ ## reg) #define snd_hdac_stream_readb(dev, reg) \ - snd_hdac_reg_readb((dev)->sd_addr + AZX_REG_ ## reg) + snd_hdac_reg_readb((dev)->bus, (dev)->sd_addr + AZX_REG_ ## reg) /* update a register, pass without AZX_REG_ prefix */ #define snd_hdac_stream_updatel(dev, reg, mask, val) \ diff --git a/sound/pci/hda/hda_tegra.c b/sound/pci/hda/hda_tegra.c index 8350954b7986..e5191584638a 100644 --- a/sound/pci/hda/hda_tegra.c +++ b/sound/pci/hda/hda_tegra.c @@ -398,6 +398,7 @@ static int hda_tegra_create(struct snd_card *card, return err; chip->bus.needs_damn_long_delay = 1; + chip->bus.core.aligned_mmio = 1; err = snd_device_new(card, SNDRV_DEV_LOWLEVEL, chip, &ops); if (err < 0) { -- 2.16.4

1 0

[alsa-devel] [PATCH v1 7/8] ASoC: Intel: Switch DMI table match to a test of variable
by Andy Shevchenko 20 Jan '20

20 Jan '20

Since we have a common x86 quirk that provides an exported variable, use it instead of local DMI table match. Cc: Cezary Rojewski <cezary.rojewski(a)intel.com> Cc: Pierre-Louis Bossart <pierre-louis.bossart(a)linux.intel.com> Cc: Liam Girdwood <liam.r.girdwood(a)linux.intel.com> Cc: Jie Yang <yang.jie(a)linux.intel.com> Cc: Mark Brown <broonie(a)kernel.org> Cc: alsa-devel(a)alsa-project.org Signed-off-by: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com> --- .../intel/common/soc-acpi-intel-cht-match.c | 28 ++----------------- 1 file changed, 3 insertions(+), 25 deletions(-) diff --git a/sound/soc/intel/common/soc-acpi-intel-cht-match.c b/sound/soc/intel/common/soc-acpi-intel-cht-match.c index d0fb43c2b9f6..833d2e130e6e 100644 --- a/sound/soc/intel/common/soc-acpi-intel-cht-match.c +++ b/sound/soc/intel/common/soc-acpi-intel-cht-match.c @@ -5,31 +5,11 @@ * Copyright (c) 2017, Intel Corporation. */ -#include <linux/dmi.h> +#include <linux/platform_data/x86/machine.h> + #include <sound/soc-acpi.h> #include <sound/soc-acpi-intel-match.h> -static unsigned long cht_machine_id; - -#define CHT_SURFACE_MACH 1 - -static int cht_surface_quirk_cb(const struct dmi_system_id *id) -{ - cht_machine_id = CHT_SURFACE_MACH; - return 1; -} - -static const struct dmi_system_id cht_table[] = { - { - .callback = cht_surface_quirk_cb, - .matches = { - DMI_MATCH(DMI_SYS_VENDOR, "Microsoft Corporation"), - DMI_MATCH(DMI_PRODUCT_NAME, "Surface 3"), - }, - }, - { } -}; - static struct snd_soc_acpi_mach cht_surface_mach = { .id = "10EC5640", .drv_name = "cht-bsw-rt5645", @@ -43,9 +23,7 @@ static struct snd_soc_acpi_mach *cht_quirk(void *arg) { struct snd_soc_acpi_mach *mach = arg; - dmi_check_system(cht_table); - - if (cht_machine_id == CHT_SURFACE_MACH) + if (x86_microsoft_surface_3_machine) return &cht_surface_mach; else return mach; -- 2.24.1

2 2

[alsa-devel] [PATCH] ALSA: pcm: fix buffer_bytes max constrained by preallocated bytes issue
by Keyon Jie 20 Jan '20

20 Jan '20

With today's code, we preallocate DMA buffer for substreams at pcm_new() stage, and the substream->buffer_bytes_max and substream->dma_max will save as the actually preallocated buffer size and maximum size that the dma buffer can be expanded by at hw_params() state, correspondingly. At pcm_open() stage, the maximum constraint of HW_PARAM_BUFFER_BYTES is set to substream->buffer_bytes_max and returned to user space as the max interval of the HW_PARAM_BUFFER_BYTES, this will lead to issue that user can't choose any buffer-bytes larger than the preallocated buffer size, and the buffer reallocation will never happen actually. Here change to use substream->dma_max as the maximum constraint of the HW_PARAM_BUFFER_BYTES and fix the issue mentioned above. Signed-off-by: Keyon Jie <yang.jie(a)linux.intel.com> --- sound/core/pcm_native.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/core/pcm_native.c b/sound/core/pcm_native.c index c375c41496f8..326e921006e7 100644 --- a/sound/core/pcm_native.c +++ b/sound/core/pcm_native.c @@ -2301,7 +2301,7 @@ static int snd_pcm_hw_rule_buffer_bytes_max(struct snd_pcm_hw_params *params, struct snd_interval t; struct snd_pcm_substream *substream = rule->private; t.min = 0; - t.max = substream->buffer_bytes_max; + t.max = substream->dma_max; t.openmin = 0; t.openmax = 0; t.integer = 1; -- 2.20.1

5 30

[alsa-devel] soc-core: Questions about cpus->name && cpus->of_node
by Daniel Baluta 20 Jan '20

20 Jan '20

Hello Morimoto-san, I have a question about this snippet from sound/soc/soc-core.c » /* » * CPU device may be specified by either name or OF node, but » * can be left unspecified, and will be matched based on DAI » * name alone.. » */ » if (link->cpus->name && link->cpus->of_node) { » » dev_err(card->dev, » » » "ASoC: Neither/both cpu name/of_node are set for %s\n", » » » link->name); » » return -EINVAL; » } Here either the warning message is wrong OR the if () condition is wrong. If the link->cpus->name = NULL && link->cpus->of_node == NULL the warning message will be not be printed.

2 1

Re: [alsa-devel] [PATCH 01/01] Add VID to support native DSD reproduction on FiiO devices.
by Mihai Luizescu 19 Jan '20

19 Jan '20

Tested-by: Mihai Luizescu <m.luizescu(a)gmail.com> --- I tested the patch today on Archlinux and I can confirm that it is working. I am able to play DSD files up to DSD256, the maximum supported by the sound card. I only compiled the snd_usb_audio module with the patch and replaced the stock one. DSD playback was confirmed by the green LED on the soundcard and by checking /proc/asound (altset 3 is used during DSD playback).

1 0

Re: [alsa-devel] [PATCH 01/01] Add VID to support native DSD reproduction on FiiO devices.
by Mihai Luizescu 19 Jan '20

19 Jan '20

Tested-by: Mihai Luizescu <m.luizescu(a)gmail.com> --- I tested the patch today on Archlinux and I can confirm that it is working. I am able to play DSD files up to DSD256, the maximum supported by the sound card. I only compiled the snd_usb_audio module with the patch and replaced the stock one. DSD playback was confirmed by the green LED on the soundcard and by checking /proc/asound (altset 3 is used during DSD playback).

1 0