Re: Acer 5920 audio chip does not work in CentOS 5.2?

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



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@xxxxxxxxxxxx> 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@xxxxxxxxxxxx> 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
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos

[Index of Archives]     [CentOS]     [CentOS Announce]     [CentOS Development]     [CentOS ARM Devel]     [CentOS Docs]     [CentOS Virtualization]     [Carrier Grade Linux]     [Linux Media]     [Asterisk]     [DCCP]     [Netdev]     [Xorg]     [Linux USB]
  Powered by Linux