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

[alsa-devel] [PATCH 0/3] ASoC: Intel: machine drivers for SOF
by Pierre-Louis Bossart 01 May '19

01 May '19

Add support for the two main machine drivers used by SOF (not tested with the Skylake driver due to lack of hardware and/or firmware signature/ missing topology) The DMIC support for HDaudio-based devices is very much needed for a number of WhiskyLake+ platforms designed for Windows. SOF will be the only Intel driver supporting this configuration. A firmware binary signed with the required production key should be available shortly. The rt5682 codec is the main validation vehicle of the Intel SOF team, with eval boards connected to the Baytrail MinnowBoard as well as more recent devices. The main difference with traditional Intel machine drivers is that the dai links are added dynamically at probe time to avoid multiple table copy/pastes. Bard liao (1): ASoC: Intel: add sof-rt5682 machine driver Rander Wang (2): ASoC: Intel: skl_hda_dsp_generic: add DMIC support ASoC: Intel: skl_hda_dsp_generic:refine code style sound/soc/intel/boards/Kconfig | 16 + sound/soc/intel/boards/Makefile | 2 + sound/soc/intel/boards/skl_hda_dsp_common.c | 22 +- sound/soc/intel/boards/skl_hda_dsp_common.h | 2 +- sound/soc/intel/boards/skl_hda_dsp_generic.c | 19 +- sound/soc/intel/boards/sof_rt5682.c | 563 ++++++++++++++++++ .../intel/common/soc-acpi-intel-byt-match.c | 6 + .../intel/common/soc-acpi-intel-cht-match.c | 6 + .../intel/common/soc-acpi-intel-cnl-match.c | 19 + .../intel/common/soc-acpi-intel-icl-match.c | 6 + 10 files changed, 656 insertions(+), 5 deletions(-) create mode 100644 sound/soc/intel/boards/sof_rt5682.c -- 2.17.1

1 3

[alsa-devel] [PATCH v3 0/5] soundwire: code cleanup
by Pierre-Louis Bossart 30 Apr '19

30 Apr '19

SoundWire support will be provided in Linux with the Sound Open Firmware (SOF) on Intel platforms. Before we start adding the missing pieces, there are a number of warnings and style issues reported by checkpatch, cppcheck and Coccinelle that need to be cleaned-up. Changes since v2: fixed inversion of devm_kcalloc parameters, detected while rebasing additional patches. Changes since v1: added missing newlines in new patch (suggested by Joe Perches) Pierre-Louis Bossart (5): soundwire: intel: fix inversion in devm_kcalloc parameters soundwire: fix style issues soundwire: bus: remove useless initializations soundwire: stream: remove useless initialization of local variable soundwire: add missing newlines in dynamic debug logs drivers/soundwire/Kconfig | 2 +- drivers/soundwire/bus.c | 137 ++++++++------- drivers/soundwire/bus.h | 16 +- drivers/soundwire/bus_type.c | 4 +- drivers/soundwire/cadence_master.c | 99 +++++------ drivers/soundwire/cadence_master.h | 22 +-- drivers/soundwire/intel.c | 103 ++++++----- drivers/soundwire/intel.h | 4 +- drivers/soundwire/intel_init.c | 12 +- drivers/soundwire/mipi_disco.c | 116 +++++++------ drivers/soundwire/slave.c | 10 +- drivers/soundwire/stream.c | 267 +++++++++++++++-------------- 12 files changed, 404 insertions(+), 388 deletions(-) -- 2.17.1

6 24

[alsa-devel] snd-usb-audio Buffer Sizes and Round Trip Latency
by Jonathan Liu 30 Apr '19

30 Apr '19

