No Input Signal from my Internal Microphones

English Multimedia
21

oldcpu, deano,
YaST - I’m learning the hard way!

oldcpu,
whilst your suggestion was clean, it gave me no sound, so I added the model option:

[INDENT=2]options snd slots=snd-hda-intel,snd-hda-intel
# nS1_.4iMtSV4J9L1:Comet Lake PCH cAVS
options snd_hda_intel index=0 vid=8086 pid=06c8 model=dual-codecs
alias snd-card-0 snd-hda-intel
# NXNs.Q5mfEK148i4:TU106 High Definition Audio Controller
options snd_hda_intel index=1 vid=10de pid=10f9 model=dual-codecs
alias snd-card-1 snd-hda-intel
[/INDENT]


 and that did work

I ran the alsa-info command you gave me (as ordinary user), the result is at: http://alsa-project.org/db/?f=aa7a99b8a0788fb1790a6a09da06e40cd0e57aac

There are oddities, I need to unmute the Headphone channel (in alsamixer) and use that as if it is Master to get output sound. For the microphone I need to amixer the Rear-Panel (toggle then use alsamixer) and flip the Input source to Internal Mic (maybe need to go back, toggle to "Mic", and retest. I still get the noise when recording which I think comes from the system itself (my typing sounds like serious pounding), I'm hoping the combination headphones will fix that.

Many thanks for your observations

regards
stevetom

22

Maybe old problem with ALC1220 recording:

https://bugzilla.kernel.org/show_bug.cgi?id=195303
Bug #1801540 “Microphone distorted sound on ALC892/1220 on AMD c...” : Bugs : pulseaudio package : Ubuntu

Audio playback seems to be fine, however audio capture results in crackling.

  • all values of position_fix have been tried and do not help
  • power_save=0 does not help
  • align_buffer_size does not help
  • enable_msi does not help

Hardware is onboard ALC1220 codec sound chipset on the ASUS Crosshair VI Hero motherboard.

Cured by SUSE’s Takashi Iwai, but maybe resurface again.

23

svyatko,

hmm… Leap 15.1 kernel is 5.5.7-1-default so after the fix but I note the comments that “maybe it has come back again”… there were a lot of tentative things to try in the discussions but they seem to delve into stuff where I would be very “out of my depth” and so they do not seem a good path for me. In any case, I get the impression that the noise is the actual sound of the physical system itself (my keyboard strokes are a resounding “thump”) i.e. not the reported crackling, but hopefully using my headset/microphone will remove that as a problem. But many thanks for the results of your researches.

regards
stevetom

24

Hmmm - it did not thou work the way I intended. I wanted the PCH to be index=0 and hence PCH be card 0 … and I wanted NVIDIA to be index=1 and hence NIVIDIA be card-1. What I had ‘wanted’ (expected) did not take place.

I note that script output has:


!!Soundcards recognised by ALSA
!!-----------------------------

 0 [NVidia         ]: HDA-Intel - HDA NVidia
                      HDA NVidia at 0xa1000000 irq 17
 1 [PCH            ]: HDA-Intel - HDA Intel PCH
                      HDAudio-Gigabyte-ALC1220DualCodecs

i.e NIVIDA as card-0 and PCH is card-1 - further the script has:


!!Aplay/Arecord output
!!--------------------

APLAY

**** List of PLAYBACK Hardware Devices ****
card 0: NVidia [HDA NVidia], device 3: HDMI 0 [HDMI 0]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
.....
snipped 
.....
card 1: PCH [HDA Intel PCH], device 0: ALC1220 Analog [ALC1220 Analog]
  Subdevices: 0/1
  Subdevice #0: subdevice #0

… again it has NVidia as card-0 and PCH as card-1.

Further it has


ARECORD

**** List of CAPTURE Hardware Devices ****
card 1: PCH [HDA Intel PCH], device 0: ALC1220 Analog [ALC1220 Analog]
  Subdevices: 1/1
  Subdevice #0: subdevice #0

ie. PCH is card-1.

i.e. your PC has NVIDIA as card-0 (index=0) and has PCH as card-1 (index=1).

The dmesg output makes that clear:


   17.406185] snd_hda_intel: unknown parameter 'vid' ignored
   17.406186] snd_hda_intel: unknown parameter 'pid' ignored
   17.406188] snd_hda_intel: unknown parameter 'vid' ignored
   17.406188] snd_hda_intel: unknown parameter 'pid' ignored

