Hello dear users,
I’ve recently switched from Windows to Fedora Kinoite. The switch went over mostly smoothly however the audio from the microphone port is really staticy. Not only that, my voice comes through intermittently at best.
Reducing the mic volume only makes the static noise quieter. My voice does not come through more reliably.
Through some research i’ve determined that my PC has a Realtek ALC887-VD audio chipset.
Thank you in advance for your help 
Sound card support in Linux is somewhat spotty. People often resort to buying a cheap USB audio adapter when their built-in sound card is not supported. That said, it is sometimes possible to get the build-in audio device to work by experimenting with the parameters to the audio driver. What audio driver is your system using? The driver name should be listed in the output of lspci -k.
You are likely using snd_hda_intel, in which case, the relevant documentation is here: More Notes on HD-Audio Driver — The Linux Kernel documentation
The following paragraph from the above link sounds like it might be relevant to the problem you are experiencing:
There seem also still other devices that don’t work with MSI. If you see a regression wrt the sound quality (stuttering, etc) or a lock-up in the recent kernel, try to pass enable_msi=0 option to disable MSI. If it works, you can add the known bad device to the blacklist defined in hda_intel.c. In such a case, please report and give the patch back to the upstream developer.
There are some model= options that might help with that card:
abit-aw9d
Pin fixups for Abit AW9D-MAX
lenovo-y530
Pin fixups for Lenovo Y530
acer-aspire-7736
Fixup for Acer Aspire 7736
asus-w90v
Pin fixup for ASUS W90V
cd
Enable audio CD pin NID 0x1c
no-front-hp
Disable front HP pin NID 0x1b
vaio-tt
Pin fixup for VAIO TT
eee1601
COEF setups for ASUS Eee 1601
alc882-eapd
Change EAPD COEF mode on ALC882
alc883-eapd
Change EAPD COEF mode on ALC883
gpio1
Enable GPIO1
gpio2
Enable GPIO2
gpio3
Enable GPIO3
alc889-coef
Setup ALC889 COEF
asus-w2jc
Fixups for ASUS W2JC
acer-aspire-4930g
Acer Aspire 4930G/5930G/6530G/6930G/7730G
acer-aspire-8930g
Acer Aspire 8330G/6935G
acer-aspire
Acer Aspire others
macpro-gpio
GPIO setup for Mac Pro
dac-route
Workaround for DAC routing on Acer Aspire
mbp-vref
Vref setup for Macbook Pro
imac91-vref
Vref setup for iMac 9,1
mba11-vref
Vref setup for MacBook Air 1,1
mba21-vref
Vref setup for MacBook Air 2,1
mp11-vref
Vref setup for Mac Pro 1,1
mp41-vref
Vref setup for Mac Pro 4,1
inv-dmic
Inverted internal mic workaround
no-primary-hp
VAIO Z/VGC-LN51JGB workaround (for fixed speaker DAC)
asus-bass
Bass speaker setup for ASUS ET2700
dual-codecs
ALC1220 dual codecs for Gaming mobos
clevo-p950
Fixups for Clevo P950
Edit: The way to pass these options to the snd_hda_intel driver is to create a “.conf” file under /etc/modprobe.d (e.g. /etc/modprobe.d/my-sound.conf). The file should contain a line like options snd_hda_intel model=lenovo-y530. After you’ve created the file, reboot your PC to get it to reload the driver. You can use cat /sys/module/snd_hda_intel/parameters/model to verify that the configuration change is in effect.
I tried setting enable_msi=0. It didn’t help. And i don’t see any setting that is relevant to my machine (Asus G20AJ).
There is a similar (but old) report of “crackling” on kernel.org here: https://bugzilla.kernel.org/show_bug.cgi?id=195303
Comment #24 and Comment #283 mention that the problem applied to the ALC887-VD chip.
Comment #152 indicates that passing position_fix=3 might be a viable workaround for some chips.
Beware that the position_fix parameter takes an array of values and you will need to “align” the assigned value with the card slot you are trying to assign the setting to as stated in Comment #127:
… you can change the behavior via position_fix option, too. This is an array for multiple instances, so be careful if you have multiple HD-audio devices (likely on AMD). If you pass a non-default value (e.g. 2, which means to forcibly use the position buffer) to the second card, pass like
position_fix=,2note the comma before “2”.
Do you have multiple cards using the snd_hda_intel driver? The output of lspci -k should indicate if that is the case.
Also, later on in that thread, someone reported that position_fix=6 worked for their audio chip. You might try that if 3 doesn’t work.
Good luck!
BTW, there is a chance that fix-up/quirk-mode setting for a similar system might also work for yours. I’d try model=alc889-coef since there appear to be mentions of coefficient settings resolving the problem in that earlier bugzilla report.
Hello again,
so i read the Bugzilla thread and unfortunately couldn’t fix my sound capture just yet. Neither with the position_fix, nor with tsched=0 etc. I also tried booting Windows first and then Fedora to read out the coefficients and values. That trick didn’t work but i believe that’s because my PC can’t remember the boot order. So perhaps i need to cold boot it and use the boot menu. Do you happen to know whether i can read the coefficients and values through Windows just in case?
That said i ran the arecord command and while my audio wasn’t entirely fixed, my voice wasn’t constantly cut off. I still had the very audible noise floor and the recording seems to be peaking. My ALC887-VD supports up to 48khz.
So it’s likely that the sample rate is misconfigured by Fedora and i need to combine a fix for this with another setting or a noise cancel config.
How can i configure the sample rate? KDE does not show any setting and OBS is apparently configured to use 48khz already. And do you have some other tips for me?
arecord will let you set the sample rate for a single run of the command. I think something like arecord -f S16_LE -c 2 -r 48000 test.wav should work. If that is all your system needs, you can probably adjust that default globally in /etc/asound.conf. I don’t know the exact syntax of that global asound.conf file off-hand. You should be able to look it up.
It looks like PipeWire defaults to 48kHz: https://wiki.archlinux.org/title/PipeWire#Changing_the_default_sample_rate
But maybe your application is connecting directly to the Alsa subsystem somehow?
Sorry, I’ve never messed with that personally.