Sound problems with HDA NVidia Realtek ALC888

English Hardware
1

Hello,

I have just purchased a AAASUS M3n72-D mother board.
The mother board has onboard audio with the HDA NVIDIA Realtek ALC888. I get some sort of sound by it is very choppy, sounds like a skipping record. I checked my alsamixer settings and they all seem to be correct. I am using alsa-1.0.16-39.1 and openSuse 11.0. I am a linux noob and I was wondering if anyone else has this problem.

Oh yeah, I want to use the SPDIF connector as well. The SPDIF works just as well as the regular audio out so it probably isn’t an issue. Also this system works just fine on my windows partition so I don’t think its faulty hardware.

Thank you.

2

Actually, just some general help on debugging the soundcard would be helpfull.

3

I find these sorts of problems difficult to solve, as the choppy/skipping record sounds can be indicative of an interrupt problem. Sometimes going into one’s BIOS and adjusting settings (to shift interrupts) can help, but its very motherboard dependent.

Anyway, can you provide more information on your onboard PC sound setup, by running the following diagnostic script with your PC connected to the internet, and run it in an xterm/konsole:

wget http://home.cfl.rr.com/infofiles/tsalsa && su -c 'bash ./tsalsa'

when prompted for a password enter the root password. Please try to answer the number of plugs/jacks question as accurate as possible (ie how many input/output jacks does your motherboard have?). When it is compete it will provide you a URL where your audio configuration is posted on the internet, … please provide that URL.

Also, with the same configuration as above, in an xterm/konsole please run the following one line at a time and paste here the output:
cat /proc/interrupts
cat /etc/modprobe.d/sound
rpm -qa | grep alsa
rpm -qa | grep pulse
rpm -q libasound2
uname -a

I also looked at the alsa site to see if there were any updates for the ALC888, and I noted there was one, but from what I can read it does not appear to be relevant to the problem you encountered:
Search results ALC888 - AlsaProject

4

With the information from this, it might be possible to fix the problem with an edit to your /etc/modprobe.d/sound file. Below are some quotes out of ALSA-Configuration.txt file:

	ALC883/888
	  3stack-dig	3-jack with SPDIF I/O
	  6stack-dig	6-jack digital with SPDIF I/O
	  3stack-6ch    3-jack 6-channel
	  3stack-6ch-dig 3-jack 6-channel with SPDIF I/O
	  6stack-dig-demo  6-jack digital for Intel demo board
	  acer		Acer laptops (Travelmate 3012WTMi, Aspire 5600, etc)
	  acer-aspire	Acer Aspire 9810
	  medion	Medion Laptops
	  medion-md2	Medion MD2
	  targa-dig	Targa/MSI
	  targa-2ch-dig	Targs/MSI with 2-channel
	  laptop-eapd   3-jack with SPDIF I/O and EAPD (Clevo M540JE, M550JE)
	  lenovo-101e	Lenovo 101E
	  lenovo-nb0763	Lenovo NB0763
	  lenovo-ms7195-dig Lenovo MS7195
	  haier-w66	Haier W66
	  6stack-hp	HP machines with 6stack (Nettle boards)
	  3stack-hp	HP machines with 3stack (Lucknow, Samba boards)
	  6stack-dell	Dell machines with 6stack (Inspiron 530)
	  mitac		Mitac 8252D
	  auto		auto-config reading BIOS (default)

and

Note 2: If you get click noises on output, try the module option
	    position_fix=1 or 2.  position_fix=1 will use the SD_LPIB
	    register value without FIFO size correction as the current
	    DMA pointer.  position_fix=2 will make the driver to use
	    the position buffer instead of reading SD_LPIB register.
	    (Usually SD_LPLIB register is more accurate than the
	    position buffer.)

    NB: If you get many "azx_get_response timeout" messages at
    loading, it's likely a problem of interrupts (e.g. ACPI irq
    routing).  Try to boot with options like "pci=noacpi".  Also, you
    can try "single_cmd=1" module option.  This will switch the
    communication method between HDA controller and codecs to the
    single immediate commands instead of CORB/RIRB.  Basically, the
    single command mode is provided only for BIOS, and you won't get
    unsolicited events, too.  But, at least, this works independently
    from the irq.  Remember this is a last resort, and should be
    avoided as much as possible...
    
    MORE NOTES ON "azx_get_response timeout" PROBLEMS:
    On some hardwares, you may need to add a proper probe_mask option
    to avoid the "azx_get_response timeout" problem above, instead.
    This occurs when the access to non-existing or non-working codec slot
    (likely a modem one) causes a stall of the communication via HD-audio
    bus.  You can see which codec slots are probed by enabling
    CONFIG_SND_DEBUG_DETECT, or simply from the file name of the codec
    proc files.  Then limit the slots to probe by probe_mask option.
    For example, probe_mask=1 means to probe only the first slot, and
    probe_mask=4 means only the third slot.

