l i n u x - u s e r s - g r o u p - o f - d a v i s
Next Meeting:
July 7: Social gathering
Next Installfest:
Latest News:
Jun. 14: June LUGOD meeting cancelled
Page last updated:
2002 Apr 25 15:55

The following is an archive of a post made to our 'vox-tech mailing list' by one of its subscribers.

Report this post as spam:

(Enter your email address)
Re: [vox-tech] ac97 sound problems
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [vox-tech] ac97 sound problems

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 

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
> # 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
vox-tech mailing list

LUGOD Group on LinkedIn
Sign up for LUGOD event announcements
Your email address:
LUGOD Group on Facebook
'Like' LUGOD on Facebook:

Hosting provided by:
Sunset Systems
Sunset Systems offers preconfigured Linux systems, remote system administration and custom software development.

LUGOD: Linux Users' Group of Davis
PO Box 2082, Davis, CA 95617
Contact Us

LUGOD is a 501(c)7 non-profit organization
based in Davis, California
and serving the Sacramento area.
"Linux" is a trademark of Linus Torvalds.

Sponsored in part by:
Sunset Systems
Who graciously hosts our website & mailing lists!