Re: [alsa-devel] Microphone detected, but no output for all ASUS G751xx with ALC668 chipset
I might not get around to writing the fix myself, but, here's the COEF's from within Windows. I've marked the ones missing inside the main init function. So, if anyone else wants to add these in, feel free.
On Wed, Sep 12, 2018 at 1:16 PM, Håvard hovardslill@gmail.com wrote:
That was without running the program (sorry)
This is output when running program:
Before there was no "Current verb...." They came when I opened up windows microphone settings. (something I didn't do before)
-Håvard
Den ons. 12. sep. 2018 kl. 19:11 skrev Håvard hovardslill@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.
(My first email was dissaproved as it was too large)
Den ons. 12. sep. 2018 kl. 19:05 skrev Håvard hovardslill@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@alsa-project.org >>> >>> >> > >>> >>> >> > http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
Can confirm that running: hda-verb /dev/snd/hwC0D0 0x20 0x500 0xc3 and hda-verb /dev/snd/hwC0D0 0x20 0x440 0x00 Fixes the issue completely.
Thanks to everyone who helped!
-Håvard
Den ons. 12. sep. 2018 kl. 22:01 skrev Connor McAdams <conmanx360@gmail.com
:
I might not get around to writing the fix myself, but, here's the COEF's from within Windows. I've marked the ones missing inside the main init function. So, if anyone else wants to add these in, feel free.
On Wed, Sep 12, 2018 at 1:16 PM, Håvard hovardslill@gmail.com wrote:
That was without running the program (sorry)
This is output when running program:
Before there was no "Current verb...." They came when I opened up windows microphone settings. (something I
didn't
do before)
-Håvard
Den ons. 12. sep. 2018 kl. 19:11 skrev Håvard hovardslill@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.
(My first email was dissaproved as it was too large)
Den ons. 12. sep. 2018 kl. 19:05 skrev Håvard hovardslill@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@alsa-project.org >>>> >>> >> > >>>> >>> >> >
Also, hda-verb /dev/snd/hwC0D0 0x20 0x500 0xc3 and hda-verb /dev/snd/hwC0D0 0x20 0x400 0x00 Makes the issue appear again!
So it seems like 0xc3 toggles it.
-Håvard
Den ons. 12. sep. 2018 kl. 22:14 skrev Håvard hovardslill@gmail.com:
Can confirm that running: hda-verb /dev/snd/hwC0D0 0x20 0x500 0xc3 and hda-verb /dev/snd/hwC0D0 0x20 0x440 0x00 Fixes the issue completely.
Thanks to everyone who helped!
-Håvard
Den ons. 12. sep. 2018 kl. 22:01 skrev Connor McAdams < conmanx360@gmail.com>:
I might not get around to writing the fix myself, but, here's the COEF's from within Windows. I've marked the ones missing inside the main init function. So, if anyone else wants to add these in, feel free.
On Wed, Sep 12, 2018 at 1:16 PM, Håvard hovardslill@gmail.com wrote:
That was without running the program (sorry)
This is output when running program:
Before there was no "Current verb...." They came when I opened up windows microphone settings. (something I
didn't
do before)
-Håvard
Den ons. 12. sep. 2018 kl. 19:11 skrev Håvard hovardslill@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.
(My first email was dissaproved as it was too large)
Den ons. 12. sep. 2018 kl. 19:05 skrev Håvard hovardslill@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@alsa-project.org >>>>> >>> >> > >>>>> >>> >> >
On Wed, 12 Sep 2018 22:17:14 +0200, Håvard wrote:
Also, hda-verb /dev/snd/hwC0D0 0x20 0x500 0xc3 and hda-verb /dev/snd/hwC0D0 0x20 0x400 0x00 Makes the issue appear again!
So it seems like 0xc3 toggles it.
Good to hear that you nailed it.
So this looks like that the alc668 headset mode would work. What happens if you pass model=alc668-headset option with 4.19-rc kernel? Does it make things working?
Takashi
-Håvard
Den ons. 12. sep. 2018 kl. 22:14 skrev Håvard hovardslill@gmail.com:
Can confirm that running: hda-verb /dev/snd/hwC0D0 0x20 0x500 0xc3 and hda-verb /dev/snd/hwC0D0 0x20 0x440 0x00 Fixes the issue completely.
Thanks to everyone who helped!
-Håvard
Den ons. 12. sep. 2018 kl. 22:01 skrev Connor McAdams < conmanx360@gmail.com>:
I might not get around to writing the fix myself, but, here's the COEF's from within Windows. I've marked the ones missing inside the main init function. So, if anyone else wants to add these in, feel free.
On Wed, Sep 12, 2018 at 1:16 PM, Håvard hovardslill@gmail.com wrote:
That was without running the program (sorry)
This is output when running program:
Before there was no "Current verb...." They came when I opened up windows microphone settings. (something I
didn't
do before)
-Håvard
Den ons. 12. sep. 2018 kl. 19:11 skrev Håvard hovardslill@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.
(My first email was dissaproved as it was too large)
Den ons. 12. sep. 2018 kl. 19:05 skrev Håvard hovardslill@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@alsa-project.org > >>>>> >>> >> > > >>>>> >>> >> >
[2 <text/html; UTF-8 (quoted-printable)>]
Hi! Sorry for late response, was doing school stuff and had problems trying to get nvidia drivers on 4.19-rc3 to work.
setting options snd-hda-intel model=alc668-headset in /etc/modprobe.d/alsa.conf on the 4.18.7-gentoo kernel it changed nothing (exept for the layout in alsamixer - that is better).
I checked the source code in sound/pci/hda/patch_realtek.c and there seems to be no difference between the code in 4.18.7 and 4.19-rc3
I could try testing more, but I am not good with sound tests without gui.
-Håvard
Den ons. 12. sep. 2018 kl. 23:16 skrev Takashi Iwai tiwai@suse.de:
On Wed, 12 Sep 2018 22:17:14 +0200, Håvard wrote:
Also, hda-verb /dev/snd/hwC0D0 0x20 0x500 0xc3 and hda-verb /dev/snd/hwC0D0 0x20 0x400 0x00 Makes the issue appear again!
So it seems like 0xc3 toggles it.
Good to hear that you nailed it.
So this looks like that the alc668 headset mode would work. What happens if you pass model=alc668-headset option with 4.19-rc kernel? Does it make things working?
Takashi
-Håvard
Den ons. 12. sep. 2018 kl. 22:14 skrev Håvard hovardslill@gmail.com:
Can confirm that running: hda-verb /dev/snd/hwC0D0 0x20 0x500 0xc3 and hda-verb /dev/snd/hwC0D0 0x20 0x440 0x00 Fixes the issue completely.
Thanks to everyone who helped!
-Håvard
Den ons. 12. sep. 2018 kl. 22:01 skrev Connor McAdams < conmanx360@gmail.com>:
I might not get around to writing the fix myself, but, here's the COEF's from within Windows. I've marked the ones missing inside the main init function. So, if anyone else wants to add these in, feel free.
On Wed, Sep 12, 2018 at 1:16 PM, Håvard hovardslill@gmail.com
wrote:
That was without running the program (sorry)
This is output when running program:
Before there was no "Current verb...." They came when I opened up windows microphone settings. (something I
didn't
do before)
-Håvard
Den ons. 12. sep. 2018 kl. 19:11 skrev Håvard <
hovardslill@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.
(My first email was dissaproved as it was too large)
Den ons. 12. sep. 2018 kl. 19:05 skrev Håvard <
hovardslill@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@alsa-project.org >> >>>>> >>> >> > >> >>>>> >>> >> >
[2 <text/html; UTF-8 (quoted-printable)>]
Also, "Mic" slider in alsamixer with model=alc668-headset does nothing, but "Mic boost"-slider still works
-Håvard
Den fre. 14. sep. 2018 kl. 17:45 skrev Håvard hovardslill@gmail.com:
Hi! Sorry for late response, was doing school stuff and had problems trying to get nvidia drivers on 4.19-rc3 to work.
setting options snd-hda-intel model=alc668-headset in /etc/modprobe.d/alsa.conf on the 4.18.7-gentoo kernel it changed nothing (exept for the layout in alsamixer - that is better).
I checked the source code in sound/pci/hda/patch_realtek.c and there seems to be no difference between the code in 4.18.7 and 4.19-rc3
I could try testing more, but I am not good with sound tests without gui.
-Håvard
Den ons. 12. sep. 2018 kl. 23:16 skrev Takashi Iwai tiwai@suse.de:
On Wed, 12 Sep 2018 22:17:14 +0200, Håvard wrote:
Also, hda-verb /dev/snd/hwC0D0 0x20 0x500 0xc3 and hda-verb /dev/snd/hwC0D0 0x20 0x400 0x00 Makes the issue appear again!
So it seems like 0xc3 toggles it.
Good to hear that you nailed it.
So this looks like that the alc668 headset mode would work. What happens if you pass model=alc668-headset option with 4.19-rc kernel? Does it make things working?
Takashi
-Håvard
Den ons. 12. sep. 2018 kl. 22:14 skrev Håvard hovardslill@gmail.com:
Can confirm that running: hda-verb /dev/snd/hwC0D0 0x20 0x500 0xc3 and hda-verb /dev/snd/hwC0D0 0x20 0x440 0x00 Fixes the issue completely.
Thanks to everyone who helped!
-Håvard
Den ons. 12. sep. 2018 kl. 22:01 skrev Connor McAdams < conmanx360@gmail.com>:
I might not get around to writing the fix myself, but, here's the COEF's from within Windows. I've marked the ones missing inside the main init function. So, if anyone else wants to add these in, feel free.
On Wed, Sep 12, 2018 at 1:16 PM, Håvard hovardslill@gmail.com
wrote:
That was without running the program (sorry)
This is output when running program:
Before there was no "Current verb...." They came when I opened up windows microphone settings. (something
I
didn't
do before)
-Håvard
Den ons. 12. sep. 2018 kl. 19:11 skrev Håvard <
hovardslill@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. > > (My first email was dissaproved as it was too large) > > Den ons. 12. sep. 2018 kl. 19:05 skrev Håvard <
hovardslill@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@alsa-project.org >>> >>>>> >>> >> > >>> >>>>> >>> >> >
[2 <text/html; UTF-8 (quoted-printable)>]
On Fri, 14 Sep 2018 17:51:14 +0200, Håvard wrote:
Also, "Mic" slider in alsamixer with model=alc668-headset does nothing, but "Mic boost"-slider still works
It's normal. The "Mic" slider means the analog loopback, so it's not about recording.
So... it's been while and I'm almost lost. How is the current situation? You tried alc668-headset option, and said that it didn't work. Is the option properly evaluated? You can check it with enabling the kernel debug messages, or replace codec_dbg() with codec_info() in snd_hda_pick_fixup().
thanks,
Takashi
-Håvard
Den fre. 14. sep. 2018 kl. 17:45 skrev Håvard hovardslill@gmail.com:
Hi! Sorry for late response, was doing school stuff and had problems trying to get nvidia drivers on 4.19-rc3 to work.
setting options snd-hda-intel model=alc668-headset in /etc/modprobe.d/alsa.conf on the 4.18.7-gentoo kernel it changed nothing (exept for the layout in alsamixer - that is better).
I checked the source code in sound/pci/hda/patch_realtek.c and there seems to be no difference between the code in 4.18.7 and 4.19-rc3
I could try testing more, but I am not good with sound tests without gui.
-Håvard
Den ons. 12. sep. 2018 kl. 23:16 skrev Takashi Iwai tiwai@suse.de:
On Wed, 12 Sep 2018 22:17:14 +0200, Håvard wrote:
Also, hda-verb /dev/snd/hwC0D0 0x20 0x500 0xc3 and hda-verb /dev/snd/hwC0D0 0x20 0x400 0x00 Makes the issue appear again!
So it seems like 0xc3 toggles it.
Good to hear that you nailed it.
So this looks like that the alc668 headset mode would work. What happens if you pass model=alc668-headset option with 4.19-rc kernel? Does it make things working?
Takashi
-Håvard
Den ons. 12. sep. 2018 kl. 22:14 skrev Håvard hovardslill@gmail.com:
Can confirm that running: hda-verb /dev/snd/hwC0D0 0x20 0x500 0xc3 and hda-verb /dev/snd/hwC0D0 0x20 0x440 0x00 Fixes the issue completely.
Thanks to everyone who helped!
-Håvard
Den ons. 12. sep. 2018 kl. 22:01 skrev Connor McAdams < conmanx360@gmail.com>:
I might not get around to writing the fix myself, but, here's the COEF's from within Windows. I've marked the ones missing inside the main init function. So, if anyone else wants to add these in, feel free.
On Wed, Sep 12, 2018 at 1:16 PM, Håvard hovardslill@gmail.com
wrote:
> That was without running the program (sorry) > > This is output when running program: > > Before there was no "Current verb...." > They came when I opened up windows microphone settings. (something
I
didn't > do before) > > -Håvard > > Den ons. 12. sep. 2018 kl. 19:11 skrev Håvard <
hovardslill@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. >> >> (My first email was dissaproved as it was too large) >> >> Den ons. 12. sep. 2018 kl. 19:05 skrev Håvard <
hovardslill@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@alsa-project.org >>>> >>>>> >>> >> > >>>> >>>>> >>> >> > http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
[2 <text/html; UTF-8 (quoted-printable)>]
Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
Hi!
Sorry it's my fault for not responding as I should have.
I originally had some problems getting the 4.19-rc kernel to work with nvidia drivers, but thanks to your email I got it working.
So here is what I found:
Not setting model=alc668-headset changed nothing
Setting model=alc668-headset Still didn't work, but made it so my "Internal microphone" in pavucontrol was plugged in, even though my headset is plugged in. Normally (and without setting model=alc668-headset) it would say "(unplugged)" when I had my microphone plugged in. And might be irrelevant, but the microphone name went from "Microphone" to "Headset microphone".
Could this be related to that my laptop has no combo headset port? I have separate inputs/outputs for mic and sound, not all in one port.
I hope we can get a fix out soon!
-Håvard
And curiously, turning on loopback only made it so the right ear could hear the output, while plain noise came from the left earpiece.
-Håvard
Den fre. 5. okt. 2018 kl. 11:56 skrev Håvard hovardslill@gmail.com:
Hi!
Sorry it's my fault for not responding as I should have.
I originally had some problems getting the 4.19-rc kernel to work with nvidia drivers, but thanks to your email I got it working.
So here is what I found:
Not setting model=alc668-headset changed nothing
Setting model=alc668-headset Still didn't work, but made it so my "Internal microphone" in pavucontrol was plugged in, even though my headset is plugged in. Normally (and without setting model=alc668-headset) it would say "(unplugged)" when I had my microphone plugged in. And might be irrelevant, but the microphone name went from "Microphone" to "Headset microphone".
Could this be related to that my laptop has no combo headset port? I have separate inputs/outputs for mic and sound, not all in one port.
I hope we can get a fix out soon!
-Håvard
This was after using the:
./hda-verb /dev/snd/hwC0D0 0x20 0x500 0xc3 ./hda-verb /dev/snd/hwC0D0 0x20 0x440 0x00
Fix that worked before, not out of the box!!
Sorry for not elaborating that better in my previous email!!
-Håvard
Den fre. 5. okt. 2018 kl. 12:00 skrev Håvard hovardslill@gmail.com:
And curiously, turning on loopback only made it so the right ear could hear the output, while plain noise came from the left earpiece.
-Håvard
Den fre. 5. okt. 2018 kl. 11:56 skrev Håvard hovardslill@gmail.com:
Hi!
Sorry it's my fault for not responding as I should have.
I originally had some problems getting the 4.19-rc kernel to work with nvidia drivers, but thanks to your email I got it working.
So here is what I found:
Not setting model=alc668-headset changed nothing
Setting model=alc668-headset Still didn't work, but made it so my "Internal microphone" in pavucontrol was plugged in, even though my headset is plugged in. Normally (and without setting model=alc668-headset) it would say "(unplugged)" when I had my microphone plugged in. And might be irrelevant, but the microphone name went from "Microphone" to "Headset microphone".
Could this be related to that my laptop has no combo headset port? I have separate inputs/outputs for mic and sound, not all in one port.
I hope we can get a fix out soon!
-Håvard
On Fri, 05 Oct 2018 12:00:30 +0200, Håvard wrote:
And curiously, turning on loopback only made it so the right ear could hear the output, while plain noise came from the left earpiece.
Maybe it's a mono mic-in.
When you record from the mic-in, do you get the signals from both left and right channels? Or it's also right-only?
Takashi
I'll try to answer your previous email first.
Everything seems identical to how it was in the 4.18-gentoo kernel when not setting the model=alc668-headset option
And using the trick we found:
./hda-verb /dev/snd/hwC0D0 0x20 0x500 0xc3 ./hda-verb /dev/snd/hwC0D0 0x20 0x440 0x00
Made it so loopback worked perfectly fine for both earpieces.
One curiosity however (this is just a small thing) is that the "base" mic level is far lower than when the "Mic" option in alsamixer is set to 100. I don't know if it was this way in 4.18-gentoo, but that's the only thing that doesnt seem correct. Here is a screenshot explaining it: http://i.imgur.com/dKPELX6.png
-Håvard
Den fre. 5. okt. 2018 kl. 12:03 skrev Takashi Iwai tiwai@suse.de:
On Fri, 05 Oct 2018 12:00:30 +0200, Håvard wrote:
And curiously, turning on loopback only made it so the right ear could
hear
the output, while plain noise came from the left earpiece.
Maybe it's a mono mic-in.
When you record from the mic-in, do you get the signals from both left and right channels? Or it's also right-only?
Takashi
It seems (as you mentioned before) that the mic volume is not decided by the "Mic" bar (it's only for loopback sound), but as you can see in the picture, even when the "Mic boost" is set to zero the "base" is still way off.
Den fre. 5. okt. 2018 kl. 12:10 skrev Håvard hovardslill@gmail.com:
I'll try to answer your previous email first.
Everything seems identical to how it was in the 4.18-gentoo kernel when not setting the model=alc668-headset option
And using the trick we found:
./hda-verb /dev/snd/hwC0D0 0x20 0x500 0xc3 ./hda-verb /dev/snd/hwC0D0 0x20 0x440 0x00
Made it so loopback worked perfectly fine for both earpieces.
One curiosity however (this is just a small thing) is that the "base" mic level is far lower than when the "Mic" option in alsamixer is set to 100. I don't know if it was this way in 4.18-gentoo, but that's the only thing that doesnt seem correct. Here is a screenshot explaining it: http://i.imgur.com/dKPELX6.png
-Håvard
Den fre. 5. okt. 2018 kl. 12:03 skrev Takashi Iwai tiwai@suse.de:
On Fri, 05 Oct 2018 12:00:30 +0200, Håvard wrote:
And curiously, turning on loopback only made it so the right ear could
hear
the output, while plain noise came from the left earpiece.
Maybe it's a mono mic-in.
When you record from the mic-in, do you get the signals from both left and right channels? Or it's also right-only?
Takashi
On Fri, 05 Oct 2018 12:10:52 +0200, Håvard wrote:
I'll try to answer your previous email first.
Everything seems identical to how it was in the 4.18-gentoo kernel when not setting the model=alc668-headset option
And using the trick we found:
./hda-verb /dev/snd/hwC0D0 0x20 0x500 0xc3 ./hda-verb /dev/snd/hwC0D0 0x20 0x440 0x00
OK, then the following patch may work. Give it a try.
Made it so loopback worked perfectly fine for both earpieces.
One curiosity however (this is just a small thing) is that the "base" mic level is far lower than when the "Mic" option in alsamixer is set to 100. I don't know if it was this way in 4.18-gentoo, but that's the only thing that doesnt seem correct. Here is a screenshot explaining it: http://i.imgur.com/dKPELX6.png
The Mic volume is only for analog loopback, so it can be normal.
Takashi
--- --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -7738,6 +7738,7 @@ enum { ALC662_FIXUP_ASUS_Nx50, ALC668_FIXUP_ASUS_Nx51_HEADSET_MODE, ALC668_FIXUP_ASUS_Nx51, + ALC668_FIXUP_ASUS_G751, ALC891_FIXUP_HEADSET_MODE, ALC891_FIXUP_DELL_MIC_NO_PRESENCE, ALC662_FIXUP_ACER_VERITON, @@ -8007,6 +8008,14 @@ static const struct hda_fixup alc662_fixups[] = { .chained = true, .chain_id = ALC668_FIXUP_ASUS_Nx51_HEADSET_MODE, }, + [ALC668_FIXUP_ASUS_G751] = { + .type = HDA_FIXUP_VERBS, + .v.verbs = (const struct hda_verb[]) { + { 0x20, AC_VERB_SET_COEF_INDEX, 0xc3 }, + { 0x20, AC_VERB_SET_PROC_COEF, 0x4000 }, + {} + }, + }, [ALC891_FIXUP_HEADSET_MODE] = { .type = HDA_FIXUP_FUNC, .v.func = alc_fixup_headset_mode, @@ -8080,6 +8089,7 @@ static const struct snd_pci_quirk alc662_fixup_tbl[] = { SND_PCI_QUIRK(0x1043, 0x11cd, "Asus N550", ALC662_FIXUP_ASUS_Nx50), SND_PCI_QUIRK(0x1043, 0x13df, "Asus N550JX", ALC662_FIXUP_BASS_1A), SND_PCI_QUIRK(0x1043, 0x129d, "Asus N750", ALC662_FIXUP_ASUS_Nx50), + SND_PCI_QUIRK(0x1043, 0x12ff, "ASUS G751", ALC668_FIXUP_ASUS_G751), SND_PCI_QUIRK(0x1043, 0x1477, "ASUS N56VZ", ALC662_FIXUP_BASS_MODE4_CHMAP), SND_PCI_QUIRK(0x1043, 0x15a7, "ASUS UX51VZH", ALC662_FIXUP_BASS_16), SND_PCI_QUIRK(0x1043, 0x177d, "ASUS N551", ALC668_FIXUP_ASUS_Nx51), @@ -8184,6 +8194,7 @@ static const struct hda_model_fixup alc662_fixup_models[] = { {.id = ALC668_FIXUP_DELL_XPS13, .name = "dell-xps13"}, {.id = ALC662_FIXUP_ASUS_Nx50, .name = "asus-nx50"}, {.id = ALC668_FIXUP_ASUS_Nx51, .name = "asus-nx51"}, + {.id = ALC668_FIXUP_ASUS_G751, .name = "asus-g751"}, {.id = ALC891_FIXUP_HEADSET_MODE, .name = "alc891-headset"}, {.id = ALC891_FIXUP_DELL_MIC_NO_PRESENCE, .name = "alc891-headset-multi"}, {.id = ALC662_FIXUP_ACER_VERITON, .name = "acer-veriton"},
Thank you so much!
Will this work for all G751 models, and will this be in the 4.19 kernel?
I am very thankful for all your hard work!!
-Håvard
Den fre. 5. okt. 2018 kl. 12:29 skrev Takashi Iwai tiwai@suse.de:
On Fri, 05 Oct 2018 12:10:52 +0200, Håvard wrote:
I'll try to answer your previous email first.
Everything seems identical to how it was in the 4.18-gentoo kernel when
not
setting the model=alc668-headset option
And using the trick we found:
./hda-verb /dev/snd/hwC0D0 0x20 0x500 0xc3 ./hda-verb /dev/snd/hwC0D0 0x20 0x440 0x00
OK, then the following patch may work. Give it a try.
Made it so loopback worked perfectly fine for both earpieces.
One curiosity however (this is just a small thing) is that the "base" mic level is far lower than when the "Mic" option in alsamixer is set to
- I
don't know if it was this way in 4.18-gentoo, but that's the only thing that doesnt seem correct. Here is a screenshot explaining it: http://i.imgur.com/dKPELX6.png
The Mic volume is only for analog loopback, so it can be normal.
Takashi
--- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -7738,6 +7738,7 @@ enum { ALC662_FIXUP_ASUS_Nx50, ALC668_FIXUP_ASUS_Nx51_HEADSET_MODE, ALC668_FIXUP_ASUS_Nx51,
ALC668_FIXUP_ASUS_G751, ALC891_FIXUP_HEADSET_MODE, ALC891_FIXUP_DELL_MIC_NO_PRESENCE, ALC662_FIXUP_ACER_VERITON,@@ -8007,6 +8008,14 @@ static const struct hda_fixup alc662_fixups[] = { .chained = true, .chain_id = ALC668_FIXUP_ASUS_Nx51_HEADSET_MODE, },
[ALC668_FIXUP_ASUS_G751] = {.type = HDA_FIXUP_VERBS,.v.verbs = (const struct hda_verb[]) {{ 0x20, AC_VERB_SET_COEF_INDEX, 0xc3 },{ 0x20, AC_VERB_SET_PROC_COEF, 0x4000 },{}},}, [ALC891_FIXUP_HEADSET_MODE] = { .type = HDA_FIXUP_FUNC, .v.func = alc_fixup_headset_mode,@@ -8080,6 +8089,7 @@ static const struct snd_pci_quirk alc662_fixup_tbl[] = { SND_PCI_QUIRK(0x1043, 0x11cd, "Asus N550", ALC662_FIXUP_ASUS_Nx50), SND_PCI_QUIRK(0x1043, 0x13df, "Asus N550JX", ALC662_FIXUP_BASS_1A), SND_PCI_QUIRK(0x1043, 0x129d, "Asus N750", ALC662_FIXUP_ASUS_Nx50),
SND_PCI_QUIRK(0x1043, 0x12ff, "ASUS G751", ALC668_FIXUP_ASUS_G751), SND_PCI_QUIRK(0x1043, 0x1477, "ASUS N56VZ",ALC662_FIXUP_BASS_MODE4_CHMAP), SND_PCI_QUIRK(0x1043, 0x15a7, "ASUS UX51VZH", ALC662_FIXUP_BASS_16), SND_PCI_QUIRK(0x1043, 0x177d, "ASUS N551", ALC668_FIXUP_ASUS_Nx51), @@ -8184,6 +8194,7 @@ static const struct hda_model_fixup alc662_fixup_models[] = { {.id = ALC668_FIXUP_DELL_XPS13, .name = "dell-xps13"}, {.id = ALC662_FIXUP_ASUS_Nx50, .name = "asus-nx50"}, {.id = ALC668_FIXUP_ASUS_Nx51, .name = "asus-nx51"},
{.id = ALC668_FIXUP_ASUS_G751, .name = "asus-g751"}, {.id = ALC891_FIXUP_HEADSET_MODE, .name = "alc891-headset"}, {.id = ALC891_FIXUP_DELL_MIC_NO_PRESENCE, .name ="alc891-headset-multi"}, {.id = ALC662_FIXUP_ACER_VERITON, .name = "acer-veriton"},
Hi!
Another issue I forgot to mention, just because I thought it was an inherent issue of the card (and it most likely is), is that when sound levels drop and/or turn off and then up/on again a little crackle goes through. This is also a very common problem under windows usage too, as many have reported hearing crackling through speakers when music starts playing. Some have got it working in windows by reinstalling drivers, but I (and many others) didn't. It is really only notable when enabling speakers, and/or purposefully dragging the volume bar fast up and down. It's not really relevant to this microphone issue, but since you asked for other problems I thought I would mention it. However if you deem it not worth the investment (which is understandable as it is only a small issue) I could open another thread specifically for this issue if it becomes a problem.
-Håvard
Den fre. 5. okt. 2018 kl. 12:31 skrev Håvard hovardslill@gmail.com:
Thank you so much!
Will this work for all G751 models, and will this be in the 4.19 kernel?
I am very thankful for all your hard work!!
-Håvard
Den fre. 5. okt. 2018 kl. 12:29 skrev Takashi Iwai tiwai@suse.de:
On Fri, 05 Oct 2018 12:10:52 +0200, Håvard wrote:
I'll try to answer your previous email first.
Everything seems identical to how it was in the 4.18-gentoo kernel when
not
setting the model=alc668-headset option
And using the trick we found:
./hda-verb /dev/snd/hwC0D0 0x20 0x500 0xc3 ./hda-verb /dev/snd/hwC0D0 0x20 0x440 0x00
OK, then the following patch may work. Give it a try.
Made it so loopback worked perfectly fine for both earpieces.
One curiosity however (this is just a small thing) is that the "base"
mic
level is far lower than when the "Mic" option in alsamixer is set to
- I
don't know if it was this way in 4.18-gentoo, but that's the only thing that doesnt seem correct. Here is a screenshot explaining it: http://i.imgur.com/dKPELX6.png
The Mic volume is only for analog loopback, so it can be normal.
Takashi
--- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -7738,6 +7738,7 @@ enum { ALC662_FIXUP_ASUS_Nx50, ALC668_FIXUP_ASUS_Nx51_HEADSET_MODE, ALC668_FIXUP_ASUS_Nx51,
ALC668_FIXUP_ASUS_G751, ALC891_FIXUP_HEADSET_MODE, ALC891_FIXUP_DELL_MIC_NO_PRESENCE, ALC662_FIXUP_ACER_VERITON,@@ -8007,6 +8008,14 @@ static const struct hda_fixup alc662_fixups[] = { .chained = true, .chain_id = ALC668_FIXUP_ASUS_Nx51_HEADSET_MODE, },
[ALC668_FIXUP_ASUS_G751] = {.type = HDA_FIXUP_VERBS,.v.verbs = (const struct hda_verb[]) {{ 0x20, AC_VERB_SET_COEF_INDEX, 0xc3 },{ 0x20, AC_VERB_SET_PROC_COEF, 0x4000 },{}},}, [ALC891_FIXUP_HEADSET_MODE] = { .type = HDA_FIXUP_FUNC, .v.func = alc_fixup_headset_mode,@@ -8080,6 +8089,7 @@ static const struct snd_pci_quirk alc662_fixup_tbl[] = { SND_PCI_QUIRK(0x1043, 0x11cd, "Asus N550", ALC662_FIXUP_ASUS_Nx50), SND_PCI_QUIRK(0x1043, 0x13df, "Asus N550JX", ALC662_FIXUP_BASS_1A), SND_PCI_QUIRK(0x1043, 0x129d, "Asus N750", ALC662_FIXUP_ASUS_Nx50),
SND_PCI_QUIRK(0x1043, 0x12ff, "ASUS G751",ALC668_FIXUP_ASUS_G751), SND_PCI_QUIRK(0x1043, 0x1477, "ASUS N56VZ", ALC662_FIXUP_BASS_MODE4_CHMAP), SND_PCI_QUIRK(0x1043, 0x15a7, "ASUS UX51VZH", ALC662_FIXUP_BASS_16), SND_PCI_QUIRK(0x1043, 0x177d, "ASUS N551", ALC668_FIXUP_ASUS_Nx51), @@ -8184,6 +8194,7 @@ static const struct hda_model_fixup alc662_fixup_models[] = { {.id = ALC668_FIXUP_DELL_XPS13, .name = "dell-xps13"}, {.id = ALC662_FIXUP_ASUS_Nx50, .name = "asus-nx50"}, {.id = ALC668_FIXUP_ASUS_Nx51, .name = "asus-nx51"},
{.id = ALC668_FIXUP_ASUS_G751, .name = "asus-g751"}, {.id = ALC891_FIXUP_HEADSET_MODE, .name = "alc891-headset"}, {.id = ALC891_FIXUP_DELL_MIC_NO_PRESENCE, .name ="alc891-headset-multi"}, {.id = ALC662_FIXUP_ACER_VERITON, .name = "acer-veriton"},
On Fri, 05 Oct 2018 12:31:37 +0200, Håvard wrote:
Thank you so much!
Will this work for all G751 models, and will this be in the 4.19 kernel?
It's only for yours (the matching PCI SSID). And it will be included only when you test the patch and confirm it working. So, please test it at first. Then I'll merge after the test rest.
thanks,
Takashi
I am very thankful for all your hard work!!
-Håvard
Den fre. 5. okt. 2018 kl. 12:29 skrev Takashi Iwai tiwai@suse.de:
On Fri, 05 Oct 2018 12:10:52 +0200, Håvard wrote:
I'll try to answer your previous email first.
Everything seems identical to how it was in the 4.18-gentoo kernel when
not
setting the model=alc668-headset option
And using the trick we found:
./hda-verb /dev/snd/hwC0D0 0x20 0x500 0xc3 ./hda-verb /dev/snd/hwC0D0 0x20 0x440 0x00
OK, then the following patch may work. Give it a try.
Made it so loopback worked perfectly fine for both earpieces.
One curiosity however (this is just a small thing) is that the "base" mic level is far lower than when the "Mic" option in alsamixer is set to
- I
don't know if it was this way in 4.18-gentoo, but that's the only thing that doesnt seem correct. Here is a screenshot explaining it: http://i.imgur.com/dKPELX6.png
The Mic volume is only for analog loopback, so it can be normal.
Takashi
--- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -7738,6 +7738,7 @@ enum { ALC662_FIXUP_ASUS_Nx50, ALC668_FIXUP_ASUS_Nx51_HEADSET_MODE, ALC668_FIXUP_ASUS_Nx51,
ALC668_FIXUP_ASUS_G751, ALC891_FIXUP_HEADSET_MODE, ALC891_FIXUP_DELL_MIC_NO_PRESENCE, ALC662_FIXUP_ACER_VERITON,@@ -8007,6 +8008,14 @@ static const struct hda_fixup alc662_fixups[] = { .chained = true, .chain_id = ALC668_FIXUP_ASUS_Nx51_HEADSET_MODE, },
[ALC668_FIXUP_ASUS_G751] = {.type = HDA_FIXUP_VERBS,.v.verbs = (const struct hda_verb[]) {{ 0x20, AC_VERB_SET_COEF_INDEX, 0xc3 },{ 0x20, AC_VERB_SET_PROC_COEF, 0x4000 },{}},}, [ALC891_FIXUP_HEADSET_MODE] = { .type = HDA_FIXUP_FUNC, .v.func = alc_fixup_headset_mode,@@ -8080,6 +8089,7 @@ static const struct snd_pci_quirk alc662_fixup_tbl[] = { SND_PCI_QUIRK(0x1043, 0x11cd, "Asus N550", ALC662_FIXUP_ASUS_Nx50), SND_PCI_QUIRK(0x1043, 0x13df, "Asus N550JX", ALC662_FIXUP_BASS_1A), SND_PCI_QUIRK(0x1043, 0x129d, "Asus N750", ALC662_FIXUP_ASUS_Nx50),
SND_PCI_QUIRK(0x1043, 0x12ff, "ASUS G751", ALC668_FIXUP_ASUS_G751), SND_PCI_QUIRK(0x1043, 0x1477, "ASUS N56VZ",ALC662_FIXUP_BASS_MODE4_CHMAP), SND_PCI_QUIRK(0x1043, 0x15a7, "ASUS UX51VZH", ALC662_FIXUP_BASS_16), SND_PCI_QUIRK(0x1043, 0x177d, "ASUS N551", ALC668_FIXUP_ASUS_Nx51), @@ -8184,6 +8194,7 @@ static const struct hda_model_fixup alc662_fixup_models[] = { {.id = ALC668_FIXUP_DELL_XPS13, .name = "dell-xps13"}, {.id = ALC662_FIXUP_ASUS_Nx50, .name = "asus-nx50"}, {.id = ALC668_FIXUP_ASUS_Nx51, .name = "asus-nx51"},
{.id = ALC668_FIXUP_ASUS_G751, .name = "asus-g751"}, {.id = ALC891_FIXUP_HEADSET_MODE, .name = "alc891-headset"}, {.id = ALC891_FIXUP_DELL_MIC_NO_PRESENCE, .name ="alc891-headset-multi"}, {.id = ALC662_FIXUP_ACER_VERITON, .name = "acer-veriton"},
[2 <text/html; UTF-8 (quoted-printable)>]
I couldn't get the patch installed automatically, so I added the changed code myself.
Everything works fine and as expected right after reboot! :) Just like we want!
I don't understand. So this won't work for other G751xx users? Or do they have to set model=asus-g751? I'm thinking of reaching out and saying it will be fixed in 4.19.
Thank you!
-Håvard
Den fre. 5. okt. 2018 kl. 14:46 skrev Takashi Iwai tiwai@suse.de:
On Fri, 05 Oct 2018 12:31:37 +0200, Håvard wrote:
Thank you so much!
Will this work for all G751 models, and will this be in the 4.19 kernel?
It's only for yours (the matching PCI SSID). And it will be included only when you test the patch and confirm it working. So, please test it at first. Then I'll merge after the test rest.
thanks,
Takashi
I am very thankful for all your hard work!!
-Håvard
Den fre. 5. okt. 2018 kl. 12:29 skrev Takashi Iwai tiwai@suse.de:
On Fri, 05 Oct 2018 12:10:52 +0200, Håvard wrote:
I'll try to answer your previous email first.
Everything seems identical to how it was in the 4.18-gentoo kernel
when
not
setting the model=alc668-headset option
And using the trick we found:
./hda-verb /dev/snd/hwC0D0 0x20 0x500 0xc3 ./hda-verb /dev/snd/hwC0D0 0x20 0x440 0x00
OK, then the following patch may work. Give it a try.
Made it so loopback worked perfectly fine for both earpieces.
One curiosity however (this is just a small thing) is that the
"base" mic
level is far lower than when the "Mic" option in alsamixer is set to
- I
don't know if it was this way in 4.18-gentoo, but that's the only
thing
that doesnt seem correct. Here is a screenshot explaining it: http://i.imgur.com/dKPELX6.png
The Mic volume is only for analog loopback, so it can be normal.
Takashi
--- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -7738,6 +7738,7 @@ enum { ALC662_FIXUP_ASUS_Nx50, ALC668_FIXUP_ASUS_Nx51_HEADSET_MODE, ALC668_FIXUP_ASUS_Nx51,
ALC668_FIXUP_ASUS_G751, ALC891_FIXUP_HEADSET_MODE, ALC891_FIXUP_DELL_MIC_NO_PRESENCE, ALC662_FIXUP_ACER_VERITON,@@ -8007,6 +8008,14 @@ static const struct hda_fixup alc662_fixups[] =
{
.chained = true, .chain_id = ALC668_FIXUP_ASUS_Nx51_HEADSET_MODE, },
[ALC668_FIXUP_ASUS_G751] = {.type = HDA_FIXUP_VERBS,.v.verbs = (const struct hda_verb[]) {{ 0x20, AC_VERB_SET_COEF_INDEX, 0xc3 },{ 0x20, AC_VERB_SET_PROC_COEF, 0x4000 },{}},}, [ALC891_FIXUP_HEADSET_MODE] = { .type = HDA_FIXUP_FUNC, .v.func = alc_fixup_headset_mode,@@ -8080,6 +8089,7 @@ static const struct snd_pci_quirk
alc662_fixup_tbl[]
= { SND_PCI_QUIRK(0x1043, 0x11cd, "Asus N550",
ALC662_FIXUP_ASUS_Nx50),
SND_PCI_QUIRK(0x1043, 0x13df, "Asus N550JX",ALC662_FIXUP_BASS_1A),
SND_PCI_QUIRK(0x1043, 0x129d, "Asus N750",ALC662_FIXUP_ASUS_Nx50),
SND_PCI_QUIRK(0x1043, 0x12ff, "ASUS G751",ALC668_FIXUP_ASUS_G751),
SND_PCI_QUIRK(0x1043, 0x1477, "ASUS N56VZ",ALC662_FIXUP_BASS_MODE4_CHMAP), SND_PCI_QUIRK(0x1043, 0x15a7, "ASUS UX51VZH", ALC662_FIXUP_BASS_16), SND_PCI_QUIRK(0x1043, 0x177d, "ASUS N551",
ALC668_FIXUP_ASUS_Nx51),
@@ -8184,6 +8194,7 @@ static const struct hda_model_fixup alc662_fixup_models[] = { {.id = ALC668_FIXUP_DELL_XPS13, .name = "dell-xps13"}, {.id = ALC662_FIXUP_ASUS_Nx50, .name = "asus-nx50"}, {.id = ALC668_FIXUP_ASUS_Nx51, .name = "asus-nx51"},
{.id = ALC668_FIXUP_ASUS_G751, .name = "asus-g751"}, {.id = ALC891_FIXUP_HEADSET_MODE, .name = "alc891-headset"}, {.id = ALC891_FIXUP_DELL_MIC_NO_PRESENCE, .name ="alc891-headset-multi"}, {.id = ALC662_FIXUP_ACER_VERITON, .name = "acer-veriton"},
[2 <text/html; UTF-8 (quoted-printable)>]
On Fri, 05 Oct 2018 21:56:20 +0200, Håvard wrote:
I couldn't get the patch installed automatically, so I added the changed code myself.
Everything works fine and as expected right after reboot! :) Just like we want!
I don't understand. So this won't work for other G751xx users? Or do they have to set model=asus-g751? I'm thinking of reaching out and saying it will be fixed in 4.19.
We need to know the exact PCI SSIDs for the matching models. Yours is 1043:12ff, and others might be different. They can be added eventually to the quirk table in the same way once when we are informed.
Since it's already a very late stage for 4.19, this fix will go into 4.20 at earliest.
thanks,
Takashi
Thank you!
-Håvard
Den fre. 5. okt. 2018 kl. 14:46 skrev Takashi Iwai tiwai@suse.de:
On Fri, 05 Oct 2018 12:31:37 +0200, Håvard wrote:
Thank you so much!
Will this work for all G751 models, and will this be in the 4.19 kernel?
It's only for yours (the matching PCI SSID). And it will be included only when you test the patch and confirm it working. So, please test it at first. Then I'll merge after the test rest.
thanks,
Takashi
I am very thankful for all your hard work!!
-Håvard
Den fre. 5. okt. 2018 kl. 12:29 skrev Takashi Iwai tiwai@suse.de:
On Fri, 05 Oct 2018 12:10:52 +0200, Håvard wrote:
I'll try to answer your previous email first.
Everything seems identical to how it was in the 4.18-gentoo kernel
when
not
setting the model=alc668-headset option
And using the trick we found:
./hda-verb /dev/snd/hwC0D0 0x20 0x500 0xc3 ./hda-verb /dev/snd/hwC0D0 0x20 0x440 0x00
OK, then the following patch may work. Give it a try.
Made it so loopback worked perfectly fine for both earpieces.
One curiosity however (this is just a small thing) is that the
"base" mic
level is far lower than when the "Mic" option in alsamixer is set to
- I
don't know if it was this way in 4.18-gentoo, but that's the only
thing
that doesnt seem correct. Here is a screenshot explaining it: http://i.imgur.com/dKPELX6.png
The Mic volume is only for analog loopback, so it can be normal.
Takashi
--- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -7738,6 +7738,7 @@ enum { ALC662_FIXUP_ASUS_Nx50, ALC668_FIXUP_ASUS_Nx51_HEADSET_MODE, ALC668_FIXUP_ASUS_Nx51,
ALC668_FIXUP_ASUS_G751, ALC891_FIXUP_HEADSET_MODE, ALC891_FIXUP_DELL_MIC_NO_PRESENCE, ALC662_FIXUP_ACER_VERITON,@@ -8007,6 +8008,14 @@ static const struct hda_fixup alc662_fixups[] =
{
.chained = true, .chain_id = ALC668_FIXUP_ASUS_Nx51_HEADSET_MODE, },
[ALC668_FIXUP_ASUS_G751] = {.type = HDA_FIXUP_VERBS,.v.verbs = (const struct hda_verb[]) {{ 0x20, AC_VERB_SET_COEF_INDEX, 0xc3 },{ 0x20, AC_VERB_SET_PROC_COEF, 0x4000 },{}},}, [ALC891_FIXUP_HEADSET_MODE] = { .type = HDA_FIXUP_FUNC, .v.func = alc_fixup_headset_mode,@@ -8080,6 +8089,7 @@ static const struct snd_pci_quirk
alc662_fixup_tbl[]
= { SND_PCI_QUIRK(0x1043, 0x11cd, "Asus N550",
ALC662_FIXUP_ASUS_Nx50),
SND_PCI_QUIRK(0x1043, 0x13df, "Asus N550JX",ALC662_FIXUP_BASS_1A),
SND_PCI_QUIRK(0x1043, 0x129d, "Asus N750",ALC662_FIXUP_ASUS_Nx50),
SND_PCI_QUIRK(0x1043, 0x12ff, "ASUS G751",ALC668_FIXUP_ASUS_G751),
SND_PCI_QUIRK(0x1043, 0x1477, "ASUS N56VZ",ALC662_FIXUP_BASS_MODE4_CHMAP), SND_PCI_QUIRK(0x1043, 0x15a7, "ASUS UX51VZH", ALC662_FIXUP_BASS_16), SND_PCI_QUIRK(0x1043, 0x177d, "ASUS N551",
ALC668_FIXUP_ASUS_Nx51),
@@ -8184,6 +8194,7 @@ static const struct hda_model_fixup alc662_fixup_models[] = { {.id = ALC668_FIXUP_DELL_XPS13, .name = "dell-xps13"}, {.id = ALC662_FIXUP_ASUS_Nx50, .name = "asus-nx50"}, {.id = ALC668_FIXUP_ASUS_Nx51, .name = "asus-nx51"},
{.id = ALC668_FIXUP_ASUS_G751, .name = "asus-g751"}, {.id = ALC891_FIXUP_HEADSET_MODE, .name = "alc891-headset"}, {.id = ALC891_FIXUP_DELL_MIC_NO_PRESENCE, .name ="alc891-headset-multi"}, {.id = ALC662_FIXUP_ACER_VERITON, .name = "acer-veriton"},
[2 <text/html; UTF-8 (quoted-printable)>]
[2 <text/html; UTF-8 (quoted-printable)>]
Ok!
Thank you very much!
So for them to work, they have to set model=asus-g751 ?
Sorry for all these questions, but I want to respond to these people as fast as possible!
-Håvard
Den lør. 6. okt. 2018 kl. 08:55 skrev Takashi Iwai tiwai@suse.de:
On Fri, 05 Oct 2018 21:56:20 +0200, Håvard wrote:
I couldn't get the patch installed automatically, so I added the changed code myself.
Everything works fine and as expected right after reboot! :) Just like we want!
I don't understand. So this won't work for other G751xx users? Or do they have to set model=asus-g751? I'm thinking of reaching out and saying it will be fixed in 4.19.
We need to know the exact PCI SSIDs for the matching models. Yours is 1043:12ff, and others might be different. They can be added eventually to the quirk table in the same way once when we are informed.
Since it's already a very late stage for 4.19, this fix will go into 4.20 at earliest.
thanks,
Takashi
Thank you!
-Håvard
Den fre. 5. okt. 2018 kl. 14:46 skrev Takashi Iwai tiwai@suse.de:
On Fri, 05 Oct 2018 12:31:37 +0200, Håvard wrote:
Thank you so much!
Will this work for all G751 models, and will this be in the 4.19
kernel?
It's only for yours (the matching PCI SSID). And it will be included only when you test the patch and confirm it working. So, please test it at first. Then I'll merge after the test rest.
thanks,
Takashi
I am very thankful for all your hard work!!
-Håvard
Den fre. 5. okt. 2018 kl. 12:29 skrev Takashi Iwai tiwai@suse.de:
On Fri, 05 Oct 2018 12:10:52 +0200, Håvard wrote:
I'll try to answer your previous email first.
Everything seems identical to how it was in the 4.18-gentoo
kernel
when
not
setting the model=alc668-headset option
And using the trick we found:
./hda-verb /dev/snd/hwC0D0 0x20 0x500 0xc3 ./hda-verb /dev/snd/hwC0D0 0x20 0x440 0x00
OK, then the following patch may work. Give it a try.
Made it so loopback worked perfectly fine for both earpieces.
One curiosity however (this is just a small thing) is that the
"base" mic
level is far lower than when the "Mic" option in alsamixer is
set to
- I
don't know if it was this way in 4.18-gentoo, but that's the only
thing
that doesnt seem correct. Here is a screenshot explaining it: http://i.imgur.com/dKPELX6.png
The Mic volume is only for analog loopback, so it can be normal.
Takashi
--- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -7738,6 +7738,7 @@ enum { ALC662_FIXUP_ASUS_Nx50, ALC668_FIXUP_ASUS_Nx51_HEADSET_MODE, ALC668_FIXUP_ASUS_Nx51,
ALC668_FIXUP_ASUS_G751, ALC891_FIXUP_HEADSET_MODE, ALC891_FIXUP_DELL_MIC_NO_PRESENCE, ALC662_FIXUP_ACER_VERITON,@@ -8007,6 +8008,14 @@ static const struct hda_fixup
alc662_fixups[] =
{
.chained = true, .chain_id = ALC668_FIXUP_ASUS_Nx51_HEADSET_MODE, },
[ALC668_FIXUP_ASUS_G751] = {.type = HDA_FIXUP_VERBS,.v.verbs = (const struct hda_verb[]) {{ 0x20, AC_VERB_SET_COEF_INDEX, 0xc3 },{ 0x20, AC_VERB_SET_PROC_COEF, 0x4000 },{}},}, [ALC891_FIXUP_HEADSET_MODE] = { .type = HDA_FIXUP_FUNC, .v.func = alc_fixup_headset_mode,@@ -8080,6 +8089,7 @@ static const struct snd_pci_quirk
alc662_fixup_tbl[]
= { SND_PCI_QUIRK(0x1043, 0x11cd, "Asus N550",
ALC662_FIXUP_ASUS_Nx50),
SND_PCI_QUIRK(0x1043, 0x13df, "Asus N550JX",ALC662_FIXUP_BASS_1A),
SND_PCI_QUIRK(0x1043, 0x129d, "Asus N750",ALC662_FIXUP_ASUS_Nx50),
SND_PCI_QUIRK(0x1043, 0x12ff, "ASUS G751",ALC668_FIXUP_ASUS_G751),
SND_PCI_QUIRK(0x1043, 0x1477, "ASUS N56VZ",ALC662_FIXUP_BASS_MODE4_CHMAP), SND_PCI_QUIRK(0x1043, 0x15a7, "ASUS UX51VZH", ALC662_FIXUP_BASS_16), SND_PCI_QUIRK(0x1043, 0x177d, "ASUS N551",
ALC668_FIXUP_ASUS_Nx51),
@@ -8184,6 +8194,7 @@ static const struct hda_model_fixup alc662_fixup_models[] = { {.id = ALC668_FIXUP_DELL_XPS13, .name = "dell-xps13"}, {.id = ALC662_FIXUP_ASUS_Nx50, .name = "asus-nx50"}, {.id = ALC668_FIXUP_ASUS_Nx51, .name = "asus-nx51"},
{.id = ALC668_FIXUP_ASUS_G751, .name = "asus-g751"}, {.id = ALC891_FIXUP_HEADSET_MODE, .name ="alc891-headset"},
{.id = ALC891_FIXUP_DELL_MIC_NO_PRESENCE, .name ="alc891-headset-multi"}, {.id = ALC662_FIXUP_ACER_VERITON, .name = "acer-veriton"},
[2 <text/html; UTF-8 (quoted-printable)>]
[2 <text/html; UTF-8 (quoted-printable)>]
On Sat, 06 Oct 2018 10:20:37 +0200, Håvard wrote:
Ok!
Thank you very much!
So for them to work, they have to set model=asus-g751 ?
They can test in that way, and they need to report their PCI SSIDs for applying the quirk as default.
Takashi
Sorry for all these questions, but I want to respond to these people as fast as possible!
-Håvard
Den lør. 6. okt. 2018 kl. 08:55 skrev Takashi Iwai tiwai@suse.de:
On Fri, 05 Oct 2018 21:56:20 +0200, Håvard wrote:
I couldn't get the patch installed automatically, so I added the changed code myself.
Everything works fine and as expected right after reboot! :) Just like we want!
I don't understand. So this won't work for other G751xx users? Or do they have to set model=asus-g751? I'm thinking of reaching out and saying it will be fixed in 4.19.
We need to know the exact PCI SSIDs for the matching models. Yours is 1043:12ff, and others might be different. They can be added eventually to the quirk table in the same way once when we are informed.
Since it's already a very late stage for 4.19, this fix will go into 4.20 at earliest.
thanks,
Takashi
Thank you!
-Håvard
Den fre. 5. okt. 2018 kl. 14:46 skrev Takashi Iwai tiwai@suse.de:
On Fri, 05 Oct 2018 12:31:37 +0200, Håvard wrote:
Thank you so much!
Will this work for all G751 models, and will this be in the 4.19
kernel?
It's only for yours (the matching PCI SSID). And it will be included only when you test the patch and confirm it working. So, please test it at first. Then I'll merge after the test rest.
thanks,
Takashi
I am very thankful for all your hard work!!
-Håvard
Den fre. 5. okt. 2018 kl. 12:29 skrev Takashi Iwai tiwai@suse.de:
On Fri, 05 Oct 2018 12:10:52 +0200, Håvard wrote: > > I'll try to answer your previous email first. > > Everything seems identical to how it was in the 4.18-gentoo
kernel
when
not > setting the model=alc668-headset option > > And using the trick we found: > > ./hda-verb /dev/snd/hwC0D0 0x20 0x500 0xc3 > ./hda-verb /dev/snd/hwC0D0 0x20 0x440 0x00
OK, then the following patch may work. Give it a try.
> Made it so loopback worked perfectly fine for both earpieces. > > One curiosity however (this is just a small thing) is that the
"base" mic
> level is far lower than when the "Mic" option in alsamixer is
set to
- I
> don't know if it was this way in 4.18-gentoo, but that's the only
thing
> that doesnt seem correct. > Here is a screenshot explaining it: > http://i.imgur.com/dKPELX6.png
The Mic volume is only for analog loopback, so it can be normal.
Takashi
--- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -7738,6 +7738,7 @@ enum { ALC662_FIXUP_ASUS_Nx50, ALC668_FIXUP_ASUS_Nx51_HEADSET_MODE, ALC668_FIXUP_ASUS_Nx51,
ALC668_FIXUP_ASUS_G751, ALC891_FIXUP_HEADSET_MODE, ALC891_FIXUP_DELL_MIC_NO_PRESENCE, ALC662_FIXUP_ACER_VERITON,@@ -8007,6 +8008,14 @@ static const struct hda_fixup
alc662_fixups[] =
{
.chained = true, .chain_id = ALC668_FIXUP_ASUS_Nx51_HEADSET_MODE, },
[ALC668_FIXUP_ASUS_G751] = {.type = HDA_FIXUP_VERBS,.v.verbs = (const struct hda_verb[]) {{ 0x20, AC_VERB_SET_COEF_INDEX, 0xc3 },{ 0x20, AC_VERB_SET_PROC_COEF, 0x4000 },{}},}, [ALC891_FIXUP_HEADSET_MODE] = { .type = HDA_FIXUP_FUNC, .v.func = alc_fixup_headset_mode,@@ -8080,6 +8089,7 @@ static const struct snd_pci_quirk
alc662_fixup_tbl[]
= { SND_PCI_QUIRK(0x1043, 0x11cd, "Asus N550",
ALC662_FIXUP_ASUS_Nx50),
SND_PCI_QUIRK(0x1043, 0x13df, "Asus N550JX",ALC662_FIXUP_BASS_1A),
SND_PCI_QUIRK(0x1043, 0x129d, "Asus N750",ALC662_FIXUP_ASUS_Nx50),
SND_PCI_QUIRK(0x1043, 0x12ff, "ASUS G751",ALC668_FIXUP_ASUS_G751),
SND_PCI_QUIRK(0x1043, 0x1477, "ASUS N56VZ",ALC662_FIXUP_BASS_MODE4_CHMAP), SND_PCI_QUIRK(0x1043, 0x15a7, "ASUS UX51VZH", ALC662_FIXUP_BASS_16), SND_PCI_QUIRK(0x1043, 0x177d, "ASUS N551",
ALC668_FIXUP_ASUS_Nx51),
@@ -8184,6 +8194,7 @@ static const struct hda_model_fixup alc662_fixup_models[] = { {.id = ALC668_FIXUP_DELL_XPS13, .name = "dell-xps13"}, {.id = ALC662_FIXUP_ASUS_Nx50, .name = "asus-nx50"}, {.id = ALC668_FIXUP_ASUS_Nx51, .name = "asus-nx51"},
{.id = ALC668_FIXUP_ASUS_G751, .name = "asus-g751"}, {.id = ALC891_FIXUP_HEADSET_MODE, .name ="alc891-headset"},
{.id = ALC891_FIXUP_DELL_MIC_NO_PRESENCE, .name ="alc891-headset-multi"}, {.id = ALC662_FIXUP_ACER_VERITON, .name = "acer-veriton"},
[2 <text/html; UTF-8 (quoted-printable)>]
[2 <text/html; UTF-8 (quoted-printable)>]
[2 <text/html; UTF-8 (quoted-printable)>]
OK!
Thank you very much for all that you have done!!
I am looking forward to seeing this in (probably) the 4.20 kernel!
-Håvard
Den lør. 6. okt. 2018 kl. 15:57 skrev Takashi Iwai tiwai@suse.de:
On Sat, 06 Oct 2018 10:20:37 +0200, Håvard wrote:
Ok!
Thank you very much!
So for them to work, they have to set model=asus-g751 ?
They can test in that way, and they need to report their PCI SSIDs for applying the quirk as default.
Takashi
Sorry for all these questions, but I want to respond to these people as fast as possible!
-Håvard
Den lør. 6. okt. 2018 kl. 08:55 skrev Takashi Iwai tiwai@suse.de:
On Fri, 05 Oct 2018 21:56:20 +0200, Håvard wrote:
I couldn't get the patch installed automatically, so I added the
changed
code myself.
Everything works fine and as expected right after reboot! :) Just
like we
want!
I don't understand. So this won't work for other G751xx users? Or do
they
have to set model=asus-g751? I'm thinking of reaching out and saying
it
will be fixed in 4.19.
We need to know the exact PCI SSIDs for the matching models. Yours is 1043:12ff, and others might be different. They can be added eventually to the quirk table in the same way once when we are informed.
Since it's already a very late stage for 4.19, this fix will go into 4.20 at earliest.
thanks,
Takashi
Thank you!
-Håvard
Den fre. 5. okt. 2018 kl. 14:46 skrev Takashi Iwai tiwai@suse.de:
On Fri, 05 Oct 2018 12:31:37 +0200, Håvard wrote:
Thank you so much!
Will this work for all G751 models, and will this be in the 4.19
kernel?
It's only for yours (the matching PCI SSID). And it will be
included
only when you test the patch and confirm it working. So, please
test
it at first. Then I'll merge after the test rest.
thanks,
Takashi
I am very thankful for all your hard work!!
-Håvard
Den fre. 5. okt. 2018 kl. 12:29 skrev Takashi Iwai <
tiwai@suse.de>:
> On Fri, 05 Oct 2018 12:10:52 +0200, > Håvard wrote: > > > > I'll try to answer your previous email first. > > > > Everything seems identical to how it was in the 4.18-gentoo
kernel
when
> not > > setting the model=alc668-headset option > > > > And using the trick we found: > > > > ./hda-verb /dev/snd/hwC0D0 0x20 0x500 0xc3 > > ./hda-verb /dev/snd/hwC0D0 0x20 0x440 0x00 > > OK, then the following patch may work. Give it a try. > > > > Made it so loopback worked perfectly fine for both earpieces. > > > > One curiosity however (this is just a small thing) is that
the
"base" mic
> > level is far lower than when the "Mic" option in alsamixer is
set to
> 100. I > > don't know if it was this way in 4.18-gentoo, but that's the
only
thing
> > that doesnt seem correct. > > Here is a screenshot explaining it: > > http://i.imgur.com/dKPELX6.png > > The Mic volume is only for analog loopback, so it can be
normal.
> > > Takashi > > --- > --- a/sound/pci/hda/patch_realtek.c > +++ b/sound/pci/hda/patch_realtek.c > @@ -7738,6 +7738,7 @@ enum { > ALC662_FIXUP_ASUS_Nx50, > ALC668_FIXUP_ASUS_Nx51_HEADSET_MODE, > ALC668_FIXUP_ASUS_Nx51, > + ALC668_FIXUP_ASUS_G751, > ALC891_FIXUP_HEADSET_MODE, > ALC891_FIXUP_DELL_MIC_NO_PRESENCE, > ALC662_FIXUP_ACER_VERITON, > @@ -8007,6 +8008,14 @@ static const struct hda_fixup
alc662_fixups[] =
{
> .chained = true, > .chain_id =
ALC668_FIXUP_ASUS_Nx51_HEADSET_MODE,
> }, > + [ALC668_FIXUP_ASUS_G751] = { > + .type = HDA_FIXUP_VERBS, > + .v.verbs = (const struct hda_verb[]) { > + { 0x20, AC_VERB_SET_COEF_INDEX, 0xc3 }, > + { 0x20, AC_VERB_SET_PROC_COEF, 0x4000
},
> + {} > + }, > + }, > [ALC891_FIXUP_HEADSET_MODE] = { > .type = HDA_FIXUP_FUNC, > .v.func = alc_fixup_headset_mode, > @@ -8080,6 +8089,7 @@ static const struct snd_pci_quirk
alc662_fixup_tbl[]
> = { > SND_PCI_QUIRK(0x1043, 0x11cd, "Asus N550",
ALC662_FIXUP_ASUS_Nx50),
> SND_PCI_QUIRK(0x1043, 0x13df, "Asus N550JX",
ALC662_FIXUP_BASS_1A),
> SND_PCI_QUIRK(0x1043, 0x129d, "Asus N750",
ALC662_FIXUP_ASUS_Nx50),
> + SND_PCI_QUIRK(0x1043, 0x12ff, "ASUS G751",
ALC668_FIXUP_ASUS_G751),
> SND_PCI_QUIRK(0x1043, 0x1477, "ASUS N56VZ", > ALC662_FIXUP_BASS_MODE4_CHMAP), > SND_PCI_QUIRK(0x1043, 0x15a7, "ASUS UX51VZH", > ALC662_FIXUP_BASS_16), > SND_PCI_QUIRK(0x1043, 0x177d, "ASUS N551",
ALC668_FIXUP_ASUS_Nx51),
> @@ -8184,6 +8194,7 @@ static const struct hda_model_fixup > alc662_fixup_models[] = { > {.id = ALC668_FIXUP_DELL_XPS13, .name = "dell-xps13"}, > {.id = ALC662_FIXUP_ASUS_Nx50, .name = "asus-nx50"}, > {.id = ALC668_FIXUP_ASUS_Nx51, .name = "asus-nx51"}, > + {.id = ALC668_FIXUP_ASUS_G751, .name = "asus-g751"}, > {.id = ALC891_FIXUP_HEADSET_MODE, .name =
"alc891-headset"},
> {.id = ALC891_FIXUP_DELL_MIC_NO_PRESENCE, .name = > "alc891-headset-multi"}, > {.id = ALC662_FIXUP_ACER_VERITON, .name =
"acer-veriton"},
> [2 <text/html; UTF-8 (quoted-printable)>]
[2 <text/html; UTF-8 (quoted-printable)>]
[2 <text/html; UTF-8 (quoted-printable)>]
I am sorry for replying once again, but since we are already fixing this, we might as well look into another one.
Many people are reporting that the headphone out port (wich is also an SPDIF out port) is not working. I can get it working by overriding pin 0x16 to Headphone in hdajackretask, but this makes the internal speakers useless.
Reports online of this issue: https://bugzilla.kernel.org/show_bug.cgi?id=190681 https://bugzilla.kernel.org/show_bug.cgi?id=106771 <- - Interesting discussion https://ubuntuforums.org/archive/index.php/t-2261149.html https://rog.asus.com/forum/showthread.php?59557-Asus-G751JY-No-sound-on-Linu... <-- Links to previous https://bbs.archlinux.org/viewtopic.php?id=213137
And, as mentioned in the last link, setting model=asus-mode5 seems to fix that issue.
I know this is much to ask, but could you take a look at this as well? It seems to affect a lot of people - I have been avoiding it by plugging my headset in the line out port, but that should be a last resort option.
-Håvard
Den lør. 6. okt. 2018 kl. 20:31 skrev Håvard hovardslill@gmail.com:
OK!
Thank you very much for all that you have done!!
I am looking forward to seeing this in (probably) the 4.20 kernel!
-Håvard
Den lør. 6. okt. 2018 kl. 15:57 skrev Takashi Iwai tiwai@suse.de:
On Sat, 06 Oct 2018 10:20:37 +0200, Håvard wrote:
Ok!
Thank you very much!
So for them to work, they have to set model=asus-g751 ?
They can test in that way, and they need to report their PCI SSIDs for applying the quirk as default.
Takashi
Sorry for all these questions, but I want to respond to these people as fast as possible!
-Håvard
Den lør. 6. okt. 2018 kl. 08:55 skrev Takashi Iwai tiwai@suse.de:
On Fri, 05 Oct 2018 21:56:20 +0200, Håvard wrote:
I couldn't get the patch installed automatically, so I added the
changed
code myself.
Everything works fine and as expected right after reboot! :) Just
like we
want!
I don't understand. So this won't work for other G751xx users? Or
do they
have to set model=asus-g751? I'm thinking of reaching out and
saying it
will be fixed in 4.19.
We need to know the exact PCI SSIDs for the matching models. Yours is 1043:12ff, and others might be different. They can be added eventually to the quirk table in the same way once when we are informed.
Since it's already a very late stage for 4.19, this fix will go into 4.20 at earliest.
thanks,
Takashi
Thank you!
-Håvard
Den fre. 5. okt. 2018 kl. 14:46 skrev Takashi Iwai tiwai@suse.de:
On Fri, 05 Oct 2018 12:31:37 +0200, Håvard wrote: > > Thank you so much! > > Will this work for all G751 models, and will this be in the 4.19
kernel?
It's only for yours (the matching PCI SSID). And it will be
included
only when you test the patch and confirm it working. So, please
test
it at first. Then I'll merge after the test rest.
thanks,
Takashi
> I am very thankful for all your hard work!! > > -Håvard > > Den fre. 5. okt. 2018 kl. 12:29 skrev Takashi Iwai <
tiwai@suse.de>:
> > > On Fri, 05 Oct 2018 12:10:52 +0200, > > Håvard wrote: > > > > > > I'll try to answer your previous email first. > > > > > > Everything seems identical to how it was in the 4.18-gentoo
kernel
when > > not > > > setting the model=alc668-headset option > > > > > > And using the trick we found: > > > > > > ./hda-verb /dev/snd/hwC0D0 0x20 0x500 0xc3 > > > ./hda-verb /dev/snd/hwC0D0 0x20 0x440 0x00 > > > > OK, then the following patch may work. Give it a try. > > > > > > > Made it so loopback worked perfectly fine for both
earpieces.
> > > > > > One curiosity however (this is just a small thing) is that
the
"base" mic > > > level is far lower than when the "Mic" option in alsamixer
is
set to
> > 100. I > > > don't know if it was this way in 4.18-gentoo, but that's
the only
thing > > > that doesnt seem correct. > > > Here is a screenshot explaining it: > > > http://i.imgur.com/dKPELX6.png > > > > The Mic volume is only for analog loopback, so it can be
normal.
> > > > > > Takashi > > > > --- > > --- a/sound/pci/hda/patch_realtek.c > > +++ b/sound/pci/hda/patch_realtek.c > > @@ -7738,6 +7738,7 @@ enum { > > ALC662_FIXUP_ASUS_Nx50, > > ALC668_FIXUP_ASUS_Nx51_HEADSET_MODE, > > ALC668_FIXUP_ASUS_Nx51, > > + ALC668_FIXUP_ASUS_G751, > > ALC891_FIXUP_HEADSET_MODE, > > ALC891_FIXUP_DELL_MIC_NO_PRESENCE, > > ALC662_FIXUP_ACER_VERITON, > > @@ -8007,6 +8008,14 @@ static const struct hda_fixup
alc662_fixups[] =
{ > > .chained = true, > > .chain_id =
ALC668_FIXUP_ASUS_Nx51_HEADSET_MODE,
> > }, > > + [ALC668_FIXUP_ASUS_G751] = { > > + .type = HDA_FIXUP_VERBS, > > + .v.verbs = (const struct hda_verb[]) { > > + { 0x20, AC_VERB_SET_COEF_INDEX, 0xc3
},
> > + { 0x20, AC_VERB_SET_PROC_COEF, 0x4000
},
> > + {} > > + }, > > + }, > > [ALC891_FIXUP_HEADSET_MODE] = { > > .type = HDA_FIXUP_FUNC, > > .v.func = alc_fixup_headset_mode, > > @@ -8080,6 +8089,7 @@ static const struct snd_pci_quirk alc662_fixup_tbl[] > > = { > > SND_PCI_QUIRK(0x1043, 0x11cd, "Asus N550", ALC662_FIXUP_ASUS_Nx50), > > SND_PCI_QUIRK(0x1043, 0x13df, "Asus N550JX", ALC662_FIXUP_BASS_1A), > > SND_PCI_QUIRK(0x1043, 0x129d, "Asus N750", ALC662_FIXUP_ASUS_Nx50), > > + SND_PCI_QUIRK(0x1043, 0x12ff, "ASUS G751", ALC668_FIXUP_ASUS_G751), > > SND_PCI_QUIRK(0x1043, 0x1477, "ASUS N56VZ", > > ALC662_FIXUP_BASS_MODE4_CHMAP), > > SND_PCI_QUIRK(0x1043, 0x15a7, "ASUS UX51VZH", > > ALC662_FIXUP_BASS_16), > > SND_PCI_QUIRK(0x1043, 0x177d, "ASUS N551", ALC668_FIXUP_ASUS_Nx51), > > @@ -8184,6 +8194,7 @@ static const struct hda_model_fixup > > alc662_fixup_models[] = { > > {.id = ALC668_FIXUP_DELL_XPS13, .name = "dell-xps13"}, > > {.id = ALC662_FIXUP_ASUS_Nx50, .name = "asus-nx50"}, > > {.id = ALC668_FIXUP_ASUS_Nx51, .name = "asus-nx51"}, > > + {.id = ALC668_FIXUP_ASUS_G751, .name = "asus-g751"}, > > {.id = ALC891_FIXUP_HEADSET_MODE, .name =
"alc891-headset"},
> > {.id = ALC891_FIXUP_DELL_MIC_NO_PRESENCE, .name = > > "alc891-headset-multi"}, > > {.id = ALC662_FIXUP_ACER_VERITON, .name =
"acer-veriton"},
> > > [2 <text/html; UTF-8 (quoted-printable)>] >
[2 <text/html; UTF-8 (quoted-printable)>]
[2 <text/html; UTF-8 (quoted-printable)>]
And the mic configuration mentioned here in comment #3 seems to work:
https://answers.launchpad.net/ubuntu/+source/alsa-driver/+question/261148
I am "Hiklo" in the last comment of the thread.
-Håvard
Den man. 8. okt. 2018 kl. 14:05 skrev Håvard hovardslill@gmail.com:
I am sorry for replying once again, but since we are already fixing this, we might as well look into another one.
Many people are reporting that the headphone out port (wich is also an SPDIF out port) is not working. I can get it working by overriding pin 0x16 to Headphone in hdajackretask, but this makes the internal speakers useless.
Reports online of this issue: https://bugzilla.kernel.org/show_bug.cgi?id=190681 https://bugzilla.kernel.org/show_bug.cgi?id=106771 <- - Interesting discussion https://ubuntuforums.org/archive/index.php/t-2261149.html
https://rog.asus.com/forum/showthread.php?59557-Asus-G751JY-No-sound-on-Linu... <-- Links to previous https://bbs.archlinux.org/viewtopic.php?id=213137
And, as mentioned in the last link, setting model=asus-mode5 seems to fix that issue.
I know this is much to ask, but could you take a look at this as well? It seems to affect a lot of people - I have been avoiding it by plugging my headset in the line out port, but that should be a last resort option.
-Håvard
Den lør. 6. okt. 2018 kl. 20:31 skrev Håvard hovardslill@gmail.com:
OK!
Thank you very much for all that you have done!!
I am looking forward to seeing this in (probably) the 4.20 kernel!
-Håvard
Den lør. 6. okt. 2018 kl. 15:57 skrev Takashi Iwai tiwai@suse.de:
On Sat, 06 Oct 2018 10:20:37 +0200, Håvard wrote:
Ok!
Thank you very much!
So for them to work, they have to set model=asus-g751 ?
They can test in that way, and they need to report their PCI SSIDs for applying the quirk as default.
Takashi
Sorry for all these questions, but I want to respond to these people as fast as possible!
-Håvard
Den lør. 6. okt. 2018 kl. 08:55 skrev Takashi Iwai tiwai@suse.de:
On Fri, 05 Oct 2018 21:56:20 +0200, Håvard wrote:
I couldn't get the patch installed automatically, so I added the
changed
code myself.
Everything works fine and as expected right after reboot! :) Just
like we
want!
I don't understand. So this won't work for other G751xx users? Or
do they
have to set model=asus-g751? I'm thinking of reaching out and
saying it
will be fixed in 4.19.
We need to know the exact PCI SSIDs for the matching models. Yours is 1043:12ff, and others might be different. They can be added eventually to the quirk table in the same way once when we are informed.
Since it's already a very late stage for 4.19, this fix will go into 4.20 at earliest.
thanks,
Takashi
Thank you!
-Håvard
Den fre. 5. okt. 2018 kl. 14:46 skrev Takashi Iwai <tiwai@suse.de
:
> On Fri, 05 Oct 2018 12:31:37 +0200, > Håvard wrote: > > > > Thank you so much! > > > > Will this work for all G751 models, and will this be in the
4.19
kernel?
> > It's only for yours (the matching PCI SSID). And it will be
included
> only when you test the patch and confirm it working. So, please
test
> it at first. Then I'll merge after the test rest. > > > thanks, > > Takashi > > > > I am very thankful for all your hard work!! > > > > -Håvard > > > > Den fre. 5. okt. 2018 kl. 12:29 skrev Takashi Iwai <
tiwai@suse.de>:
> > > > > On Fri, 05 Oct 2018 12:10:52 +0200, > > > Håvard wrote: > > > > > > > > I'll try to answer your previous email first. > > > > > > > > Everything seems identical to how it was in the 4.18-gentoo
kernel
> when > > > not > > > > setting the model=alc668-headset option > > > > > > > > And using the trick we found: > > > > > > > > ./hda-verb /dev/snd/hwC0D0 0x20 0x500 0xc3 > > > > ./hda-verb /dev/snd/hwC0D0 0x20 0x440 0x00 > > > > > > OK, then the following patch may work. Give it a try. > > > > > > > > > > Made it so loopback worked perfectly fine for both
earpieces.
> > > > > > > > One curiosity however (this is just a small thing) is that
the
> "base" mic > > > > level is far lower than when the "Mic" option in alsamixer
is
set to
> > > 100. I > > > > don't know if it was this way in 4.18-gentoo, but that's
the only
> thing > > > > that doesnt seem correct. > > > > Here is a screenshot explaining it: > > > > http://i.imgur.com/dKPELX6.png > > > > > > The Mic volume is only for analog loopback, so it can be
normal.
> > > > > > > > > Takashi > > > > > > --- > > > --- a/sound/pci/hda/patch_realtek.c > > > +++ b/sound/pci/hda/patch_realtek.c > > > @@ -7738,6 +7738,7 @@ enum { > > > ALC662_FIXUP_ASUS_Nx50, > > > ALC668_FIXUP_ASUS_Nx51_HEADSET_MODE, > > > ALC668_FIXUP_ASUS_Nx51, > > > + ALC668_FIXUP_ASUS_G751, > > > ALC891_FIXUP_HEADSET_MODE, > > > ALC891_FIXUP_DELL_MIC_NO_PRESENCE, > > > ALC662_FIXUP_ACER_VERITON, > > > @@ -8007,6 +8008,14 @@ static const struct hda_fixup
alc662_fixups[] =
> { > > > .chained = true, > > > .chain_id =
ALC668_FIXUP_ASUS_Nx51_HEADSET_MODE,
> > > }, > > > + [ALC668_FIXUP_ASUS_G751] = { > > > + .type = HDA_FIXUP_VERBS, > > > + .v.verbs = (const struct hda_verb[]) { > > > + { 0x20, AC_VERB_SET_COEF_INDEX, 0xc3
},
> > > + { 0x20, AC_VERB_SET_PROC_COEF,
0x4000 },
> > > + {} > > > + }, > > > + }, > > > [ALC891_FIXUP_HEADSET_MODE] = { > > > .type = HDA_FIXUP_FUNC, > > > .v.func = alc_fixup_headset_mode, > > > @@ -8080,6 +8089,7 @@ static const struct snd_pci_quirk > alc662_fixup_tbl[] > > > = { > > > SND_PCI_QUIRK(0x1043, 0x11cd, "Asus N550", > ALC662_FIXUP_ASUS_Nx50), > > > SND_PCI_QUIRK(0x1043, 0x13df, "Asus N550JX", > ALC662_FIXUP_BASS_1A), > > > SND_PCI_QUIRK(0x1043, 0x129d, "Asus N750", > ALC662_FIXUP_ASUS_Nx50), > > > + SND_PCI_QUIRK(0x1043, 0x12ff, "ASUS G751", > ALC668_FIXUP_ASUS_G751), > > > SND_PCI_QUIRK(0x1043, 0x1477, "ASUS N56VZ", > > > ALC662_FIXUP_BASS_MODE4_CHMAP), > > > SND_PCI_QUIRK(0x1043, 0x15a7, "ASUS UX51VZH", > > > ALC662_FIXUP_BASS_16), > > > SND_PCI_QUIRK(0x1043, 0x177d, "ASUS N551", > ALC668_FIXUP_ASUS_Nx51), > > > @@ -8184,6 +8194,7 @@ static const struct hda_model_fixup > > > alc662_fixup_models[] = { > > > {.id = ALC668_FIXUP_DELL_XPS13, .name =
"dell-xps13"},
> > > {.id = ALC662_FIXUP_ASUS_Nx50, .name = "asus-nx50"}, > > > {.id = ALC668_FIXUP_ASUS_Nx51, .name = "asus-nx51"}, > > > + {.id = ALC668_FIXUP_ASUS_G751, .name = "asus-g751"}, > > > {.id = ALC891_FIXUP_HEADSET_MODE, .name =
"alc891-headset"},
> > > {.id = ALC891_FIXUP_DELL_MIC_NO_PRESENCE, .name = > > > "alc891-headset-multi"}, > > > {.id = ALC662_FIXUP_ACER_VERITON, .name =
"acer-veriton"},
> > > > > [2 <text/html; UTF-8 (quoted-printable)>] > > > [2 <text/html; UTF-8 (quoted-printable)>]
[2 <text/html; UTF-8 (quoted-printable)>]
On Mon, 08 Oct 2018 14:05:22 +0200, Håvard wrote:
I am sorry for replying once again, but since we are already fixing this, we might as well look into another one.
Another one is another one. No need to continue this too lengthy thread.
So, just start a new thread, involve the right people in Cc so that we can continue working on it. Picking up random bugzilla entries won't drive us in a better way, unfortunately.
And, don't forget: people dislike top-posting :)
thanks,
Takashi
Many people are reporting that the headphone out port (wich is also an SPDIF out port) is not working. I can get it working by overriding pin 0x16 to Headphone in hdajackretask, but this makes the internal speakers useless.
Reports online of this issue: https://bugzilla.kernel.org/show_bug.cgi?id=190681 https://bugzilla.kernel.org/show_bug.cgi?id=106771 <- - Interesting discussion https://ubuntuforums.org/archive/index.php/t-2261149.html https://rog.asus.com/forum/showthread.php?59557-Asus-G751JY-No-sound-on-Linu... <-- Links to previous https://bbs.archlinux.org/viewtopic.php?id=213137
And, as mentioned in the last link, setting model=asus-mode5 seems to fix that issue.
I know this is much to ask, but could you take a look at this as well? It seems to affect a lot of people - I have been avoiding it by plugging my headset in the line out port, but that should be a last resort option.
-Håvard
Den lør. 6. okt. 2018 kl. 20:31 skrev Håvard hovardslill@gmail.com:
OK!
Thank you very much for all that you have done!!
I am looking forward to seeing this in (probably) the 4.20 kernel!
-Håvard
Den lør. 6. okt. 2018 kl. 15:57 skrev Takashi Iwai tiwai@suse.de:
On Sat, 06 Oct 2018 10:20:37 +0200, Håvard wrote:
Ok!
Thank you very much!
So for them to work, they have to set model=asus-g751 ?
They can test in that way, and they need to report their PCI SSIDs for applying the quirk as default.
Takashi
Sorry for all these questions, but I want to respond to these people as fast as possible!
-Håvard
Den lør. 6. okt. 2018 kl. 08:55 skrev Takashi Iwai tiwai@suse.de:
On Fri, 05 Oct 2018 21:56:20 +0200, Håvard wrote:
I couldn't get the patch installed automatically, so I added the
changed
code myself.
Everything works fine and as expected right after reboot! :) Just
like we
want!
I don't understand. So this won't work for other G751xx users? Or
do they
have to set model=asus-g751? I'm thinking of reaching out and
saying it
will be fixed in 4.19.
We need to know the exact PCI SSIDs for the matching models. Yours is 1043:12ff, and others might be different. They can be added eventually to the quirk table in the same way once when we are informed.
Since it's already a very late stage for 4.19, this fix will go into 4.20 at earliest.
thanks,
Takashi
Thank you!
-Håvard
Den fre. 5. okt. 2018 kl. 14:46 skrev Takashi Iwai tiwai@suse.de:
> On Fri, 05 Oct 2018 12:31:37 +0200, > Håvard wrote: > > > > Thank you so much! > > > > Will this work for all G751 models, and will this be in the 4.19
kernel?
> > It's only for yours (the matching PCI SSID). And it will be
included
> only when you test the patch and confirm it working. So, please
test
> it at first. Then I'll merge after the test rest. > > > thanks, > > Takashi > > > > I am very thankful for all your hard work!! > > > > -Håvard > > > > Den fre. 5. okt. 2018 kl. 12:29 skrev Takashi Iwai <
tiwai@suse.de>:
> > > > > On Fri, 05 Oct 2018 12:10:52 +0200, > > > Håvard wrote: > > > > > > > > I'll try to answer your previous email first. > > > > > > > > Everything seems identical to how it was in the 4.18-gentoo
kernel
> when > > > not > > > > setting the model=alc668-headset option > > > > > > > > And using the trick we found: > > > > > > > > ./hda-verb /dev/snd/hwC0D0 0x20 0x500 0xc3 > > > > ./hda-verb /dev/snd/hwC0D0 0x20 0x440 0x00 > > > > > > OK, then the following patch may work. Give it a try. > > > > > > > > > > Made it so loopback worked perfectly fine for both
earpieces.
> > > > > > > > One curiosity however (this is just a small thing) is that
the
> "base" mic > > > > level is far lower than when the "Mic" option in alsamixer
is
set to
> > > 100. I > > > > don't know if it was this way in 4.18-gentoo, but that's
the only
> thing > > > > that doesnt seem correct. > > > > Here is a screenshot explaining it: > > > > http://i.imgur.com/dKPELX6.png > > > > > > The Mic volume is only for analog loopback, so it can be
normal.
> > > > > > > > > Takashi > > > > > > --- > > > --- a/sound/pci/hda/patch_realtek.c > > > +++ b/sound/pci/hda/patch_realtek.c > > > @@ -7738,6 +7738,7 @@ enum { > > > ALC662_FIXUP_ASUS_Nx50, > > > ALC668_FIXUP_ASUS_Nx51_HEADSET_MODE, > > > ALC668_FIXUP_ASUS_Nx51, > > > + ALC668_FIXUP_ASUS_G751, > > > ALC891_FIXUP_HEADSET_MODE, > > > ALC891_FIXUP_DELL_MIC_NO_PRESENCE, > > > ALC662_FIXUP_ACER_VERITON, > > > @@ -8007,6 +8008,14 @@ static const struct hda_fixup
alc662_fixups[] =
> { > > > .chained = true, > > > .chain_id =
ALC668_FIXUP_ASUS_Nx51_HEADSET_MODE,
> > > }, > > > + [ALC668_FIXUP_ASUS_G751] = { > > > + .type = HDA_FIXUP_VERBS, > > > + .v.verbs = (const struct hda_verb[]) { > > > + { 0x20, AC_VERB_SET_COEF_INDEX, 0xc3
},
> > > + { 0x20, AC_VERB_SET_PROC_COEF, 0x4000
},
> > > + {} > > > + }, > > > + }, > > > [ALC891_FIXUP_HEADSET_MODE] = { > > > .type = HDA_FIXUP_FUNC, > > > .v.func = alc_fixup_headset_mode, > > > @@ -8080,6 +8089,7 @@ static const struct snd_pci_quirk > alc662_fixup_tbl[] > > > = { > > > SND_PCI_QUIRK(0x1043, 0x11cd, "Asus N550", > ALC662_FIXUP_ASUS_Nx50), > > > SND_PCI_QUIRK(0x1043, 0x13df, "Asus N550JX", > ALC662_FIXUP_BASS_1A), > > > SND_PCI_QUIRK(0x1043, 0x129d, "Asus N750", > ALC662_FIXUP_ASUS_Nx50), > > > + SND_PCI_QUIRK(0x1043, 0x12ff, "ASUS G751", > ALC668_FIXUP_ASUS_G751), > > > SND_PCI_QUIRK(0x1043, 0x1477, "ASUS N56VZ", > > > ALC662_FIXUP_BASS_MODE4_CHMAP), > > > SND_PCI_QUIRK(0x1043, 0x15a7, "ASUS UX51VZH", > > > ALC662_FIXUP_BASS_16), > > > SND_PCI_QUIRK(0x1043, 0x177d, "ASUS N551", > ALC668_FIXUP_ASUS_Nx51), > > > @@ -8184,6 +8194,7 @@ static const struct hda_model_fixup > > > alc662_fixup_models[] = { > > > {.id = ALC668_FIXUP_DELL_XPS13, .name = "dell-xps13"}, > > > {.id = ALC662_FIXUP_ASUS_Nx50, .name = "asus-nx50"}, > > > {.id = ALC668_FIXUP_ASUS_Nx51, .name = "asus-nx51"}, > > > + {.id = ALC668_FIXUP_ASUS_G751, .name = "asus-g751"}, > > > {.id = ALC891_FIXUP_HEADSET_MODE, .name =
"alc891-headset"},
> > > {.id = ALC891_FIXUP_DELL_MIC_NO_PRESENCE, .name = > > > "alc891-headset-multi"}, > > > {.id = ALC662_FIXUP_ACER_VERITON, .name =
"acer-veriton"},
> > > > > [2 <text/html; UTF-8 (quoted-printable)>] > > > [2 <text/html; UTF-8 (quoted-printable)>]
[2 <text/html; UTF-8 (quoted-printable)>]
[2 <text/html; UTF-8 (quoted-printable)>]
On Fri, 05 Oct 2018 11:56:06 +0200, Håvard wrote:
Hi!
Sorry it's my fault for not responding as I should have.
I originally had some problems getting the 4.19-rc kernel to work with nvidia drivers, but thanks to your email I got it working.
So here is what I found:
Not setting model=alc668-headset changed nothing
Setting model=alc668-headset Still didn't work, but made it so my "Internal microphone" in pavucontrol was plugged in, even though my headset is plugged in. Normally (and without setting model=alc668-headset) it would say "(unplugged)" when I had my microphone plugged in. And might be irrelevant, but the microphone name went from "Microphone" to "Headset microphone".
Could this be related to that my laptop has no combo headset port? I have separate inputs/outputs for mic and sound, not all in one port.
OK, that sounds like a reasonable explanation.
Is anything else missing if you load *without* model option (i.e. the system as-is)? Basically it's easy to add a quirk only applying the COEF verbs you've found, but we should fix other things as well if we play with quirk table.
thanks,
Takashi
On Fri, 14 Sep 2018 17:45:39 +0200, Håvard wrote:
Hi! Sorry for late response, was doing school stuff and had problems trying to get nvidia drivers on 4.19-rc3 to work.
setting options snd-hda-intel model=alc668-headset in /etc/modprobe.d/alsa.conf on the 4.18.7-gentoo kernel it changed nothing (exept for the layout in alsamixer - that is better).
I checked the source code in sound/pci/hda/patch_realtek.c and there seems to be no difference between the code in 4.18.7 and 4.19-rc3
There is a difference, and this option didn't take effect on 4.18. You need 4.19-rc for allowing that option.
Takashi
I could try testing more, but I am not good with sound tests without gui.
-Håvard
Den ons. 12. sep. 2018 kl. 23:16 skrev Takashi Iwai tiwai@suse.de:
On Wed, 12 Sep 2018 22:17:14 +0200, Håvard wrote:
Also, hda-verb /dev/snd/hwC0D0 0x20 0x500 0xc3 and hda-verb /dev/snd/hwC0D0 0x20 0x400 0x00 Makes the issue appear again!
So it seems like 0xc3 toggles it.
Good to hear that you nailed it.
So this looks like that the alc668 headset mode would work. What happens if you pass model=alc668-headset option with 4.19-rc kernel? Does it make things working?
Takashi
-Håvard
Den ons. 12. sep. 2018 kl. 22:14 skrev Håvard hovardslill@gmail.com:
Can confirm that running: hda-verb /dev/snd/hwC0D0 0x20 0x500 0xc3 and hda-verb /dev/snd/hwC0D0 0x20 0x440 0x00 Fixes the issue completely.
Thanks to everyone who helped!
-Håvard
Den ons. 12. sep. 2018 kl. 22:01 skrev Connor McAdams < conmanx360@gmail.com>:
I might not get around to writing the fix myself, but, here's the COEF's from within Windows. I've marked the ones missing inside the main init function. So, if anyone else wants to add these in, feel free.
On Wed, Sep 12, 2018 at 1:16 PM, Håvard hovardslill@gmail.com
wrote:
That was without running the program (sorry)
This is output when running program:
Before there was no "Current verb...." They came when I opened up windows microphone settings. (something I
didn't
do before)
-Håvard
Den ons. 12. sep. 2018 kl. 19:11 skrev Håvard <
hovardslill@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. > > (My first email was dissaproved as it was too large) > > Den ons. 12. sep. 2018 kl. 19:05 skrev Håvard <
hovardslill@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@alsa-project.org >>> >>>>> >>> >> > >>> >>>>> >>> >> >
[2 <text/html; UTF-8 (quoted-printable)>]
[2 <text/html; UTF-8 (quoted-printable)>]
participants (3)
-
Connor McAdams -
Håvard -
Takashi Iwai