pulseaudio is started twice - effectively making device management impossible.

Bug #1296425 reported by Søren Holm on 2014-03-23
92
This bug affects 18 people
Affects Status Importance Assigned to Milestone
alsa-plugins (Ubuntu)
High
Unassigned
Trusty
Undecided
Unassigned
ubuntu-drivers-common (Ubuntu)
Undecided
Martin Pitt
Trusty
High
Unassigned

Bug Description

[Impact]

On the current kubuntu 14.04 live-image (and for a 13.10 upgraded system) pulseaudio is running twice. This makes attaching/deattaching of usb-headset and other stuff impossible because the two instances fight over the events.

The fix is https://github.com/tseliot/ubuntu-drivers-common/commit/5fe70ce1

[Test Case]

To reproduce just boot up the current image and do a "ps -ef | grep pulseaudio"

[Regression Potential]

Low. This fix has been out for many months in 14.10, and only changes the environment that "aplay -l" gets called with. In the absolutely worst case if this goes totally wrong, ubuntu-drivers would stop to detect sl-modem capable soft-modems.

ProblemType: Bug
DistroRelease: Ubuntu 14.04
Package: pulseaudio 1:4.0-0ubuntu10
ProcVersionSignature: Ubuntu 3.13.0-19.39-lowlatency 3.13.6
Uname: Linux 3.13.0-19-lowlatency i686
ApportVersion: 2.13.3-0ubuntu1
Architecture: i386
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC1: sgh 2336 F.... pulseaudio
                      sgh 2796 F.... pulseaudio
 /dev/snd/controlC0: sgh 2336 F.... pulseaudio
                      sgh 2796 F.... pulseaudio
CurrentDesktop: KDE
Date: Sun Mar 23 22:36:50 2014
InstallationDate: Installed on 2013-12-24 (89 days ago)
InstallationMedia: Kubuntu 14.04 LTS "Trusty Tahr" - Alpha i386 (20131224)
SourcePackage: pulseaudio
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 07/02/2012
dmi.bios.vendor: LENOVO
dmi.bios.version: G7ET31WW (1.13 )
dmi.board.asset.tag: Not Available
dmi.board.name: 2356GCG
dmi.board.vendor: LENOVO
dmi.board.version: Not Defined
dmi.chassis.asset.tag: No Asset Information
dmi.chassis.type: 10
dmi.chassis.vendor: LENOVO
dmi.chassis.version: Not Available
dmi.modalias: dmi:bvnLENOVO:bvrG7ET31WW(1.13):bd07/02/2012:svnLENOVO:pn2356GCG:pvrThinkPadT430s:rvnLENOVO:rn2356GCG:rvrNotDefined:cvnLENOVO:ct10:cvrNotAvailable:
dmi.product.name: 2356GCG
dmi.product.version: ThinkPad T430s
dmi.sys.vendor: LENOVO

Søren Holm (sgh) wrote :
Søren Holm (sgh) wrote :

I can add that it is the first instance started that is the correct one. Shutting that doesn will make it respawn. That is not the case for the second instance.

Søren Holm (sgh) wrote :

The issue is also present when running the latest cd-image in virtualbox.

Launchpad Janitor (janitor) wrote :

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

Changed in pulseaudio (Ubuntu):
status: New → Confirmed
Søren Holm (sgh) wrote :

It does not happend in Unity - only KDE.

It renders essential functionality of the package (or a dependent one) broken.

Changed in pulseaudio (Ubuntu):
importance: Undecided → High
Søren Holm (sgh) wrote :

Is anything happening with this bug. I'll be happy to recompile anything to help tracking this down.

Søren Holm (sgh) wrote :

Heres a log on a KDE startup and as far as I can see it is a cascade looking something like this.

DriverManager start python3 which then starts aplay which then again starts pulseaudio. Parallel to that kmixctl is also starting pulseaudio. Both lines of events happen 2 or 3 times. They sort of race eachother.

Søren Holm (sgh) wrote :

Another thing. The *first* pulseaudio is the instance that works and respawns if killed. So kmixctl is from my perspective allowed to start pulseaudio aplay is not.

Søren Holm (sgh) wrote :

ok - "chmod -x /usr/bin/aplay" solves it. Now that aplay does not run pulseaudio no additional instances is run.

Now the question is why aplay runs pulseaudio.

Lokking the the alsa-repositories I found the following
* alsa-utils - nothing interesting.
* alsa-lib - nothing interesting.
* alsa-plugins - lots of pulseaudio related stuff.

It also turns out that leaving aplay executable and uninstalling libasound2-plugins gives a working system with no duplicate pulseaudio processes.