Hi, I want to start a discussion regarding round trip latency for class compliant USB audio interfaces on Linux. In particular, I am noticing with my USB 2.0 RME Babyface Pro audio interface that the round trip latency is considerably higher on Linux than on macOS High Sierra and Windows 10. I tested the round trip latency using a loopback audio cable and the ReaInsert plugin included with Reaper DAW (www.reaper.fm) that can be downloaded for Windows/macOS/Linux to calculate the additional delay. Here are the results for 48000 Hz, 24-bit on my RME Babyface Pro: === block_size/periods block_size*periods + additional_delay ~ round_trip_latency round_trip_latency = (block_size*periods + additional_delay) / 48000 * 1000 Linux 4.17.14, Class Compliant Mode (snd-usb-audio, ALSA backend): 16/2 32 + 80 ~ 2.333 ms 16/3 48 + 109 ~ 3.271 ms 32/2 64 + 129 ~ 4.021 ms 32/3 96 + 166 ~ 5.458 ms 64/2 128 + 205 ~ 6.938 ms 64/3 192 + 242 ~ 9.042 ms 128/2 256 + 352 ~ 12.667 ms 128/3 384 + 496 ~ 18.334 ms 256/2 512 + 650 ~ 24.208 ms 256/3 768 + 650 ~ 29.542 ms 512/2 1024 + 634 ~ 34.542 ms 512/3 1536 + 634 ~ 45.208 ms 1024/2 2048 + 650 ~ 56.208 ms 1024/3 3072 + 650 ~ 77.542 ms 2048/2 4096 + 633 ~ 98.521 ms 2048/3 6144 + 633 ~ 141.188 ms macOS High Sierra, Class Compliant Mode (Apple Driver): 16/2 32 + 205 ~ 4.938 ms 32/2 64 + 205 ~ 5.604 ms 64/2 128 + 205 ~ 6.938 ms 128/2 256 + 205 ~ 9.604 ms 256/2 512 + 205 ~ 14.938 ms 512/2 1024 + 205 ~ 25.604 ms 1024/2 2048 + 205 ~ 46.938 ms 2048/2 4096 + 205 ~ 89.604 ms macOS High Sierra, PC Mode (RME Driver v3.08): 16/2 32 + 59 ~ 1.896 ms 32/2 64 + 59 ~ 2.563 ms 64/2 128 + 59 ~ 3.896 ms 128/2 256 + 59 ~ 6.563 ms 256/2 512 + 59 ~ 11.596 ms 512/2 1024 + 59 ~ 22.563 ms 1024/2 2048 + 59 ~ 43.896 ms 2048/2 4096 + 59 ~ 86.563 ms Windows 10, PC Mode (RME Driver 1.099): 48/2 96 + 63 ~ 3.313 ms 64/2 128 + 63 ~ 3.979 ms 96/2 192 + 63 ~ 5.313 ms 128/2 256 + 63 ~ 6.646 ms 256/2 512 + 63 ~ 11.979 ms 512/2 1024 + 63 ~ 22.646 ms 1024/2 2048 + 63 ~ 43.979 ms 2048/2 4096 + 63 ~ 86.646 ms === Some things in particular I noticed on Linux: - additional_delay varies a bit if I close and open the audio device again - additional_delay seems to increase as the block_size increases. I can make the additional_delay stay about the same rather than increasing by setting MAX_PACKS and MAX_PACKS_HS to 1 in sound/usb/card.h. In Linux versions before 3.13 there was a nrpacks parameter for snd-usb-audio to control this but it was removed with commit https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… - additional_delay is not constant as block_size is increased like on macOS and Windows I made a patch to snd-usb-audio to expose the snd-usb-audio constants as runtime adjustable module parameters (/sys/module/snd_usb_audio/parameters/) for testing (takes effect when the device is disconnected+reconnected and logs the parameter values to dmesg): https://aur.archlinux.org/cgit/aur.git/plain/parameters.patch?h=snd-usb-aud… The patch is used in my Arch Linux AUR package for convenience (using DKMS to avoid having to recompile entire kernel): https://aur.archlinux.org/packages/snd-usb-audio-lowlatency-dkms/ Can snd-usb-audio be improved so the additional_delay is always the same when closing/opening/reconfiguring the audio device and does not increase as the block_size increases? I noticed using USB audio on Linux at lower latencies (block_size <= 128) is more prone to audio dropouts under load compared to macOS and Windows, even with CPU power management disabled (writing 0 to /dev/cpu_dma_latency). What can be done about this? Thanks. Regards, Jonathan

