[vox-tech] ac97 sound problems
Kai Harris
vox-tech@lists.lugod.org
Thu, 25 Apr 2002 13:20:55 -0700
Mike,
thanks for all the info! however, working on possible kernel bugs and even
driver bugs is WAY over my head! i will submit a bug report to the via8233
driver maintainer though.
i have gotten ALSA up and running though....i can finally listen to some
music.
Kai
On Thursday 25 April 2002 10:50 am, you wrote:
> 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.
> _______________________________________________
> vox-tech mailing list
> vox-tech@lists.lugod.org
> http://lists.lugod.org/mailman/listinfo/vox-tech