Does the microphone appear in the "Input Devices" tab of pavucontrol before the microphone restart? By "restart", do you mean setting the card profile to "Off" and then back to "Analog Input" (or whatever the profile is called)?

The verbose server log would be interesting. To get the log, put this to /etc/pulse/daemon.conf:

log-target = newfile:/tmp/pulselog.txt
log-level = debug

After reboot there should be file /tmp/pulselog.txt, and quite possibly also /tmp/pulselog.txt.1, /tmp/pulselog.txt.2 etc. If there are multiple files, attach the file with the highest number. (Please use the "Add an attachment" link. Sometimes people paste the log into the comment box, which makes it hard to read the discussion.)

To return things back to normal, undo the changes in daemon.conf.

Created attachment 137841 [details]
pulseverbose.log

Created attachment 137842 [details]
pulseverbose.log.1

Tanu, exactly!

Microphone does appear in the "input devices" and by restart I set card profile to "off" and then back to "Analog Input mono"!

Unfortunately I couldn't generate the log with your instructions but, I followed "Logging startup (advanced)" guide from:

https://wiki.ubuntu.com/PulseAudio/Log


Before powering off this card profile, input devices "sound level bar" react really slow compared with normal mic behavior!

I didn't see anything unusual in the log. It's strange if switching the profile is required. The source will suspend itself after being idle for a while, and I'd expect that to reset the kernel driver or the hardware equally well as a profile switch. Running pavucontrol prevents the source from suspending, but the log showed that the source was idle for long enough to suspend before you opened pavucontrol. So at least one suspension isn't enough.

Could you try the following:

After a reboot, check that the microphone is suspended with this command:

    pactl list sources short | grep usb

At the end of the line it should say SUSPENDED. If it says RUNNING or IDLE, wait for a few seconds and run the command again. If it's not changing to SUSPENDED, something is keeping the microphone open. Don't run pavucontrol, since it will keep all devices open all the time.

When you've checked that the microphone is suspended, record some audio from it with this command:

    parecord --device=alsa_input.usb-046d_0802_033D4660-02.analog-mono test.wav

Does that work? Is the audio ok? If it doesn't work, wait until the microphone is suspended again and try again. Repeat this a couple of times. If it doesn't start to work, then clearly suspending is not sufficient. Then try these commands:

    pactl set-card-profile alsa_card.usb-046d_0802_033D4660-02 off
    pactl set-card-profile alsa_card.usb-046d_0802_033D4660-02 input:analog-mono

That should have the same effect as changing the profile in pavucontrol. Does recording audio with parecord now work?

Created attachment 137872 [details]
test after reboot.wav

 pactl list sources short | grep usb
1	alsa_input.usb-046d_0802_033D4660-02.analog-mono	module-alsa-card.c	s16le 1ch 48000Hz	SUSPENDED

Created attachment 137873 [details]
test - first profile restart

Created attachment 137874 [details]
test - second profile restart.wav

test - second profile restart.wav

So "test after reboot.wav" and "test - first profile restart.wav" play too fast, but "test - second profile restart.wav" is fine.

The file names say "profile restart", but I'm not sure what you mean by that. I requested that you don't change the profile until you have tested a few times without changing the profile, so are all three files recorded without changing the profile at any point?

What if you just wait for a while after reboot, does the microphone work with the first try? Or is it really so that the first two recordings will always fail, no matter how long you wait, and from the third recording onwards things start to work?

Excuse my recklessness Tanu! I was so excited to show you a view of this mic behavior! 

I did not checked suspending sufficiency and proceeded changing the profile in pavucontrol with those commands you provided to me! 

But I'm pretty sure, although I lack your tecnical knowledge, that is suspension problem because I tried numerous times to use duolingo's microphone feature in the past!

Should I follow your directions and record some audio once more?

Yes, it would be good to do some more testing. The purpose is to figure out what exactly makes the microphone work. It seems unlikely that a profile switch is really required.

So, in summary: after rebooting, don't open pavucontrol or other audio programs, just record a bit of audio with parecord a few times. Before each recording, check that the source is suspended with the pactl command I gave earlier. If all of the recordings are bad, then switch the profile with pactl (still don't open pavucontrol) and try again. If that fixes the audio, then that suggests that a profile switch is indeed required (though I don't understand why that would be the case).

Also try the other thing I suggested: after a reboot, wait for a while without doing anything and then try recording. Maybe the hardware just takes some time to initialize itself properly.

(Note that in the end you're most likely going to file a bug for kernel/alsa, since this doesn't sound like anything that PulseAudio would be causing.)

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/pulseaudio/pavucontrol/issues/31.