To see if you get many “azx_get_response timeout” messages at loading, it will likely be necessary to examine your dmesg output. In which case, IMMEDIATELY after rebooting your PC, please run in an xterm/konsole:
dmesg > dmesg.txt
and open dmesg.txt with a text editor, and pastebin the output to a site like general pastebin - simplified internet collaboration and post here the URL.

5

The URL:
tsalsa.txt - nopaste.com (beta)

Other Stuff:
jrwarner@linux-jpns:~> cat /proc/interrupts
CPU0 CPU1 CPU2 CPU3
0: 66 0 0 3 IO-APIC-edge timer
1: 0 0 0 2 IO-APIC-edge i8042
4: 0 0 0 5 IO-APIC-edge
6: 0 0 0 5 IO-APIC-edge floppy
7: 1 0 0 0 IO-APIC-edge
8: 0 0 0 1 IO-APIC-edge rtc0
9: 0 0 0 0 IO-APIC-fasteoi acpi
12: 0 0 0 4 IO-APIC-edge i8042
14: 7736 0 1 292 IO-APIC-edge pata_amd
15: 0 0 0 0 IO-APIC-edge pata_amd
16: 0 50787 3 2022 IO-APIC-fasteoi nvidia
19: 0 0 0 2 IO-APIC-fasteoi ohci1394
20: 0 0 0 4 IO-APIC-fasteoi ehci_hcd:usb3
21: 490 0 961 357 IO-APIC-fasteoi ohci_hcd:usb2, HDA Intel
22: 10967 0 7 305 IO-APIC-fasteoi ohci_hcd:usb1
23: 0 0 0 7 IO-APIC-fasteoi ehci_hcd:usb4
4346: 44532 0 9 1897 PCI-MSI-edge eth0
4347: 4904 5149 29 8292 PCI-MSI-edge ahci
NMI: 0 0 0 0 Non-maskable interrupts
LOC: 26273 19637 13735 14752 Local timer interrupts
RES: 5528 7544 9490 5263 Rescheduling interrupts
CAL: 312 426 416 172 function call interrupts
TLB: 1129 1030 1107 757 TLB shootdowns
TRM: 0 0 0 0 Thermal event interrupts
THR: 0 0 0 0 Threshold APIC interrupts
SPU: 0 0 0 0 Spurious interrupts
ERR: 1

jrwarner@linux-jpns:~> cat /etc/modprobe.d/sound
alias snd-card-0 snd-hda-intel
alias sound-slot-0 snd-hda-intel

jrwarner@linux-jpns:~> rpm -qa | grep alsa
alsa-1.0.16-39.1
alsa-oss-1.0.15-48.1
alsa-utils-1.0.16-35.1
alsa-tools-1.0.16-47.1
alsa-firmware-1.0.16-24.1
alsa-plugins-1.0.16-57.1
alsa-oss-32bit-1.0.15-48.1

jrwarner@linux-jpns:~> rpm -qa | grep pulse
I removed all of pulse audio in an attempt to fix this problem.

jrwarner@linux-jpns:~> rpm -q libasound2
libasound2-1.0.16-39.1

jrwarner@linux-jpns:~> uname -a
Linux linux-jpns 2.6.25.11-0.1-default #1 SMP 2008-07-13 20:48:28 +0200 x86_64 x86_64 x86_64 GNU/Linux

Also looked for timeout messages in the dmesg.txt, there are none. File is here: general pastebin - Dmesg.txt - post number 1089738

Thank you for your help.

6

Thanks … I took a look at the mixer settings and I did not pickup anything really obvious.

Ok, so your sound is sharing IRQ-21 with usb2. I wonder, … could this be a USB mouse? What happens if you put your USB mouse in a different USB port?

There are a lot of ACPI messages for IRQ21 (used by your audio) in your dmesg that i don’t begin to understand. For example:

# ACPI: PCI Interrupt Link [AU1B] enabled at IRQ 21
# ACPI: PCI Interrupt 0000:00:04.0[A] -> Link [AU1B] -> GSI 21 (level, low) -> IRQ 21
# PCI: Setting latency timer of device 0000:00:04.0 to 64

and

