[CentOS] Acer 5920 audio chip does not work in CentOS 5.2?

John Bowden

j-alan at btconnect.com
Mon Jul 7 18:51:58 UTC 2008


On Monday 07 July 2008 10:50:11 William L. Maltby wrote:
> On Mon, 2008-07-07 at 11:48 +1000, hce wrote:
> > On 7/4/08, William L. Maltby <CentOS4Bill at triad.rr.com> wrote:
> > >  On Fri, 2008-07-04 at 12:41 +1000, hce wrote:
> > >  > On Fri, Jul 4, 2008 at 12:18 AM, William L. Maltby
> > >  >
> > >  > <CentOS4Bill at triad.rr.com> wrote:
> > >  > ><snip>
> > >  > >
> > >  > > After this, I'll pop in Mark Knoppfler's "Shangri-La" and diff the
> > >  > > two files.
> > >  > > # cd /proc/asound
> > >  > > # find . -type f -exec echo {} \; -exec cat {} \; >/tmp/asound
> > >  >
> > >  > I guess alsa and /proc are all fine on my machine, but I've got a
> > >  > blank result on /proc/asound running following find, no sure if that
> > >  > was significant:
>
> If all files below /proc/asound are empty after trying to play a sound
> are empty, things can't be alright and that is significant. What it
> implies, I haven't a clue.
>
> > > Blank result? I'm skeptical about that. <*scratching head*>
> > >
> > >  > [asound]$ find . -type f -exec echo {} \; -exec cat {} \; >
> > >  > /tmp/asound
> > >
> > > The /tmp/asound file should contain at least the file names that it
>
> s/file/files found under asound and its sub-dirs/
>
> > >  found. And I can't believe that trying to play something would remove
> > >  the contents of those files. 1) It would have to be root and 2) IIRC,
> > > we can't remove stuff in /proc as it is from the kernel and not a real
> > > file system and 3) We could only change the contents of *some* things.
> > >
> > >  I tested the above command with a C&P and it worked. Maybe you had a
> > >  typo or the frustration is getting to you and you examined the wrong
> > >  file?
> >
> > I used above command with a C&P as well. I've also verified the
> > command to my another FC7 box which has sound worked well, it also
> > shown a blank result as well.
>
> That puts me at a total loss. If every file below the /proc/asound tree
> is empty after trying to play a file/CD is empty, then all the driver
> modules would be gone. Then an lsmod should show no drivers loaded. If
> drivers appear in lsmod, some files under asound and its sub-directories
> have to be non-empty.
>
> Remember that an ls -lR /proc/asound will show 0-length files even
> though there is something in those files. If you depended on ls to
> determine if a file was empty, that's a mistake.
>
> > >  > $ rpm -qa | grep -i alsaalsa-utils-1.0.14-3.rc4.el5
> > >  > alsa-lib-devel-1.0.14-1.rc4.el5
> > >  > alsa-lib-1.0.14-1.rc4.el5
> > >  >
> > >  > ]$ rpm --verify  alsa-lib-1.0.14-1.rc4.el5.i386
> > >  > alsa-utils-1.0.14-3.rc4.el5.i386 | echo $?
> > >  > 0
> > >
> > > The above command s/b rpm --verify .... ; echo $?
> > >  ----------------------------------------|
> > >
> > >  If you meant "||", it would still be logically incorrect as we want to
> > >  see the return value, regardless.
> >
> > Actually, I tried without echo $? first, it display lots of
> > parameters, seems file. I can try the echo $? again, what is the
> > correct command for it? Is following command correct?
> >
> > rpm --verify  alsa-lib-1.0.14-1.rc4.el5.i386
> > lsa-utils-1.0.14-3.rc4.el5.i386; echo $?
>
> If that is all on one line or the first line ends with a " \", yes. But
> the form with "-v --verify" is useful too. It will let you know if
> something is scrogged. The man page for rpm will tell the meaning of the
> output. If you put a redirect to a temporary file, you can look at the
> results. Something like this
>
>    rpm -v --verify ... ... >/tmp/rpm.lst; echo $?
>
> > >  > [asound]$ ls
> > >  > card0  cards  devices  Intel  modules  oss  pcm  seq  timers 
> > >  > version
> > >  >
> > >  > [asound]$ pwd && cat modules && cat cards /proc/asound
> > >  >  0 snd_hda_intel
> > >  >  0 [Intel          ]: HDA-Intel - HDA Intel
> > >  >                       HDA Intel at 0xf0500000 irq 66
> > >  >
> > >  >
> > >  > I've also tried to ls in /proc/asound/Intel:
> > >  >
> > >  > $ ls
> > >  > codec#0  codec#1  id  oss_mixer  pcm0c  pcm0p  pcm2c
> > >  >
> > >  > Seems, all drivers there, is there any command such as cat to verify
> > >  > low level drivers by playing a sound?
> > >
> > > You need an application to do that. I've only used various Gnome
> > > desktop facilities. The file manager (Nautilus?) should do that when
> > > you double click a sound file. I'll test ... BRB
> > >
> > >  Yep. I went to /usr/share/sounds/alsa, using file manager, and it
> > > opened totem and played the sounds. This means that you could open
> > > totem directly, or any other sound playing application and try it.
> > >  Unfortunately, unless we suspect broken applications are the problem,
> > >  this really only is the same as what you tried to do originally, less
> > >  the CD.
> >
> > I can use vlc to play the *.wav or other audio files, but I tried to
> > figure out where is the block or missing link with the audio. Right
> > now, no sound when I run vlc to play audio files. If I could check and
> > play in some means with low level driver first, I guess I could find
> > if the problem is high level applications or low lever drivers. Seems
> > that the drivers all there, but don't know if them are working or not.
>
> ISTR that long ago there were CLI sound/CD players. I don't know if
> there are any left. I suggest a Google.
>
> > Thank you.
> >
> > Kind Regards,
> >
> > Jim
> > <snip sig stuff>

Stupid question, have you tested the speakers on another system, is the cable 
plugged into the correct socket on the back plane / sound card?
John

-- 
Guy Fawkes, the only man to enter the house's of Parliament
with honest intentions, (he was going to blow them up!)
Registered Linux user number 414240



More information about the CentOS mailing list