[vox-tech] ac97 sound problems
vox-tech@lists.lugod.org
vox-tech@lists.lugod.org
Thu, 25 Apr 2002 13:50:14 -0400
Kai,
I'm going to rearrange some things...
On Wed, Apr 24, 2002 at 09:15:51PM -0700, Kai Harris wrote:
> 1. the ac97 device driver is being loaded on startup:
> Via 686a audio driver 1.9.1
> ac97_codec: AC97 Audio codec, id: 0x414c:0x4710 (ALC200/200P)
> via82cxxx: board #1 at 0xE800, IRQ 11
>
> via_audio: ignoring drain playback error -11
Okay quick scan says that when the driver is being unloaded, it waits
around to play the last of the audio that is queued for the device.
If the device was open in non-blocking mode, then it will allow an
application to release the device before the buffer is really empty,
-11 or (-EAGAIN) i what it returns if this happens.
There is an obvious endless loop inside the kernel if the device was
opened in standard blocking mode and any audio was sent to it, and there
is something wrong... because the loop looks like the last chunk below.
The only reason your machine doesn't lock solid in this loop is there
is a "schedule()" call inside which allows the kernel to do something
else if it thinks there is something to do.
./drivers/sound/via82cxxx_audio.c
# * via_dsp_drain_playback - sleep until all playback samples are flushed
# *
# * Sleeps until all playback has been flushed to the audio
# * hardware.
/usr/include/asm/errno.h:
# #define EAGAIN 11 /* Try again */
./drivers/sound/via82cxxx_audio.c
# for (;;) {
# __set_current_state(TASK_INTERRUPTIBLE);
# if (atomic_read (&chan->n_frags) >= chan->frag_number)
# break;
#
# if (nonblock) {
# DPRINTK ("EXIT, returning -EAGAIN\n");
# ret = -EAGAIN;
# break;
# }
[...]
# }
> 4. top shows multiple copies of aRtsd running and I cannot kill them. They
> continue to run after I log out of KDE and X and cannot be killed by their
> owner (me), or by root. If I completely log out and then log in as root,
> they are still running. One of these processes uses a significant amount of
> CPU% (80-90%).
>
> It seems to me that this is a very likely culprit. Is it possible for aRtsd
> to bork so that it won't even respond to a kill signal? where would I go to
> look for reasons for such a freeze?
aRtsd must open the device in blocking mode, combined with the code above
it explains the following...
The process that is using 90% of the CPU is the first one to open the
device and play the login greeting for KDE (or whatever)... since it sent
some audio to the device there is something in the buffer, which is trying
to be played but can't, so when aRtsd tried to close the device you hit
that endless kernel loop.
The reason the other processes are using none of the CPU is standard
kernel sound drivers create open once devices... the first open causes
anyone else to block waiting for the caller to close the device before
they can continue... if the first process exited *then* the others would
have a chance to go.
If you send a "kill -9" and the process does not die instantly, then
you have a kernel bug... there is no way to "block" or "hide" from kill -9.
However, do not start killing things with -9, many programs have cleanup
operations they need to run when exiting, by using -9 they never get
to run their shutdown things, and that might mess up those programs on
the next start. So only try kill -9 on things that you tried a normal
kill and 5 seconds later they are still around.
So you have a kernel bug.
> 5. when playing an mp3 using mpg123 directly after a reboot, mpg123 plays
> without returning an error message. however, there is no sound. Ctrl-c
> mpg123 and run it again returns an error message:
> audio: Resource temporarily unavailable
Something odd about this report is the
"Resource temporarily unavailable" message
is a EAGAIN thing, which you should only get if mpg123 opens something
non-blocking, the fact that when you hit cntl-c you get a prompt back
means that it is not hitting the same bug as above ... my copy mpg123
opens /dev/dsp in blocking mode so you might have another mpg123 variant.
It appears there might be another bug in the audio driver in that it
doesn't make the device available again to the next program after the
first closes.
> 2. the soundcard is setup as a module.
> from /etc/modules.conf:
> alias sound-slot-0 via82cxxx_audio
The dmesg output explains which drive you are using, this contains
nothing new. Good to include that file in bug reports though, so
people know nothing is wrong there.
> 6. Logging into X and KDE gives error message:
> error: Error while initializing the sound driver:
> device /dev/dsp can't be opened (Resource temporarily unavailable)
> The sound server will continue, using the null output device
>
> I do not know what to do. I have looked for help at the Mandrake Support
> center and done multiple google searches on everything from my particular
> error messages to generic ac97 support. I have searched VIA's support
> center. Anybody have an idea?
I checked out the ALSA sound driver for that card is _completely_
different code from the kernel version you are running. Which means
there is a fair chance that it will work... try that next, I think
Mark gave you some pointers.
The other thing would be to report to the kernel developer in question
your results (possibly this email). Since I don't have your hardware
and I'm not a kernel hacker, I'd be pretty useless trying to figure
out how to fix that problem.
/usr/src/linux/MAINTAINERS
# VIA 82Cxxx AUDIO DRIVER
# P: Jeff Garzik
# L: linux-via@gtf.org
# S: Odd fixes
/usr/src/linux/Documentation/DocBook/via-audio.sgml
# Please send bug reports to the mailing list linux-via@gtf.org
# To subscribe, e-mail majordomo@gtf.org with "subscribe linux-via"
# in the body of the message.
Anyway here is an archive of that mailing list:
http://marc.theaimsgroup.com/?l=linux-via&r=1&w=
I don't see alot of activity there... but check it out.
Sounds like there are three drivers for that chipset:
kernel, ALSA, OSS... maybe one will work.