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

[alsa-devel] Applied "ALSA: hda: Fix implicit definition of pci_iomap() on SH" to the asoc tree
by Mark Brown 13 Sep '18

13 Sep '18

The patch ALSA: hda: Fix implicit definition of pci_iomap() on SH has been applied to the asoc tree at https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark >From d9b84a15892c02334ac8a5c28865ae54168d9b22 Mon Sep 17 00:00:00 2001 From: Mark Brown <broonie(a)kernel.org> Date: Wed, 12 Sep 2018 12:31:32 +0100 Subject: [PATCH] ALSA: hda: Fix implicit definition of pci_iomap() on SH Include asm/io.h directly so we've got a definition of pci_iomap(), the current set of includes do this implicitly on most architectures but not on SH. Reported-by: kbuild test robot <lkp(a)intel.com> Signed-off-by: Mark Brown <broonie(a)kernel.org> --- sound/pci/hda/patch_ca0132.c | 1 + 1 file changed, 1 insertion(+) diff --git a/sound/pci/hda/patch_ca0132.c b/sound/pci/hda/patch_ca0132.c index a585d0ec6d77..6ea04f889809 100644 --- a/sound/pci/hda/patch_ca0132.c +++ b/sound/pci/hda/patch_ca0132.c @@ -31,6 +31,7 @@ #include <linux/types.h> #include <linux/io.h> #include <linux/pci.h> +#include <asm/io.h> #include <sound/core.h> #include <sound/hda_codec.h> #include "hda_local.h" -- 2.19.0.rc2

1 0

[alsa-devel] [PATCH 1/3] Revert "ASoC: Intel: Skylake: Acquire irq after RIRB allocation"
by Yu Zhao 13 Sep '18

13 Sep '18

This reverts commit 12eeeb4f4733bbc4481d01df35933fc15beb8b19. The patch doesn't fix accessing memory with null pointer in skl_interrupt(). There are two problems: 1) skl_init_chip() is called twice, before and after dma buffer is allocate. The first call sets bus->chip_init which prevents the second from initializing bus->corb.buf and rirb.buf from bus->rb.area. 2) snd_hdac_bus_init_chip() enables interrupt before snd_hdac_bus_init_cmd_io() initializing dma buffers. There is a small window which skl_interrupt() can be called if irq has been acquired. If so, it crashes when using null dma buffer pointers. Will fix the problems in the following patches. Also attaching the crash for future reference. [ 16.949148] general protection fault: 0000 [#1] PREEMPT SMP KASAN PTI [ 16.950829] gsmi: Log Shutdown Reason 0x03 [ 16.950830] Modules linked in: uvcvideo(+) videobuf2_vmalloc snd_soc_skl(+) videobuf2_memops videobuf2_v4l2 videobuf2_core snd_soc_skl_ipc snd_soc_sst_ipc snd_soc_sst_dsp snd_soc_acpi snd_hda_ext_core snd_hda_core snd_soc_max98357a acpi_als snd_soc_da7219 lzo lzo_compress zram snd_seq_dummy snd_seq snd_seq_device bridge stp llc ipt_MASQUERADE nf_nat_masquerade_ipv4 xt_mark fuse cfg80211 iio_trig_sysfs cros_ec_sensors cros_ec_sensors_ring cros_ec_sensors_core industrialio_triggered_buffer kfifo_buf industrialio smsc95xx usbnet mii joydev [ 16.950874] CPU: 0 PID: 1083 Comm: chrome Not tainted 4.14.64 #14 [ 16.950875] Hardware name: Google Yorp/Yorp, BIOS Google_Yorp.10985.0.2018_08_20_1648 08/17/2018 [ 16.950878] task: ffff88015b1c2b80 task.stack: ffff880155f30000 [ 16.950887] RIP: 0010:snd_hdac_bus_update_rirb+0x19b/0x4cf [snd_hda_core] [ 16.950889] RSP: 0000:ffff88015c807c08 EFLAGS: 00010003 [ 16.950891] RAX: 0000000000000101 RBX: 000000000000080c RCX: 1ffff10026822185 [ 16.950893] RDX: dffffc0000000000 RSI: ffff88015b1c2b80 RDI: ffffc90000514058 [ 16.950894] RBP: ffff88015c807c68 R08: 0000000000000000 R09: 0000000000000000 [ 16.950895] R10: 0000000000000000 R11: ffffffffc043074f R12: 0000000000000800 [ 16.950897] R13: 0000000000000001 R14: 0000000000000002 R15: 1ffff10026822119 [ 16.950899] FS: 00007d85924cc740(0000) GS:ffff88015c800000(0000) knlGS:0000000000000000 [ 16.950900] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 16.950902] CR2: 000058a54df16038 CR3: 00000001551c0000 CR4: 00000000003406f0 [ 16.950903] Call Trace: [ 16.950906] <IRQ> [ 16.950918] skl_interrupt+0x19e/0x2d6 [snd_soc_skl] [ 16.950926] ? dma_supported+0xb5/0xb5 [snd_soc_skl] [ 16.950933] __handle_irq_event_percpu+0x27a/0x6c8 [ 16.950937] ? __irq_wake_thread+0x1d1/0x1d1 [ 16.950942] ? __do_softirq+0x57a/0x69e [ 16.950944] handle_irq_event_percpu+0x95/0x1ba [ 16.950948] ? _raw_spin_unlock+0x65/0xdc [ 16.950951] ? __handle_irq_event_percpu+0x6c8/0x6c8 [ 16.950953] ? _raw_spin_unlock+0x65/0xdc [ 16.950957] ? time_cpufreq_notifier+0x483/0x483 [ 16.950959] handle_irq_event+0x89/0x123 [ 16.950962] handle_fasteoi_irq+0x16f/0x425 [ 16.950965] handle_irq+0x1fe/0x28e [ 16.950969] do_IRQ+0x6e/0x12e [ 16.950972] common_interrupt+0x7a/0x7a [ 16.950974] </IRQ> [ 16.950976] RIP: 0033:0x58097f61a5c0 [ 16.950978] RSP: 002b:00007ffe95c971a8 EFLAGS: 00000206 ORIG_RAX: ffffffffffffffbc [ 16.950980] RAX: 000058097f61a5c0 RBX: 00000e4ac5220560 RCX: 0000000000004e10 [ 16.950982] RDX: 000058098563df20 RSI: 00007ffe95c97250 RDI: 00000e4ac5220500 [ 16.950983] RBP: 00007ffe95c97410 R08: 0000000000000000 R09: 00007ffe95c97250 [ 16.950984] R10: 0000000000000000 R11: 0000000000000000 R12: 00000e4ac5220560 [ 16.950986] R13: 00000e4ac5220560 R14: 00000e4ac47c9650 R15: 0000580987646350 [ 16.950988] Code: 74 12 48 89 df e8 eb 2d 8e cd 48 ba 00 00 00 00 00 fc ff df 4c 8b 23 44 89 f0 83 c8 01 0f b7 c0 49 8d 1c 84 48 89 d8 48 c1 e8 03 <8a> 04 10 84 c0 0f 85 da 01 00 00 44 8b 3b 41 0f b7 c6 49 8d 1c [ 16.951031] RIP: snd_hdac_bus_update_rirb+0x19b/0x4cf [snd_hda_core] RSP: ffff88015c807c08 [ 16.951036] ---[ end trace 58bf9ece1775bc92 ]--- [ 16.956871] Kernel panic - not syncing: Fatal exception in interrupt [ 16.956888] Kernel Offset: 0xc800000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff) Signed-off-by: Yu Zhao <yuzhao(a)google.com> --- sound/soc/intel/skylake/skl.c | 10 ++++------ 1 file changed, 4 insertions(+), 6 deletions(-) diff --git a/sound/soc/intel/skylake/skl.c b/sound/soc/intel/skylake/skl.c index cf09721ca13e..dce649485649 100644 --- a/sound/soc/intel/skylake/skl.c +++ b/sound/soc/intel/skylake/skl.c @@ -838,7 +838,11 @@ static int skl_first_init(struct hdac_bus *bus) snd_hdac_bus_parse_capabilities(bus); + if (skl_acquire_irq(bus, 0) < 0) + return -EBUSY; + pci_set_master(pci); + synchronize_irq(bus->irq); gcap = snd_hdac_chip_readw(bus, GCAP); dev_dbg(bus->dev, "chipset global capabilities = 0x%x\n", gcap); @@ -871,12 +875,6 @@ static int skl_first_init(struct hdac_bus *bus) if (err < 0) return err; - err = skl_acquire_irq(bus, 0); - if (err < 0) - return err; - - synchronize_irq(bus->irq); - /* initialize chip */ skl_init_pci(skl); -- 2.19.0.rc2.392.g5ba43deb5a-goog

