Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.os.linux.hardware > #759 > unrolled thread

Basic check of sound hardware?

Back to article view | Back to comp.os.linux.hardware

Contents

  Basic check of sound hardware? no.top.post@gmail.com - 2011-11-05 15:43 +0000
    Re: Basic check of sound hardware? Vilmos Soti <vilmos@soti.ca> - 2011-11-05 09:47 -0700
      Re (2): Basic check of sound hardware? no.top.post@gmail.com - 2011-11-06 03:27 +0000
      Re (2): Basic check of sound hardware? no.top.post@gmail.com - 2011-11-15 20:18 +0000
        Re: Re (2): Basic check of sound hardware? Vilmos Soti <vilmos@soti.ca> - 2011-11-16 22:55 -0800
          Re (3): Basic check of sound hardware? no.top.post@gmail.com - 2011-11-27 18:37 +0000
    Re: Basic check of sound hardware? Bit Twister <BitTwister@mouse-potato.com> - 2011-11-05 16:57 +0000
      Re (2): Basic check of sound hardware? no.top.post@gmail.com - 2011-11-06 03:27 +0000
        Re: Re (2): Basic check of sound hardware? Clemens Ladisch <clemens@ladisch.de> - 2011-11-29 21:04 +0100
      Re (2): Basic check of sound hardware? no.top.post@gmail.com - 2011-11-15 20:18 +0000

#759 — Basic check of sound hardware?

My MOBO has got the 3 sockets for sound, which I understand are:
left out, mic in, right out.

So just to confirm that the hardware is OK, what's the basic CLI command to:
=> input from mic-socket to a file;
=> output the same file to left/right out ?

Or does the mic-signal need to be amplified?

I think I've got some <sound files> somewhere, and remember that /dev/dsp
is involved ?

== TIA

[toc] | [next] | [standalone]

#760

no.top.post@gmail.com writes:

> My MOBO has got the 3 sockets for sound, which I understand are:
> left out, mic in, right out.
> 
> So just to confirm that the hardware is OK, what's the basic CLI command to:
> => input from mic-socket to a file;

cat /dev/audio > file

> => output the same file to left/right out ?

cat file > /dev/audio

Hey, you can even do a "cat /dev/audio > /dev/audio"
to test full duplex. You should hear anything you
speak into the mic back within a few (at most 10)
seconds.

In earlier systems, I could even do something like this:
cat /dev/audio

And watch the stuff on the screen. It was a fairly uniform
pattern. Once I started to talk into the nic, the pattern
drastically changed. Unfortunately, this very handy behaviour
is not there anymore.

> Or does the mic-signal need to be amplified?

For this simple test, no.

Vilmos

[toc] | [prev] | [next] | [standalone]

#763 — Re (2): Basic check of sound hardware?

In article <lq39e2zfc3.fsf@pia.msmri.medicine.ubc.ca>, Vilmos Soti <vilmos@soti.ca> wrote: 

> no.top.post@gmail.com writes:
> 
> > My MOBO has got the 3 sockets for sound, which I understand are:
> > left out, mic in, right out.
> > 
> > So just to confirm that the hardware is OK, what's the basic CLI command to:
> > => input from mic-socket to a file;
> 
> cat /dev/audio > file
> 
> > => output the same file to left/right out ?
> 
> cat file > /dev/audio
> 
--->   ls -l /dev/audio  ==
crw-------    1 root     root      14,   4 Sep 15  2003 /dev/audio

OK!
> Hey, you can even do a "cat /dev/audio > /dev/audio"
> to test full duplex. You should hear anything you
> speak into the mic back within a few (at most 10)
> seconds.
> 
> In earlier systems, I could even do something like this:
> cat /dev/audio
> 
> And watch the stuff on the screen. It was a fairly uniform
> pattern. Once I started to talk into the nic, the pattern
> drastically changed. Unfortunately, this very handy behaviour
> is not there anymore.
> 
> > Or does the mic-signal need to be amplified?
> 
> For this simple test, no.
> 
> Vilmos