This has me wondering if the syntax needed for vid and pid assignments has changed.

Or possibly that by adding the “model=dual-codecs” entry that the PID and VID entries are ignored.

This “model=dual-codecs” model entry is new to me. I had not seen that in use before. Researching this now I note this : HD-Audio Codec-Specific Models — The Linux Kernel documentation

where according to that entry for the ALC1220 ‘dual-codecs’ can be used for


dual-codecs
    ALC1220 dual codecs for Gaming mobos

but as to exactly what ‘dual-codecs’ does and as to why the VID and PID entries were ignored is not clear to me.
.

25

The supported parameters for a given module can be got via

modinfo -p snd-hda-intel

I remember an old thread I helped with on a similar issue

The ‘id=’ option might work here…something like this perhaps…

options snd_hda_intel id=NVidia model=dual-codecs index=1
options snd_hda_intel id=PCH model=dual-codecs index=0
26

https://bbs.archlinux.org/viewtopic.php?id=241469

Dual ALC 1220 with Front & Rear 120dB SNR HD Audio with Dual Smart Headphone Amps

Audio 2 x Realtek® ALC1220 codecs

2 codecs instead of one to enhance sound quality and squeeze out extra money from not so clever buyers of a “gaming” gizmos.

IMHO OP have no this stuff, so don’t use this parameter.

27

deano,

 the id attribute  made no difference as far as I can tell - the card order remains the same, and once I unmute the "headphones" in alsamixer, the speakers then work. The aplay -l looks very strange. If you really want an alsa-info I can provide it, but now I'm going to deep dive into documentation so might be quiet for a day or so. As far as I'm concerned, sound output works, it might not be pretty but from a pragmatic pov I'm happy so far.

thanks and regards
stevetom

28

oldcpu,
many thanks for that documentation reference - or rather the library it is part of - I shall try to educate myself before groping further!

regards
stevetom

29

svyatko, oldcpu, deano (in order of appearance)

thank you for your interest in my microphone/sound “opportunity”. I’ve been doing some reading, apart from following your published words and links, the following are my primary references so far:

https://www.kernel.org/doc/html/latest/sound/index.html
a little too low level for me, my C skills are many years behind me, but this reference does have some titbits I can use.
From the above documentation:
*/proc/asound/
the next are from the kernel source (after searching for “dual-codecs”):
*/usr/src/linux/Documentation/sound/hd-audio/models.rst
/usr/src/linux/Documentation/sound/hd-audio/notes.rst
/usr/*src/linux/sound/pci/hda/patch_realtek.c
(I note that the kernel documentation, the hd-audio notes and the patch reference from svyatko, are all by Takashi Iwai.)

The notes explain the use of the modprobe.d/50-sound.conf: options: model:

“The most common problem regarding the HD-audio driver is the
unsupported codec features or the mismatched device configuration.
Most of codec-specific code has several preset models, either to
override the BIOS setup or to provide more comprehensive features.”

“What model option values are available depends on the codec chip.
Check your codec chip from the codec proc file (see “Codec Proc-File”
section below). It will show the vendor/product name of your codec
chip. Then, see Documentation/sound/hd-audio/models.rst file,
the section of HD-audio driver. You can find a list of codecs
and model options belonging to each codec.”

Inspection of the patch_realtek.c code shows that “dual-codecs” does little more than rename a couple of pins/sound-channels – what else the patch may do has not yet been investigated.

From a pragmatic point of view, sound output is fine (my core priority), but sound input is also important and might be fixed by resolving some curiosities:
inability to make the PCH card index=0 when second card added
actual function of each of the alsamixer sound-channel labels
To that end, I intend to do a number of tests and review results from each subtest:
Test: no cards, single card, two cards
Sub-test: init 3, gnome, YaST
assumptions:
start point for all tests: either to (init) multi-user or graphical
all changes via reboot and runlevel: multi-user ie CLI
YaST → Hardware → Sound – changes created with no → Volume?
YaST → Hardware → Sound → Volume – changes created with no edit
use amixer commands before reboot to ensure sane control settings

outputs:
*/etc/modprobe/50-sound.conf

