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

[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

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

12 Sep '18

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. (My first email was dissaproved as it was too large) Den ons. 12. sep. 2018 kl. 19:05 skrev Håvard <hovardslill(a)gmail.com>: > 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 0

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

12 Sep '18

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. These are my kernel configs: https://paste.pound-python.org/show/GRk4T6xNvmdp8W7K9slJ/ Thank you! -Håvard

3 19

[alsa-devel] [PATCH] ASoC: pxa: remove duplicated snd_soc_component_driver ops
by petrcvekcz＠gmail.com 11 Sep '18

11 Sep '18

From: Petr Cvek <petrcvekcz(a)gmail.com> The sound soc drivers which are using a platform driver pxa-pcm-audio and cpu dai drivers from the pxa tree have defined pxa2xx_soc_pcm_new() twice. The function will get called in soc_new_pcm() for two components (platform and cpu dai) which causes a double allocation of DMA resources and later during a close of the playback/capture a kernel warning: WARNING: CPU: 0 PID: 892 at drivers/dma/dmaengine.c:788 dma_release_channel+0x44/0xa0 chan reference count 0 != 1 Modules linked in: snd_soc_magician snd_soc_pxa2xx snd_pxa2xx_lib ... CPU: 0 PID: 892 Comm: aplay Tainted: G C 4.18.0-rc6-next-20180726-magician+ #16 Hardware name: HTC Magician [<c0107d90>] (unwind_backtrace) from [<c010594c>] (show_stack+0x10/0x14) [<c010594c>] (show_stack) from [<c0111680>] (__warn+0xd4/0xec) [<c0111680>] (__warn) from [<c01112d0>] (warn_slowpath_fmt+0x44/0x6c) [<c01112d0>] (warn_slowpath_fmt) from [<c034908c>] (dma_release_channel+0x44/0xa0) [<c034908c>] (dma_release_channel) from [<bf330528>] (snd_dmaengine_pcm_close_release_chan+0x44/0xb1c [snd_pcm_dmaengine]) [<bf330528>] (snd_dmaengine_pcm_close_release_chan [snd_pcm_dmaengine]) from [<bf26c29c>] (soc_pcm_components_close+0x8c/0xac [snd_soc_core]) [<bf26c29c>] (soc_pcm_components_close [snd_soc_core]) from [<bf26c3a0>] (soc_pcm_close+0xe4/0xd44 [snd_soc_core]) [<bf26c3a0>] (soc_pcm_close [snd_soc_core]) from [<bf167254>] (snd_pcm_release_substream+0x88/0x108 [snd_pcm]) [<bf167254>] (snd_pcm_release_substream [snd_pcm]) from [<bf167330>] (snd_pcm_release+0x5c/0xd2c [snd_pcm]) [<bf167330>] (snd_pcm_release [snd_pcm]) from [<c01c39e4>] (__fput+0xdc/0x1e8) [<c01c39e4>] (__fput) from [<c0129e7c>] (task_work_run+0xc4/0xd4) [<c0129e7c>] (task_work_run) from [<c01053ac>] (do_work_pending+0xc0/0xc8) [<c01053ac>] (do_work_pending) from [<c0101068>] (slow_work_pending+0xc/0x20) Exception stack(0xc2fdffb0 to 0xc2fdfff8) ffa0: 00000000 0154d1a0 01542a3c 00000000 ffc0: 0154d150 00000000 0009283c 00000006 000003f0 0154d4c8 00000000 0154d4c8 ffe0: b6ee7d70 bef13960 b6e547b8 b6cfe018 60000010 00000004 The problem was found for cpu dai drivers: pxa-i2s and pxa-ssp and by a calltrace sent from Robert Jarzmik on pxa-ac97 (although there was no observed kernel warning). The git grep shows these 3 cpu dai drivers are the only one which assign the .pcm_new to pxa2xx_soc_pcm_new() and almost every machine which is using one of these cpu dai drivers is using the platform driver pxa-pcm-audio too. The only exception is TTC_DKB board which is using a platform driver mmp-pcm-audio. A quick look in the code of mmp-pcm-audio shows it allocates the DMA in the similar way as PXA. The solution is to remove one of pxa2xx_soc_pcm_new() assignments and the patch does it for 3 cpu dai drivers (SSP/I2S/AC97). The result was tested on HTC Magician board (SSP for playback, I2S for capture) and the DMA buffers are correctly allocated. Signed-off-by: Petr Cvek <petrcvekcz(a)gmail.com> --- sound/soc/pxa/pxa-ssp.c | 3 --- sound/soc/pxa/pxa2xx-ac97.c | 3 --- sound/soc/pxa/pxa2xx-i2s.c | 3 --- 3 files changed, 9 deletions(-) diff --git a/sound/soc/pxa/pxa-ssp.c b/sound/soc/pxa/pxa-ssp.c index 69033e1a84e6..9689a1552d53 100644 --- a/sound/soc/pxa/pxa-ssp.c +++ b/sound/soc/pxa/pxa-ssp.c @@ -867,9 +867,6 @@ static struct snd_soc_dai_driver pxa_ssp_dai = { static const struct snd_soc_component_driver pxa_ssp_component = { .name = "pxa-ssp", - .ops = &pxa2xx_pcm_ops, - .pcm_new = pxa2xx_soc_pcm_new, - .pcm_free = pxa2xx_pcm_free_dma_buffers, }; #ifdef CONFIG_OF diff --git a/sound/soc/pxa/pxa2xx-ac97.c b/sound/soc/pxa/pxa2xx-ac97.c index 9f779657bc86..c52b33802bf2 100644 --- a/sound/soc/pxa/pxa2xx-ac97.c +++ b/sound/soc/pxa/pxa2xx-ac97.c @@ -214,9 +214,6 @@ static struct snd_soc_dai_driver pxa_ac97_dai_driver[] = { static const struct snd_soc_component_driver pxa_ac97_component = { .name = "pxa-ac97", - .ops = &pxa2xx_pcm_ops, - .pcm_new = pxa2xx_soc_pcm_new, - .pcm_free = pxa2xx_pcm_free_dma_buffers, }; #ifdef CONFIG_OF diff --git a/sound/soc/pxa/pxa2xx-i2s.c b/sound/soc/pxa/pxa2xx-i2s.c index 42820121e5b9..e7184de0de04 100644 --- a/sound/soc/pxa/pxa2xx-i2s.c +++ b/sound/soc/pxa/pxa2xx-i2s.c @@ -364,9 +364,6 @@ static struct snd_soc_dai_driver pxa_i2s_dai = { static const struct snd_soc_component_driver pxa_i2s_component = { .name = "pxa-i2s", - .ops = &pxa2xx_pcm_ops, - .pcm_new = pxa2xx_soc_pcm_new, - .pcm_free = pxa2xx_pcm_free_dma_buffers, }; static int pxa2xx_i2s_drv_probe(struct platform_device *pdev) -- 2.18.0

2 2

[alsa-devel] [PATCH 03/11] compat_ioctl: remove translation for sound ioctls
by Arnd Bergmann 11 Sep '18

11 Sep '18

The SNDCTL_* and SOUND_* commands are the old OSS user interface. I checked all the sound ioctl commands listed in fs/compat_ioctl.c to see if we still need the translation handlers. Here is what I found: - sound/oss/ is (almost) gone from the kernel, this is what actually needed all the translations - The ALSA emulation for OSS correctly handles all compat_ioctl commands already. - sound/oss/dmasound/ is the last holdout of the original OSS code, this is only used on arch/m68k, which has no 64-bit mode and hence needs no compat handlers - arch/um/drivers/hostaudio_kern.c may run in 64-bit mode with 32-bit x86 user space underneath it. This rare corner case is the only one that still needs the compat handlers. By adding a simple redirect of .compat_ioctl to .unlocked_ioctl in the UML driver, we can remove all the COMPATIBLE_IOCTL() annotations without a change in functionality. For completeness, I'm adding the same thing to the dmasound file, knowing that it makes no difference. The compat_ioctl list contains one comment about SNDCTL_DSP_MAPINBUF and SNDCTL_DSP_MAPOUTBUF, which actually would need a translation handler if implemented. However, the native implementation just returns -EINVAL, so we don't care. Signed-off-by: Arnd Bergmann <arnd(a)arndb.de> --- arch/um/drivers/hostaudio_kern.c | 1 + fs/compat_ioctl.c | 157 ----------------------------- sound/core/oss/pcm_oss.c | 4 + sound/oss/dmasound/dmasound_core.c | 2 + 4 files changed, 7 insertions(+), 157 deletions(-) diff --git a/arch/um/drivers/hostaudio_kern.c b/arch/um/drivers/hostaudio_kern.c index 7f9dbdbc4eb7..0278a642a622 100644 --- a/arch/um/drivers/hostaudio_kern.c +++ b/arch/um/drivers/hostaudio_kern.c @@ -298,6 +298,7 @@ static const struct file_operations hostaudio_fops = { .write = hostaudio_write, .poll = hostaudio_poll, .unlocked_ioctl = hostaudio_ioctl, + .compat_ioctl = hostaudio_ioctl, .mmap = NULL, .open = hostaudio_open, .release = hostaudio_release, diff --git a/fs/compat_ioctl.c b/fs/compat_ioctl.c index c2c73b802fb3..875516658c39 100644 --- a/fs/compat_ioctl.c +++ b/fs/compat_ioctl.c @@ -78,7 +78,6 @@ #include <linux/if_bonding.h> #include <linux/watchdog.h> -#include <linux/soundcard.h> #include <linux/lp.h> #include <linux/ppdev.h> @@ -605,162 +604,6 @@ COMPATIBLE_IOCTL(SG_GET_KEEP_ORPHAN) /* PPP stuff */ COMPATIBLE_IOCTL(PPPIOCGUNIT) COMPATIBLE_IOCTL(PPPIOCGCHAN) -/* Big A */ -/* sparc only */ -/* Big Q for sound/OSS */ -COMPATIBLE_IOCTL(SNDCTL_SEQ_RESET) -COMPATIBLE_IOCTL(SNDCTL_SEQ_SYNC) -COMPATIBLE_IOCTL(SNDCTL_SYNTH_INFO) -COMPATIBLE_IOCTL(SNDCTL_SEQ_CTRLRATE) -COMPATIBLE_IOCTL(SNDCTL_SEQ_GETOUTCOUNT) -COMPATIBLE_IOCTL(SNDCTL_SEQ_GETINCOUNT) -COMPATIBLE_IOCTL(SNDCTL_SEQ_PERCMODE) -COMPATIBLE_IOCTL(SNDCTL_FM_LOAD_INSTR) -COMPATIBLE_IOCTL(SNDCTL_SEQ_TESTMIDI) -COMPATIBLE_IOCTL(SNDCTL_SEQ_RESETSAMPLES) -COMPATIBLE_IOCTL(SNDCTL_SEQ_NRSYNTHS) -COMPATIBLE_IOCTL(SNDCTL_SEQ_NRMIDIS) -COMPATIBLE_IOCTL(SNDCTL_MIDI_INFO) -COMPATIBLE_IOCTL(SNDCTL_SEQ_THRESHOLD) -COMPATIBLE_IOCTL(SNDCTL_SYNTH_MEMAVL) -COMPATIBLE_IOCTL(SNDCTL_FM_4OP_ENABLE) -COMPATIBLE_IOCTL(SNDCTL_SEQ_PANIC) -COMPATIBLE_IOCTL(SNDCTL_SEQ_OUTOFBAND) -COMPATIBLE_IOCTL(SNDCTL_SEQ_GETTIME) -COMPATIBLE_IOCTL(SNDCTL_SYNTH_ID) -COMPATIBLE_IOCTL(SNDCTL_SYNTH_CONTROL) -COMPATIBLE_IOCTL(SNDCTL_SYNTH_REMOVESAMPLE) -/* Big T for sound/OSS */ -COMPATIBLE_IOCTL(SNDCTL_TMR_TIMEBASE) -COMPATIBLE_IOCTL(SNDCTL_TMR_START) -COMPATIBLE_IOCTL(SNDCTL_TMR_STOP) -COMPATIBLE_IOCTL(SNDCTL_TMR_CONTINUE) -COMPATIBLE_IOCTL(SNDCTL_TMR_TEMPO) -COMPATIBLE_IOCTL(SNDCTL_TMR_SOURCE) -COMPATIBLE_IOCTL(SNDCTL_TMR_METRONOME) -COMPATIBLE_IOCTL(SNDCTL_TMR_SELECT) -/* Little m for sound/OSS */ -COMPATIBLE_IOCTL(SNDCTL_MIDI_PRETIME) -COMPATIBLE_IOCTL(SNDCTL_MIDI_MPUMODE) -COMPATIBLE_IOCTL(SNDCTL_MIDI_MPUCMD) -/* Big P for sound/OSS */ -COMPATIBLE_IOCTL(SNDCTL_DSP_RESET) -COMPATIBLE_IOCTL(SNDCTL_DSP_SYNC) -COMPATIBLE_IOCTL(SNDCTL_DSP_SPEED) -COMPATIBLE_IOCTL(SNDCTL_DSP_STEREO) -COMPATIBLE_IOCTL(SNDCTL_DSP_GETBLKSIZE) -COMPATIBLE_IOCTL(SNDCTL_DSP_CHANNELS) -COMPATIBLE_IOCTL(SOUND_PCM_WRITE_FILTER) -COMPATIBLE_IOCTL(SNDCTL_DSP_POST) -COMPATIBLE_IOCTL(SNDCTL_DSP_SUBDIVIDE) -COMPATIBLE_IOCTL(SNDCTL_DSP_SETFRAGMENT) -COMPATIBLE_IOCTL(SNDCTL_DSP_GETFMTS) -COMPATIBLE_IOCTL(SNDCTL_DSP_SETFMT) -COMPATIBLE_IOCTL(SNDCTL_DSP_GETOSPACE) -COMPATIBLE_IOCTL(SNDCTL_DSP_GETISPACE) -COMPATIBLE_IOCTL(SNDCTL_DSP_NONBLOCK) -COMPATIBLE_IOCTL(SNDCTL_DSP_GETCAPS) -COMPATIBLE_IOCTL(SNDCTL_DSP_GETTRIGGER) -COMPATIBLE_IOCTL(SNDCTL_DSP_SETTRIGGER) -COMPATIBLE_IOCTL(SNDCTL_DSP_GETIPTR) -COMPATIBLE_IOCTL(SNDCTL_DSP_GETOPTR) -/* SNDCTL_DSP_MAPINBUF, XXX needs translation */ -/* SNDCTL_DSP_MAPOUTBUF, XXX needs translation */ -COMPATIBLE_IOCTL(SNDCTL_DSP_SETSYNCRO) -COMPATIBLE_IOCTL(SNDCTL_DSP_SETDUPLEX) -COMPATIBLE_IOCTL(SNDCTL_DSP_GETODELAY) -COMPATIBLE_IOCTL(SNDCTL_DSP_PROFILE) -COMPATIBLE_IOCTL(SOUND_PCM_READ_RATE) -COMPATIBLE_IOCTL(SOUND_PCM_READ_CHANNELS) -COMPATIBLE_IOCTL(SOUND_PCM_READ_BITS) -COMPATIBLE_IOCTL(SOUND_PCM_READ_FILTER) -/* Big C for sound/OSS */ -COMPATIBLE_IOCTL(SNDCTL_COPR_RESET) -COMPATIBLE_IOCTL(SNDCTL_COPR_LOAD) -COMPATIBLE_IOCTL(SNDCTL_COPR_RDATA) -COMPATIBLE_IOCTL(SNDCTL_COPR_RCODE) -COMPATIBLE_IOCTL(SNDCTL_COPR_WDATA) -COMPATIBLE_IOCTL(SNDCTL_COPR_WCODE) -COMPATIBLE_IOCTL(SNDCTL_COPR_RUN) -COMPATIBLE_IOCTL(SNDCTL_COPR_HALT) -COMPATIBLE_IOCTL(SNDCTL_COPR_SENDMSG) -COMPATIBLE_IOCTL(SNDCTL_COPR_RCVMSG) -/* Big M for sound/OSS */ -COMPATIBLE_IOCTL(SOUND_MIXER_READ_VOLUME) -COMPATIBLE_IOCTL(SOUND_MIXER_READ_BASS) -COMPATIBLE_IOCTL(SOUND_MIXER_READ_TREBLE) -COMPATIBLE_IOCTL(SOUND_MIXER_READ_SYNTH) -COMPATIBLE_IOCTL(SOUND_MIXER_READ_PCM) -COMPATIBLE_IOCTL(SOUND_MIXER_READ_SPEAKER) -COMPATIBLE_IOCTL(SOUND_MIXER_READ_LINE) -COMPATIBLE_IOCTL(SOUND_MIXER_READ_MIC) -COMPATIBLE_IOCTL(SOUND_MIXER_READ_CD) -COMPATIBLE_IOCTL(SOUND_MIXER_READ_IMIX) -COMPATIBLE_IOCTL(SOUND_MIXER_READ_ALTPCM) -COMPATIBLE_IOCTL(SOUND_MIXER_READ_RECLEV) -COMPATIBLE_IOCTL(SOUND_MIXER_READ_IGAIN) -COMPATIBLE_IOCTL(SOUND_MIXER_READ_OGAIN) -COMPATIBLE_IOCTL(SOUND_MIXER_READ_LINE1) -COMPATIBLE_IOCTL(SOUND_MIXER_READ_LINE2) -COMPATIBLE_IOCTL(SOUND_MIXER_READ_LINE3) -COMPATIBLE_IOCTL(MIXER_READ(SOUND_MIXER_DIGITAL1)) -COMPATIBLE_IOCTL(MIXER_READ(SOUND_MIXER_DIGITAL2)) -COMPATIBLE_IOCTL(MIXER_READ(SOUND_MIXER_DIGITAL3)) -COMPATIBLE_IOCTL(MIXER_READ(SOUND_MIXER_PHONEIN)) -COMPATIBLE_IOCTL(MIXER_READ(SOUND_MIXER_PHONEOUT)) -COMPATIBLE_IOCTL(MIXER_READ(SOUND_MIXER_VIDEO)) -COMPATIBLE_IOCTL(MIXER_READ(SOUND_MIXER_RADIO)) -COMPATIBLE_IOCTL(MIXER_READ(SOUND_MIXER_MONITOR)) -COMPATIBLE_IOCTL(SOUND_MIXER_READ_MUTE) -/* SOUND_MIXER_READ_ENHANCE, same value as READ_MUTE */ -/* SOUND_MIXER_READ_LOUD, same value as READ_MUTE */ -COMPATIBLE_IOCTL(SOUND_MIXER_READ_RECSRC) -COMPATIBLE_IOCTL(SOUND_MIXER_READ_DEVMASK) -COMPATIBLE_IOCTL(SOUND_MIXER_READ_RECMASK) -COMPATIBLE_IOCTL(SOUND_MIXER_READ_STEREODEVS) -COMPATIBLE_IOCTL(SOUND_MIXER_READ_CAPS) -COMPATIBLE_IOCTL(SOUND_MIXER_WRITE_VOLUME) -COMPATIBLE_IOCTL(SOUND_MIXER_WRITE_BASS) -COMPATIBLE_IOCTL(SOUND_MIXER_WRITE_TREBLE) -COMPATIBLE_IOCTL(SOUND_MIXER_WRITE_SYNTH) -COMPATIBLE_IOCTL(SOUND_MIXER_WRITE_PCM) -COMPATIBLE_IOCTL(SOUND_MIXER_WRITE_SPEAKER) -COMPATIBLE_IOCTL(SOUND_MIXER_WRITE_LINE) -COMPATIBLE_IOCTL(SOUND_MIXER_WRITE_MIC) -COMPATIBLE_IOCTL(SOUND_MIXER_WRITE_CD) -COMPATIBLE_IOCTL(SOUND_MIXER_WRITE_IMIX) -COMPATIBLE_IOCTL(SOUND_MIXER_WRITE_ALTPCM) -COMPATIBLE_IOCTL(SOUND_MIXER_WRITE_RECLEV) -COMPATIBLE_IOCTL(SOUND_MIXER_WRITE_IGAIN) -COMPATIBLE_IOCTL(SOUND_MIXER_WRITE_OGAIN) -COMPATIBLE_IOCTL(SOUND_MIXER_WRITE_LINE1) -COMPATIBLE_IOCTL(SOUND_MIXER_WRITE_LINE2) -COMPATIBLE_IOCTL(SOUND_MIXER_WRITE_LINE3) -COMPATIBLE_IOCTL(MIXER_WRITE(SOUND_MIXER_DIGITAL1)) -COMPATIBLE_IOCTL(MIXER_WRITE(SOUND_MIXER_DIGITAL2)) -COMPATIBLE_IOCTL(MIXER_WRITE(SOUND_MIXER_DIGITAL3)) -COMPATIBLE_IOCTL(MIXER_WRITE(SOUND_MIXER_PHONEIN)) -COMPATIBLE_IOCTL(MIXER_WRITE(SOUND_MIXER_PHONEOUT)) -COMPATIBLE_IOCTL(MIXER_WRITE(SOUND_MIXER_VIDEO)) -COMPATIBLE_IOCTL(MIXER_WRITE(SOUND_MIXER_RADIO)) -COMPATIBLE_IOCTL(MIXER_WRITE(SOUND_MIXER_MONITOR)) -COMPATIBLE_IOCTL(SOUND_MIXER_WRITE_MUTE) -/* SOUND_MIXER_WRITE_ENHANCE, same value as WRITE_MUTE */ -/* SOUND_MIXER_WRITE_LOUD, same value as WRITE_MUTE */ -COMPATIBLE_IOCTL(SOUND_MIXER_WRITE_RECSRC) -COMPATIBLE_IOCTL(SOUND_MIXER_INFO) -COMPATIBLE_IOCTL(SOUND_OLD_MIXER_INFO) -COMPATIBLE_IOCTL(SOUND_MIXER_ACCESS) -COMPATIBLE_IOCTL(SOUND_MIXER_AGC) -COMPATIBLE_IOCTL(SOUND_MIXER_3DSE) -COMPATIBLE_IOCTL(SOUND_MIXER_PRIVATE1) -COMPATIBLE_IOCTL(SOUND_MIXER_PRIVATE2) -COMPATIBLE_IOCTL(SOUND_MIXER_PRIVATE3) -COMPATIBLE_IOCTL(SOUND_MIXER_PRIVATE4) -COMPATIBLE_IOCTL(SOUND_MIXER_PRIVATE5) -COMPATIBLE_IOCTL(SOUND_MIXER_GETLEVELS) -COMPATIBLE_IOCTL(SOUND_MIXER_SETLEVELS) -COMPATIBLE_IOCTL(OSS_GETVERSION) /* Raw devices */ COMPATIBLE_IOCTL(RAW_SETBIND) COMPATIBLE_IOCTL(RAW_GETBIND) diff --git a/sound/core/oss/pcm_oss.c b/sound/core/oss/pcm_oss.c index f8d4a419f3af..3f25c9d7b7df 100644 --- a/sound/core/oss/pcm_oss.c +++ b/sound/core/oss/pcm_oss.c @@ -2732,6 +2732,10 @@ static long snd_pcm_oss_ioctl(struct file *file, unsigned int cmd, unsigned long static long snd_pcm_oss_ioctl_compat(struct file *file, unsigned int cmd, unsigned long arg) { + /* + * Everything is compatbile except SNDCTL_DSP_MAPINBUF/SNDCTL_DSP_MAPOUTBUF, + * which are not implemented for the native case either + */ return snd_pcm_oss_ioctl(file, cmd, (unsigned long)compat_ptr(arg)); } #else diff --git a/sound/oss/dmasound/dmasound_core.c b/sound/oss/dmasound/dmasound_core.c index fc9bcd47d6a4..b6b5f5a5df9c 100644 --- a/sound/oss/dmasound/dmasound_core.c +++ b/sound/oss/dmasound/dmasound_core.c @@ -384,6 +384,7 @@ static const struct file_operations mixer_fops = .owner = THIS_MODULE, .llseek = no_llseek, .unlocked_ioctl = mixer_unlocked_ioctl, + .compat_ioctl = mixer_unlocked_ioctl, .open = mixer_open, .release = mixer_release, }; @@ -1167,6 +1168,7 @@ static const struct file_operations sq_fops = .write = sq_write, .poll = sq_poll, .unlocked_ioctl = sq_unlocked_ioctl, + .compat_ioctl = sq_unlocked_ioctl, .open = sq_open, .release = sq_release, }; -- 2.18.0

2 2