Thanks, I'll try this when I get to my during-the-week-PC.
This one hasn't got any sound-sockets.
I move the IDE between PCs so the software can be the same.

BYW since you use emacs, my aim is to test emacspeak.
Do you have any knowledge/experience of emacspeak?
I'm wondering what <speech engine> linux uses.

== Chris Glur.

[toc] | [prev] | [next] | [standalone]

#809 — Re (2): Basic check of sound hardware?

In article <lq39e2zfc3.fsf@pia.msmri.medicine.ubc.ca>, Vilmos Soti <vilmos@soti.ca> wrote: 

> no.top.post@gmail.com writes:
> 
> > My MOBO has got the 3 sockets for sound, which I understand are:
> > left out, mic in, right out.
> > 
> > So just to confirm that the hardware is OK, what's the basic CLI command to:
> > => input from mic-socket to a file;
> 
> cat /dev/audio > file
> 
	`ls -l /dev/audio` is OK
	
> > => output the same file to left/right out ?
> 
> cat file > /dev/audio
> 
 I used a *.wav that lasted many seconds, but heard no sound on
 the earphones on any of the 3 sockets.
 What about going to a lowe level?  Shouldn't the sound-system be detected
 during boot-stage?  `dmesg` shows nothing for sound.
 This MOBO has got 2 USB sockets, but they seem dud and there's a 
 daughter-board with 2 working USB sockets. I'm guessing that the 
 previous owner damaged the MOBO USBs.  Can't that also happen to
 the sound chip?
 
 If it's a problem of IRQ setting, I guess `dmesg` would show that it
 was trying something?
 
> Hey, you can even do a "cat /dev/audio > /dev/audio"
> to test full duplex. You should hear anything you
> speak into the mic back within a few (at most 10)
> seconds.
> 
> In earlier systems, I could even do something like this:
> cat /dev/audio
> 
> And watch the stuff on the screen. It was a fairly uniform
> pattern. Once I started to talk into the nic, the pattern
> drastically changed. Unfortunately, this very handy behaviour
> is not there anymore.
> 
> > Or does the mic-signal need to be amplified?
> 
> For this simple test, no.
> 
> Vilmos

Yes, that's only possible if the lower-level is working first.

Thanks.

[toc] | [prev] | [next] | [standalone]

#811 — Re: Re (2): Basic check of sound hardware?

no.top.post@gmail.com writes:

>> cat file > /dev/audio
> 
>  I used a *.wav that lasted many seconds, but heard no sound on
>  the earphones on any of the 3 sockets.

Then that's actually a good sign. :-)

Don't expect to hear a "normal" sound when you send a .wav file
to /dev/audio. AFAIK, /dev/audio reads/writes sun .au format files.
try "locate .au" to find some.

With .wav, you will just hear a "white noise". But that would be a
good sign, since it proves that the sound system is ok. You just
sent a "wrongly" encoded file to the device.

If you cat anything to /dev/audio, and it "hangs", then it possibly
means that the soundcard is ok (no conflict), and just the volume
is turned down or most probably muted. Try alsamixer to muck around.
AFAIR, alsa mutes the soundcards by default.

And to avoid a retarded mistake once I did, do check that /dev/audio
is an actual device file, and not a regular file...

>  What about going to a lowe level?  Shouldn't the sound-system
> be detected during boot-stage?  `dmesg` shows nothing for sound.

Look around /proc/asound/. If it is there, then your soundcard
was found by the kernel. If not, then ... that's the problem.

>  This MOBO has got 2 USB sockets, but they seem dud and there's a 
>  daughter-board with 2 working USB sockets. I'm guessing that the 
>  previous owner damaged the MOBO USBs.  Can't that also happen to
>  the sound chip?

Yes, it can.

> If it's a problem of IRQ setting, I guess `dmesg` would
> show that it was trying something?

Also, in that case "cat file > /dev/audio" would return
immediately with an error message.

Vilmos

[toc] | [prev] | [next] | [standalone]

#872 — Re (3): Basic check of sound hardware?