# ohci_hcd 0000:00:04.0: OHCI Host Controller
# ohci_hcd 0000:00:04.0: new USB bus registered, assigned bus number 2
# ohci_hcd 0000:00:04.0: irq 21, io mem 0xfe02d000

and there are many others. But most important I note this:

hda_codec: Unknown model for ALC883, trying auto-probe from BIOS...

Strange it would say ALC883 and not ALC888. Lets see what happens if we assign a model in your /etc/modprobe.d/sound file.

You provided this:

Lets try some different settings here. In your /etc/modprobe.d/sound file, change the file (from above) to:

alias snd-card-0 snd-hda-intel
options snd-hda-intel model=auto
alias sound-slot-0 snd-hda-intel

and restart alsa with rcalsasound restart and test your sound. Any difference?

If “auto” does not work, try instead “6stack-dig”, save, and restart alsa with rcalsasound restart and test your sound. Any difference? Because this hiccup was noted in the dmesg during a boot, you may need to try a reboot.

Try also 6stack-dig-demo, 6stack-hp, 6-stack-dell (restarting alsa and testing your sound in each case), and if none of those work, try some of the other settings from the ALSA-Configuration.txt file that I suggested above.

7

This may be usb related. When I unplug and replug the usb mouse while a test sound is playing it alters how the sound is distorted. It sounds like a skipping cd, but when I remove the mouse or plug it back in it skips in a different way.

They other suggestions did not help.

8

How about running the dmesg > dmesg.txt when you have one of the more promising model options in your /etc/modprobe.d/sound file, and see if it gives the same error about the bios looking for the model info ?

Did you try all of the model options? … saving the file, and restarting alsa in each case?

9

Can you be explicit as to what you tried here with the BIOS? Did you change any of the USB options to see if that made a difference? Did you look for any “plug and play” options and try the opposite setting?

10

I tried all the options in the modeprobe.d/sound file.
It is left at auto now and it appears with auto in the sound file and it appears the the bios model error went away in the dmesg.txt.

But, the sound problem still persists.
There is a plug n play bios option that was off that I turned on.
That had no effect.
There seems to be no individual control of interrupts in my bios. Only a select few have the option of being PCI or reserved.
I did not touch any of these settings.
There is options to disable each of the usb busses, but I need at least one for the mouse.
I didn’t touch these setting either.

Do you have any other ideas that come to mind?

11

I always leave that OFF.

You could try turning one or more of those off (you can always reboot and switch on later (in fact proably should switch on later)) to help see if one of those are related to the problem.

Lots of speculative things to try.

You could update to the latest alsa (now at 1.0.17). Guidance for that is here: Alsa-update - openSUSE Restart after updating.

You could try some of the other techniques from the ALSA-Configuration.txt file:


Note 2: If you get click noises on output, try the module option
	    position_fix=1 or 2.  position_fix=1 will use the SD_LPIB
	    register value without FIFO size correction as the current
	    DMA pointer.  position_fix=2 will make the driver to use
	    the position buffer instead of reading SD_LPIB register.
	    (Usually SD_LPLIB register is more accurate than the
	    position buffer.) 

Try to boot with options like "pci=noacpi".  Also, you
    can try "single_cmd=1" module option.  This will switch the
    communication method between HDA controller and codecs to the
    single immediate commands instead of CORB/RIRB.  Basically, the
    single command mode is provided only for BIOS, and you won't get
    unsolicited events, too.  But, at least, this works independently
    from the irq.  Remember this is a last resort, and should be
    avoided as much as possible...
12

I realize this thread is pretty old (about a month since the last post) but I have to say thank you.

I just got a Shuttle SN78SH7 barebones setup and first attempted to install Fedora on it. However, I got some god-awful scratching sounds out of my audio. After a lot of searching (and some unanswered posts over at their forums) I found this thread. I tried to install the newest alsa on my fedora installation but just wound up wiping out the sound all-together.

Today, I finally decided to give openSUSE a shot. The sound was still screwed up, but by following the suggestion to update to the latest alsa, I was able to finally fix my sound.

One caveat though: at first, my audio was dreadfully low. I’m not 100% sure exactly what fixed it, but I ran alsamixer both as a regular user but saw nothing out of the ordinary. However, when I ran alsamixer as root, my sound levels jumped.

Just thought I’d throw that out there.

13

Interesting. Thanks for that tidbit.

Sometimes going into YaST > HARDWARE > Sound > Other > Volume and move the slider bar(s) to the right (70% or so) can be helpful for improving very low sound. However going into YaST > HARDWRE > Sound unfortunately has the disadvantage of possibly deleting one’s custom settings in /etc/modprobe.d/sound file.

