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