In article <lqwrazxmpm.fsf@pia.msmri.medicine.ubc.ca>, Vilmos Soti <vilmos@soti.ca> wrote: 

> no.top.post@gmail.com writes:
> 
> >> cat file > /dev/audio
> > 
> >  I used a *.wav that lasted many seconds, but heard no sound on
> >  the earphones on any of the 3 sockets.
> 
> Then that's actually a good sign. :-)
> 
> Don't expect to hear a "normal" sound when you send a .wav file
> to /dev/audio. AFAIK, /dev/audio reads/writes sun .au format files.
> try "locate .au" to find some.
> 
> With .wav, you will just hear a "white noise". But that would be a
> good sign, since it proves that the sound system is ok. You just
> sent a "wrongly" encoded file to the device.
> 
> If you cat anything to /dev/audio, and it "hangs", then it possibly
> means that the soundcard is ok (no conflict), and just the volume
> is turned down or most probably muted. Try alsamixer to muck around.
> AFAIR, alsa mutes the soundcards by default.
> 
The hope is to test at the lowest most primitive level, rather than introduce
ANOTHER layer of unknown software.

> And to avoid a retarded mistake once I did, do check that /dev/audio
> is an actual device file, and not a regular file...
> 
> >  What about going to a lowe level?  Shouldn't the sound-system
> > be detected during boot-stage?  `dmesg` shows nothing for sound.
> 
> Look around /proc/asound/. If it is there, then your soundcard
> was found by the kernel. If not, then ... that's the problem.
> 
ls /proc/asound   ==
SI7012@ card0/ cards modules pcm timers UART@ card1/ devices oss/ seq/ version

 less /proc/asound/cards ==
0 [SI7012 ]: ICH - SiS SI7012 
                 SiS SI7012 with ALC100,100P at irq 11 
1 [UART ]: MPU-401 UART - MPU-401 UART 
                 MPU-401 UART at 0x300, irq 10

> 
> >  This MOBO has got 2 USB sockets, but they seem dud and there's a 
> >  daughter-board with 2 working USB sockets. I'm guessing that the 
> >  previous owner damaged the MOBO USBs.  Can't that also happen to
> >  the sound chip?
> 
> Yes, it can.
> 
> > If it's a problem of IRQ setting, I guess `dmesg` would
> > show that it was trying something?
> 
> Also, in that case "cat file > /dev/audio" would return
> immediately with an error message.
> 
> Vilmos
Where does the 3-wire cable from the CD [which does play 
and control an earphone volume] come in?

Does that feed into the sound-chip?

I haven't even looked at the many straps/jumpers!

[toc] | [prev] | [next] | [standalone]

#761

On Sat, 5 Nov 2011 15:43:04 +0000 (UTC), no.top.post@gmail.com wrote:

First, it always helps when you provide information Vendor, Model,
Distribution, version, desktop manager,.....

> My MOBO has got the 3 sockets for sound, which I understand are:
> left out, mic in, right out.

You may want to see if you can find a manual for your system.

Usually a 3 socket setup is Line IN, Mic In, Line OUT.
I think they may be color coded.
lime green line out
Pinkish Mic IN
Blueish Line IN

First you might want to run something like alsamixer-c 0
or aumix or kmix, .... and set all sliders to mid point.
If distribution is running pulseaudio, then use pavucontrol to
set/save slider settings.

If it were me I, would move the speaker plug/jack or headset plug/jack around
until the Line OUT socket was located.

Depending on Distro and Display manager you can use
play some.wav, or aplay some.wav for audio out.

I would recommend using something like audacity to locate the Mic in socket.

[toc] | [prev] | [next] | [standalone]

#762 — Re (2): Basic check of sound hardware?

In article <slrnjbaqn5.s2t.BitTwister@wb.home.test>, Bit Twister <BitTwister@mouse-potato.com> wrote: 

> On Sat, 5 Nov 2011 15:43:04 +0000 (UTC), no.top.post@gmail.com wrote:
> 
> First, it always helps when you provide information Vendor, Model,
> Distribution, version, desktop manager,.....
> 
My PCs are old hand-me-downs. And I expect computing to be
standardised.

