How to test the microphone on a laptop?

Question

Everything here works so far -- in that, crucially, the sound plays back.

How is the microphone itself tested?

nicholas@gondor:~$ 
nicholas@gondor:~$ sudo aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: Intel [HDA Intel], device 0: STAC9228 Analog [STAC9228 Analog]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: Intel [HDA Intel], device 1: STAC9228 Digital [STAC9228 Digital]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
nicholas@gondor:~$ 
nicholas@gondor:~$ aplay /usr/share/sounds/alsa/Front_Center.wav
Playing WAVE '/usr/share/sounds/alsa/Front_Center.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Mono
nicholas@gondor:~$ 
nicholas@gondor:~$ pacmd
Welcome to PulseAudio 13.99.2! Use "help" for usage information.
>>> list-sinks
1 sink(s) available.
  * index: 1
    name: <alsa_output.pci-0000_00_1b.0.analog-stereo>
    driver: <module-alsa-card.c>
    flags: HARDWARE HW_MUTE_CTRL HW_VOLUME_CTRL DECIBEL_VOLUME LATENCY DYNAMIC_LATENCY
    state: SUSPENDED
    suspend cause: IDLE
    priority: 9039
    volume: front-left: 49789 /  76% / -7.16 dB,   front-right: 49789 /  76% / -7.16 dB
            balance 0.00
    base volume: 65536 / 100% / 0.00 dB
    volume steps: 65537
    muted: no
    current latency: 0.00 ms
    max request: 0 KiB
    max rewind: 0 KiB
    monitor source: 1
    sample spec: s16le 2ch 48000Hz
    channel map: front-left,front-right
                 Stereo
    used by: 0
    linked by: 0
    configured latency: 0.00 ms; range is 0.50 .. 1837.50 ms
    card: 0 <alsa_card.pci-0000_00_1b.0>
    module: 23
    properties:
        alsa.resolution_bits = "16"
        device.api = "alsa"
        device.class = "sound"
        alsa.class = "generic"
        alsa.subclass = "generic-mix"
        alsa.name = "STAC9228 Analog"
        alsa.id = "STAC9228 Analog"
        alsa.subdevice = "0"
        alsa.subdevice_name = "subdevice #0"
        alsa.device = "0"
        alsa.card = "0"
        alsa.card_name = "HDA Intel"
        alsa.long_card_name = "HDA Intel at 0xfe9fc000 irq 29"
        alsa.driver_name = "snd_hda_intel"
        device.bus_path = "pci-0000:00:1b.0"
        sysfs.path = "/devices/pci0000:00/0000:00:1b.0/sound/card0"
        device.bus = "pci"
        device.vendor.id = "8086"
        device.vendor.name = "Intel Corporation"
        device.product.id = "284b"
        device.product.name = "82801H (ICH8 Family) HD Audio Controller (Inspiron 1420)"
        device.form_factor = "internal"
        device.string = "front:0"
        device.buffering.buffer_size = "352800"
        device.buffering.fragment_size = "176400"
        device.access_mode = "mmap+timer"
        device.profile.name = "analog-stereo"
        device.profile.description = "Analog Stereo"
        device.description = "Built-in Audio Analog Stereo"
        module-udev-detect.discovered = "1"
        device.icon_name = "audio-card-pci"
    ports:
        analog-output-speaker: Speakers (priority 10000, latency offset 0 usec, available: unknown)
            properties:
                device.icon_name = "audio-speakers"
        analog-output-headphones: Headphones (priority 9900, latency offset 0 usec, available: no)
            properties:
                device.icon_name = "audio-headphones"
    active port: <analog-output-speaker>
>>> q
Unknown command: q
>>> quit
Unknown command: quit
>>> exit
>>> nicholas@gondor:~$ 

above is from:

https://help.ubuntu.com/community/SoundTroubleshooting

Ideally, I'd record a few sounds with the microphone to then troubleshoot zoom itself.