*/*proc/asound/ - various directories & files
various asound commands

any comments, observations, or other advice?

regards
stevetom

30

I’m still puzzling over the VID/PID assignments. I thought they worked for the snd_hda_intel modules, but maybe my memory has failed me.

As a further note, which may (or may not) be relevant to this thread, one of my desktop PCs has 3 sound devices, where two are associated with the motherboard Intel chipset (PCH/HDMI) and a 3rd associated with a USB webcam.

Normally, if I boot my PC with no 50-sound.conf file, my order of devices is:

  • card-0: HDMI
  • card-1: PCH
  • card-2: USB device

.
If I apply this simple edit to the /etc/modprobe.d/50-sound.conf file I can change the HDMI/PCH order of devices to the following:


options snd-hda-intel index=1,0

which yields:

  • card-0: PCH
  • card-1: HDMI
  • card-2: USB device

Further, if I apply this simple edit, I can change the order of devices making the USB card-0:


options snd-hda-intel index=2,1

which yields:

  • card-0: USB device
  • card-1: PCH
  • card-2: HDMI

The above works on my PC under the assumption that the PCI detection order is fixed and that the card/USB device detection is stable. Fortunately on my PC it is stable. However I have read of other users where the detection is not stable, and that causes them problems.

Fortunately, in today’s GNU/Linux, with pulse audio and ‘pavucontrol’ application, the order of devices is not so important, as pulse audio can direct the audio as required, with ‘pavucontrol’ providing the user the needed control.
.

31

I should add to the above, with different order of devices in the "index= … " in the 50-sound.conf, which can change the sound card assignments, one may need to tune pulse audio via pavucontrol afterward, to ensure sound from an application goes to the correct sound device.

32

I also remember a time when they were valid…but not now…

# modinfo -p snd-hda-intel
index:Index value for Intel HD audio interface. (array of int)
id:ID string for Intel HD audio interface. (array of charp)
enable:Enable Intel HD audio interface. (array of bool)
model:Use the given board model. (array of charp)
position_fix:DMA pointer read method.(-1 = system default, 0 = auto, 1 = LPIB, 2 = POSBUF, 3 = VIACOMBO, 4 = COMBO, 5 = SKL+, 6 = FIFO). (array of int)
bdl_pos_adj:BDL position adjustment offset. (array of int)
probe_mask:Bitmask to probe codecs (default = -1). (array of int)
probe_only:Only probing and no codec initialization. (array of int)
jackpoll_ms:Ms between polling for jack events (default = 0, using unsol events only) (array of int)
single_cmd:Use single command to communicate with codecs (for debugging only). (bint)
enable_msi:Enable Message Signaled Interrupt (MSI) (bint)
patch:Patch file for Intel HD audio interface. (array of charp)
beep_mode:Select HDA Beep registration mode (0=off, 1=on) (default=1). (array of bool)
dmic_detect:Allow DSP driver selection (bypass this driver) (0=off, 1=on) (default=1); deprecated, use snd-intel-dspcfg.dsp_driver option instead (bool)
power_save:Automatic power-saving timeout (in second, 0 = disable). (xint)
pm_blacklist:Enable power-management blacklist (bool)
power_save_controller:Reset controller in power save mode. (bool)
align_buffer_size:Force buffer and period sizes to be multiple of 128 bytes. (bint)
snoop:Enable/disable snooping (bint)

Fortunately, in today’s GNU/Linux, with pulse audio and ‘pavucontrol’ application, the order of devices is not so important, as pulse audio can direct the audio as required, with ‘pavucontrol’ providing the user the needed control.
.

Yes, PA provides that effective functionality.

33

oldcpu, deano,

it seems that reboot is responsible for changing the order of the sound cards… I tested 0,1,2 cards (no YaST, editing 50-sound.conf directly) then booted into “multi-user” then a “init 5”. After editing 50-sound.conf from one card to two cards, after reboot, the PCH card (originally card 0) was pushed down to “card 1” (and also suffered a name change from PCH to NVidia) with the NVidia as “card 0”
one card rl3

=== /etc/modprobe.d/50-sound.conf ===


options snd slots=snd-hda-intel
# nS1_.4iMtSV4J9L1:Comet Lake PCH cAVS
options snd_hda_intel index=0 model=dual-codecs id=PCH
alias snd-card-0 snd-hda-intel

=== /proc/asound/cards ===

 0 [PCH            ]: HDA-Intel - HDA Intel PCH
                      HDAudio-Gigabyte-ALC1220DualCodecs
 1 [NVidia         ]: HDA-Intel - HDA NVidia
                      HDA NVidia at 0xa1000000 irq 17

####################################################################

two cards rl3

=== /etc/modprobe.d/50-sound.conf ===


options snd slots=snd-hda-intel,snd-hda-intel
# nS1_.4iMtSV4J9L1:Comet Lake PCH cAVS
options snd_hda_intel index=0 model=dual-codecs id=PCH
alias snd-card-0 snd-hda-intel
# NXNs.Q5mfEK148i4:TU106 High Definition Audio Controller
options snd_hda_intel index=1 model=dual-codecs id=NVidia
alias snd-card-1 snd-hda-intel

=== /proc/asound/cards ===

 0 [NVidia_1       ]: HDA-Intel - HDA NVidia
                      HDA NVidia at 0xa1000000 irq 17
 1 [NVidia         ]: HDA-Intel - HDA Intel PCH
                      HDAudio-Gigabyte-ALC1220DualCodecs

so it looks like leap 15.1 is responsible.

I will experiment more tomorrow hopefully.

regards
stevetom

34

IMHO, there appears to be duplication in the 50-sound.conf files that you are using where more entries are in place than needed ? … although I could be wrong.

Did you try the following four different 50-sound.conf file entries:

First edit this into the 50-sound.conf (and nothing else) followed by a reboot to test:


options snd-hda-intel index=0,1

Does that give sound that works? and if so, which device is sound card 0 and sound card 1 ?

and instead this 50-sound.conf, followed by a reboot to test properly:


options snd-hda-intel index=1,0

Does that give sound that works? and if so, which device is sound card 0 and sound card 1 ?

Or if the above yields no sound and if this “model=dual-codecs” is necessary, try only this in the 50-sound.conf followed by a reboot to test:


options snd-hda-intel index=0,1 model=dual-codecs

Does that give sound that works? and if so, which device is sound card 0 and sound card 1 ?

and instead this 50-sound.conf, followed by a reboot to test properly:


options snd-hda-intel index=1,0 model=dual-codecs

Does that give sound that works? and if so, which device is sound card 0 and sound card 1 ?

My idea is to keep the 50-sound.conf file simple - as simple as possible - where I find keeping things simple helps me to understand better the affect of individual entries. If I put in a bunch of entries it totally confuses me as to what each entry does.

35

oldcpu,many thanks - I understand: the KISS principle. Would you believe your post came in just after I had closed down after a testing session - I haven’t even reviewed the results yet! I may be able to do your tests later this afternoon, if not then this evening - each test generates a shed-load of diags.
To tell truth, currently I haven’t been actually testing the actual sound - just watching the kernel stuff moving around - but will for your tests.
i also note there is a dkms build failure (journal -b|grep realtek), but that should probably be investigated via a separate thread.

regards
stevetom

36

oldcpu,from your sequence of tests I can confirm that sound works only with the model assignment in the options line - output works fine with no problem whichever order was used in the index assignment. However, whilst input (internal mike) is working (I can see activity in the arecord VU meter) but aplay is silent. I did watch aplay in pavucontrol (output devices) and the activity was there also - but no sound. Subsequently playing an mp3 image via the Files application was also silent, whereas it had worked during my output test - looks like pavucontrol had routed the sound somewhere.

applying the dual-codecs value does change the names reported in alsacontrol, and is confirmed in /proc/asound/cardX/codec#Y ← there are other more subtle changes to be seen in that data, I suspect I will find other differences.
reboot seems to mute and otherwise modify the controls, but once my config settles down I can script the relevant amixer sset changes.
Plus the dkms build failure mentioned before.

Option 1

oldcpu opt #1

=== /etc/modprobe.d/50-sound.conf ===

options snd-hda-intel index=0,1

=== /proc/asound/cards ===

 0 [PCH            ]: HDA-Intel - HDA Intel PCH
                      HDA Intel PCH at 0x6052200000 irq 174
 1 [NVidia         ]: HDA-Intel - HDA NVidia
                      HDA NVidia at 0xa1000000 irq 17

Option 4

oldcpu opt 4

=== /etc/modprobe.d/50-sound.conf ===

options snd-hda-intel index=0,1 model=dual-codecs

=== /proc/asound/cards ===

 0 [PCH            ]: HDA-Intel - HDA Intel PCH
                      HDAudio-Gigabyte-ALC1220DualCodecs
 1 [NVidia         ]: HDA-Intel - HDA NVidia
                      HDA NVidia at 0xa1000000 irq 17

I can recreate and get you alsa-info.sh images if you want them.

regards
stevetom

37

OK, my understanding is there is no sound with the above as there is no ‘model=dual-codecs’ assignment.

I think this next one was actually the 3rd test (as “index=0,1” was always an odd # test in the order of tests I suggested) …

My understanding the above, with ‘index=0,1’ and ‘model=dual-codecs’ gives you ok sound and mic working. I suspect with the reverse ‘index=1,0’ you probably could also get to work but you would need to tune pavucontrol as sound cards would be reversed.

No need to run the script again if my above understanding is correct.

38

oldcpu, deano, Svyatko,

many thanks for your inputs, and apologies for the radio silence – I needed to take a bit of a break. In the meantime, I have made some progress of sorts albeit somewhat circular.
In comparing my results from oldcpu’s 50-sound.conf suggestions, I didn’t find too much enlightenment, so experimented with Bluetooth connection:

Initially very varied results, until I noticed the “Sound Settings” button when clicking on my connected device (in Activities → Bluetooth→ ) – a slightly cut-down pavucontrol. There I can select the device to use for Input/Output which included the internal microphone/headphone options and my Bluetooth device. The (Bluetooth) output certainly works, I suspect the input works (it shows activity on the Input tab “VU meter”, but arecord/aplay does not reproduce the expected recording – I suspect it is switched away to a digital (unconnected) sink).

Then curiosity got the better of me, the above results were using a 50-sound.conf:

options snd-hda-intel index=0,1 model=dual-codecs

what would happen if I used the “factory fresh” version ie no 50-sound.conf? Answer: It still works.

So it appears I have wasted people’s time & efforts – apologies - by trying to get the simple things working (ie internal devices) rather than going straight for the bluetooth jugular. In retrospect a simpler starting point (for multimedia: sound) would have been Activities → Settings → Sound

regards
stevetom

39

Interesting news.

openSUSE and GNU/Linux in general has made significant progress the past 15 years (IMHO) wrt automatic sound configuration. There was a day when many GNU/Linux users needed to to tune the ‘equivalent’ of 50-sound.conf. Today - the alsa configuration is often automatic and such 50-sound.conf (or equivalent) tuning is often not needed. Rather its the higher layer (pulseaudio) configuration that confuses new users, resulting in them tuning alsa,when in fact its pulse audio (or some other higher level aspect) that requires the tuning.

I don’t see anyone’s time wasted here.

We all can learn from such things IMHO.

40

oldcpu - many thanks

I was a bit “economical with the truth” in saying “it still works” - without the** 50-sound.conf**, the internal speakers again do not work. I’m not too worried about that as my preferred target would be some bluetooth speakers (MiniRigs - use 80 of them for a 3000 Watt sound system! small, good quality, and very rugged).

I did find a very useful document via the** pulseaudio** website: https://gavv.github.io/articles/pulseaudio-under-the-hood/ - if not ready to dive into code, then the first 4 sections & the Example Setups sections make me feel that I now have some useful tools to explore what is happening with my internal speakers - probably.

Currently I’m running without the 50-sound.conf tuning - it’s “cleaner”, and fixes two issues: the dkms build errors, and the alsamixer channel labels.

I was going to close down this thread, but it now looks as if I need to flex my pactl list wings.

cheers
stevetom