4 19

[alsa-devel] [PATCH 0/2][RFC] ALSA: firewire-lib: change packet processing timing in process context
by Takashi Sakamoto 13 Sep '18

13 Sep '18

In IEC 61883-1/6 engine in ALSA firewire stack, a work to process packet is done in three places: 1. bottom-half of handler for interrupts scheduled on 1394OHCI controller 2. a callback of struct 'snd_pcm_ops.pointer()' 3. a callback of struct 'snd_pcm_ops.ack()' This patchset adds optimization for 3., and remove 2. for efficiency. In Linux kernel v2.6.39, 1. and 2. was committed in initial implementation of this engine at a commit 31ef9134eb52('ALSA: add LaCie FireWire Speakers/Griffin FireWave Surround driver'). This engine schedules hardware interrupts 16 packets (=INTERRUPT_INTERVAL) thus 1. appears in software IRQ context every 2 msec (= 16packets * 1sec / 8,000cycle). In Linux kernel v3.5, an idea of 2. was introduced at a commit e9148dddc3c7('ALSA: firewire-lib: flush completed packets when reading PCM position') to reduce timing gap between queueing/dequeueing PCM frames and scheduling packet transmission. Additionally, it has an effect to reduce load of the software IRQ context. It's done in a call of ioctl(2) with SNDRV_PCM_IOCTL_HWSYNC. As a result, in mmap programming scenario, a call of snd_pcm_hwsync() can process packets for recent isochronous cycle. while (1): snd_pcm_hwsync() ->ioctl(HWSYNC) ->struct snd_pcm_ops.pointer() = amdtp_stream_pcm_pointer() ->fw_iso_context_flush_completions() snd_pcm_mmap_begin() (queue/dequeue PCM frames here.) snd_pcm_mmap_commit() In Linux kernel v4.13, ALSA PCM core was improved in an aspect of updating appl_ptr at a commit 9027c4639ef1('ALSA: pcm: Call ack() whenever appl_ptr is updated'). This commit ensures callback of 'struct snd_pcm_ops.ack()' when updating appl_ptr. This callback can be done in below ioctl(2) requests: - SNDRV_PCM_IOCTL_REWIND - SNDRV_PCM_IOCTL_FORWARD - SNDRV_PCM_IOCTL_SYNC_PTR - SNDRV_PCM_IOCTL_READ[I|N]_FRAMES - SNDRV_PCM_IOCTL_WRITE[I|N]_FRAMES As I notes in a commit 875becf8412c('ALSA: firewire: process packets in 'struct snd_pcm_ops.ack' callback'), 3. works less efficiently because in usual PCM operation the above ioctl(2) requests are not used in event loop. At the same time of the appl_ptr improvement, a new flag of PCM hardware definition was added at a commit 42f945970af9('ALSA: pcm: Add the explicit appl_ptr sync support'), and relevant changes were added to ALSA PCM core and alsa-lib v1.1.5. This flag expects userspace to call ioctl(2) with SNDRV_PCM_IOCTL_SYNC_PTR request per iteration of PCM frame queueing/dequeueing in mmap programming scenario below: while (1): snd_pcm_hwsync() ->ioctl(HWSYNC) ->struct snd_pcm_ops.pointer() = amdtp_stream_pcm_pointer() ->fw_iso_context_flush_completions() snd_pcm_mmap_begin() (queue/dequeue PCM frames here.) snd_pcm_mmap_commit() ->ioctl(SYNC_PTR) This patchset aims to support the new flag, SNDRV_PCM_INFO_SYNC_APPLPTR, to tell userspace to call ioctl(2) with SNDRV_PCM_IOCTL_SYNC_PTR after queueing/dequeueing PCM frames in each iteration of event dispatcher. As a result: while (1): snd_pcm_hwsync() ->ioctl(HWSYNC) ->struct snd_pcm_ops.pointer() = amdtp_stream_pcm_pointer() ->fw_iso_context_flush_completions() snd_pcm_mmap_begin() (queue/dequeue PCM frames here.) snd_pcm_mmap_commit() ->ioctl(SYNC_PTR) ->struct snd_pcm_ops.ack() = amdtp_stream_pcm_ack() ->fw_iso_context_flush_completions() This patchset also adds optimization for timing to process packets in process context. As the above call graph shows, support of the flag brings closest two calls to process packet against intervals of isochronous cycle and it is not enough efficient. This patchset also cancel packet processing in .pointer() callback. As a result: while (1): snd_pcm_hwsync() snd_pcm_mmap_begin() (queue/dequeue PCM frames here.) snd_pcm_mmap_commit() ->ioctl(SYNC_PTR) ->struct snd_pcm_ops.ack() = amdtp_stream_pcm_ack() ->fw_iso_context_flush_completions() Takashi Sakamoto (2): ALSA: firewire-lib: adopt SYNC_APPLPTR flag to flush packets after queueing/dequeueing PCM frames ALSA: firewire-lib: cancel processing packets in struct snd_pcm_ops.pointer() call sound/firewire/amdtp-stream.c | 34 ++-------------------------------- sound/firewire/amdtp-stream.h | 12 +++++++++++- 2 files changed, 13 insertions(+), 33 deletions(-) -- 2.17.1

