USB microphone inputs not detected by Pulseaudio on Kubuntu Trusty

[Julius Schwartzenberg]

When I connect an audio device using USB, I can only use it to play back stereo sound. Anything else is not detected. I tried it with two different devices and they both give me the same result. Neither in KDE nor in Google Hangouts, I can use my microphone. It does not show up as a selectable input device anywhere.

ALSA does seem to correctly detect that these USB devices have a microphone.

The microphone of my internal audio does work.

Ubuntu release is 14.04
Package version of Pulseaudio is 1:4.0-0ubuntu11

ProblemType: Bug
DistroRelease: Ubuntu 14.04
Package: pulseaudio 1:4.0-0ubuntu11
ProcVersionSignature: Ubuntu 3.13.0-27.50-generic 3.13.11
Uname: Linux 3.13.0-27-generic x86_64
ApportVersion: 2.14.1-0ubuntu3.2
Architecture: amd64
CurrentDesktop: KDE
Date: Sun Jun 1 01:13:50 2014
SourcePackage: pulseaudio
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 07/08/2008
dmi.bios.version: 1.04
dmi.board.name: JHL91
dmi.board.version: REFERENCE
dmi.chassis.type: 1
dmi.chassis.version: N/A
dmi.modalias: dmi:bvn:bvr1.04:bd07/08/2008:svn:pn:pvr:rvn:rnJHL91:rvrREFERENCE:cvn:ct1:cvrN/A:

[Raymond (superquad-vortex2)]

your HDMI and onboard Mic have higher priority than your USB Audio device

Default sink name: alsa_output.pci-0000_00_1b.0.hdmi-stereo
Default source name: alsa_input.pci-0000_00_1b.0.analog-stereo

analog-input-microphone: Microfoon (priority 8700, latency offset 0 usec, available: yes)
   properties:
    device.icon_name = "audio-input-microphone"

  hdmi-output-0: HDMI / DisplayPort (priority 5900, latency offset 0 usec, available: yes)
   properties:
    device.icon_name = "video-display"
    device.product.name = "SONY AVAMP"
    index: 3

[Julius Schwartzenberg (jschwart)]

That is correct, but changing the priorities does not allow the other recording devices to show up.

[Julius Schwartzenberg (jschwart)]

On #pulseaudio, fritsch gave me the suggestion to look at the output of 'pulseaudio -vvv'.
Here is the log produced when reconnecting the 1st device. After this its microphone actually showed up!

[Julius Schwartzenberg (jschwart)]

The I connected the second device. This did not give me any microphone input option. Here is the log of that.

[Julius Schwartzenberg (jschwart)]

After standby, Pulseaudio completely refuses to detect my device properly when I remove and insert multiple times it I get either:
- nothing
- only a stereo playback device
- only a recording device

I do not get both at the same time.

[David Henningsson (diwic)]

Error -16 means "EBUSY", or that some other application or daemon is trying to use the device, so PulseAudio can't open it. Could you check with this command:

sudo fuser -v /dev/snd/*

to see if anything else is trying to grab the mic input?

[Julius Schwartzenberg (jschwart)]

I just tried plugging in my second USB device and only the playback device was recognized, the microphone was not. Here is the output:

$ fuser -v /dev/snd/*
                     GEBRUIKER PID SOORT PROGRAMMA
/dev/snd/controlC0: julius 3304 F.... pulseaudio
                     julius 4056 F.... pulseaudio
/dev/snd/controlC1: julius 3304 F.... pulseaudio
                     julius 4056 F.... pulseaudio
/dev/snd/controlC2: julius 3304 F.... pulseaudio
                     julius 4056 F.... pulseaudio
/dev/snd/pcmC0D3p: julius 3304 F...m pulseaudio
/dev/snd/pcmC1D0c: julius 3304 F...m pulseaudio
/dev/snd/pcmC1D0p: julius 3304 F...m pulseaudio

The new device is on /dev/snd/pcmC2* so it doesn't seem to be used by something else. I'm a bit surprised there are two pulseaudios with different PIDs active though. Could that be a problem?
I'm in a phone call (pcmC1) and playing music over HDMI (pcmC0D3), so it's correct it's using those devices. When I do a reboot, it seems the device is always recognized properly. It's just hot-plugging which doesn't tend to work correctly.

[David Henningsson (diwic)]

 > I'm a bit surprised there are two pulseaudios with different PIDs active though. Could that be a problem?

Yes, probably. On hotplugging, they could both try to probe the device at the same time, and only one of them succeeds. Probably one of the instances gets the playback and the other one gets the recording.

The question is why there is second instance of pulseaudio (4056 in the list above). Any attempt to start such an instance should fail if there is already a pulseaudio present and working.

[Julius Schwartzenberg (jschwart)]

It seems that on Kubuntu Trusty, by default two pulseaudios are running:
$ ps aux|grep pulse
julius 3414 1.1 0.1 588164 7056 ? S<l 19:38 0:56 /usr/bin/pulseaudio --start --log-target=syslog
julius 3969 0.0 0.1 502228 5520 ? S<l 19:41 0:00 /usr/bin/pulseaudio --start --log-target=syslog

The log-in process start pulseaudio 2 times and the presence detection appears to be broken.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[juanmanuel (rockerito99)]

I found the root cause and wrote it in comments 21 and 22 of the duplicate bug:

           https://bugs.launchpad.net/ubuntu/+source/ubuntu-drivers-common/+bug/1296425

SUMMARY: ubuntu-drivers-common scripts (sl-modem.py) are calling "aplay -l" with an empty environment, thus "aplay -l" creates a new "pulseaudio" process instead of using the session's pulseaudio, which interferes with sound card recognition (device busy errors). There is a one liner fix in the comment. Kubuntu calls ubuntu-drivers-common scripts on login to KDE, but the issue affects also Ubuntu users if they run any program that calls those scripts, until they restart.

Cheers,
Juan Manuel Cabo