Answer 1

Might be enough to:

arecord | aplay

though, it might sound better if you play with the recording settings to something like:

arecord -f FLOAT_LE -r 192000 -B 1 | aplay

where -B 1 decreases the buffer size to minimum to decrease the time between when something is recorded and when it's played back. -r 192000 is to increase the sampling rate to maximum. -f FLOAT_LE is the sample format that sounds best for me. Other formats are listed in the manpage where -f is documented.

Answer 2

Install Audacity using

sudo apt-add-repository universe
sudo apt-get install audacity

launch it, record some fragment using microphone, play the recorded sound.

Answer 3

Using textnow I was able to call the cell phone and got muffled sound. Exactly where the microphone is, or how good it is, I cannot say. But, it worked to an extent.

This establishes that the microphone functions and that the browser allows the microphone correctly.

This was using the Dell Inspiron 1420.

I consider the answer from N0rbert effectively complete, just want to continue testing before clicking the check mark.

Answer 4

I've had lots of hassles with this over the years. Often clicking around in the GNOME GUI left me still unable to get sound input working. You need to (1) select the right input, (2) get the gain set to something reasonable, and then (3) verify that it actually works.

Testing with Audacity doesn't necessarily work, because Audacity's menus make it extremely difficult to figure out which mic you're selecting. In Preferences, there is a menu that on my desktop system is extremely long, and the names don't make sense or connect to reality, e.g., I have a default:Front Mic:0, which actually seems to select a USB microphone that I have plugged into the back of the machine.

There are two sound systems on Linux, alsa and pulseaudio (PA). You probably have both running, one on top of the other. Alsa is low-level, and is controlled by commands like amixer. Pulseaudio is the software mixer, and is controlled by pacmd. GUI interfaces may provide sliders or knobs, but it can be hard to figure out whether they're manipulating the gain in Alsa or in PA. Older software like amixer predates PA, so it won't help you if your gain is set too low in PA.

The following command will tell you what mics you have:

pacmd list-sources | grep name:

(Note the colon at the end.) On my system, here's what the output looks like:

name: <alsa_input.usb-046d_HD_Webcam_C615_F8E031B0-00.mono-fallback>
name: <alsa_input.usb-C-Media_Electronics_Inc._TONOR_TC-777_Audio_Device-00.mono-fallback>
name: <alsa_output.pci-0000_00_1b.0.analog-stereo.monitor>
name: <alsa_input.pci-0000_00_1b.0.analog-stereo>

The first two names are easily identifiable as a USB webcam and a USB mic that I have plugged in. If you're using a "dumb" input like a phono plug, then it won't be identified so clearly. That's probably what the "analog-stereo" line is.

The following is a shell script I wrote that selects the mic I want and sets its gain to 100%.

#!/bin/sh

Select the Tonor mic and set it to 100% volume:
pacmd "set-default-source alsa_input.usb-C-Media_Electronics_Inc._TONOR_TC-777_Audio_Device-00.mono-fallback"
pacmd "set-source-volume alsa_input.usb-C-Media_Electronics_Inc._TONOR_TC-777_Audio_Device-00.mono-fallback 65000"

Video conferencing software such as zoom will by default try to set your mic gain automatically and without asking your permission. Sometimes it gets this wrong, which will break sound. You can turn off this misfeature, but most people don't know it exists. Running the script will reactivate sound when sound has been broken for this reason, but it's better just to deactivate the feature.

To verify that this is actually working, try the following:

arecord -l

Identify the part of the output from your mic, e.g.:

card 3: Device [TONOR TC-777 Audio Device], device 0: USB Audio [USB Audio]

This tells you that it's card 3, device 0. Then:

arecord -f S16_LE --device="hw:3,0" temp.wav

This should record sound into temp.wav. When you're done recording, hit control-C. You can verify that it worked by playing back the sound using aplay or by opening the file in audacity.