4 11

[alsa-devel] [PATCH] ALSA: hda - Register irq handler after the chip initialization
by Takashi Iwai 30 Apr '19

30 Apr '19

Currently the IRQ handler in HD-audio controller driver is registered before the chip initialization. That is, we have some window opened between the azx_acquire_irq() call and the CORB/RIRB setup. If an interrupt is triggered in this small window, the IRQ handler may access to the uninitialized RIRB buffer, which leads to a NULL dereference Oops. This is usually no big problem since most of Intel chips do register the IRQ via MSI, and we've already fixed the order of the IRQ enablement and the CORB/RIRB setup in the former commit b61749a89f82 ("sound: enable interrupt after dma buffer initialization"), hence the IRQ won't be triggered in that room. However, some platforms use a shared IRQ, and this may allow the IRQ trigger by another source. Another possibility is the kdump environment: a stale interrupt might be present in there, the IRQ handler can be falsely triggered as well. For covering this small race, let's move the azx_acquire_irq() call after hda_intel_init_chip() call. Although this is a bit radical change, it can cover more widely than checking the CORB/RIRB setup locally in the callee side. Reported-by: Liwei Song <liwei.song(a)windriver.com> Signed-off-by: Takashi Iwai <tiwai(a)suse.de> --- sound/pci/hda/hda_intel.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c index 2ec91085fa3e..789308f54785 100644 --- a/sound/pci/hda/hda_intel.c +++ b/sound/pci/hda/hda_intel.c @@ -1788,9 +1788,6 @@ static int azx_first_init(struct azx *chip) chip->msi = 0; } - if (azx_acquire_irq(chip, 0) < 0) - return -EBUSY; - pci_set_master(pci); synchronize_irq(bus->irq); @@ -1904,6 +1901,9 @@ static int azx_first_init(struct azx *chip) return -ENODEV; } + if (azx_acquire_irq(chip, 0) < 0) + return -EBUSY; + strcpy(card->driver, "HDA-Intel"); strlcpy(card->shortname, driver_short_names[chip->driver_type], sizeof(card->shortname)); -- 2.16.4

1 0

[alsa-devel] [PATCH] ALSA: hda: check RIRB to avoid use NULL pointer
by Song liwei 30 Apr '19

30 Apr '19

From: Liwei Song <liwei.song(a)windriver.com> Fix the following BUG: BUG: unable to handle kernel NULL pointer dereference at 000000000000000c Workqueue: events azx_probe_work [snd_hda_intel] RIP: 0010:snd_hdac_bus_update_rirb+0x80/0x160 [snd_hda_core] Call Trace: <IRQ> azx_interrupt+0x78/0x140 [snd_hda_codec] __handle_irq_event_percpu+0x49/0x300 handle_irq_event_percpu+0x23/0x60 handle_irq_event+0x3c/0x60 handle_edge_irq+0xdb/0x180 handle_irq+0x23/0x30 do_IRQ+0x6a/0x140 common_interrupt+0xf/0xf The Call Trace happened when run kdump on a NFS rootfs system. Exist the following calling sequence when boot the second kernel: azx_first_init() --> azx_acquire_irq() <-- interrupt come in, azx_interrupt() was called --> hda_intel_init_chip() --> azx_init_chip() --> snd_hdac_bus_init_chip() --> snd_hdac_bus_init_cmd_io(); --> init rirb.buf and corb.buf Interrupt happened after azx_acquire_irq() while RIRB still didn't got initialized, then NULL pointer will be used when process the interrupt. Check the value of RIRB to ensure it is not NULL, to aviod some special case may hang the system. Fixes: 14752412721c ("ALSA: hda - Add the controller helper codes to hda-core module") Signed-off-by: Liwei Song <liwei.song(a)windriver.com> --- sound/hda/hdac_controller.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/sound/hda/hdac_controller.c b/sound/hda/hdac_controller.c index 74244d8e2909..2f0fa5353361 100644 --- a/sound/hda/hdac_controller.c +++ b/sound/hda/hdac_controller.c @@ -195,6 +195,9 @@ void snd_hdac_bus_update_rirb(struct hdac_bus *bus) return; bus->rirb.wp = wp; + if (!bus->rirb.buf) + return; + while (bus->rirb.rp != wp) { bus->rirb.rp++; bus->rirb.rp %= AZX_MAX_RIRB_ENTRIES; -- 2.7.4

