Bug 90490 - module-bluetooth-discover works only if started after the X11 session is up
Summary: module-bluetooth-discover works only if started after the X11 session is up
Status: RESOLVED MOVED
Alias: None
Product: PulseAudio
Classification: Unclassified
Component: modules (show other bugs)
Version: unspecified
Hardware: All Linux (All)
: medium major
Assignee: pulseaudio-bugs
QA Contact: pulseaudio-bugs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-05-17 06:58 UTC by Britt Yazel
Modified: 2018-07-30 10:35 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Attachments
pulse.log of the described issue (272.45 KB, text/plain)
2015-09-19 23:23 UTC, Dor
Details
journalctl snippet (3.13 KB, text/plain)
2015-09-20 08:30 UTC, Dor
Details
pulse.log which includes establishing a connection (397.00 KB, text/plain)
2015-09-20 08:34 UTC, Dor
Details

Description Britt Yazel 2015-05-17 06:58:21 UTC
Pulseaudio has an issue in that module-bluetooth-discover works only if started after the X11 session is up.

This issue is prevalent for me with bluetooth headsets in that they only work with hsa profiles with aweful sound and in mono, as a2dp does not load, and trying to load it manually results in an error.

There is a workaround that I restated in this post:
https://bbs.archlinux.org/viewtopic.php?id=197482

I do not know if this is a new bug, or Gnome specific, as I just discovered it today as I just got my first bluetooth headset. I do have this issue on both my intel based laptop and my amd based desktop though, and the workaround worked for each.
Comment 1 Britt Yazel 2015-05-17 19:27:05 UTC
I believe this issue is actually localized to the Gnome-Desktop, perhaps with their changes to gdm and wayland. Either way, I hope that both projects can come to a resolution.

https://bugzilla.gnome.org/show_bug.cgi?id=749208
Comment 2 Tanu Kaskinen 2015-05-27 10:11:03 UTC
This sounds pretty weird. It shouldn't matter when module-bluetooth-discover is loaded.

The available profiles depend on which profiles get connected. Gnome is responsible for connecting the profiles, but I don't know why Gnome would behave differently depending on whether module-bluetooth-discover is loaded in PulseAudio or not.

Could you revert your workaround, and attach a PulseAudio log of the failing case?

Instructions for getting the log:

Put these lines to ~/.config/pulse/daemon.conf (remember to fix the home directory path):

log-target = newfile:/home/you/pulse.log
log-level = debug
log-time = yes

Then reboot. There should now be a log file named "pulse.log" in your home directory. There may also be files named "pulse.log.N" (N being a number). Attach the last one of those.

For comparison, you could also re-apply your workaround, reboot, and attach again the newest log file.
Comment 3 Britt Yazel 2015-05-29 04:04:29 UTC
so funny thing, there is no pulse.log file being output. And yes I got the path right :-p

I don't think the daemon.conf file is being read and executed.
Comment 4 Britt Yazel 2015-05-29 04:04:30 UTC
so funny thing, there is no pulse.log file being output. And yes I got the path right :-p

I don't think the daemon.conf file is being read and executed.
Comment 5 Britt Yazel 2015-05-29 04:20:06 UTC
Ok I tried for a third time, and there is no log being output.

log-target = newfile:/home/britt/pulse.log
log-level = debug
log-time = yes

Likewise I put the above lines in /etc/pulse/daemon.conf at the bottom of the file, and I still had no log file output. This seems weird to me.

Perhaps the bug is actually to do with Gnome not executing pulseaudio commands properly as it starts the service? Or perhaps gnome is getting in the way of pulseaudio somehow?
Comment 6 Tanu Kaskinen 2015-05-30 10:11:42 UTC
I think the problem is that when pulseaudio is autospawned, one of the command line parameters is --log-target=syslog, which overrides the configuration file.

Does it help if you put this line to client.conf:

extra-arguments =

That is, leave it empty. The default value of that option is "--log-target=syslog", which is not nice in this case.
Comment 7 Dor 2015-09-19 23:23:24 UTC
Created attachment 118365 [details]
pulse.log of the described issue

I also experience this issue. I run an up-to-date Arch Linux system with GDM 3.16.3, pulseaudio 6.0 and bluez 5.34.


I've added this line to /etc/pulse/client.conf:

extra-arguments = --log-target=newfile:/home/dor/pulse.log


I also added these two lines to /etc/pulse/daemon.conf:

log-level = debug
log-time = yes


Attached is pulse.log, which was generated after a reboot was performed. Let me know if anything else is needed.
Comment 8 Tanu Kaskinen 2015-09-20 06:14:49 UTC
Dor, the log shows that there are no profiles connected. Does Gnome show the device as connected?
Comment 9 Dor 2015-09-20 08:30:20 UTC
Created attachment 118369 [details]
journalctl snippet

I guess the the bug report is missing some information.

The issue appears to be that while devices can be discovered, paired and connected, audio doesn't play on the host device at all.

Attached is a snippet from journalctl. I tried to include all of the related lines.
Comment 10 Dor 2015-09-20 08:34:16 UTC
Created attachment 118370 [details]
pulse.log which includes establishing a connection

Attached is pulse.log which includes establishing a connection.
Comment 11 Tanu Kaskinen 2015-09-20 09:15:08 UTC
What are you trying to do? The log shows that you connected a phone, not a headset as in the original report. If your problem is not about headsets, I think it's better to open a new bug report.
Comment 12 Dor 2015-09-20 10:03:52 UTC
Sorry, my mistake. You're right, I'm trying to use the PC as an audio sink, not as an audio source.

However, for what's it worth, the errors that appear in journalctl appear regardless of setting up the PC as a sink or as a source, since they appear at boot time and before any bluetooth device is connected. Looking up the symptoms online, I'm getting the feeling that the root issue is shared between the two.
Comment 13 Tanu Kaskinen 2015-09-20 11:09:37 UTC
In any case your description doesn't sound like the same problem that the original reporter had. The original reporter wasn't able to use a2dp with a headset without a strange workaround, but hsp worked fine. In your case I've seen that using a2dp with a phone works at least for a few seconds, but I don't know what problems (if any) you're having with headsets.

Regarding the journal log, I'm not familiar enough with bluetoothd to decipher the error messages. But at least the errors don't entirely prevent a2dp streaming. Your PulseAudio log shows that there's some audio moving for a few seconds. I don't know why the streaming stops after a few seconds - either you stopped playback on the phone yourself, or the phone just decided to stop the streaming for some reason.
Comment 14 GitLab Migration User 2018-07-30 10:35:20 UTC
-- 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/pulseaudio/issues/520.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.