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