3 5

[alsa-devel] [GIT PULL] soundwire updates for v5.2-rc1
by Vinod Koul 30 Apr '19

30 Apr '19

Hey Greg, Please PULL to receive updates to soundwire subsystem The following changes since commit bfeffd155283772bbe78c6a05dec7c0128ee500c: Linux 5.0-rc1 (2019-01-06 17:08:20 -0800) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/vkoul/soundwire.git tags/soundwire-5.2-rc1 for you to fetch changes up to 4abbd783d126cabfc20d1b8d50b1d5026b5cba09: soundwire: intel: fix implicit header use of module.h/export.h (2019-04-14 15:52:50 +0530) ---------------------------------------------------------------- soundwire updates for v5.2-rc1 This round saw interest from Intel, Linaro and Cadence in Soundwire. More patches are in pipeline (maybe next cycle) - removal of useless initialzation in core - couple of header and kcalloc inversion fixes on Intel driver ---------------------------------------------------------------- Paul Gortmaker (1): soundwire: intel: fix implicit header use of module.h/export.h Pierre-Louis Bossart (3): soundwire: intel: fix inversion in devm_kcalloc parameters soundwire: remove useless initializations soundwire: stream: remove useless initialization of local variable drivers/soundwire/bus.c | 2 -- drivers/soundwire/intel.c | 5 +++-- drivers/soundwire/intel_init.c | 2 ++ drivers/soundwire/stream.c | 2 +- 4 files changed, 6 insertions(+), 5 deletions(-) Thanks -- ~Vinod

3 4

[alsa-devel] move eapd coef function before ACT_PRE_PROBE state
by Kailang 30 Apr '19

30 Apr '19

Hi Takashi, alc_fill_eapd_coef(),this function was change EAPD control to default. Default was set EAPD by verb control. This function was run in ACT_INIT state. Move it to ACT_PRE_PROBE above. It will have a chance to change EAPD control on ACT_PRE_PROBE state. It could change control by 0x20 coef bit. BR, Kailang

2 1

Re: [alsa-devel] ALC892 acquisition stutter
by Takashi Iwai 30 Apr '19

30 Apr '19