2 4

[alsa-devel] What causes a STOP in the trigger?
by Rob 13 Sep '18

13 Sep '18

I'm seeing a weird issue where ALSA doesn't ever hit the pointer function, and we go straight from START to STOP. Debugging the DMA, we get IRQs, I call the period_elapsed. It looks like we hit STOP before we even get the first IRQ. I've checked my parentheses, and theres no overrun or underrun messages. I don't hit the close function, nor any other functions until i control-C. Once I do that, I get a large series of pointer() printks showing multiples of IRQ positions, as if it queued up the commands... I thought I was IRQing too fast maybe, but as mentioned above, the irqreturn function doesn't even get called before we STOP. What in aplay would instantly force a STOP? Audio plays a few frames (I can hear a chord), then stalls and repeats until i Ctrl-C. Thanks, Rob

2 1

[alsa-devel] [PATCH] ALSA: rawmidi: A lightweight function to discard pending bytes
by Takashi Iwai 13 Sep '18

13 Sep '18

For discarding the pending bytes on rawmidi, we process with a loop of snd_rawmidi_transmit() which is just a waste of CPU power. Implement a lightweight API function to discard the pending bytes and the proceed the ring buffer instantly, and use it instead of open codes. Signed-off-by: Takashi Iwai <tiwai(a)suse.de> --- include/sound/rawmidi.h | 1 + sound/core/rawmidi.c | 22 ++++++++++++++++++++++ sound/core/seq/seq_virmidi.c | 4 +--- sound/usb/midi.c | 3 +-- 4 files changed, 25 insertions(+), 5 deletions(-) diff --git a/include/sound/rawmidi.h b/include/sound/rawmidi.h index 6665cb29e1a2..3b5a061132b6 100644 --- a/include/sound/rawmidi.h +++ b/include/sound/rawmidi.h @@ -171,6 +171,7 @@ int __snd_rawmidi_transmit_peek(struct snd_rawmidi_substream *substream, unsigned char *buffer, int count); int __snd_rawmidi_transmit_ack(struct snd_rawmidi_substream *substream, int count); +int snd_rawmidi_proceed(struct snd_rawmidi_substream *substream); /* main midi functions */ diff --git a/sound/core/rawmidi.c b/sound/core/rawmidi.c index 08d5662039e3..ee601d7f0926 100644 --- a/sound/core/rawmidi.c +++ b/sound/core/rawmidi.c @@ -1236,6 +1236,28 @@ int snd_rawmidi_transmit(struct snd_rawmidi_substream *substream, } EXPORT_SYMBOL(snd_rawmidi_transmit); +/** + * snd_rawmidi_proceed - Discard the all pending bytes and proceed + * @substream: rawmidi substream + * + * Return: the number of discarded bytes + */ +int snd_rawmidi_proceed(struct snd_rawmidi_substream *substream) +{ + struct snd_rawmidi_runtime *runtime = substream->runtime; + unsigned long flags; + int count = 0; + + spin_lock_irqsave(&runtime->lock, flags); + if (runtime->avail < runtime->buffer_size) { + count = runtime->buffer_size - runtime->avail; + __snd_rawmidi_transmit_ack(substream, count); + } + spin_unlock_irqrestore(&runtime->lock, flags); + return count; +} +EXPORT_SYMBOL(snd_rawmidi_proceed); + static long snd_rawmidi_kernel_write1(struct snd_rawmidi_substream *substream, const unsigned char __user *userbuf, const unsigned char *kernelbuf, diff --git a/sound/core/seq/seq_virmidi.c b/sound/core/seq/seq_virmidi.c index cb988efd1ed0..e5a40795914a 100644 --- a/sound/core/seq/seq_virmidi.c +++ b/sound/core/seq/seq_virmidi.c @@ -149,9 +149,7 @@ static void snd_vmidi_output_work(struct work_struct *work) /* discard the outputs in dispatch mode unless subscribed */ if (vmidi->seq_mode == SNDRV_VIRMIDI_SEQ_DISPATCH && !(vmidi->rdev->flags & SNDRV_VIRMIDI_SUBSCRIBE)) { - char buf[32]; - while (snd_rawmidi_transmit(substream, buf, sizeof(buf)) > 0) - ; /* ignored */ + snd_rawmidi_proceed(substream); return; } diff --git a/sound/usb/midi.c b/sound/usb/midi.c index dcfc546d81b9..b737f0ec77d0 100644 --- a/sound/usb/midi.c +++ b/sound/usb/midi.c @@ -1175,8 +1175,7 @@ static void snd_usbmidi_output_trigger(struct snd_rawmidi_substream *substream, if (port->ep->umidi->disconnected) { /* gobble up remaining bytes to prevent wait in * snd_rawmidi_drain_output */ - while (!snd_rawmidi_transmit_empty(substream)) - snd_rawmidi_transmit_ack(substream, 1); + snd_rawmidi_proceed(substream); return; } tasklet_schedule(&port->ep->tasklet); -- 2.18.0

1 0

[alsa-devel] [PATCH] ALSA: hda - Enable runtime PM on AMD/ATI GPU only for discrete GPU
by Takashi Iwai 13 Sep '18

13 Sep '18

The recent change of vga_switcheroo allowed the runtime PM for HD-audio on AMD GPU, but this also resulted in a regression. When the HD-audio controller driver gets runtime-suspended, HD-audio link is turned off, and the hotplug notification is ignored. This leads to the inconsistent audio state (the connection isn't notified and ELD is ignored). The best fix would be to implement the proper ELD notification via the audio component, but it's still not ready. As a quick workaround, this patch adds the check of runtime_idle and allows the runtime suspend only when the vga_switcheroo is bound with discrete GPU. That is, a system with a single GPU would be again without runtime PM (of the controller), as well as the APU that needs to keep the HD-audio link for the hotplug notification and ELD read out. For identifying the audio client connection type, a new API is added to vga_switcheroo. Other than that, the patch does a pretty simple job. Note that this patch won't influence on the HD-audio *codec* runtime PM. When a codec is unused and the system goes to S3/S4 and resumed, the codec won't be resumed immediately because it's unused. This likely keeps the hotplug notification broken, but this is basically the expected behavior, a cost needed for the power-saving. The hotplug state will be activated once when you access to the device (or triggering the power up via reading a codec#* proc file or such). Again, this issue will be solved by the proper audio component notification, but it's still not ready. Until then, user would need to disable the power-saving explicitly if the ELD hotplug notification is required. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=200945 Fixes: 07f4f97d7b4b ("vga_switcheroo: Use device link for HDA controller") Signed-off-by: Takashi Iwai <tiwai(a)suse.de> --- drivers/gpu/vga/vga_switcheroo.c | 20 ++++++++++++++++++++ include/linux/vga_switcheroo.h | 1 + sound/pci/hda/hda_intel.c | 8 ++++++++ 3 files changed, 29 insertions(+) diff --git a/drivers/gpu/vga/vga_switcheroo.c b/drivers/gpu/vga/vga_switcheroo.c index a96bf46bc483..89598adbf6be 100644 --- a/drivers/gpu/vga/vga_switcheroo.c +++ b/drivers/gpu/vga/vga_switcheroo.c @@ -485,6 +485,26 @@ enum vga_switcheroo_state vga_switcheroo_get_client_state(struct pci_dev *pdev) } EXPORT_SYMBOL(vga_switcheroo_get_client_state); +/** + * vga_switcheroo_get_client_id() - obtain client id of a given client + * @pdev: client pci device + */ +enum vga_switcheroo_client_id vga_switcheroo_get_client_id(struct pci_dev *pdev) +{ + struct vga_switcheroo_client *client; + enum vga_switcheroo_client_id ret; + + mutex_lock(&vgasr_mutex); + client = find_client_from_pci(&vgasr_priv.clients, pdev); + if (!client) + ret = VGA_SWITCHEROO_UNKNOWN_ID; + else + ret = client_id(client); + mutex_unlock(&vgasr_mutex); + return ret; +} +EXPORT_SYMBOL(vga_switcheroo_get_client_id); + /** * vga_switcheroo_unregister_client() - unregister client * @pdev: client pci device diff --git a/include/linux/vga_switcheroo.h b/include/linux/vga_switcheroo.h index a34539b7f750..e52fcd7b68f3 100644 --- a/include/linux/vga_switcheroo.h +++ b/include/linux/vga_switcheroo.h @@ -167,6 +167,7 @@ int vga_switcheroo_process_delayed_switch(void); bool vga_switcheroo_client_probe_defer(struct pci_dev *pdev); enum vga_switcheroo_state vga_switcheroo_get_client_state(struct pci_dev *dev); +enum vga_switcheroo_client_id vga_switcheroo_get_client_id(struct pci_dev *dev); int vga_switcheroo_init_domain_pm_ops(struct device *dev, struct dev_pm_domain *domain); void vga_switcheroo_fini_domain_pm_ops(struct device *dev); diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c index 1b2ce304152a..48ab090648a7 100644 --- a/sound/pci/hda/hda_intel.c +++ b/sound/pci/hda/hda_intel.c @@ -1201,6 +1201,14 @@ static int azx_runtime_idle(struct device *dev) azx_bus(chip)->codec_powered || !chip->running) return -EBUSY; +#ifdef SUPPORT_VGA_SWITCHEROO + /* ELD notification gets broken on AMD GPUs when HD-audio bus is off */ + if ((chip->pci->vendor == PCI_VENDOR_ID_ATI || + chip->pci->vendor == PCI_VENDOR_ID_AMD) && + vga_switcheroo_get_client_id(chip->pci) != VGA_SWITCHEROO_DIS) + return -EBUSY; +#endif + return 0; } -- 2.18.0

1 1

[alsa-devel] [PATCH RFC 0/5] Add devres support to card resources
by Takashi Iwai 13 Sep '18

13 Sep '18

Hi, the devres or device-managed resource allocation is a popular method among many drivers but we didn't have such a mechanism for the core sound card objects. Here is an attempt to implement that. The first patch gives the devm-version of page allocator helper, and the second patch provides the devm-version of snd_card_new(). The rest patches are examples of the new API usages. As of now, this patch series is still an RFC. The usefulness of this is still unclear, but I believe this can be used in all legacy ALSA drivers pretty well. For ASoC, this would help very little, supposedly, though. The latest patches are found in topic/devres branch of my sound.git tree, too. thanks, Takashi === Takashi Iwai (5): ALSA: core: Add device-managed page allocator helper ALSA: core: Add managed card creation ALSA: intel8x0: Allocate resources with device-managed APIs ALSA: atiixp: Allocate resources with device-managed APIs ALSA: hda: Allocate resources with device-managed APIs include/sound/core.h | 5 ++ include/sound/memalloc.h | 4 + sound/core/init.c | 95 +++++++++++++++++++++- sound/core/memalloc.c | 88 +++++++++++++++----- sound/pci/atiixp.c | 104 +++++++----------------- sound/pci/atiixp_modem.c | 104 +++++++----------------- sound/pci/hda/hda_controller.h | 1 - sound/pci/hda/hda_intel.c | 43 +++------- sound/pci/intel8x0.c | 143 +++++++++++---------------------- sound/pci/intel8x0m.c | 143 +++++++++++---------------------- 10 files changed, 332 insertions(+), 398 deletions(-) -- 2.18.0

1 5

[alsa-devel] [PATCH] ALSA: intel8x0m: Register irq handler after register initializations
by Takashi Iwai 13 Sep '18

13 Sep '18

The interrupt handler has to be acquired after the other resource initialization when allocated with IRQF_SHARED. Otherwise it's triggered before the resource gets ready, and may lead to unpleasant behavior. Signed-off-by: Takashi Iwai <tiwai(a)suse.de> --- sound/pci/intel8x0m.c | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/sound/pci/intel8x0m.c b/sound/pci/intel8x0m.c index 943a726b1c1b..c84629190cba 100644 --- a/sound/pci/intel8x0m.c +++ b/sound/pci/intel8x0m.c @@ -1171,16 +1171,6 @@ static int snd_intel8x0m_create(struct snd_card *card, } port_inited: - if (request_irq(pci->irq, snd_intel8x0m_interrupt, IRQF_SHARED, - KBUILD_MODNAME, chip)) { - dev_err(card->dev, "unable to grab IRQ %d\n", pci->irq); - snd_intel8x0m_free(chip); - return -EBUSY; - } - chip->irq = pci->irq; - pci_set_master(pci); - synchronize_irq(chip->irq); - /* initialize offsets */ chip->bdbars_count = 2; tbl = intel_regs; @@ -1224,11 +1214,21 @@ static int snd_intel8x0m_create(struct snd_card *card, chip->int_sta_reg = ICH_REG_GLOB_STA; chip->int_sta_mask = int_sta_masks; + pci_set_master(pci); + if ((err = snd_intel8x0m_chip_init(chip, 1)) < 0) { snd_intel8x0m_free(chip); return err; } + if (request_irq(pci->irq, snd_intel8x0m_interrupt, IRQF_SHARED, + KBUILD_MODNAME, chip)) { + dev_err(card->dev, "unable to grab IRQ %d\n", pci->irq); + snd_intel8x0m_free(chip); + return -EBUSY; + } + chip->irq = pci->irq; + if ((err = snd_device_new(card, SNDRV_DEV_LOWLEVEL, chip, &ops)) < 0) { snd_intel8x0m_free(chip); return err; -- 2.18.0

1 0

[alsa-devel] [RFC - AAF PCM plugin 0/5] Introduce AVTP Audio Format (AAF) plugin
by Andre Guedes 13 Sep '18

13 Sep '18

Hi all, This patchset introduces the AAF plugin to the alsa-plugins project which enables TSN audio applications on Linux. For those not familiarized with TSN, it stands for Time-Sensitive Networking, and it's a set of IEEE technologies (enhancements to IEEE 802.1Q and Ethernet protocols) that provide precise time synchronization, bounded latency and application interoperability to bridged networks. Those technologies enable time-sensitive applications such as audio, video and control loops to run on top of bridged networks, co-existing with regular applications. TSN technologies are a super set of Audio Video Bridging (AVB) technologies also developed by IEEE. AVTP is the protocol defined to transport data in a TSN system, and AAF is one of the formats defined by AVTP to encapsulate audio data. AAF is specified in Chapter 7 from the AVTP spec [1]. This work is part of the effort to enable TSN technologies on upstream Linux ecosystem. All building-blocks required to enable TSN audio applications have been already developed and pushed to upstream projects. Time synchronization features are provided by linuxptp project [2], bounded latency features are provided by Linux Traffic Control subsystem since kernel version 4.15 [3], and AVTP packetization is provided by libavtp [4]. What is currently missing in the ecosystem to enable TSN audio applications is a piece of software that plumbs it all together and interfaces with Linux Audio system properly. That's the point of the AAF plugin introduced here. The AAF plugin is a PCM plugin that uses AVTP protocol to transmit/receive audio data through a TSN capable network. When operating in playback mode, the plugin reads PCM samples from the audio buffer, encapsulates into AVTP packets and transmits to the network, mimicking a typical AVTP Talker. When operating in capture mode, the plugin receives AVTP packets from the network, retrieves the PCM samples, and present them to alsa-lib layer at the presentation time, mimicking a typical AVTP Listener. Details about the plugin implementation are provided in the patches description, and information on how to configure and run the AAF plugin is provided in doc/aaf.txt file. Best regards, Andre [1] 1722-2016 - IEEE Standard for a Transport Protocol for Time-Sensitive Applications in Bridged Local Area Networks [2] http://linuxptp.sourceforge.net [3] https://patchwork.ozlabs.org/cover/826678/ [4] https://github.com/AVnu/libavtp Andre Guedes (5): aaf: Introduce plugin skeleton aaf: Load configuration parameters aaf: Implement Playback mode support aaf: Prepare for Capture mode support aaf: Implement Capture mode support Makefile.am | 3 + aaf/Makefile.am | 9 + aaf/pcm_aaf.c | 1172 +++++++++++++++++++++++++++++++++++++++++++++++++++++++ configure.ac | 9 + doc/aaf.txt | 110 ++++++ 5 files changed, 1303 insertions(+) create mode 100644 aaf/Makefile.am create mode 100644 aaf/pcm_aaf.c create mode 100644 doc/aaf.txt -- 2.14.4

4 26

Re: [alsa-devel] Microphone detected, but no output for all ASUS G751xx with ALC668 chipset
by Connor McAdams 12 Sep '18

12 Sep '18

You get that terminal output while running the program? Those vfio_region_writes shouldn't be visible from the terminal... they should be fed into QemuHDADump, and then it outputs it's own stuff. If that is the output you're seeing, you might not have set up logging to go to stderr. On Wed, Sep 12, 2018 at 1:05 PM, Håvard <hovardslill(a)gmail.com> wrote: > I think this is right! > > I first booted up, then tested speakers (That I could not hear) and then > tested microphone (Which worked perfectly) in windows settings. > > -Håvard > > Den ons. 12. sep. 2018 kl. 18:49 skrev Connor McAdams > <conmanx360(a)gmail.com>: >> >> Also, sorry to keep sending more replies, make sure the only trace you >> have on is vfio_region_write, and not the read one. The read spams up >> the console. >> >> On Wed, Sep 12, 2018 at 12:43 PM, Connor McAdams <conmanx360(a)gmail.com> >> wrote: >> > Reason being, it may not have identified the CORB buffer properly or >> > something. That's very odd to have no data. Never seen that before. >> > >> > On Wed, Sep 12, 2018 at 12:42 PM, Connor McAdams <conmanx360(a)gmail.com> >> > wrote: >> >> Could you try again and make a copy of your terminal output? >> >> >> >> On Wed, Sep 12, 2018 at 12:41 PM, Håvard <hovardslill(a)gmail.com> wrote: >> >>> Hi again. >> >>> Sorry for not noticing all files were empty, did it not run for long >> >>> enough? >> >>> >> >>> -Håvard >> >>> >> >>> Den ons. 12. sep. 2018 kl. 18:39 skrev Håvard <hovardslill(a)gmail.com>: >> >>>> >> >>>> Sorry my bad again it was working perfectly, just missed a step. >> >>>> >> >>>> I'll add the dumps as an attatchment. I had both external headset and >> >>>> microphone plugged in and let the VM run in the background for ~30min >> >>>> while >> >>>> doing other stuff. I did not play music or test my microphone in the >> >>>> VM >> >>>> either, If i did anything wrong, please tell me! >> >>>> >> >>>> It stopped at 0x104f4 >> >>>> >> >>>> -Håvard >> >>>> >> >>>> Den ons. 12. sep. 2018 kl. 00:31 skrev Connor McAdams >> >>>> <conmanx360(a)gmail.com>: >> >>>>> >> >>>>> Hm.... that's odd. They should show up in the folder you ran the >> >>>>> command from. Does your console show any "DumpMem entered..." or >> >>>>> something like that? You may have a permissions error. I've had some >> >>>>> people report that as an issue before. >> >>>>> >> >>>>> On Tue, Sep 11, 2018 at 5:08 PM, Håvard <hovardslill(a)gmail.com> >> >>>>> wrote: >> >>>>> > Hi! >> >>>>> > >> >>>>> > Took a while, but I think I got it working. Did not see any >> >>>>> > "frame[xx]" >> >>>>> > files though. What dumps do you want? >> >>>>> > >> >>>>> > -Håvard >> >>>>> > >> >>>>> > Den tir. 11. sep. 2018 kl. 21:27 skrev Håvard >> >>>>> > <hovardslill(a)gmail.com>: >> >>>>> >> >> >>>>> >> Sorry about that, I forgot to enable a kernel config... >> >>>>> >> >> >>>>> >> -Håvard >> >>>>> >> >> >>>>> >> Den tir. 11. sep. 2018 kl. 21:20 skrev Connor McAdams >> >>>>> >> <conmanx360(a)gmail.com>: >> >>>>> >>> >> >>>>> >>> When it's bound as a stub, it shouldn't show up in alsamixer >> >>>>> >>> controls. >> >>>>> >>> You can check what module is loaded by doing lspci -v . It >> >>>>> >>> should say >> >>>>> >>> kernel driver in use: pci-stub. Also, did you run the vfio-bind >> >>>>> >>> script >> >>>>> >>> before trying it? >> >>>>> >>> >> >>>>> >>> On Tue, Sep 11, 2018 at 3:18 PM, Håvard <hovardslill(a)gmail.com> >> >>>>> >>> wrote: >> >>>>> >>> > Thank you for the offer! >> >>>>> >>> > >> >>>>> >>> > I run gentoo, but your github guide is very useful. I can't >> >>>>> >>> > seem to >> >>>>> >>> > bind my >> >>>>> >>> > audio driver to a pci-stud. Is the Sound card still supposed >> >>>>> >>> > to >> >>>>> >>> > function as >> >>>>> >>> > normal when I (think I) have bound it to a stud. >> >>>>> >>> > >> >>>>> >>> > -Håvard >> >>>>> >>> > >> >>>>> >>> > Den tir. 11. sep. 2018 kl. 20:26 skrev Connor McAdams >> >>>>> >>> > <conmanx360(a)gmail.com>: >> >>>>> >>> >> >> >>>>> >>> >> One thing you could try, is using the program I used to >> >>>>> >>> >> reverse >> >>>>> >>> >> engineer the Sound Blaster Z series of cards, QemuHDADump. If >> >>>>> >>> >> your >> >>>>> >>> >> processor supports pci-passthrough with a virtual machine, >> >>>>> >>> >> you >> >>>>> >>> >> could >> >>>>> >>> >> run a Windows virtual machine with the sound card in it and >> >>>>> >>> >> capture >> >>>>> >>> >> the commands. I'd be willing to look through the dumps to see >> >>>>> >>> >> if >> >>>>> >>> >> there >> >>>>> >>> >> are any special verbs or anything. >> >>>>> >>> >> >> >>>>> >>> >> You can find the program here: >> >>>>> >>> >> https://github.com/Conmanx360/QemuHDADump >> >>>>> >>> >> >> >>>>> >>> >> Let me know. >> >>>>> >>> >> >> >>>>> >>> >> On Tue, Sep 11, 2018 at 2:15 PM, Håvard >> >>>>> >>> >> <hovardslill(a)gmail.com> >> >>>>> >>> >> wrote: >> >>>>> >>> >> > Sorry, my gmail didn't update so I wrote my response before >> >>>>> >>> >> > I >> >>>>> >>> >> > read >> >>>>> >>> >> > your >> >>>>> >>> >> > last one. >> >>>>> >>> >> > >> >>>>> >>> >> > It is a separate mic port as the G751JT doesn't have any >> >>>>> >>> >> > headset >> >>>>> >>> >> > multijacks. >> >>>>> >>> >> > >> >>>>> >>> >> > I'll try and dig around in the kernel! Thanks for the tip! >> >>>>> >>> >> > >> >>>>> >>> >> > -Håvard >> >>>>> >>> >> > >> >>>>> >>> >> > Den tir. 11. sep. 2018 kl. 20:09 skrev Håvard >> >>>>> >>> >> > <hovardslill(a)gmail.com>: >> >>>>> >>> >> > >> >>>>> >>> >> >> Thank you for taking your time and trying to help! :) >> >>>>> >>> >> >> >> >>>>> >>> >> >> Do you know where I can ask around for more help on the >> >>>>> >>> >> >> issue? >> >>>>> >>> >> >> I >> >>>>> >>> >> >> don't >> >>>>> >>> >> >> want to give up yet. >> >>>>> >>> >> >> >> >>>>> >>> >> >> -Håvard >> >>>>> >>> >> >> >> >>>>> >>> >> >> Den tir. 11. sep. 2018 kl. 20:02 skrev Takashi Iwai >> >>>>> >>> >> >> <tiwai(a)suse.de>: >> >>>>> >>> >> >> >> >>>>> >>> >> >>> On Tue, 11 Sep 2018 19:14:37 +0200, >> >>>>> >>> >> >>> Håvard wrote: >> >>>>> >>> >> >>> > >> >>>>> >>> >> >>> > Yes, microphone gets detected instantly and it >> >>>>> >>> >> >>> > automatically >> >>>>> >>> >> >>> > changes >> >>>>> >>> >> >>> > to >> >>>>> >>> >> >>> it >> >>>>> >>> >> >>> > in pavucontrol. >> >>>>> >>> >> >>> >> >>>>> >>> >> >>> Then it likely requires some additional initialization >> >>>>> >>> >> >>> outside >> >>>>> >>> >> >>> HD-audio. It's hard to know, as it's pretty much >> >>>>> >>> >> >>> vendor-specific. >> >>>>> >>> >> >>> You can dig down the Windows, but I have no idea about >> >>>>> >>> >> >>> Windows >> >>>>> >>> >> >>> implementation, so can't give any hints, unfortunately. >> >>>>> >>> >> >>> >> >>>>> >>> >> >>> >> >>>>> >>> >> >>> Takashi >> >>>>> >>> >> >>> >> >>>>> >>> >> >>> > >> >>>>> >>> >> >>> > Den tir. 11. sep. 2018 kl. 18:52 skrev Takashi Iwai >> >>>>> >>> >> >>> > <tiwai(a)suse.de>: >> >>>>> >>> >> >>> > >> >>>>> >>> >> >>> > > On Tue, 11 Sep 2018 18:40:23 +0200, >> >>>>> >>> >> >>> > > Håvard wrote: >> >>>>> >>> >> >>> > > > >> >>>>> >>> >> >>> > > > Thank you for replying! >> >>>>> >>> >> >>> > > > >> >>>>> >>> >> >>> > > > Enabling loopback in alsamixer: >> >>>>> >>> >> >>> > > > http://i.imgur.com/lNo6e7T.png >> >>>>> >>> >> >>> > > > >> >>>>> >>> >> >>> > > > And unmuting more and more things in "Mic Playback >> >>>>> >>> >> >>> > > > Volume" >> >>>>> >>> >> >>> > > > in >> >>>>> >>> >> >>> > > hdaanalyzer: >> >>>>> >>> >> >>> > > > http://i.imgur.com/H0HiOhy.png >> >>>>> >>> >> >>> > > > made white noise come from the headset. However it >> >>>>> >>> >> >>> > > > did >> >>>>> >>> >> >>> > > > not >> >>>>> >>> >> >>> > > > change or >> >>>>> >>> >> >>> > > react >> >>>>> >>> >> >>> > > > at all when I talked or even muted the microphone >> >>>>> >>> >> >>> > > > physically. >> >>>>> >>> >> >>> > > > >> >>>>> >>> >> >>> > > > I couldn't find "Mic Playback Switch" anywhere in >> >>>>> >>> >> >>> > > > either >> >>>>> >>> >> >>> > > > alsamixer >> >>>>> >>> >> >>> or >> >>>>> >>> >> >>> > > > hdaanalyzer. >> >>>>> >>> >> >>> > > >> >>>>> >>> >> >>> > > It's a mixer mute switch. >> >>>>> >>> >> >>> > > >> >>>>> >>> >> >>> > > > The microphone works perfectly fine under Windows, >> >>>>> >>> >> >>> > > > so I >> >>>>> >>> >> >>> > > > don't >> >>>>> >>> >> >>> > > > think >> >>>>> >>> >> >>> it is >> >>>>> >>> >> >>> > > > the mic pin. >> >>>>> >>> >> >>> > > >> >>>>> >>> >> >>> > > But the fact above indicates the possibility of the >> >>>>> >>> >> >>> > > wrong >> >>>>> >>> >> >>> > > pin, >> >>>>> >>> >> >>> > > too. >> >>>>> >>> >> >>> > > >> >>>>> >>> >> >>> > > Does the jack detection of the ext mic pin work? >> >>>>> >>> >> >>> > > >> >>>>> >>> >> >>> > > >> >>>>> >>> >> >>> > > Takashi >> >>>>> >>> >> >>> > > >> >>>>> >>> >> >>> > > > >> >>>>> >>> >> >>> > > > -Håvard >> >>>>> >>> >> >>> > > > >> >>>>> >>> >> >>> > > > Den man. 10. sep. 2018 kl. 22:39 skrev Takashi Iwai >> >>>>> >>> >> >>> > > > <tiwai(a)suse.de >> >>>>> >>> >> >>> >: >> >>>>> >>> >> >>> > > > >> >>>>> >>> >> >>> > > > > On Thu, 06 Sep 2018 20:44:30 +0200, >> >>>>> >>> >> >>> > > > > Håvard wrote: >> >>>>> >>> >> >>> > > > > > >> >>>>> >>> >> >>> > > > > > Additional relevant info: >> >>>>> >>> >> >>> > > > > > >> >>>>> >>> >> >>> > > > > > A similar issue was also discussed three years >> >>>>> >>> >> >>> > > > > > ago >> >>>>> >>> >> >>> > > > > > on >> >>>>> >>> >> >>> > > > > > Sun >> >>>>> >>> >> >>> > > > > > Jun >> >>>>> >>> >> >>> > > 17:15:54 >> >>>>> >>> >> >>> > > > > CEST >> >>>>> >>> >> >>> > > > > > 2015 and was about his surround sound setup, >> >>>>> >>> >> >>> > > > > > but did >> >>>>> >>> >> >>> > > > > > not >> >>>>> >>> >> >>> > > > > > touch >> >>>>> >>> >> >>> on the >> >>>>> >>> >> >>> > > > > > external microphone problem: >> >>>>> >>> >> >>> > > > > > >> >>>>> >>> >> >>> > > > > >> >>>>> >>> >> >>> > > >> >>>>> >>> >> >>> >> >>>>> >>> >> >>> >> >>>>> >>> >> >>> >> >>>>> >>> >> >>> >> >>>>> >>> >> >>> http://mailman.alsa-project.org/pipermail/alsa-devel/2015-June/093317.html >> >>>>> >>> >> >>> > > > > > >> >>>>> >>> >> >>> > > > > > alsa-info.sh: >> >>>>> >>> >> >>> > > > > > >> >>>>> >>> >> >>> > > > > >> >>>>> >>> >> >>> > > >> >>>>> >>> >> >>> >> >>>>> >>> >> >>> >> >>>>> >>> >> >>> >> >>>>> >>> >> >>> >> >>>>> >>> >> >>> http://www.alsa-project.org/db/?f=1d8616ba5977308e03db6c3a86e36e9e9b38d6f0 >> >>>>> >>> >> >>> > > > > > >> >>>>> >>> >> >>> > > > > > Graph of ALC668 chipset from hdaanalyzer: >> >>>>> >>> >> >>> > > > > > http://i.imgur.com/c08DNJW.png >> >>>>> >>> >> >>> > > > > > >> >>>>> >>> >> >>> > > > > > setting alsa-mode[1-8] does nothing to help the >> >>>>> >>> >> >>> > > > > > issue. >> >>>>> >>> >> >>> > > > > > >> >>>>> >>> >> >>> > > > > > There are several of similar bug reports around >> >>>>> >>> >> >>> > > > > > the >> >>>>> >>> >> >>> > > > > > web >> >>>>> >>> >> >>> experiencing >> >>>>> >>> >> >>> > > > > > similar issues, and on different distros. >> >>>>> >>> >> >>> > > > > > >> >>>>> >>> >> >>> > > > > > Microphone works perfectly in windows >> >>>>> >>> >> >>> > > > > > >> >>>>> >>> >> >>> > > > > > I have a ASUS ROG G751JT, but this problem >> >>>>> >>> >> >>> > > > > > seems to >> >>>>> >>> >> >>> > > > > > happen >> >>>>> >>> >> >>> > > > > > with >> >>>>> >>> >> >>> all >> >>>>> >>> >> >>> > > > > laptops >> >>>>> >>> >> >>> > > > > > under the G751 name. >> >>>>> >>> >> >>> > > > > >> >>>>> >>> >> >>> > > > > When you enable the loopback volume and switch, >> >>>>> >>> >> >>> > > > > and >> >>>>> >>> >> >>> > > > > unmute/adjust >> >>>>> >>> >> >>> "Mic >> >>>>> >>> >> >>> > > > > Playback Volume", and "Mic Playback Switch", do >> >>>>> >>> >> >>> > > > > you >> >>>>> >>> >> >>> > > > > hear >> >>>>> >>> >> >>> > > > > the >> >>>>> >>> >> >>> > > > > input >> >>>>> >>> >> >>> > > > > from the ext mic? It's a route directly from NID >> >>>>> >>> >> >>> > > > > 0x18 >> >>>>> >>> >> >>> > > > > to >> >>>>> >>> >> >>> > > > > the >> >>>>> >>> >> >>> mixer >> >>>>> >>> >> >>> > > > > NID 0x0b, then output mixer NID 0x0c, then >> >>>>> >>> >> >>> > > > > outputs. >> >>>>> >>> >> >>> > > > > So >> >>>>> >>> >> >>> > > > > this >> >>>>> >>> >> >>> > > > > can >> >>>>> >>> >> >>> be >> >>>>> >>> >> >>> > > > > used to verify the hardware routing. >> >>>>> >>> >> >>> > > > > >> >>>>> >>> >> >>> > > > > If you don't hear via this route, it means that >> >>>>> >>> >> >>> > > > > the >> >>>>> >>> >> >>> > > > > input >> >>>>> >>> >> >>> > > > > from >> >>>>> >>> >> >>> the ext >> >>>>> >>> >> >>> > > > > mic pin itself is broken, and it implies that >> >>>>> >>> >> >>> > > > > something >> >>>>> >>> >> >>> > > > > outside >> >>>>> >>> >> >>> > > > > HD-audio codec. >> >>>>> >>> >> >>> > > > > >> >>>>> >>> >> >>> > > > > >> >>>>> >>> >> >>> > > > > Takashi >> >>>>> >>> >> >>> > > > > >> >>>>> >>> >> >>> > > > [2 <text/html; UTF-8 (quoted-printable)>] >> >>>>> >>> >> >>> > > > >> >>>>> >>> >> >>> > > >> >>>>> >>> >> >>> > [2 <text/html; UTF-8 (quoted-printable)>] >> >>>>> >>> >> >>> > >> >>>>> >>> >> >>> >> >>>>> >>> >> >> >> >>>>> >>> >> > _______________________________________________ >> >>>>> >>> >> > Alsa-devel mailing list >> >>>>> >>> >> > Alsa-devel(a)alsa-project.org >> >>>>> >>> >> > http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

1 2