Strange behaviour with snd_hda_intel at 1.0.13

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,
I've googled and browsed all the documentation that I can found and I
can't see anything that describes this problem, but if I have missed
something then feel free to point me to the appropriate source.

This is a bit long but I think more detail up front is probably helpful.

I have a Sony Vaio with a Intel ICH6 sound that identifies itself as:

        0000:00:1b.0 Class 0403: Intel Corp. 82801FB/FBM/FR/FW/FRW (ICH6 Family) High Definition Audio Controller (rev 03)

The Linux distribution that I installed (SuSE 9.2) didn't have the alsa
driver (snd-hda-intel) for this so I compiled and installed 1.0.11 and
the libs and tools and all was fine.

About a month ago SuSE made a security update to the kernel which
necessitated my rebuilding the alsa drivers so I downloaded 1.0.12 and
everything basically was fine except that gnome-volume-control stopped
working with:

ALSA lib pcm_hw.c:1357:(_snd_pcm_hw_open) Invalid value for card

for what is probably forever. I've assumed that this is either a
misconfiguration of the application or some mis-use of the API and just
haven't got round to getting the source of that version to see where the
problem lies.  But otherwise the sound was working (modulo the crackling
that is documented for the driver.)

Anyway, I decided yesterday to install the 1.0.13 drivers to see if that
would solve the problem with the gnome-volume-control and also the
crackling.  I installed the 1.0.13 drivers/libs/utils and just for good
measure the latest OSS api library.

Running alsaconf seemed fine, detecting the appropriate driver and so
forth, until it went to play the test sample where it seemed to hang
without making any sound. Okay that's fine, these things happen, so I ^C
the program. Checking the generated /etc/modprobe.d/sound it appears to
be fine:

        alias snd-card-0 snd-hda-intel
        alias sound-slot-0 snd-hda-intel

So check the levels in alsamixer and try to play the test sample in
alsaplayer as a normal non-root user and it comes up with a whole bunch
of errors relating to permissions on IPC objects and so forth (I can't
paste these as I haven't replicated this since.) I assume that this is
as a result of the alsaplayer hanging when run as root and my
terminating it and subsequently some resource not being released. So I
reboot.

Rebooted I again check the levels in alsamixer (and strangely they have
reverted to the all off default) and attempt to play the test sample
again ... it makes a sound, however unfortunately it appears that it is
playing the first "buffer full" of the sample over and over again for
what appears to be forever (or at least until my patience expired,
certainly longer than the original sample by a factor of 10.)  The the
same problem is experienced in aplay, play and it appears the sound
output of some other programs such as gaim so its not just a problem
with alsamixer.

All the modules appear loaded fine :

snd_pcm_oss            45736  0
snd_mixer_oss          18048  2 snd_pcm_oss
snd_hda_intel          19352  4
snd_hda_codec         161456  1 snd_hda_intel
snd_pcm                76168  4 snd_pcm_oss,snd_hda_intel,snd_hda_codec
snd_timer              23172  2 snd_pcm
snd_page_alloc         10504  2 snd_hda_intel,snd_pcm
snd                    57536  11
snd_pcm_oss,snd_mixer_oss,snd_hda_intel,snd_hda_codec,snd_pcm,snd_timer,snd_page_alloc
soundcore               9056  2 snd

I hadn't noticed it before but there now appears a [hda_codec] in the
process list as a child of [events/0] (it may have been there all along
while it was working but I didn't notice it.)

The only slightly suspicious thing I can see in dmesg is:

ALSA /home/jonathan/drivers/alsa/alsa-driver-1.0.13/alsa-kernel/pci/hda/hda_intel.c:540: hda_intel: azx_get_response timeout, switching to polling mode...

which kind of hints that this might be another symptom of the problem
(or otherwise indicative of the cause.) There are no other ALSA messages
in any of the logs.

It might be coincidental but firefox (which depends on libaoss) started
to develop random freezing behaviour since I changed the driver (though
I'm not quite sure why it needs the libray TBH.)
 
So, before I revert to an earlier version, has anyone got any clues as
to what might be going on here? I'm quite happy to do other tests etc to
provide debugging information. I'd even be quite happy to install a CVS
version as I'm sure it can't be worse than what I have now. However I am
suspecting that there is some configuration part that I have missed.




-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Alsa-user mailing list
Alsa-user@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/alsa-user

[Index of Archives]     [ALSA Devel]     [Linux Audio Users]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [Yosemite Photos]     [KDE Users]     [Fedora Tools]

  Powered by Linux