On Tue, 30 Apr 2019 08:27:54 +0200, rodomar705(a)protonmail.com wrote: > > Nope, neither adding AZX_DCAPS_PM_RUNTIME as seen on other AMD codecs below seems to affect it, unfortunately. Please don't drop Cc to ML and others. And, did you try other position_fix option value, too? Otherwise I have out of idea. It must be platform-specific issue only the hardware vendors know. Takashi > > Sent with ProtonMail Secure Email. > > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ > Il lunedì 29 aprile 2019 21:28, Takashi Iwai <tiwai(a)suse.de> ha scritto: > > > On Mon, 29 Apr 2019 20:21:22 +0200, > > rodomar705(a)protonmail.com wrote: > > > > > Whoops, sorry. Here it is. > > > > OK, it's an AMD chip and not listed explicitly in the driver config. > > Does the patch below have any influence? > > > > Takashi > > > > --- a/sound/pci/hda/hda_intel.c > > +++ b/sound/pci/hda/hda_intel.c > > @@ -2452,6 +2452,9 @@ static const struct pci_device_id azx_ids[] = { > > /* AMD Hudson */ > > { PCI_DEVICE(0x1022, 0x780d), > > .driver_data = AZX_DRIVER_GENERIC | AZX_DCAPS_PRESET_ATI_SB }, > > > > - /* AMD family 17h */ > > - { PCI_DEVICE(0x1022, 0x1457), > > - .driver_data = AZX_DRIVER_GENERIC | AZX_DCAPS_PRESET_ATI_SB }, > > > > > > /* AMD Stoney */ > > { PCI_DEVICE(0x1022, 0x157a), > > .driver_data = AZX_DRIVER_GENERIC | AZX_DCAPS_PRESET_ATI_SB | > > > >

1 0

Re: [alsa-devel] ALC892 acquisition stutter
by Takashi Iwai 29 Apr '19

29 Apr '19

On Mon, 29 Apr 2019 20:21:22 +0200, rodomar705(a)protonmail.com wrote: > > Whoops, sorry. Here it is. OK, it's an AMD chip and not listed explicitly in the driver config. Does the patch below have any influence? Takashi --- a/sound/pci/hda/hda_intel.c +++ b/sound/pci/hda/hda_intel.c @@ -2452,6 +2452,9 @@ static const struct pci_device_id azx_ids[] = { /* AMD Hudson */ { PCI_DEVICE(0x1022, 0x780d), .driver_data = AZX_DRIVER_GENERIC | AZX_DCAPS_PRESET_ATI_SB }, + /* AMD family 17h */ + { PCI_DEVICE(0x1022, 0x1457), + .driver_data = AZX_DRIVER_GENERIC | AZX_DCAPS_PRESET_ATI_SB }, /* AMD Stoney */ { PCI_DEVICE(0x1022, 0x157a), .driver_data = AZX_DRIVER_GENERIC | AZX_DCAPS_PRESET_ATI_SB |

1 0

[alsa-devel] [PATCH] ASoC: Intel: avoid Oops if DMA setup fails
by Ross Zwisler 29 Apr '19

29 Apr '19

Currently in sst_dsp_new() if we get an error return from sst_dma_new() we just print an error message and then still complete the function successfully. This means that we are trying to run without sst->dma properly set up, which will result in NULL pointer dereference when sst->dma is later used. This was happening for me in sst_dsp_dma_get_channel(): struct sst_dma *dma = dsp->dma; ... dma->ch = dma_request_channel(mask, dma_chan_filter, dsp); This resulted in: BUG: unable to handle kernel NULL pointer dereference at 0000000000000018 IP: sst_dsp_dma_get_channel+0x4f/0x125 [snd_soc_sst_firmware] Fix this by adding proper error handling for the case where we fail to set up DMA. Signed-off-by: Ross Zwisler <zwisler(a)google.com> Cc: stable(a)vger.kernel.org --- sound/soc/intel/common/sst-firmware.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/sound/soc/intel/common/sst-firmware.c b/sound/soc/intel/common/sst-firmware.c index 1e067504b6043..9be3a793a55e3 100644 --- a/sound/soc/intel/common/sst-firmware.c +++ b/sound/soc/intel/common/sst-firmware.c @@ -1251,11 +1251,15 @@ struct sst_dsp *sst_dsp_new(struct device *dev, goto irq_err; err = sst_dma_new(sst); - if (err) + if (err) { dev_warn(dev, "sst_dma_new failed %d\n", err); + goto dma_err; + } return sst; +dma_err: + free_irq(sst->irq, sst); irq_err: if (sst->ops->free) sst->ops->free(sst); -- 2.21.0.593.g511ec345e18-goog

3 4