affects: pulseaudio (Ubuntu) → alsa-plugins (Ubuntu)
Søren Holm (sgh) wrote :

Am I the only one that cares for this bug. Unfortunately I'm unable to figure out why aplau trigger pulseaudio to that more times. And release is in 48 hours or so.

lordievader (oliviervdtoorn) wrote :

This happens in Kubuntu Utopic too.

lordievader (oliviervdtoorn) wrote :

My workaround is disabling Pulseaudio's respawn and starting Pulseaudio through ~/.profile.

David Henningsson (diwic) wrote :

Well, the question is why aplay -> alsa pulse plugin -> libpulse does not connect to the existing instance but instead starts a new one.
What about the files in /var/run/user/<userid>/pulse/ - if there are pid files, to they point to the new-invalid or old-valid pulse instance?

At the end here at least, the pid file points to the lowest PID. Could I check it during the start-up phase as well? Could it be possible the 2nd instance is already loading before the 1st has a chance to write its pid file?

Does it make sense that Pulseaudio's respawn option should be turned on, while it is also explicitly loaded by the log-on scripts? I would say either it either uses or respawn or it's loaded already when logging in.

Søren Holm (sgh) wrote :

Did you see my systemtao log of a KDE login from a cold reboot.

https://launchpadlibrarian.net/172625307/kde-login.stap

David Henningsson (diwic) wrote :

