I guess I was mistaken about commenting out "load-module module-
bluetooth-policy" and "load-module module-bluetooth-discover", that did
not solve the problem for me.


A successful workaround though was to "sudo rm 
/xdg/autostart/pulseaudio.desktop" which stops gnome-session from trying to 
start start-pulseaudio-x11 (and block until it signals completion of startup, 
which takes about 30 seconds).

Even without /xdg/autostart/pulseaudio.desktop pulse is being spawned by
something, as can be seen from "pgrep pulse", and I can play sounds
fine.

I am *not* recommending this as a general solution for everyone as I do
not know what ramifications there might be to not having
/xdg/autostart/pulseaudio.desktop that I just might not have noticed. I
assume that it is there for a reason.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to pulseaudio in Ubuntu.
https://bugs.launchpad.net/bugs/1596344

Title:
  pulseaudio causes long login delay waiting for bluetooth

Status in pulseaudio package in Ubuntu:
  Confirmed

Bug description:
  Kubuntu 16.04 --

  I was experiencing a long delay when logging in, on the order of 20+
  seconds. After entering the password on the splash screen, it would
  stay there before showing the desktop.

  journalctl revealed a timeout form pulseaudio waiting for a bluetooth
  service (I don't not use bluetooth, and it is disabled, but I believe
  I saw this even when I enabled it?)

  Jun 26 10:43:42 machinename org.kde.KScreen[1988]: kscreen: Primary output 
changed from KScreen::Output(Id: 68 , Name: "HDMI1" ) ( "HDMI1" ) to 
KScreen::Output(Id: 68 , Name: "HDMI1" ) ( "HDMI1" )
  Jun 26 10:44:02 machinename dbus[982]: [system] Failed to activate service 
'org.bluez': timed out
  Jun 26 10:44:02 machinename pulseaudio[2121]: [pulseaudio] bluez5-util.c: 
GetManagedObjects() failed: org.freedesktop.DBus.Error.NoReply: Did not receive 
a reply. Possible causes include: the remote application did not send a reply, 
the message bus security policy blocked the reply, the reply timeout expired, 
or the network connection was broken.

  I can fix the problem by editing /etc/pulse/default.pa and commenting
  out both bluetooth lines ("load-module module-bluetooth-policy" and
  "load-module module-bluetooth-discover" -- not sure if both are
  actually necessary.)

  I have seen other bugs relating to blocking calls to bluetooth causing
  problems. Perhaps there are a few left.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/1596344/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to     : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

Reply via email to