Welcome to openSUSE.

As a further note, now that you have your sound working, you are likely going to want to install media players and codecs that are not crippled (while the one’s provided by Novell/SuSE-GmbH tend to be crippled). One can get non-crippled versions from Packman packagers of selected openSUSE multimedia software. I recommend new users setup their Software package management repositories (repos) per this URL:
Repositories - openSUSE-Community
I also recommend they limit it the repos to only OSS, NON-OSS, Update and Packman. In particular do not select videolan. The reason being some of the videolan applications are not compatible with the packman packaged applications. Many users have recently reported problems with both vlc and libffmpeg0 when they used the videolan repos.

Other repos can be added on a temporary adhoc basis, software installed, and the other repos removed as required. While easy to add repos via YaST, it is incredibly quick (handful of seconds) to add and remove repos via YaST (once one learns the syntax).

Again, welcome to openSUSE and welcome to our forum.

14

Thanks for the warm welcome.

I’ve actually seen the opposite, in terms of vlc (I installed it shortly after getting my sound to work). The videolan version works fine (as long as I launch it with ‘padsp vlc’ instead of just ‘vlc’) whereas the packman packaged version of vlc has messed up color (and very choppy/no sound). What kinds of issues have people seen?

One small question I have about repositories (since you brought it up) is the default openSUSE-DVD repo. Is it possible to not use that (keeping up with discs is one of my weaker points…I just know I’m going to have to re-download the entire DVD at some point)

On topic, I’ve had some issues with using my line-in and/or mic jacks. I can’t seem to get a signal from them. My end goal is to use Ardour with Jack, but right now, I’d be happy just getting a signal.

Thanks.

15

If one mixes the packman vlc with the videolan libffmpeg0, users have had either audio or video or both not work, mainly because (IMHO) libffmpeg0 provides most of the codecs that one uses.

vlc was updated recently on packman, and I noticed last night some choppy issues in certain parts when playing back a video_ts directory. I have not had the time to check that out in more detail, and indeed given an upcoming busy schedule, it could be November or December before I can look at that i more detail. Hopefully someone else will chase that down.

My understanding is the OSS and NON-OSS repos (which I recommended) together will replace the CD/DVD. For updates, one uses the “Update” repos.

If you are going to keep both the videolan and packman repos, be very careful as to the source of your installed multimedia, as those repos are notorious for not working with packages packaged by the other.

I just know I’m going to have to re-download the entire DVD at some point)

This can be tricky. It can be either:
a. driver related (sometimes a more up to date alsa is needed), or
b. mixer related

One can search the ALSA site for one’s hardware audio codec (ie ALC888 in this thread) to see if there are any updates associated with the line-in / mic.

Or one can run the tsalsa diagnostic script I referenced in this thread (above) post the URL provided here, and ask for a 3rd party assessment of one’s mixer configuration, as typically this is a mixer problem. Or one can do screen dumps of one’s mixer settings, and post those on a paste site (and post the URL here). There are various ways to get such an assessment.

I recommend one use the “arecord” application for a simple mic check on the line-in.

16

I discovered a choppy behaviour with the packman packaged vlc (v.0.9.1) when handling vob and .mpeg files (but not with .avi h264 and xvid that were used to create the .mpeg and .vob).

Hence on my openSUSE-10.3 32-bit PC, I rolled back my packman version of vlc from vlc-0.9.1-0.pm.2.i586 29.08.2008 to vlc-0.8.6i-0.pm.2.i586 29.07.2008 and the choppiness went away. This appears to be a problem with the new 0.9.1 vlc. I am not sure if it is packager induced.

I’ll send an email to the packager.

17

sorry to bring back what seems like a dead post but I just made a startling discovery with my ALC888 sound device:

I have the same problem where if I raise the volume levels above 70% or so I had some really choppy playback, I mean terrible to listen too. If I use the front panel output jack as opposed to the motherboard mounted rear panel jack, the playback is near perfect, even when all volume levels are turned up to 100%.

This must be a bug with the ALSA driver or the Realtek driver. I wouldn’t know how to narrow that one down. I’m running Ubuntu btw, not to spoil the SUSE party ;o)

18

If you were using openSUSE, you could raise a bug report on openSUSE, and the SuSE-GmbH packager (who is also an alsa developer) would look at it.

Since you are using Ubuntu, you will have to find a different approach.

Maybe raise this issue in the Ubuntu forums. Or raise a bug report direct on the alsa bug reporting tool.