It seems to be specific to KDE too. It could be related to KDE having a login sound which Unity does not have (I assume that's what the aplay does?), but it could also be something in the way KDE sets up sessions...?

Yes, it only seems to happen with KDE. I also found that Pulseaudio installs one extra start-up script for KDE only in /etc/xdg/autostart. The man pages of these scripts both mention they will use an already running Pulseaudio.

I think the proper solution is either:
- run Pulseaudio *once* and never again (when logging in)
- fix Pulseaudio's self-detection so that it works when the first instance is still initializing

As for running Pulseaudio as a specific user, I wonder what would happen when multiple users are logging onto a system at the same time. Would this not create a similar conflict with each user's Pulseaudio trying to use the ALSA devices at the same time?

David Henningsson (diwic) wrote :

 > - fix Pulseaudio's self-detection so that it works when the first instance is still initializing

Yes, this is what should happen.

 > As for running Pulseaudio as a specific user, I wonder what would happen when multiple users are logging onto a system at the
 > same time. Would this not create a similar conflict with each user's Pulseaudio trying to use the ALSA devices at the same time?

Only one user can have access to keyboard and screen at the same time, same should go for the sound card. Access to the sound card is handled by logind/consolekit.

Søren Holm (sgh) wrote :

Pulseaudio and KDE aside.

What is aplay doing the the KDE-startup sequence in the first place?
I know theres a login sound, but should'nt that be played by some application through pulseaudio directly.?

juanmanuel (rockerito99) wrote :
Download full text (3.5 KiB)

On saturday I made some tests and found the root CAUSE of the issue, and the SOLUTION.

The reason "aplay" is called, is because it is used to enumerate sound cards,
(with the -l argument as in "aplay -l"), by ubuntu-drivers, to find ye-old software modems.
The "ubuntu-drivers-common" package scripts are called by the "kubuntu-driver-manager"
package scripts on login to KDE's desktop. Aplay is also called when going to AdditionalDrivers
or running "ubuntu-drivers list".

The reason why the "pulseaudio" process created by 'aplay' remains running, is because "aplay" and thus
"pulseaudio" receive an empty environment (no environment variables).
    Since "pulseaudio" receives an empty environment, it cannot know from which session or
DISPLAY it was called, and whether another pulseaudio is already running for that session.

Because of that, we end up with two different pulseaudio processes, and thus one interferes with the
other, producing "device busy" errors while plugging our USB headsets/mics/webcams,
resulting in them not getting fully recognized.

The solution is as follows: Edit this file:

          /usr/share/ubuntu-drivers-common/detect/sl-modem.py

and replace this line:

        aplay = subprocess.Popen(['aplay', '-l'], env={},

with this line:

        aplay = subprocess.Popen(['aplay', '-l'],

By removing the named 'env={}' argument, the "aplay -l" receives the environment
and can distinguish the correct pulseaudio process.

Another way to workaround this, but quick and dirty, is to simply add a line:

         return None

right above the aplay line, with the same spacing (indentation level), to disable looking for software modems at login if you don't plan on using dial-up modems :-)

Details:
--------

I obtained the process list by adding redirecting 'aplay' temporarily to a script, which had a "sleep 30" delay, so
that I could get it in "ps axf".
The process list at the time of calling aplay is:

        \_ init --user
            [...]
            \_ dbus-daemon --fork --session --address=unix:abstract=/tmp/dbus-l0CdfJrRGy
            | \_ [dbus-daemon] <defunct>
            [...]
            \_ python3 /usr/lib/kde4/libexec/DriverManager_DBus
                \_ /usr/bin/aplay -l
                    \_ /usr/bin/pulseaudio --start --log-target=syslog

Looking by the process number, for the second pulseaudio instance,
          cat /proc/NNNN/environ
is empty.
I found by tracing the python calls that the file which runs aplay is:

          /usr/share/ubuntu-drivers-common/detect/sl-modem.py

(if I skip/comment the call to aplay on that file, the issue dissapears).
The file "sl-modem.py" belongs to the package:

          ubuntu-drivers-common

and the DriverManager_DBus script which runs at logon belongs to the package:

          kubuntu-driver-manager

which explains why this issue only affects us Kubuntu users, but in reality,
it also affects all Ubuntu users, because any time they enter the
driver manager (either by softwarke-properties-gtk or "Additional Drivers", or
by running "ubuntu-drivers list" in the console) they are going to get a
duplicate process for "pulseaudio" until they restart.

Many...

Read more...

Changed in ubuntu-drivers-common (Ubuntu):
status: New → Confirmed
status: Confirmed → New
juanmanuel (rockerito99) wrote :

I'm sorry that the previous post was too long.
This is the summary:

1) "aplay -l" gets called with an empty environment by a script in ubuntu-drivers-common which Kubuntu runs at startup, through the "DriverManager_DBus".
"aplay -l" doesn't find a pulseaudio and creates a new one (through libasound), because it has no environment and no way to know the session on which pulseaudio is already running.

2) The solution is to: Edit this file:
          /usr/share/ubuntu-drivers-common/detect/sl-modem.py
and replace this line:
        aplay = subprocess.Popen(['aplay', '-l'], env={},
with this line:
        aplay = subprocess.Popen(['aplay', '-l'],

NOTE TO MAINTAINERS: please evaluate if this solution is safe and sound, and if so, create a patch so that everyone benefits, and can have USB sound devices usable again (no more "device busy" errors while having an spurious extra pulseaudio instance).

Cheers,
Juan Manuel Cabo

Victor Nieto (victor-nieto-vn) wrote :

@juanmanuel , your solution worked for me. I am running 14.04 upgraded from 13.10.

Søren Holm (sgh) wrote :

Works on current 14.10 also. Good job juanmanuel !!

Also solved the problem here!

Using 'aplay -l' seems like a rather strange hack to detect a software modem. I think either the Python ALSA bindings or /proc/asound/cards for that instead only. Right now 'aplay -l' apparently is only called when no modem is found through /proc/asound/cards as a fallback.

Martin Pitt, is there any specific reason for this fallback behavior? Should it be reimplemented using Python's ALSA bindings or maybe could be gotten rid off completely?

Martin Pitt (pitti) wrote :

The aplay call was introduced in http://bazaar.launchpad.net/~jockey-hackers/jockey/trunk/revision/519 for bug 295158. Apparently some sl-modem types don't appear in /proc/asound/cards. It's indeed a strange hack, but so is sl-modem in the first place :) Beyond that bug report I'm afraid I have no idea about this -- I never had such a modem, and thus I don't have the opportunity to test any change.

I don't know why aplay invokes pulseaudio (that seems wrong, as pulseaudio usually uses ALSA as a backend), but if passing on the environment (for DBUS_SESSION_BUS_ADDRESS etc.) helps, I'm fine with doing that. The main reason for passing an empty environment was to ensure that this does not use any localization.

Changed in alsa-plugins (Ubuntu):
status: Confirmed → Invalid
Martin Pitt (pitti) wrote :
Changed in ubuntu-drivers-common (Ubuntu):
status: New → Fix Committed
assignee: nobody → Martin Pitt (pitti)
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package ubuntu-drivers-common - 1:0.2.97

---------------
ubuntu-drivers-common (1:0.2.97) utopic; urgency=medium

  * tests/testarchive.py: Organize debs in pool/ structure, for better
    reusability.
  * tests/ubuntu_drivers.py: Drop expected failures, they've succeeded for a
    long time. This needs to be fixed properly if there's a bug.
  * sl-modem plugin: Keep environment for aplay, just ensure it's using the C
    locale. (LP: #1296425)
  * Disable linux-firmware-nonfree autopkgtest for now. bcma does not declare
    any firmware dependencies and linux-firmware-nonfree does not declare
    modaliases, so it either just works now, or the driver needs fixing first.
 -- Martin Pitt <email address hidden> Mon, 18 Aug 2014 10:13:11 +0200

Changed in ubuntu-drivers-common (Ubuntu):
status: Fix Committed → Fix Released
juanmanuel (rockerito99) wrote :

To Martin Pitt: Thank you very much for the fix. I manually applied that commit to my sl_modem.py and it of course works. Restarting the computer, or running "ubuntu-drivers list" doesn't result in a second instance of pulseaudio.

Also, the duplicate bug:

        "USB microphone inputs not detected by Pulseaudio...."
        https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/1325282

is of course fixed for me too with that fix
(the two pulseaudio instances raced each other for opening the "/dev/snd/..." devices).

Thanks!

Cheers!
Juan Manuel Cabo

On Mon, Aug 18, 2014 at 04:26:16PM AEST, Martin Pitt wrote:
> I don't know why aplay invokes pulseaudio (that seems wrong, as
> pulseaudio usually uses ALSA as a backend), but if passing on the
> environment (for DBUS_SESSION_BUS_ADDRESS etc.) helps, I'm fine with
> doing that. The main reason for passing an empty environment was to
> ensure that this does not use any localization.

Aplay invokes pulseaudio because if you have pulseaudio installed, ALSA is configured to send its audio via pulseaudio, so you can get individual volume control for ALSA apps. Since pulseaudio is not running, pulseaudio gets spawned. An alternative way to solve this would have been to set the environment variable PULSE_INTERNAL to 0.

David Henningsson (diwic) wrote :

Thanks jaunmanuel for finding the fix and sharing the knowledge about how you found it.
I'll add "redirecting 'aplay' temporarily to a script" to my list of debugging techniques :-)

juanmanuel (rockerito99) wrote :

> Thanks jaunmanuel for finding the fix and sharing the knowledge
> about how you found it.
> I'll add "redirecting 'aplay' temporarily to a script" to my list of
> debugging techniques :-)

:-) Nice to hear!
Juan Manuel Cabo

Sergey Tryuber (stryuber) wrote :

Fix from #22 helped me (Kubuntu 14.04 upgraded from 12.04). Thanks, guys!

frausch (rauscher) wrote :

Hi,

can this be backported to the 1:0.2.91.x-branch (the one in ubuntu 14.04).

Thanks!

Felix

Alberto Milone, could you add the updated version of this package to 14.04 backport the fix?

Changed in alsa-plugins (Ubuntu Trusty):
status: New → Invalid
Changed in ubuntu-drivers-common (Ubuntu Trusty):
status: New → Triaged
importance: Undecided → High

I tried applying the patch in comment 22 to my 14.04 installation (3.13.0-39-generic, upgraded from 12.04) and rebooting, but it didn't solve the problem with my Logitec webcam microphone. I still get the same error.

ubuntu-drivers-common 1:0.2.91.7 is the currently installed version.

Are they any other scripts that might be doing the same thing?

Forgot to mention I am using Gnome3 shell, not Unity or KDE.

Martin Pitt (pitti) wrote :

Backported fix uploaded to trusty SRU review queue: https://launchpad.net/ubuntu/trusty/+queue?queue_state=1

Now the SRU team needs to review and accept this, then testing the -proposed package would be much appreciated!

description: updated
Changed in ubuntu-drivers-common (Ubuntu Trusty):
status: Triaged → In Progress
Chris J Arges (arges) wrote :

This can be accepted once bug 1376966 is verified. Thanks

description: updated

I can confirm that the fix as in proposed works as intended.

Changed in ubuntu-drivers-common (Ubuntu Trusty):
status: In Progress → Fix Committed
tags: added: verification-done
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package ubuntu-drivers-common - 1:0.2.91.9

---------------
ubuntu-drivers-common (1:0.2.91.9) trusty-proposed; urgency=medium

  * sl-modem plugin: Keep environment for aplay, just ensure it's using the C
    locale. This avoids staring pulseaudio twice and causing races for
    attaching devices to pulseaudio. (LP: #1296425)

ubuntu-drivers-common (1:0.2.91.8) trusty-proposed; urgency=medium

  * gpu-manager.c:
    - Refine checks for blacklisted modules, so that we don't end up
      catching false positives (LP: #1376966).
      Thanks to Pär Lindfors for the patch.
 -- Martin Pitt <email address hidden> Mon, 05 Jan 2015 17:27:53 +0100

Changed in ubuntu-drivers-common (Ubuntu Trusty):
status: Fix Committed → Fix Released

The verification of the Stable Release Update for ubuntu-drivers-common has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers