Hello, First of all let me apologize if I'm not fulfilling any requirements for this list, and for any errors in my English. I've sent a mail with same subject and content to this list as a non-subscriber on April, 26, but perhaps that's gone lost, or perhaps is still under moderation or didn't pass it, so I'm resending this from a different address as a subscriber. So, please, ignore my previous mail if it came out from moderation.
As per subject, I'm experiencing problems with my motherboard built-in audio device (an Asrock with ATI SB8xx), embedding a Via VT2020 codec (I haven't tested the ATI HDMI part in same conditions).
The card is recognized 'about' correctly (later in this mail something about dmesg and other issues), and stuff in /proc/asound seems correct, also I have no apparent problem with /dev special files, but I get no sound after having installed kernel 2.6.38.2 and updated to version 2.6.38.3 (both compiled from source); no mixer seems to work (later specific errors), but everything still works with older kernel 2.6.33.2 I've kept in my system (built with the same build environment). Since I'm using the very same userspace environment in both cases, I deem it to be a driver(s) related issue more likely; though, I've updated my alsa-lib and -utils to latest versions (were such when I downloaded sources - alsa-lib 1.0.24.1 & alsa-utils 1.0.24.2) and still get the very same results.
But let me go into more details. Here is an excerpt from dmesg called with kernel 2.6.33.2 (sound works, but I'm just using headphone jack, so I can't tell about anything related with later issue with smart5.1 and hda I've seen in list archives):
[...] HDA Intel 0000:00:14.2: PCI INT A -> GSI 16 (level, low) -> IRQ 16 HDA Intel 0000:01:05.1: PCI INT B -> GSI 19 (level, low) -> IRQ 19 HDA Intel 0000:01:05.1: irq 28 for MSI/MSI-X HDA Intel 0000:01:05.1: setting latency timer to 64 [...] ohci1394 0000:04:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16 ohci1394 0000:04:00.0: setting latency timer to 64 [...] ohci1394: fw-host0: OHCI-1394 1.1 (PCI): IRQ=[16] MMIO=[fe9ff800-fe9fffff] Max Packet=[2048] IR/IT contexts=[4/8] ieee1394: Host added: ID:BUS[0-00:1023] GUID[008f130043910900] [...] hda-intel: azx_get_response timeout, switching to polling mode: last cmd=0x000f0001 [...]
Notice last line is an harmless warning (sound works) and is there because msi seems to be enabled by default; by adding "options snd-hda-intel enable_msi=0" to /etc/modprobe.d/alsa-base.conf both the warning and any reference to MSI/MSI-X disappear; same effect with pci=nomsi on command line (this time affecting other drivers, such as r8169). VT2020 is part of device 0000:00:14.2 sharing IRQ 16 with ohci1394; device 0000:01:05.1 is ATI HDMI, while device 0000:05.0 should be embedded radeon vga (bridged together according with lspci -t with 0000:00:01.0 on top); for each bridge I can find with lspci -t corresponding msi_bus file in sys filesystem (in /sys/bus/pci/devices/*) is always 1, regardless of any boot command (this with kernel 2.6.33.2).
Now an excerpt from dmesg in kernel 2.6.38.3:
[...] HDA Intel 0000:00:14.2: PCI INT A -> GSI 16 (level, low) -> IRQ 16 hda-codec: no NID for mapping control Independent HP:0:0 HDA Intel 0000:01:05.1: PCI INT B -> GSI 19 (level, low) -> IRQ 19 HDA Intel 0000:01:05.1: setting latency timer to 64 [...] r8169 0000:03:00.0: irq 43 for MSI/MSI-X [...] firewire_ohci 0000:04:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16 firewire_ohci 0000:04:00.0: setting latency timer to 64 [...] firewire_ohci: Added fw-ohci device 0000:04:00.0, OHCI v1.10, 4 IR + 8 IT contexts, quirks 0x11 firewire_core: created device fw0: GUID 008f130043910900, S400 [...]
Now firewire_ohci replaces ohci1394, again sharing IRQ 16 with hda-intel for vt2020. Line about r8169 is just for reference, since it gets a different irq for msi now. Similar behaviour for MSI: enabled/disabled with pci=nomsi (seems to be enabled by default without pci=msi) and msi_bus == 1 for bridges regardless of boot options, *but for bridge on top of ati hdmi device*: now msi seems to be disabled regardless of both 'enable_msi' option and pci=* boot command and corresponding bridge (device at bus 0000:00:01.0) holds a value of 0 for msi_bus...
Notice there are no more warnings about response timeouts, as it happened in older kernel after disabling msi (both globally and for alsa through alsa config options).
Notice also line "hda-codec: no NID for mapping control Independent HP:0:0". That's because function
'snd_hda_get_connections' (patch_via.c)
called by
'via_hp_build'
returns 3 ( test for 'nums <= 1' fails and the function doesn't return), but function
'side_mute_channel',
called to init knew->subdevice when 'registering' via_hp_mixer[1], returns 0 (default value) and so condition 'if(nid > 0)', in function
'snd_hda_add_nid' (hda_codec.c),
is not met and the error is triggered (by the way, param nid is of type hda_nid_t which in turn is an unsigned integer (u16), so, should that be 'if(nid != 0)' instead? just to avoid the risk of giving the impression that negative values are possible but mistaken (hda_nid_t is defined elsewhere). Also: param @nid, in function comment/documentation is defined as optional, but it doesn't seem to be). Incidentally, in /proc/asound/card0/codec#0 node 0x35 looks much like node 0x34 (with both older and newer kernel; posting excerpt for kernel 2.6.38.3):
Node 0x34 [Audio Selector] wcaps 0x300501: Stereo Control: name="Independent HP", index=0, device=0 Power states: D0 D1 D2 D3 Power: setting=D0, actual=D0 Connection: 3 0x08 0x0b 0x0c* Node 0x35 [Audio Selector] wcaps 0x300501: Stereo Power states: D0 D1 D2 D3 Power: setting=D0, actual=D0 Connection: 3 0x08 0x0b* 0x0c
(notice connections and wcaps similarity, if relevant at all)
Since I'm quite crazy, I've tried to modify 'side_mute_channel' to have it returning '0x35' for codec type 'VT1718S', but to no avail; I also tried to bypass 'snd_hda_add_nid', both avoiding 'via_hp_build' to clone via_hp_mixer[<something>] and/or modifying 'via_build_controls' and 'snd_hda_add_new_ctls' (hda_control.c) so that "Independent HP" ctls were handled by the latter (achieving this was just a matter of a pair of strcmp's to choose skipping the rest of an iteration or not), as I deem it was done in alsa 1.0.21 (embedded in kernel 2.6.33.2), but it didn't work (the only result I got this ways was to avoid that error message about nids in system logs).
Additional infos from userspace applications:
mplayer works fine with kernel 2.6.33.2 (again, only using one exit, I haven't tested all jacks combinations); called from cmdline (under X - but that's the same shutting X down) with default options ('mplayer <path/to/file>') it gives the following output (relevant excerpt, as I deem it, after codec choice, can provide more if needed):
socket(): Address family not supported by protocol AO: [pulse] Init failed: Connection refused Failed to initialize audio driver 'pulse' AO: [alsa] 48000Hz 2ch s16le (2 bytes per sample) Starting playback...
(notice I'm not using alsa-tools, such as pulse-audio; with the above invocation sound/video works)
running mplayer with option '-ao sdl' (using sdl audio, same file) I get the following output:
[AO SDL] Samplerate: 44100Hz Channels: Stereo Format s16le AO: [sdl] 44100Hz 2ch s16le (2 bytes per sample) Starting playback...
Again, sound works. In both cases, I can notice a change in /proc/asound/card0/codec#0 as follows:
In nodes 0x08, 0x09, 0x0a, 0x0e (all [Audio Output] nodes, first 3 with 'wcaps 0x41d: Stereo Amp-Out', last with 'wcaps 0x611: Stereo Digital'), the following line:
Converter: stream=0, channel=0
changes into:
Converter: stream=5, channel=0
With kernel 2.6.38.x I get the following:
running mplayer with no option, I get no sound and following output:
socket(): Address family not supported by protocol AO: [pulse] Init failed: Connection refused Failed to initialize audio driver 'pulse' [AO_ALSA] alsa-lib: confmisc.c:768:(parse_card) cannot find card '0' [AO_ALSA] alsa-lib: conf.c:4184:(_snd_config_evaluate) function snd_func_card_driver returned error: No such device [AO_ALSA] alsa-lib: confmisc.c:392:(snd_func_concat) error evaluating strings [AO_ALSA] alsa-lib: conf.c:4184:(_snd_config_evaluate) function snd_func_concat returned error: No such device [AO_ALSA] alsa-lib: confmisc.c:1251:(snd_func_refer) error evaluating name [AO_ALSA] alsa-lib: conf.c:4184:(_snd_config_evaluate) function snd_func_refer returned error: No such device [AO_ALSA] alsa-lib: conf.c:4663:(snd_config_expand) Evaluate error: No such device [AO_ALSA] alsa-lib: pcm.c:2212:(snd_pcm_open_noupdate) Unknown PCM default [AO_ALSA] Playback open error: No such device Failed to initialize audio driver 'alsa' [AO SDL] Samplerate: 44100Hz Channels: Stereo Format s16le [AO SDL] using aalib audio driver. [AO SDL] Unable to open audio: No available audio device Failed to initialize audio driver 'sdl:aalib' Could not open/initialize audio device -> no sound. Audio: no sound
and nothing changes in codec#0 file; with option -ao sdl, instead:
[AO SDL] Samplerate: 44100Hz Channels: Stereo Format s16le ALSA lib confmisc.c:768:(parse_card) cannot find card '0' ALSA lib conf.c:4184:(_snd_config_evaluate) function snd_func_card_driver returned error: No such device ALSA lib confmisc.c:392:(snd_func_concat) error evaluating strings ALSA lib conf.c:4184:(_snd_config_evaluate) function snd_func_concat returned error: No such device ALSA lib confmisc.c:1251:(snd_func_refer) error evaluating name ALSA lib conf.c:4184:(_snd_config_evaluate) function snd_func_refer returned error: No such device ALSA lib conf.c:4663:(snd_config_expand) Evaluate error: No such device ALSA lib pcm.c:2212:(snd_pcm_open_noupdate) Unknown PCM default AO: [sdl] 44100Hz 2ch s16le (2 bytes per sample)
And sound works! Same changes as per (working) playback with kernel 33.2 (alsa 1.0.21) are noticeable in /proc/asound/card0/codec#0 in this case (that is, when getting sound with kernel 2.6.38.x); in addition, node 0x0c, now changes as well (again, '[Audio Output] wcaps 0x41d: Stereo Amp-Out.' and 'Converter: stream=5, channel=0')
Moreover: with kernel 38.2, 38.3 alsamixer fails telling about problems finding device:
cannot open mixer: No such device
And amixer says:
amixer: Mixer attach default error: No such device
But there's no problem with /dev stuff (and same devices works pretty fine with kernel 2.6.33.2) - aplay -l doesn't work as well:
aplay: device_list:240: no soundcards found...
With kernel 2.6.33.2, aplay -l says:
**** List of PLAYBACK Hardware Devices **** card 0: SB [HDA ATI SB], device 0: VT2020 Analog [VT2020 Analog] Subdevices: 2/2 Subdevice #0: subdevice #0 Subdevice #1: subdevice #1 card 0: SB [HDA ATI SB], device 1: VT2020 Digital [VT2020 Digital] Subdevices: 2/2 Subdevice #0: subdevice #0 Subdevice #1: subdevice #1 card 1: HDMI [HDA ATI HDMI], device 3: ATI HDMI [ATI HDMI] Subdevices: 1/1 Subdevice #0: subdevice #0
A 'third party' mixer embedded in my distribution aborts by hitting a failed assertion in function
'snd_hctl_load' (hcontrol.c)
failing assertion being 'assert(hctl->count == 0)' - I've added a few simple lines above the assertion to print out some info on stderr, and got the following results:
In kernel 2.6.33.2:
hctl->count: 0 hctl->ctl: 134748144 (0x80817F0) hctl->ctl->name: hw:0
which seems reasonable - according to /proc/iomem address 0x80817F0 is in range 00100000-cf83ffff (system ram) and higher than kernel stuff subranges ( 01000000-012c3be7: Kernel code - 012c3be8-0141dadf : Kernel data - 01481000-014b1e03 : Kernel bss);
In kernel 2.6.38.2 & .38.3:
hctl->count: 1156 hctl->ctl: 5398 (0x1516) Segmentation fault
suggesting memory corruption (that's always the same address) - according to /proc/iomem address 0x1516 is in first range (0x0000-0xffff) which is reserved.
I thought (and hoped) that could have been somehow related to cached/noncached pages issue solved by commit c27b92295ab4c6b90b1cee94c4c9c1b4732e1c2e, but applying diff patch for kernel 2.6.38.3 didn't change anything. After that, I've read changelog for kermel 2.6.38.4 but such didn't seem to me to present related material, so I didn't updgrade.
I hope this post can help solving this issue and improving alsa infrastracture (I cannot easily go further). Best regards.