> > My MOBO has got the 3 sockets for sound, which I understand are:
> > left out, mic in, right out.
> 
> You may want to see if you can find a manual for your system.
> 
> Usually a 3 socket setup is Line IN, Mic In, Line OUT.
> I think they may be color coded.
> lime green line out
> Pinkish Mic IN
> Blueish Line IN
> 
OK, I've got a daughter-board end-plate here and the mic
is in the middle. The metal plate is marked/labeled.

> First you might want to run something like alsamixer-c 0
> or aumix or kmix, .... and set all sliders to mid point.
> If distribution is running pulseaudio, then use pavucontrol to
> set/save slider settings.
> 
-> whereis alsamixer  == na

-> apropos mixer  ==
aumix                (1)  - adjust audio mixer
dump-mixers          (1)  - dump OSS mixer settings to standard output

> If it were me I, would move the speaker plug/jack or headset 
> plug/jack around until the Line OUT socket was located.
> 
> Depending on Distro and Display manager you can use
> play some.wav, or aplay some.wav for audio out.
> 
OK, I if it passes the CLI test I'll test a graphical-manager.

> I would recommend using something like audacity to 
> locate the Mic in socket.

Thanks, I'll test this when I get to my during-the-week PC.

[toc] | [prev] | [next] | [standalone]

#885 — Re: Re (2): Basic check of sound hardware?

no.top.post@gmail.com wrote:
> I expect computing to be standardised.

"The nice thing about standards is that you have so many to choose from."
(Andrew S. Tanenbaum)

> OK, I've got a daughter-board end-plate here and the mic
> is in the middle. The metal plate is marked/labeled.

Labeled with what?

>> First you might want to run something like alsamixer-c 0 ...
>
> -> whereis alsamixer  == na

Then you don't have the alsa-utils package (which also contains
aplay/arecord, which you also need for basic testing).  Try to
find it in the package manager of your distribution.

In any more or less modern distribution, this package also has
scripts to help with initializing the mixer settings.


Regards,
Clemens

[toc] | [prev] | [next] | [standalone]

#808 — Re (2): Basic check of sound hardware?

In article <slrnjbaqn5.s2t.BitTwister@wb.home.test>, Bit Twister <BitTwister@mouse-potato.com> wrote: 

> On Sat, 5 Nov 2011 15:43:04 +0000 (UTC), no.top.post@gmail.com wrote:
> 
> First, it always helps when you provide information Vendor, Model,
> Distribution, version, desktop manager,.....
> 
> > My MOBO has got the 3 sockets for sound, which I understand are:
> > left out, mic in, right out.
> > 
> > So just to confirm that the hardware is OK, what's the basic CLI command to:
> > => input from mic-socket to a file;
> 
> You may want to see if you can find a manual for your system.
> 
I expect PCs to be comodity items like pencils.

> Usually a 3 socket setup is Line IN, Mic In, Line OUT.
> I think they may be color coded.
> lime green line out
> Pinkish Mic IN
> Blueish Line IN
> 
> First you might want to run something like alsamixer-c 0
> or aumix or kmix, .... and set all sliders to mid point.
> If distribution is running pulseaudio, then use pavucontrol to
> set/save slider settings.
> 
> If it were me I, would move the speaker plug/jack or headset 
> plug/jack around until the Line OUT socket was located.
> 
> Depending on Distro and Display manager you can use
> play some.wav, or aplay some.wav for audio out.
> 
> I would recommend using something like audacity to 
> locate the Mic in socket.

The low-level: cat *.wav > /dev/audio gives no sound
at any of the 3 sockets, with an earphone, while it's taking
20 seconds to 'play'.

I'd have to go to a low-level, like I had big problems getting a
zero-CD wireless modem working which had no linux drivers.

You have to use `lsusb` to see what USB is detected during
boot-probing and/or PnP, check which /dev/* is connected
to the device ..etc.

I don't know how/if IRQs are involved too?!

Thanks.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.os.linux.hardware

csiph-web